What is the difference between RAG and fine-tuning?
RAG injects relevant external passages into the prompt at query time so the model answers from current or proprietary data it was never trained on, whereas fine-tuning changes the model's weights on a curated dataset to adapt its task behaviour, format, or style. RAG is the right tool when the requirement is fresh or private knowledge and citations, because you can update the corpus without retraining. Fine-tuning is the right tool when you need consistent format, tone, or behaviour on a narrow task that prompting alone cannot reach. They are complementary: many production systems fine-tune for behaviour and use RAG for knowledge, and you should exhaust prompt engineering before reaching for either.
How do I reduce hallucinations in an LLM application?
Hallucinations are reduced by grounding the model in retrieved context and instructing it to answer only from that context, to cite the passages it uses, and to say it does not know when the context is insufficient. Improve retrieval first, because the generator cannot use evidence the retriever never surfaces; add re-ranking and hybrid search to raise precision. Then enforce abstention in the system prompt and measure faithfulness with an LLM-as-judge against the supplied context so you can drive the hallucination rate down release over release. No single trick eliminates hallucination; it is a layered problem of retrieval, prompting, and evaluation.
What chunk size should I use for RAG?
There is no universal best chunk size; it depends on your documents and queries, so you should measure it on your own eval set rather than copy a number. As a starting point, passages of roughly 300 to 600 characters (a few sentences) with a small overlap work well for question answering, because chunks that are too large dilute relevance and waste tokens while chunks that are too small lose the context needed to answer. Structure-aware splitting by headings or paragraphs usually beats blind fixed-size windows. Tune chunk size and overlap by watching retrieval recall and answer faithfulness, not by intuition.
How do I evaluate a RAG system?
Build a golden eval set of representative questions paired with reference answers and the grounding passages that support them, then score each generated answer for faithfulness (is it supported by the retrieved context?), answer relevancy (does it address the question?), and context recall (did retrieval surface the needed evidence?). Frameworks such as RAGAS, promptfoo, and DeepEval automate these metrics, often using an LLM as judge. Gate releases on a faithfulness floor and treat the eval set as immutable so the measurement stays honest. Evaluate retrieval and generation separately, because a weak retriever caps answer quality no matter how good the generator is.
When should I use an agent instead of a fixed workflow?
Use the simplest pattern that solves the problem: a single prompt, then a fixed workflow (prompt chaining, routing, parallelisation), and only an autonomous agent when the task genuinely requires the model to decide its own steps at runtime. Agents add flexibility for open-ended tasks but cost more in tokens and latency and are harder to make reliable, because control flow is delegated to a non-deterministic model. If you can express the task as a predictable sequence of steps, a workflow will be cheaper, faster, and easier to debug. Reserve agents for cases where the path cannot be known in advance.
How can I control the cost of an LLM feature?
The largest levers are routing easy requests to a smaller, cheaper model and reserving the strongest model for hard ones; using prompt caching for stable prefixes like long system prompts or documents; and keeping outputs short, since generation is the dominant cost. Trim retrieved context with re-ranking instead of stuffing the window, and cache full responses for repeated identical queries. Measure cost per request end to end, not just per token, because embeddings, vector search, and re-ranking add up. Total cost of ownership is won by model routing, caching, and disciplined context size far more than by haggling over per-token price.
What is prompt injection and how do I defend against it?
Prompt injection is an attack where untrusted input - user text, a retrieved document, or a tool result - carries instructions that override your system prompt and hijack the model's behaviour; indirect injection hides those instructions inside content the model reads. There is no perfect defence, so use defence in depth: keep trusted instructions clearly separated from untrusted data, give tools the least privilege they need, validate and constrain every tool call and output, and never execute model output (SQL, shell, code, payments) without an independent check. Treat anything the model reads as potentially adversarial. Monitoring and a separate guard model add further layers.
Should I run open-source models or use a hosted API?
Hosted APIs (Claude, GPT, Gemini) give you the strongest models with no infrastructure to manage and are usually the fastest path to a working feature, at a per-token cost and with data leaving your perimeter. Self-hosting open-weight models (Llama, Mistral, Qwen) keeps data on-premises and can be cheaper at high, steady volume, but you own the GPU capacity, scaling, and quality gap. The decision turns on privacy requirements, sustained volume, the quality your task actually needs, and your team's operational maturity. Many teams prototype on an API and self-host later only where privacy or cost clearly justifies it.
What is the difference between embeddings and a vector database?
An embedding is the dense numeric vector that represents the meaning of a piece of text, produced by an embedding model; a vector database is the system that stores those vectors and performs fast approximate nearest-neighbour search over them, usually with metadata filtering. You generate embeddings once at ingestion time and at query time, and the vector database is what makes retrieving the closest ones fast at scale. Choosing an embedding model affects retrieval quality; choosing a vector store affects scale, cost, filtering, and operations. They are distinct decisions and both matter for RAG.
How do I keep my RAG corpus from going stale?
Treat the corpus as a living index: track when each chunk was retrieved or ingested, re-embed and re-index when source documents change, and remove or supersede outdated content rather than letting it compete with current information. Drift - corpus staleness, shifting user intent, and silent provider model updates - degrades quality quietly, so monitor answer faithfulness against a fixed eval set to catch it before users do. Version your content so a correction creates a new version instead of mutating history. Scheduled re-indexing plus continuous evaluation is how production RAG stays accurate over time.
What temperature should I set for production?
For factual answering, structured output, extraction, and tool calling, use a low temperature (often 0 to 0.3) because you want consistent, focused, repeatable output; higher temperatures add diversity that helps brainstorming but hurts reliability. Temperature changes only the randomness of token sampling, not the model's correctness, so it is not a quality dial - it is a determinism dial. Pair low temperature with grounding and validation for tasks where the answer must be right. For creative generation, raise it deliberately and accept the variability.
How should I handle structured output from a model?
Define the desired shape explicitly - via a tool/function schema, JSON mode, or constrained decoding - and then validate the model's output against that schema in code rather than trusting it to comply. Models occasionally emit malformed or schema-violating JSON, so parse defensively, and retry or repair on failure. Keep schemas as small and unambiguous as the task allows, because over-large schemas raise error rates. Reliable structured output is the combination of a clear schema, a model feature that constrains generation, and a programmatic validator on the boundary.
What metrics should I monitor for an LLM system in production?
Monitor latency (time-to-first-token and total, at p50/p95/p99), token usage and cost per request, error and rate-limit (429) rates, and quality signals such as faithfulness sampled by an LLM-as-judge, plus user feedback like thumbs and regenerations. Capture per-request traces with the full prompt, retrieved context, tool calls, and output, because the same input can yield different outputs and you cannot debug what you did not record. Watch for drift by re-running a fixed eval set on a schedule. Observability for non-deterministic systems is built on complete tracing, not just aggregate counters.
Why does my RAG system retrieve the wrong passages?
The most common causes are chunks that are too large or too small, an embedding model poorly matched to your domain, missing lexical signal for exact terms and rare tokens, and the absence of re-ranking so noisy candidates stay near the top. Diagnose by inspecting the actual retrieved passages for failing eval questions rather than guessing. Add hybrid search to combine keyword and vector recall, add a cross-encoder re-ranker to improve precision, and re-tune chunking. Retrieval quality sets a hard ceiling on answer quality, so fix it before blaming the generator.
How do I make agent tool calls safe and reliable?
Constrain the action space to the minimum set of tools the task needs, give each tool the least privilege required, and validate every argument the model proposes before executing it - never run model-generated SQL, shell, or code without checks. Cap the number of iterations so an agent cannot loop forever, and make side-effecting actions idempotent (for example with an idempotency key) because non-deterministic agents and retries can issue the same call more than once. Log every tool call and its result for observability. Reliable agents come from tight scoping, strict validation, and bounded loops, not from a cleverer prompt alone.
What is the Model Context Protocol and why does it matter?
The Model Context Protocol (MCP) is an open standard introduced by Anthropic that defines how applications expose tools, resources, and prompts to LLM clients through one common interface, so an agent can connect to many data sources and tools without bespoke per-integration code. A server advertises its capabilities and a client - an IDE, chat app, or agent runtime - discovers and invokes them. It matters because it standardises the integration layer that every agent needs, reducing custom glue and making tools reusable across applications. It is becoming a common way to wire context and actions into LLM systems.