RAG frente a fine-tuning: cuándo usar cada uno

When you need an LLM to work well on your specific domain, you have two main strategies: Retrieval-Augmented Generation (RAG) dynamically injects relevant knowledge at inference time, while fine-tuning updates the model's weights to bake in knowledge, style, or format preferences. Choosing between them correctly can mean the difference between a reliable system and months of expensive GPU compute wasted on the wrong approach.

Fine-tuning updates the model's weights by training on example input-output pairs. It excels at changing behavior: teaching a model to always respond in a specific JSON format, adopt a brand voice, follow domain-specific reasoning patterns, or perform a task type it was not optimized for. Fine-tuning does not reliably update factual knowledge — models can overfit on training examples without generalizing the underlying facts to new queries.

RAG does not modify model weights. Instead, it changes the information available to the model at inference time by placing relevant documents in the context window. RAG excels at knowledge: answering questions about private documents, keeping answers current with frequently updated data, and grounding responses in verifiable sources. What RAG does not easily change is the model's inherent style, format preferences, or reasoning approach.

For any use case where information changes over time, RAG is clearly superior. Re-indexing a vector store when documents update takes minutes and requires no GPU resources. Fine-tuning a model on new data requires retraining (expensive and slow), and even then the model may not reliably recall the new facts. Product catalogs, legal regulations, medical guidelines, and company policies are all better served by RAG than fine-tuning.

If you need the model to always respond in a very specific style, tone, or structured format that prompt engineering alone cannot reliably enforce, fine-tuning is the right tool. Examples: a customer service bot that must always use your brand's specific vocabulary, a code generator that must produce code matching your company's internal style guide, or a classification model that must output a rigid taxonomy reliably across thousands of edge cases.

Fine-tuning has high upfront cost (compute for training, dataset preparation time, evaluation) but reduces per-query cost if fine-tuning enables you to use a smaller model. RAG has low upfront cost (vector database indexing is cheap) but adds per-query overhead: an embedding API call plus slightly longer prompts with injected context. For most applications under 10M daily queries, RAG's per-query overhead is negligible compared to fine-tuning's development cost.

Fine-tuned models can be faster at inference because shorter prompts are needed — the knowledge is in the weights, not the context. RAG adds two round-trips: an embedding API call and a vector search query. Total overhead is typically 50-200ms. For latency-sensitive applications like real-time voice assistants, this overhead matters. For most chat and Q&A applications, the additional latency is imperceptible to users.

RAG provides a clear audit trail: for every answer, you know exactly which documents were retrieved and can show them to the user. Fine-tuned models answer from opaque weights — there is no record of which training example produced a given output. In regulated industries like finance, healthcare, and law, where answers must be explainable and verifiable, RAG's transparency is a significant advantage over fine-tuning.

RAG and fine-tuning are not mutually exclusive. A common production pattern is: fine-tune a model for consistent output format and domain vocabulary, then add RAG on top to supply current factual knowledge. The fine-tuned model handles the style and structure reliably, while RAG handles the knowledge. This combination outperforms either approach alone for high-stakes enterprise applications.

Follow this decision path: Is the problem about style or format consistency? → Consider fine-tuning. Is the information private or frequently updated? → Use RAG. Do you need source citations? → Use RAG. Is the dataset too small for fine-tuning (under 500 examples)? → Use RAG with few-shot prompting. Do you need the model to handle a task it currently refuses to do? → Fine-tune with RLHF or DPO. When uncertain, start with RAG — it is faster to build, easier to update, and more transparent.

Use these scenarios to build intuition: Internal HR chatbot (policies change quarterly, must cite sources) → RAG. Code completion for a proprietary framework (consistent code style, framework patterns) → Fine-tuning. Legal document Q&A (private documents, precise citation needed) → RAG. Customer support bot (specific tone, product FAQ changes weekly) → Fine-tuning for tone + RAG for knowledge. Medical literature summarizer (current research, attribution critical) → RAG.

Test your understanding of AI Engineering concepts from this lesson.

In this lesson you learned: fine-tuning changes model behavior and style but not reliably factual knowledge, RAG dynamically supplies knowledge at inference time with full transparency and source citation, and the decision framework for choosing — use RAG for frequently updated private knowledge requiring attribution, use fine-tuning for consistent style and format, and combine both for high-stakes enterprise applications. Next up we start building a complete RAG pipeline from scratch.