AI & Machine Learning Topic
Build a Useful AI App: Models, Prompts, Tools and Clear Limits
Start with a small job: explain a lesson, summarise an approved note or extract a few fields. A useful AI app is more than a model call. It also checks input, handles failure and helps people understand the result.
What a language model does
A large language model, or LLM, generates output from its input and learned patterns. It can produce fluent text that is wrong. It does not automatically know your private documents or the latest change in your app.
The application decides what context to send, which tools are available and what happens with the output. A model request to use a tool is not permission to carry out every action it suggests.
Choose a model by testing the task
Compare quality, response time, cost, data handling and the features you need. Test examples that resemble the actual task. No provider or model is best for every app. Model names, availability and limits change, so use the provider's current documentation and an accessible model ID.
Hosted APIs run a model through a provider. Running model weights yourself gives a different operating setup and still needs hardware, maintenance and licence review. Open weights do not automatically mean unrestricted use or a free deployment.
Design one small request
Task: Explain the supplied lesson note for a beginner.
Audience: A person learning Python for the first time.
Use short, common sentences.
Keep the answer under 80 words.
Do not add facts that are absent from the note.
If the note is missing, ask for it.
Lesson note: A Python list stores items in order.This gives a task, audience, context and output limit. It improves clarity, but it cannot guarantee factual accuracy. Check the answer against the note. For a real app, separate application instructions from untrusted user and document text using the provider's supported message structure.
Know three ways to extend an app
- RAG: retrieve relevant information and include it as context for an answer.
- Tool calling: let the model request a defined operation that your app validates and runs.
- Fine-tuning: train from examples to change model behaviour for a suitable task.
These are not interchangeable. A new timetable usually belongs in a data source, not in model training. A booking action needs server-side access checks. A consistent writing style may be addressed by a good prompt before considering fine-tuning.
Keep the API on the server
Do not put a provider key in browser JavaScript. Send a request to your own backend, check the user's access and input size, then call the provider from there. Do not send private material unless your policy and the provider terms allow it.
Set a timeout and bounded retries for appropriate transient failures. A quota or billing error may need a person to act; endless retries make it worse. Log a useful request identifier and error type without exposing keys or private prompts.
Test before adding more features
Keep a small fixed set of normal, unclear and difficult inputs. Check factual support, format, refusals or missing-information behaviour, latency and cost. Save the model identifier, prompt version and relevant settings. Re-run the set after a change.
For JSON output, use supported structured-output features when available and validate the result in your app. Valid JSON can still contain a wrong value. A model grading itself is a useful signal at most, not independent proof.
Practice
Write ten invented lesson notes, including one blank and one with conflicting facts. Define the expected behaviour before asking a model. Then use the API integration guide, RAG lesson or tool-calling project for the implementation you actually need.
Official references
Reviewed on 25 October 2026. Use documentation for your installed versions.
Comments (0)
No comments yet. Be the first to comment!