DEV Community: Victor Lopes

RAG vs. Fine-Tuning: The Wrong Question to Ask When Building AI Systems

Victor Lopes — Sat, 10 Oct 2026 16:52:32 +0000

A platform team is evaluating an LLM-based assistant, still in testing, meant to answer developers' architecture questions using the company's ADRs (Architecture Decision Records) and internal documentation. During an evaluation round, the team itself notices that the assistant recommended a service-to-service authentication pattern the company abandoned last year and, on top of that, suggested calling an endpoint on an internal API already marked as deprecated. The answer was plausible, well written, and technically defensible in general terms. It just contradicted a standing decision.

The failure was caught before it reached any user, and that is exactly why the conversation that follows matters. Two proposals land on the table. The first: "We need to fine-tune on our ADRs, so the model learns our decisions." The second: "We need RAG over the ADRs, so it can look up the standing decision." Both are reasonable, and each starts from a theory about what the model is missing: one assumes it needs to learn the content, the other that it needs to consult the content. But there is a prior question that neither one answers: what, exactly, went wrong in that answer?

That question matters more than it seems, because the same outdated recommendation can have very different origins. The ADR that superseded the old pattern may never have been indexed. The old ADR, marked "superseded," may have been retrieved instead of the new one. Both may have been retrieved and the model ignored the context, answering from what it learned about the pattern in public documentation. Or the question may have been generic and the system instruction never asked it to prioritize the standing decision. Each cause calls for a different fix, and none of them is resolved, on its own, by whichever technique won the argument. Fine-tuning on today's ADRs, for example, does not help when the decision is superseded tomorrow. This is not unique to our scenario: an engineering report on RAG systems identified seven distinct failure points when building this kind of system.

To understand how we got to this debate, it helps to recall the context. Since ChatGPT arrived in late 2022, organizations have been trying to put LLMs in front of what used to live in wikis, shared folders, and operational documents, with the promise of making that knowledge more accessible to whoever needs it. Along the way, two techniques that were research topics became everyday vocabulary: retrieval-augmented generation (RAG), proposed by Lewis et al. in 2020, and fine-tuning, which parameter-efficient methods like LoRA made far cheaper to run. When two powerful tools arrive together and address the same apparent "pain," it is natural for the market to put them head to head. That is how the standard framing was born: RAG or fine-tuning?

The problem with that framing is that it asks you to pick the answer before agreeing on the question. There is research comparing the two approaches side by side, and it deserves a careful reading, not a slogan. OpenAI's guide on optimizing accuracy, for instance, treats them as answers to different problems and as approaches that are "additive, not exclusive." The question, therefore, should not start from the technique. It should start from the failure.

Figure 1. The difference between the two conversations is not the technique chosen, but the step that was skipped.

This article argues for that inversion and proposes a practical way to make it, separating what a system needs to know, how it needs to behave, and what it needs to do. It is the first step in a series about the decisions that happen beyond the model, where an AI system either becomes reliable or stops being so.

1. The problem

Back to the architecture assistant. The two proposals on the table have something in common: both start from a technique and only then look for the problem it would solve. It is a subtle inversion, because the conversation sounds technical and mature. But engineering's usual path is the opposite: observe the symptom, form a hypothesis about the cause, test it, and only then intervene. In LLM-based systems, diagnosis tends to be the easiest step to skip.

Why is it skipped? From my own observation, we can think of several reasons, but three seem the most plausible. First, techniques are tangible: they have tools, tutorials, budget, and a name that fits on a roadmap. Second, diagnosing is work: it requires opening the traces, separating what was retrieved from what was generated, reproducing the failure, and understanding at which stage it originated. Third, "RAG or fine-tuning?" is a question you can answer with an opinion, while "what caused this failure?" can only be answered with evidence.

The cost of choosing the technique before the diagnosis shows up in at least three ways.

The original failure is still there. If the problem was the old ADR being retrieved instead of the new one, training the model on the ADRs changes nothing: the wrong content still reaches the context. If the problem was the model ignoring the retrieved context, retrieving more context does not solve it either. The intervention ships, the team considers the problem solved, and the outdated recommendation shows up again in the next evaluation round.

The intervention can make the system worse. OpenAI's own guide on optimizing accuracy includes an example where RAG "confused" the model by adding noise and lowered the score by four points. On the fine-tuning side, a controlled study of question answering without external lookup showed that examples containing new knowledge are learned more slowly and, once learned, increase the model's tendency to hallucinate. That result holds for that specific setting and should not be extended to all fine-tuning. Still, it shows that "one more technique" is not a risk-free bet.

The complexity becomes yours. Each technique brings a new maintenance surface. RAG requires indexing, updating, ranking, and permission control. Fine-tuning requires training data, versioning, re-evaluation on every base-model change, and a plan for when the content changes. If the real cause was an ambiguous instruction, the team paid that cost to solve something a prompt adjustment would have fixed. Not by coincidence, that same OpenAI guide recommends starting with prompt engineering.

None of this means either technique is the villain. The evidence is mixed, and that is part of the problem. In direct comparisons of knowledge injection, RAG outperformed unsupervised fine-tuning, both for previously seen knowledge and for new knowledge (Ovadia et al., 2023). A more recent study, on multi-hop questions over novel knowledge, found the highest overall accuracy with supervised fine-tuning. Both are preprints, with small or synthetic benchmarks, and neither answers our team's question. They show that each technique has its own territory, and that finding out which territory the failure sits in is precisely the work the question "RAG or fine-tuning?" skips. We return to these studies, in more detail, in section 5.

2. The engineering hypothesis

If the problem is starting from the technique, the alternative needs to be something testable, not just a preference for a method. I propose the following working hypothesis:

H1. A large share of the observable failures in an assistant like ours can be attributed to one of three categories, knowledge, behavior, or execution, and each category responds better to a different intervention.

This is a hypothesis, not a result. It was not tested for this article. To test it, a team could collect the failures from an evaluation round, ask independent reviewers to classify each one, and measure the agreement between them. Next, they would apply the intervention indicated for each category and compare the outcome against the alternative. The hypothesis weakens if inter-reviewer agreement is low, if most failures do not fit the three categories, or if all of them call for the same intervention. Upcoming articles in the series return to this experimental design.

There is, however, a refinement our scenario suggests, and one that usually stays out of the discussion. Back to the superseded ADR. In his original text on the format, Michael Nygard recommends that reversed decisions not be deleted: they stay on record and are marked "superseded," because "it is still relevant to know that it was the decision, but is no longer the decision" (Documenting Architecture Decisions). In other words, a healthy ADR repository contains, by design, obsolete knowledge. What distinguishes the standing from the obsolete is the status, the date, and the relationship between records, not the text itself. A model that only sees the text has no way to know.

That leads to a second hypothesis, complementary to the first:

H2. Part of the failures classified as "knowledge" are not a lack of knowledge. They are curation failures: the right information exists, but the way the corpus is organized does not allow telling the standing from the obsolete, and no technique applied to the model fixes that.

If H2 is true, the first question in the face of a knowledge failure stops being "RAG or fine-tuning?" and becomes "is the corpus in a condition to be consulted?". Curation, in this sense, is a set of engineering decisions about knowledge, prior to any decision about the model. Four forms, in increasing order of cost:

Form of curation	What it addresses in our scenario	Cost and risk
Metadata and lifecycle	Status (proposed, accepted, deprecated, superseded), date, owner, and a reference to the record that supersedes it; filtering on that information at retrieval time	Low. Requires discipline in filling and updating
Canonical source and deduplication	Guarantees a single source of truth per decision, instead of diverging copies across wikis and folders	Medium. Requires an owner and a review process
Explicit relationships	Records that ADR 31 supersedes ADR 12 and that a pattern applies to a set of services	Medium to high. Requires modelling the domain
Ontology and knowledge graph	Represents concepts (decision, pattern, API, service) and relationships in a queryable, verifiable way	High. Requires modelling, construction, and continuous maintenance

The last two items deserve a comment, because they enter ontology territory. Gruber's classic definition describes an ontology as a formal specification of a conceptualization, that is, an explicit agreement about which concepts exist in a domain and how they relate. In our case, that would mean declaring that "Decision," "Pattern," "API," and "Service" are kinds of thing, and that "supersedes," "depends on," and "applies to" are relationships between them. With that, the question "what is the standing decision for service-to-service authentication?" stops being a text-similarity search and becomes a query with a verifiable answer.

The literature on combining LLMs with knowledge graphs points to both the potential and the cost. Pan et al. argue that knowledge graphs store factual knowledge explicitly and can help LLMs with external information and interpretability, and that the two are complementary. The same authors note that these graphs are hard to build and are constantly evolving. On the practical side, GraphRAG proposes using an LLM to derive an entity graph from the documents and, with it, answer questions about the entire corpus, which conventional RAG struggles with. The authors report improvements in comprehensiveness and diversity of answers on datasets of around one million tokens. One caveat: GraphRAG was designed for global summarization questions, not for the problem of resolving which decision is standing. It shows that giving structure to the corpus can help, but it does not demonstrate that it solves our case. That remains a hypothesis to test.

In short, the article's question gains two layers. The first is H1's: which category is the failure in? The second is H2's: if it is knowledge, is the corpus curated well enough to be used? Only after those two answers does it make sense to discuss RAG, fine-tuning, or tools.

3. Three axes: knowledge, behavior, task execution

If H1 is to be useful, it needs categories a team can apply to a real failure without relying on interpretation. I propose three axes, each defined by a question you can ask of the system.

Figure 2. Each kind of failure points to a different capability.

Knowledge: does the model have access to the right information?

This is the axis of the outdated recommendation. The typical symptom is an answer citing a decision that does not exist, has expired, or has been superseded. The diagnostic test is simple: if we manually place the standing ADR in the context, does the model get it right? If it does, the problem is not the model's capability but access to information, and the conversation shifts to retrieval and curation (H2). This is the territory OpenAI's guide assigns to context optimization: the case where the model lacks knowledge because it was not in the training data. The natural intervention is RAG, with the caveat that it has several failure points of its own, from indexing to generation.

Behavior: given the information, does the model use it the expected way?

Here the model has the right ADR in context and still answers poorly. It does not follow the format the team requires, does not cite the decision's status, mixes recommendation with opinion, or loses the expected structure in long answers. The diagnostic test changes: with correct context and a clear instruction, does the formatting error persist consistently? If it does, and only after exhausting instructions and examples, fine-tuning becomes a candidate. That same OpenAI guide associates it with inconsistent or incorrectly formatted results. There is conceptual support for this split: Gekhman et al. conclude that models acquire most factual knowledge during pre-training, and that fine-tuning mainly teaches them to use it better. RAFT shows a concrete use: training the model to ignore irrelevant retrieved documents and cite the relevant passages, that is, fine-tuning shaping how the model uses retrieval, not what it knows.

Execution: does the task require querying a system or acting?

Some questions should not be answered by text, neither from the model nor from a document. If the question is "is this API deprecated today?", the source of truth is the API catalog, not an ADR written months ago. The symptom is an answer that mixes model memory or outdated text with a fact that lives in a queryable system. The intervention is a tool: the model calls the catalog, receives the current status, and answers based on it. Work like ReAct, which combines reasoning and acting, and Toolformer, where the model learns when and how to call APIs such as a calculator and search, shows that tools address what the model cannot maintain on its own. There is a porous boundary with the knowledge axis, because querying a catalog is also access to information. The practical difference is the source: a document corpus that needs curating, on one side, and an authoritative, queryable, current system on the other. Tools also carry their own risks. The MCP specification, for example, treats tools as arbitrary code execution and advises treating tool behavior descriptions as untrusted unless they come from a trusted source.

What falls outside the three axes

The three axes do not cover everything, and it is important to say so. An ambiguous instruction and insufficient reasoning also produce wrong answers, and none of the three capabilities fixes that. That is why the decision tree in section 7 begins with a step zero, before any technique: improve the task specification, decompose it, or use a more capable model. This is also consistent with OpenAI's advice to start with prompt engineering. This limitation is one of the reasons H1 speaks of "a large share of failures," not all of them.

There is also a point about combinations. The axes describe the cause of a failure, not an exclusive choice of solution. RAFT is an example of fine-tuning (behavior) working in service of retrieval (knowledge), and that same OpenAI guide describes the approaches as additive, not exclusive. The gain of thinking in axes is knowing which lever to pull first and how to tell whether it worked.

4. The architecture

Figure 3. The model is one component. Knowledge, behavior, and actions have different homes in the system.

The three axes from the previous section take on practical meaning once we place them in an architecture. Figure 3 shows the ADR assistant from our scenario and indicates where each capability lives. The central idea is that the model is one component among several, and that each axis corresponds to a different place in the system where you can intervene.

Follow the path of a question like "which authentication pattern should we use between services?".

Retrieval. The question passes through a block that searches the documents and applies filters, for example discarding ADRs with superseded status. This is where the knowledge axis manifests at runtime.
Knowledge base. Behind retrieval sits the corpus, and that is where section 2's curation happens: status, relationships, canonical source. Optimal retrieval over a poorly curated corpus still returns outdated answers.
Model. Receives the question and the context and generates the answer. The behavior axis lives here: instructions, examples, and, when justified, a model adapted by fine-tuning.
Tools. Instead of trusting text, the model can query an authoritative system, such as the API catalog, and come back with the current fact. This is the execution axis.
Answer. The result returns to the user, ideally with the source and the status of the decisions used.

This reading is consistent with a trend described in the AI engineering literature. The Berkeley group, in a post describing "compound AI systems", argues that state-of-the-art results increasingly come from systems with multiple components, such as model calls, retrievers, and tools, rather than from an isolated model, and that iterating on the system tends to be faster than retraining the model. Anthropic's guide on agents starts from the same idea and recommends seeking the simplest possible solution, noting that many applications need only a single well-optimized model call. The architecture in Figure 3 is therefore a ceiling of complexity, not a goal. Not every system needs every block, and starting without them is a legitimate choice.

Two observations about the diagram. The first is that the blocks have different owners and lifecycles. The corpus changes when a decision changes, the model changes when the provider changes or when there is retraining, and tools change with the systems they query. Mixing these layers into one, for example by training the model on content that should live in the corpus, is the kind of decision section 1 called "complexity that becomes yours." The second is that the figure deliberately omits the layer that cuts across every block: evaluation and observability. Without recording what was retrieved, what the model received, and which tool was called, the diagnosis from the previous sections is not possible, and we go back to choosing techniques by opinion. That topic deserves its own article in the series.

5. Evidence

Before proposing a decision tree, it is worth asking what research has already shown. The short answer is that useful evidence exists, but it is more limited than the debates make it seem. The studies below compare the two approaches for injecting knowledge. This section is based on the studies' abstracts, not the full papers, so I only cite results the abstracts themselves state.

Study	Setting	What the authors report
Ovadia et al. (2023)	Knowledge-intensive tasks, with previously seen and new knowledge	Unsupervised fine-tuning improves things somewhat, but RAG is better in both cases. Models struggle to learn new facts this way
Soudani et al. (2024)	Synthetic question answering over low-popularity knowledge, across twelve models	Fine-tuning improves at every popularity level, but RAG beats it by a wide margin, especially on the least popular facts
Balaguer et al. (2024), Microsoft	Agriculture case study, with Llama2-13B, GPT-3.5, and GPT-4	Fine-tuning raised accuracy by more than 6 percentage points, and RAG added about 5 points on top. The effects accumulated
Zhang et al. (2024), RAFT	Domain-specific adaptation with RAG	Training the model to ignore irrelevant documents and cite the relevant ones brought consistent gains across three datasets
Mecklenburg et al. (2024), Microsoft	Recent sports events	Supervised fine-tuning can inject facts, provided the training data is well constructed. Coverage was uneven with token-based scaling and more uniform with fact-based scaling
Yang et al. (2026)	Multi-hop questions over novel knowledge, across three 7B models	RAG gave consistent gains, but supervised fine-tuning had the highest overall accuracy
Abonizio et al. (2025)	Knowledge injection in a low-resource regime	RAG-based injection tended to degrade performance on control sets more than parametric methods did

What can be stated carefully. For new or rare facts, unsupervised fine-tuning over raw text is a weak path, and RAG was superior in every direct comparison I read. At the same time, supervised fine-tuning with well-constructed data can add knowledge and, in a 2026 study, had the best overall accuracy. And the effects can add up, as in the agriculture case. The most honest reading is that the techniques act in different places, which supports H1, not that one beats the other.

What the evidence does not say. There are four limits the reader should keep in mind:

Quality of the evidence. Almost all the studies above are preprints, and most use small or synthetic benchmarks, such as agriculture, sports events, and invented entities. There is no reason to assume the results transfer to a corporate corpus.
None of them tests our problem. The studies measure whether the model learns or retrieves facts. None measures the distinction between a standing and an obsolete decision, which is the center of this article's scenario, and therefore none tests H2.
RAG is not always better. Besides the Abonizio study, the example from OpenAI's guide shows a case where RAG lowered the score through noise. The gain depends on retrieval bringing in the right content.
Fine-tuning effects depend on the setting. The increase in hallucination reported by Gekhman et al. was measured on question answering without external lookup, with new knowledge. It does not extend to fine-tuning for format or style.

In short, the research supports the thesis that the two approaches do not compete on the same ground, but it does not replace a test on your own corpus and with your real failures. That is why one of the upcoming articles in the series covers the experiment.

6. The trade-offs

Choosing a capability means accepting a set of costs that do not appear on the proposal slide. The table below compares the three capabilities across six dimensions, applied to the ADR assistant. It is a qualitative comparison: this article did not measure latency or cost, and I leave those measurements for a future article in the series rather than repeating numbers of dubious origin.

Dimension	Retrieval (RAG)	Fine-tuning	Tools
Updating	Reindex what changed. When an ADR is superseded, updating the corpus is enough	Retrain to reflect the change, and re-evaluate	Immediate: the tool queries the current system
Recurring cost	Indexing infrastructure and more context text on every query	Training data, training, evaluation, and a new round on every base-model change	Integration and maintenance of each tool and its contract
Latency	Adds at least one search step before generation	Generally adds no steps at inference	Adds round trips on every call
Auditability	Lets you point to the source, but the citation must be verified	Knowledge diffused in the weights, hard to trace or remove	Calls are loggable and reproducible
Security	Permissions and cross-context leakage must be handled at retrieval	Training data becomes part of the model	Tools are code execution and require trust and limits
Maintenance	Continuous curation of the corpus (H2)	Coupling to the base model and the provider's lifecycle	Versioning and compatibility of the integrations

Some points in the table deserve an explanation.

Updating and cost follow the speed of change. In our scenario, architecture decisions change at a reasonable rate. An ADR superseded today requires, under RAG, updating the corpus, and under fine-tuning, retraining and re-evaluating the model so it forgets the previous decision. The more volatile the content, the heavier fine-tuning's recurring cost. On the other hand, parameter-efficient methods reduce the cost of training itself: LoRA reports roughly 10,000 times fewer trainable parameters and about 3 times less GPU memory, compared to full fine-tuning of GPT-3 175B with Adam. That lowers the barrier to entry, but it does not eliminate the cost of data, evaluation, and maintenance.

Auditability is not the same as verifiability. RAG lets you show where the answer came from, and that is a real advantage over knowledge diffused in weights. But citing a source does not guarantee the source supports the claim. In a human audit of generative search engines, only 51.5% of sentences were fully supported by their citations, and 74.5% of citations supported the corresponding sentence. These were 2023 systems and not corporate assistants, so the number does not transfer, but the warning stands: a citation must be verified, not merely displayed.

Security enters through retrieval. OWASP treats vectors and embeddings as a risk of their own in its 2025 Top 10 (LLM08), including context leakage between users in shared vector databases, and recommends permission-aware storage and immutable logs of retrievals. In an ADR assistant, not every ADR should be visible to every team. This topic deserves its own article in the series.

Fine-tuning ties you to the base model's lifecycle. Providers retire models. Anthropic states a notice of at least 60 days before retiring public models, and OpenAI, of at least 6 months for generally available models and around 2 weeks for previews, according to the pages consulted in October 2026. A model fine-tuned on a base that is discontinued has to be redone. This is an inference by the author, not a documented rule for every case, but it is a cost worth putting in the budget from the start.

The balance point between these dimensions depends on the case. In general, and this is a rule of thumb from the author rather than a research result, a stable corpus with tight latency and a rigid output format leans toward fine-tuning, while a corpus that changes every week and demands traceability leans toward retrieval and tools. What the table delivers is the list of questions to ask before deciding, and it is with that list that the next section's decision tree is built.

7. The decision framework

Figure 4. From failure to intervention. A synthesis by the author, to validate with your own data.

Figure 4 turns the previous sections into a procedure. Before using it, a caveat: it is a synthesis by the author, built from the axes in section 3 and from the split OpenAI makes between context and behavior. It is not a published taxonomy and has not been empirically validated. Treat it as a starting point for your team, not as a rule.

How to use it. The tree starts from a concrete failure, already observed and recorded, never from a preference. The tree has a step zero and three steps. For each question, the diagnostic test from section 3 says how to answer with evidence instead of opinion:

Is the instruction ambiguous or the reasoning insufficient? Adjust the task specification (instruction, success criteria, and output format), decompose the task, or consider a more capable model. It is the cheapest step to check, and OpenAI's guide recommends starting with prompt engineering.
Does the answer depend on private, recent, or mutable information? Run the manual context test: with the right information at hand, does the model get it right? If so, the path is retrieval, and the first check is the corpus's curation (H2) before touching retrieval.
Is the content right, but form, style, or format fail? If the error persists with correct context and instructions, fine-tuning is a candidate, but only after proving that instructions and examples are not enough. That "proving" is the subject of one of the upcoming articles in the series.
Does the task require computation, a system query, or an action? Prefer a tool that queries the authoritative source over an answer based on text.

Step zero comes first because fixing the task specification is the cheapest and because no capability compensates for a poorly specified task. After each fix, re-evaluate the original failure before moving on. And if no question gets a "yes," the conclusion is to go back to diagnosis: the failure may have more than one cause, or the cause may not have been identified yet.

Applying it to our scenario. The table shows how four hypothetical failures of the ADR assistant would travel the tree. These are illustrative examples, not results.

Observed failure	Diagnostic test	Path through the tree	Intervention
The ADR that superseded the old pattern was never indexed	With the new ADR in context, the model gets it right	Step 1: yes	Index it and fix the ingestion process
The old, "superseded" ADR is retrieved instead of the new one	The model gets it right when only the standing ADR is provided	Step 1: yes	Curation: status and supersession relationship, filter at retrieval
The model receives the right ADR and still recommends the old pattern	With clear context and instructions, does the error persist, or does it disappear with a better instruction?	Step 0 first; then step 2	Reinforce the instruction to prioritize the standing decision; fine-tuning only if it persists
The question is whether an API is still active today	The source of truth is the catalog, not a document	Step 3: yes	A tool that queries the API catalog

Notice what the four rows have in common: none of them calls, as a first step, for choosing between RAG and fine-tuning. Three of them are resolved without touching the model's weights. This is exactly what the article's thesis anticipates, but the limit is worth repeating: these are four scenarios chosen to illustrate the procedure, not an estimate of how often each cause appears in practice.

Checklist before acting. On any team, before approving an intervention, it is worth being able to answer:

What is the failure, and is it recorded with the input, the expected output, and the output obtained?
Which diagnostic test confirmed the category of the cause?
What is the cheapest alternative that has already been tried?
How will we know the intervention worked, with which evaluation set and which criterion defined before running?

8. The takeaway

Let us return, one last time, to the team that saw the assistant recommend an abandoned architectural pattern. In the version of the conversation that starts from the technique, they leave with a decision: fine-tuning or RAG. In the version that starts from the failure, they leave with an answered question: what, exactly, went wrong in that answer? The second version is slower on day one and cheaper on every other day.

The principle this article proposes fits in one sentence: diagnose the failure before choosing the technique. To apply it, three ideas:

Separate knowing, behaving, and doing. Knowledge, behavior, and execution are different problems (H1), and each points to a different capability: retrieval, model adaptation, or tools. Before them, confirm that the task is well specified.
Curate the corpus before blaming the model. Part of knowledge failures are curation failures (H2): the corpus contains, by design, both the standing and the obsolete, and no technique applied to the model tells one from the other without status, dates, and explicit relationships.
Demand evidence before intervening. Record the failure, confirm the category with a diagnostic test, try the cheapest alternative, and define, before running, how you will know it worked.

One final caveat, for consistency with what the article asks for. H1 and H2 are working hypotheses, not results: the research we reviewed shows that the techniques act in different places, but none of the studies tests the distinction between a standing and an obsolete decision, and the decision tree is a synthesis by the author. Its value lies in offering a procedure your team can test and correct with your own data, not in replacing that test.

The question "RAG or fine-tuning?" is not wrong because it is useless. It is wrong because it arrives too early. When diagnosis comes first, it comes back as a better question: which of these capabilities is my failure asking for?

About the series

This is the first article in the Beyond the Model series, about the decisions that turn language models into reliable software systems. In the next ones, the series goes deeper into the two points left open here:

Stop Adding RAG to Everything details the failure taxonomy: how a wrong answer is classified into knowledge, retrieval, instruction, reasoning, tools, or behavior, and why each cause points to a different intervention.
Before You Fine-Tune an LLM, Prove That You Need To shows how to turn the decision into an experiment: baseline, evaluation set, metrics, and decision criteria defined before training.

If you have been through a conversation like the one at the start of this article, tell me in the comments which failure sparked the discussion and which intervention the team chose. Those cases are exactly the material the next articles need.

References

Barnett, S. et al. (2024). Seven Failure Points When Engineering a Retrieval Augmented Generation System. arXiv:2401.05856
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020
Hu, E. J. et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685
Ovadia, O. et al. (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. arXiv:2312.05934
OpenAI. Optimizing LLM Accuracy
Gekhman, Z. et al. (2024). Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?. EMNLP 2024
Yang et al. (2026). Fine-Tuning vs. RAG for Multi-Hop Question Answering with Novel Knowledge. arXiv:2601.07054 (preprint)
Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 Nov 2011
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 199–220
Pan, S. et al. (2024). Unifying Large Language Models and Knowledge Graphs: A Roadmap. IEEE TKDE (arXiv:2306.08302)
Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130
Zhang, T. et al. (2024). RAFT: Adapting Language Model to Domain Specific RAG. arXiv:2403.10131 (preprint)
Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629 (ICLR 2023)
Schick, T. et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761
Model Context Protocol. Specification (revision 2026-07-28)
Zaharia, M. et al. (2024). The Shift from Models to Compound AI Systems. BAIR Blog, 18 Feb 2024
Anthropic (2024). Building Effective Agents. 19 Dec 2024
Soudani, H., Kanoulas, E., Hasibi, F. (2024). Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge. arXiv:2403.01432
Balaguer, A. et al. (2024). RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture. arXiv:2401.08406 (preprint)
Abonizio, H., Almeida, T. S., Lotufo, R., Nogueira, R. (2025). Comparing Knowledge Injection Methods for LLMs in a Low-Resource Regime. arXiv:2508.06178 (preprint)
Mecklenburg, N. et al. (2024). Injecting New Knowledge into Large Language Models via Supervised Fine-Tuning. arXiv:2404.00213 (preprint)
Liu, N. F., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP 2023 (arXiv:2304.09848)
OWASP GenAI Security Project. LLM08:2025 Vector and Embedding Weaknesses
Anthropic. Model deprecations (consulted 2026-10-10)
OpenAI. Deprecations (consulted 2026-10-10)

RAG ou fine-tuning: a pergunta errada para quem constrói sistemas de IA

Victor Lopes — Sat, 10 Oct 2026 16:21:02 +0000

Um time de plataforma está validando um assistente baseado em LLM, ainda em fase de testes, para responder dúvidas de arquitetura dos desenvolvedores, com acesso aos ADRs (Architecture Decision Records) e à documentação interna. Numa rodada de avaliação, o próprio time percebe que o assistente recomendou um padrão de autenticação entre serviços que a empresa abandonou no ano passado e, de quebra, sugeriu chamar um endpoint de uma API interna já marcada como obsoleta. A resposta era plausível, bem escrita e tecnicamente defensável em termos gerais. Só contrariava uma decisão vigente.

A falha foi pega antes de chegar a qualquer usuário, e é justamente aí que a conversa seguinte importa. Duas propostas aparecem na mesa. A primeira: "Precisamos fazer fine-tuning com os nossos ADRs, para o modelo aprender as nossas decisões." A segunda: "Precisamos de RAG sobre os ADRs, para ele consultar a decisão vigente." As duas são razoáveis, e cada uma parte de uma teoria sobre o que falta ao modelo: uma supõe que falta aprender o conteúdo, a outra que falta consultar o conteúdo. Mas existe uma pergunta anterior que nenhuma das duas responde: o que, exatamente, deu errado nessa resposta?

Essa pergunta importa mais do que parece, porque a mesma recomendação desatualizada pode ter origens bem diferentes. O ADR que substituiu o padrão antigo pode nunca ter sido indexado. O ADR antigo, com status "superseded", pode ter sido recuperado no lugar do novo. Os dois podem ter sido recuperados e o modelo ter ignorado o contexto, respondendo a partir do que aprendeu sobre o padrão em documentação pública. Ou a pergunta pode ter sido genérica e a instrução do sistema nunca ter pedido para priorizar a decisão vigente. Cada causa pede uma correção diferente, e nenhuma delas se resolve, por si só, com a técnica que ganhou a discussão. Um fine-tuning com os ADRs de hoje, por exemplo, não ajuda quando a decisão for substituída amanhã. Isso não é exclusivo do nosso cenário: um relato de engenharia sobre sistemas RAG identificou sete pontos de falha distintos ao construir esse tipo de sistema.

Para entender como chegamos a esse debate, vale lembrar o contexto. Desde a chegada do ChatGPT, no fim de 2022, as organizações tentam colocar LLMs na frente do que antes vivia em wikis, pastas compartilhadas e documentos operacionais, com a promessa de tornar esse conhecimento mais acessível a quem precisa dele. No caminho, duas técnicas que eram tema de pesquisa viraram vocabulário do dia a dia: a geração aumentada por recuperação (RAG), proposta por Lewis et al. em 2020, e o fine-tuning, que métodos eficientes em parâmetros como o LoRA tornaram bem mais barato de executar. Quando duas ferramentas poderosas chegam juntas e resolvem o mesmo tipo de "dor" aparente, é natural que o mercado as coloque frente a frente. Assim nasceu o enquadramento padrão: RAG ou fine-tuning?

O problema desse enquadramento é que ele pede para escolher a resposta antes de combinar a pergunta. Existe pesquisa comparando as duas abordagens lado a lado, e ela merece uma leitura cuidadosa, não um slogan. O guia da OpenAI sobre otimização de acurácia, por exemplo, trata as duas como respostas a problemas diferentes e como abordagens "aditivas, não exclusivas". A pergunta, portanto, não deveria partir da técnica. Deveria partir da falha.

Figura 1. A diferença entre as duas conversas não está na técnica escolhida, e sim na etapa que foi pulada.

Este artigo defende essa inversão e propõe uma forma prática de fazê-la, separando o que um sistema precisa saber, como precisa se comportar e o que precisa fazer. É o primeiro passo de uma série sobre as decisões que acontecem além do modelo, onde um sistema de IA se torna confiável, ou deixa de ser.

1. O problema

Voltemos ao assistente de arquitetura. As duas propostas que apareceram na mesa têm algo em comum: ambas começam por uma técnica e só depois procuram o problema que ela resolveria. É uma inversão sutil, porque a conversa soa técnica e madura. Mas o caminho habitual da engenharia é o contrário: observar o sintoma, formular uma hipótese sobre a causa, testar e só então intervir. Em sistemas baseados em LLMs, o diagnóstico costuma ser a etapa mais fácil de pular.

Por que ele é pulado? Pela minha observação, podemos pensar em várias razões, mas três parecem as mais plausíveis. Primeiro, técnicas são tangíveis: têm ferramentas, tutoriais, orçamento e um nome que cabe num roadmap. Segundo, diagnosticar dá trabalho: exige abrir os traces, separar o que foi recuperado do que foi gerado, reproduzir a falha e entender em qual etapa ela nasceu. Terceiro, "RAG ou fine-tuning?" é uma pergunta que se responde com opinião, enquanto "o que causou esta falha?" só se responde com evidência.

O custo de escolher a técnica antes do diagnóstico aparece de pelo menos três formas.

A falha original continua lá. Se o problema era o ADR antigo sendo recuperado no lugar do novo, treinar o modelo com os ADRs não muda nada: o conteúdo errado continua chegando ao contexto. Se o problema era o modelo ignorar o contexto recuperado, recuperar mais contexto também não resolve. A intervenção é entregue, o time dá o problema por resolvido, e a recomendação desatualizada volta a aparecer na rodada de testes seguinte.

A intervenção pode piorar o sistema. O próprio guia da OpenAI sobre otimização de acurácia traz um exemplo em que o RAG "confundiu" o modelo ao adicionar ruído e reduziu a nota em quatro pontos. Do lado do fine-tuning, um estudo controlado de perguntas e respostas sem consulta externa mostrou que exemplos com conhecimento novo são aprendidos mais devagar e, depois de aprendidos, aumentam a tendência do modelo a alucinar. Esse resultado vale para aquele cenário específico e não deve ser estendido a todo fine-tuning. Ainda assim, mostra que "mais uma técnica" não é uma aposta sem risco.

A complexidade passa a ser sua. Cada técnica traz uma superfície nova de manutenção. O RAG exige indexação, atualização, ranqueamento e controle de permissões. O fine-tuning exige dados de treinamento, versionamento, reavaliação a cada mudança de modelo base e um plano para quando o conteúdo mudar. Se a causa real era uma instrução ambígua, o time pagou esse custo para resolver algo que um ajuste na instrução resolveria. Não por acaso, o mesmo guia da OpenAI recomenda começar pela engenharia de prompt.

Nada disso significa que uma das técnicas seja a vilã. A evidência é mista, e isso é parte do problema. Em comparações diretas de injeção de conhecimento, o RAG superou o fine-tuning não supervisionado, tanto para conhecimento já visto quanto para conhecimento novo (Ovadia et al., 2023). Já um estudo mais recente, com perguntas de múltiplos saltos sobre conhecimento novo, encontrou a maior acurácia geral no fine-tuning supervisionado. Ambos são preprints, com benchmarks pequenos ou sintéticos, e nenhum deles responde à pergunta do nosso time. Eles mostram que cada técnica tem o seu território, e que descobrir em qual território a falha está é o trabalho que a pergunta "RAG ou fine-tuning?" dispensa. Voltamos a esses estudos, com mais detalhe, na seção 5.

2. A hipótese de engenharia

Se o problema é começar pela técnica, a alternativa precisa ser algo que possa ser testado, e não apenas uma preferência de método. Proponho a seguinte hipótese de trabalho:

H1. Grande parte das falhas observáveis em um assistente como o nosso pode ser atribuída a uma de três categorias, conhecimento, comportamento ou execução, e cada categoria responde melhor a uma intervenção diferente.

Isto é uma hipótese, não um resultado. Ela não foi testada para este artigo. Para testá-la, um time poderia coletar as falhas de uma rodada de avaliação, pedir a revisores independentes que classifiquem cada uma e medir a concordância entre eles. Em seguida, aplicaria a intervenção indicada para cada categoria e compararia o resultado com a alternativa. A hipótese enfraquece se a concordância entre revisores for baixa, se a maioria das falhas não couber nas três categorias ou se todas pedirem a mesma intervenção. Os próximos artigos da série voltam a esse desenho experimental.

Há, porém, um refinamento que o nosso cenário sugere, e que costuma ficar de fora da discussão. Voltemos ao ADR substituído. Em seu texto original sobre o formato, Michael Nygard recomenda que decisões revertidas não sejam apagadas: elas ficam registradas e marcadas como "superseded", porque "ainda é relevante saber que aquela foi a decisão, mas que não é mais a decisão". Ou seja, um repositório de ADRs saudável contém, por desenho, conhecimento obsoleto. O que distingue o vigente do obsoleto é o status, a data e a relação entre os registros, e não o texto em si. Um modelo que só vê o texto não tem como saber.

Isso leva a uma segunda hipótese, complementar à primeira:

H2. Parte das falhas classificadas como "conhecimento" não é falta de conhecimento. É falha de curadoria: a informação certa existe, mas a organização do acervo não permite distinguir o vigente do obsoleto, e nenhuma técnica sobre o modelo corrige isso.

Se H2 for verdadeira, a primeira pergunta diante de uma falha de conhecimento deixa de ser "RAG ou fine-tuning?" e passa a ser "o acervo está em condições de ser consultado?". Curadoria, nesse sentido, é um conjunto de decisões de engenharia sobre o conhecimento, antes de qualquer decisão sobre o modelo. Quatro formas, em ordem crescente de custo:

Forma de curadoria	O que ela trata no nosso cenário	Custo e risco
Metadados e ciclo de vida	Status (proposto, aceito, depreciado, substituído), data, responsável e referência ao registro que o substitui; filtro dessas informações na hora da recuperação	Baixo. Exige disciplina de preenchimento e atualização
Fonte canônica e deduplicação	Garante uma única fonte de verdade por decisão, em vez de cópias divergentes em wikis e pastas	Médio. Exige dono e processo de revisão
Relações explícitas	Registra que o ADR 31 substitui o ADR 12 e que um padrão se aplica a um conjunto de serviços	Médio a alto. Exige modelar o domínio
Ontologia e grafo de conhecimento	Representa conceitos (decisão, padrão, API, serviço) e relações de forma consultável e verificável	Alto. Exige modelagem, construção e manutenção contínuas

Os dois últimos itens merecem um comentário, porque entram no território de ontologias. A definição clássica de Gruber descreve uma ontologia como uma especificação formal de uma conceitualização, ou seja, um acordo explícito sobre quais conceitos existem em um domínio e como se relacionam. No nosso caso, isso significaria declarar que "Decisão", "Padrão", "API" e "Serviço" são tipos de coisa, e que "substitui", "depende de" e "se aplica a" são relações entre elas. Com isso, a pergunta "qual é a decisão vigente para autenticação entre serviços?" deixa de ser uma busca por similaridade de texto e passa a ser uma consulta com resposta verificável.

A literatura sobre a combinação de LLMs com grafos de conhecimento aponta tanto o potencial quanto o custo. Pan et al. defendem que grafos de conhecimento guardam conhecimento factual de forma explícita e podem ajudar os LLMs com informação externa e interpretabilidade, e que os dois são complementares. Os mesmos autores lembram que esses grafos são difíceis de construir e estão em constante evolução. Na linha prática, o GraphRAG propõe usar um LLM para derivar um grafo de entidades a partir dos documentos e, com ele, responder a perguntas sobre o corpus inteiro, para as quais o RAG convencional tem dificuldade. Os autores relatam melhorias em abrangência e diversidade das respostas em conjuntos de dados de cerca de um milhão de tokens. Vale a ressalva: o GraphRAG foi desenhado para perguntas globais de síntese, e não para o problema de resolver qual decisão está vigente. Ele mostra que dar estrutura ao acervo pode ajudar, mas não demonstra que resolve o nosso caso. Essa continua sendo uma hipótese a testar.

Em resumo, a pergunta do artigo ganha duas camadas. A primeira é a de H1: em qual categoria a falha está? A segunda é a de H2: se for conhecimento, o acervo está curado o bastante para ser usado? Só depois dessas duas respostas faz sentido discutir RAG, fine-tuning ou ferramentas.

3. Três eixos: conhecimento, comportamento e execução

Se H1 for útil, ela precisa de categorias que um time consiga aplicar a uma falha real, sem depender de interpretação. Proponho três eixos, cada um definido por uma pergunta que se pode fazer ao sistema.

Figura 2. Cada tipo de falha aponta para uma capacidade diferente.

Conhecimento: o modelo tem acesso à informação certa?

É o eixo da recomendação desatualizada. O sintoma típico é uma resposta que cita uma decisão inexistente, vencida ou substituída. O teste diagnóstico é simples: se colocarmos manualmente o ADR vigente no contexto, o modelo acerta? Se acerta, o problema não é de capacidade do modelo, e sim de acesso à informação, e a conversa passa a ser sobre recuperação e curadoria (H2). Esse é o território que o guia da OpenAI atribui à otimização de contexto: o caso em que o modelo não tem conhecimento por ele não estar nos dados de treinamento. A intervenção natural é o RAG, com a ressalva de que ele próprio tem vários pontos de falha, da indexação à geração.

Comportamento: tendo a informação, o modelo a usa do jeito esperado?

Aqui o modelo tem o ADR certo no contexto e ainda assim responde mal. Ele não segue o formato exigido pelo time, não cita o status da decisão, mistura recomendação com opinião ou perde a estrutura esperada em respostas longas. O teste diagnóstico muda: com contexto correto e instrução clara, o erro de forma persiste de modo consistente? Se persistir, e só depois de esgotar instrução e exemplos, o fine-tuning passa a ser um candidato. O mesmo guia da OpenAI o associa a resultados inconsistentes ou com formato incorreto. Há uma sustentação conceitual para essa divisão: Gekhman et al. concluem que os modelos adquirem a maior parte do conhecimento factual no pré-treino, e que o fine-tuning ensina principalmente a usá-lo melhor. O RAFT mostra um uso concreto: treinar o modelo para ignorar documentos irrelevantes recuperados e citar os trechos relevantes, ou seja, o fine-tuning moldando como o modelo usa a recuperação, e não o que ele sabe.

Execução: a tarefa exige consultar um sistema ou agir?

Algumas perguntas não deveriam ser respondidas por texto, nem do modelo nem de um documento. Se a dúvida é "esta API está obsoleta hoje?", a fonte de verdade é o catálogo de APIs, não um ADR escrito meses atrás. O sintoma é uma resposta que mistura memória do modelo ou texto desatualizado com um dado que existe em um sistema consultável. A intervenção é uma ferramenta: o modelo chama o catálogo, recebe o status atual e responde com base nele. Trabalhos como o ReAct, que combina raciocínio e ação, e o Toolformer, em que o modelo aprende quando e como chamar APIs como calculadora e busca, mostram que ferramentas atacam o que o modelo não consegue manter por conta própria. Há uma fronteira porosa com o eixo do conhecimento, porque uma consulta a um catálogo também é acesso à informação. A diferença prática está na fonte: um acervo de documentos que precisa ser curado, de um lado, e um sistema autoritativo, consultável e atual, do outro. Ferramentas também trazem riscos próprios. A especificação do MCP, por exemplo, trata ferramentas como execução arbitrária de código e orienta tratar descrições de comportamento de ferramentas como não confiáveis, a menos que venham de uma fonte confiável.

O que fica fora dos três eixos

Os três eixos não cobrem tudo, e é importante dizer isso. Uma instrução ambígua e um raciocínio insuficiente também geram respostas erradas, e nenhuma das três capacidades resolve isso. Por isso a árvore de decisão da seção 7 começa por um passo zero, antes de qualquer técnica: melhorar a especificação da tarefa, decompô-la ou usar um modelo mais capaz. Isso também é coerente com o conselho da OpenAI de começar por engenharia de prompt. Essa limitação é uma das razões pelas quais H1 fala em "grande parte das falhas", e não em todas.

Há ainda um ponto sobre combinações. Os eixos descrevem a causa de uma falha, não uma escolha exclusiva de solução. O RAFT é um exemplo de fine-tuning (comportamento) trabalhando a serviço da recuperação (conhecimento), e o mesmo guia da OpenAI descreve as abordagens como aditivas, não exclusivas. O ganho de pensar em eixos é saber qual alavanca puxar primeiro e como saber se ela funcionou.

4. A arquitetura

Figura 3. O modelo é um componente. Conhecimento, comportamento e ações têm lugares diferentes no sistema.

Os três eixos da seção anterior ganham sentido prático quando os colocamos em uma arquitetura. A Figura 3 mostra o assistente de ADRs do nosso cenário e indica onde cada capacidade vive. A ideia central é que o modelo é um componente entre vários, e que cada eixo corresponde a um lugar diferente do sistema onde se pode intervir.

Siga o caminho de uma pergunta como "qual padrão de autenticação devemos usar entre serviços?".

Recuperação. A pergunta passa por um bloco que busca nos documentos e aplica filtros, por exemplo descartar ADRs com status substituído. É aqui que o eixo do conhecimento se manifesta no tempo de execução.
Base de conhecimento. Por trás da recuperação está o acervo, e é nele que a curadoria da seção 2 acontece: status, relações, fonte canônica. Uma recuperação ótima sobre um acervo mal curado continua devolvendo respostas desatualizadas.
Modelo. Recebe a pergunta e o contexto e gera a resposta. O eixo do comportamento vive aqui: instrução, exemplos e, quando justificado, um modelo adaptado por fine-tuning.
Ferramentas. Em vez de confiar em texto, o modelo pode consultar um sistema autoritativo, como o catálogo de APIs, e voltar com o dado atual. É o eixo da execução.
Resposta. O resultado volta ao usuário, idealmente com a fonte e o status das decisões usadas.

Essa leitura é coerente com uma tendência descrita na literatura de engenharia de IA. O grupo de Berkeley, em um post que descreve os "compound AI systems", argumenta que resultados de ponta vêm cada vez mais de sistemas com vários componentes, como chamadas ao modelo, recuperadores e ferramentas, e não de um modelo isolado, e que iterar no sistema costuma ser mais rápido do que retreinar o modelo. O guia da Anthropic sobre agentes parte da mesma ideia e recomenda buscar a solução mais simples possível, lembrando que muitas aplicações precisam apenas de uma única chamada bem otimizada ao modelo. A arquitetura da Figura 3 é, portanto, um teto de complexidade, não uma meta. Nem todo sistema precisa de todos os blocos, e começar sem eles é uma escolha legítima.

Duas observações sobre o diagrama. A primeira é que os blocos têm donos e ciclos de vida diferentes. O acervo muda quando uma decisão muda, o modelo muda quando o provedor muda ou quando há retreino, e as ferramentas mudam com os sistemas que elas consultam. Misturar essas camadas em uma só, por exemplo treinando o modelo com conteúdo que deveria viver no acervo, é o tipo de decisão que a seção 1 chamou de "complexidade que passa a ser sua". A segunda é que a figura omite, de propósito, a camada que atravessa todos os blocos: avaliação e observabilidade. Sem registrar o que foi recuperado, o que o modelo recebeu e qual ferramenta foi chamada, o diagnóstico das seções anteriores não é possível, e voltamos a escolher técnica por opinião. Esse tema merece artigo próprio dentro da série.

5. O que diz a evidência

Antes de propor uma árvore de decisão, vale perguntar o que a pesquisa já mostrou. A resposta curta é que existe evidência útil, mas ela é mais limitada do que os debates fazem parecer. Os estudos abaixo comparam as duas abordagens para injetar conhecimento. Esta seção se baseia nos resumos (abstracts) dos estudos, não nos artigos completos, então só cito os resultados que os próprios resumos declaram.

Estudo	Cenário	O que os autores relatam
Ovadia et al. (2023)	Tarefas intensivas em conhecimento, com conhecimento já visto e novo	Fine-tuning não supervisionado melhora um pouco, mas o RAG é melhor em ambos os casos. Os modelos têm dificuldade em aprender fatos novos por esse caminho
Soudani et al. (2024)	Perguntas e respostas sintéticas sobre conhecimento pouco popular, em doze modelos	O fine-tuning melhora em todos os níveis de popularidade, mas o RAG o supera por ampla margem, principalmente nos fatos menos populares
Balaguer et al. (2024), Microsoft	Estudo de caso em agricultura, com Llama2-13B, GPT-3.5 e GPT-4	O fine-tuning elevou a acurácia em mais de 6 pontos percentuais, e o RAG somou cerca de 5 pontos por cima. Os efeitos se acumularam
Zhang et al. (2024), RAFT	Adaptação a domínios específicos com RAG	Treinar o modelo para ignorar documentos irrelevantes e citar os relevantes trouxe ganhos consistentes em três conjuntos de dados
Mecklenburg et al. (2024), Microsoft	Eventos esportivos recentes	O fine-tuning supervisionado consegue injetar fatos, desde que os dados de treino sejam bem construídos. A cobertura foi desigual com escala por tokens e mais uniforme com escala por fatos
Yang et al. (2026)	Perguntas de múltiplos saltos sobre conhecimento novo, em três modelos de 7B	O RAG deu ganhos consistentes, mas o fine-tuning supervisionado teve a maior acurácia geral
Abonizio et al. (2025)	Injeção de conhecimento com poucos dados	A injeção por RAG tendeu a degradar o desempenho em conjuntos de controle mais do que os métodos paramétricos

O que dá para afirmar com cuidado. Para fatos novos ou raros, o fine-tuning não supervisionado sobre texto bruto é um caminho fraco, e o RAG foi superior em todas as comparações diretas que li. Ao mesmo tempo, o fine-tuning supervisionado com dados bem construídos consegue acrescentar conhecimento e, em um estudo de 2026, teve a melhor acurácia geral. E os efeitos podem se somar, como no caso da agricultura. A leitura mais honesta é de que as técnicas atuam em lugares diferentes, o que sustenta H1, e não de que uma vence a outra.

O que a evidência não diz. Há quatro limites que o leitor deve ter em mente:

Qualidade da evidência. Quase todos os estudos acima são preprints, e a maioria usa benchmarks pequenos ou sintéticos, como agricultura, eventos esportivos e entidades inventadas. Não há razão para supor que os resultados se transfiram para um acervo corporativo.
Nenhum deles testa o nosso problema. Os estudos medem se o modelo aprende ou recupera fatos. Nenhum mede a distinção entre decisão vigente e obsoleta, que é o centro do cenário do artigo, e portanto nenhum testa H2.
RAG não é sempre melhor. Além do estudo de Abonizio, o exemplo do guia da OpenAI mostra um caso em que o RAG reduziu a nota por ruído. O ganho depende de a recuperação trazer o conteúdo certo.
Efeitos de fine-tuning dependem do cenário. O aumento de alucinação relatado por Gekhman et al. foi medido em perguntas e respostas sem consulta externa, com conhecimento novo. Não se estende a fine-tuning para formato ou estilo.

Em resumo, a pesquisa justifica a tese de que as duas abordagens não competem no mesmo terreno, mas não substitui um teste no seu próprio acervo e com as suas falhas reais. É por isso que um dos próximos artigos da série trata do experimento.

6. Os trade-offs

Escolher uma capacidade é aceitar um conjunto de custos que não aparecem no slide da proposta. A tabela abaixo compara as três capacidades em seis dimensões, aplicadas ao assistente de ADRs. É uma comparação qualitativa: este artigo não mediu latência nem custo, e deixo essas medições para um artigo futuro da série, em vez de repetir números de origem duvidosa.

Dimensão	Recuperação (RAG)	Fine-tuning	Ferramentas
Atualização	Reindexar o que mudou. Quando um ADR é substituído, basta atualizar o acervo	Retreinar para refletir a mudança, e reavaliar	Imediata: a ferramenta consulta o sistema atual
Custo recorrente	Infraestrutura de indexação e mais texto de contexto a cada consulta	Dados de treino, treinamento, avaliação e nova rodada a cada mudança de modelo base	Integração e manutenção de cada ferramenta e do seu contrato
Latência	Acrescenta pelo menos uma etapa de busca antes da geração	Em geral não acrescenta etapas na inferência	Acrescenta idas e voltas a cada chamada
Auditabilidade	Permite apontar a fonte, mas a citação precisa ser verificada	Conhecimento difuso nos pesos, difícil de rastrear ou remover	Chamadas registráveis e reproduzíveis
Segurança	Permissões e vazamento entre contextos precisam ser tratados na recuperação	Dados de treino passam a fazer parte do modelo	Ferramentas são execução de código e exigem confiança e limites
Manutenção	Curadoria contínua do acervo (H2)	Atrelamento ao modelo base e ao ciclo de vida do provedor	Versionamento e compatibilidade das integrações

Alguns pontos da tabela merecem uma explicação.

Atualização e custo seguem a velocidade da mudança. No nosso cenário, decisões de arquitetura mudam com frequência razoável. Um ADR substituído hoje exige, no RAG, atualizar o acervo, e no fine-tuning, retreinar e reavaliar o modelo para que ele esqueça a decisão anterior. Quanto mais volátil o conteúdo, mais o custo recorrente do fine-tuning pesa. Por outro lado, métodos eficientes em parâmetros reduzem o custo do treino em si: o LoRA relata cerca de 10.000 vezes menos parâmetros treináveis e cerca de 3 vezes menos memória de GPU, em comparação com o ajuste completo do GPT-3 175B com Adam. Isso baixa a barreira de entrada, mas não elimina o custo de dados, avaliação e manutenção.

Auditabilidade não é o mesmo que verificabilidade. O RAG permite mostrar de onde veio a resposta, e isso é uma vantagem real sobre conhecimento difuso nos pesos. Mas citar uma fonte não garante que a fonte sustente a afirmação. Em uma auditoria humana de buscadores generativos, apenas 51,5% das frases estavam totalmente sustentadas pelas citações, e 74,5% das citações sustentavam a frase correspondente. São sistemas de 2023 e não assistentes corporativos, então o número não se transfere, mas o aviso permanece: uma citação precisa ser verificada, não apenas exibida.

Segurança entra pela recuperação. O OWASP trata vetores e embeddings como risco próprio no seu Top 10 de 2025 (LLM08), inclusive o vazamento de contexto entre usuários em bancos vetoriais compartilhados, e recomenda armazenamento com controle de acesso por permissão e registros imutáveis das recuperações. Em um assistente de ADRs, nem todo ADR deve ser visível a todos os times. Esse tema merece um artigo próprio na série.

Fine-tuning prende você ao ciclo de vida do modelo base. Provedores aposentam modelos. A Anthropic informa um aviso de pelo menos 60 dias antes da aposentadoria de modelos públicos, e a OpenAI, de pelo menos 6 meses para modelos de disponibilidade geral e cerca de 2 semanas para prévias, segundo as páginas consultadas em outubro de 2026. Um modelo ajustado sobre uma base que sai de linha precisa ser refeito. É uma inferência do autor, não uma regra documentada para todos os casos, mas é um custo que merece entrar na conta desde o início.

O ponto de equilíbrio entre essas dimensões depende do caso. Em geral, e esta é uma regra de bolso do autor e não um resultado de pesquisa, um acervo estável, com latência apertada e formato rígido de saída, pende para o fine-tuning, enquanto um acervo que muda toda semana e exige rastreabilidade pende para recuperação e ferramentas. O que a tabela entrega é a lista de perguntas a fazer antes de decidir, e é com ela que a árvore de decisão da próxima seção é construída.

7. O framework de decisão

Figura 4. Da falha à intervenção. Síntese do autor, para validar com dados próprios.

A Figura 4 transforma as seções anteriores em um procedimento. Antes de usá-la, uma ressalva: ela é uma síntese do autor, construída a partir dos eixos da seção 3 e da divisão que a OpenAI faz entre contexto e comportamento. Não é uma taxonomia publicada nem foi validada empiricamente. Trate-a como ponto de partida para o seu time, não como regra.

Como usar. A árvore parte de uma falha concreta, já observada e registrada, nunca de uma preferência. A árvore tem um passo zero e três passos. Para cada pergunta, o teste diagnóstico da seção 3 diz como responder com evidência em vez de opinião:

A instrução é ambígua ou o raciocínio é insuficiente? Ajuste a especificação da tarefa (instrução, critérios de sucesso e formato de saída), decomponha a tarefa ou considere um modelo mais capaz. É o passo mais barato de verificar, e o guia da OpenAI recomenda começar pela engenharia de prompt.
A resposta depende de informação privada, recente ou mutável? Faça o teste do contexto manual: com a informação certa à mão, o modelo acerta? Se sim, o caminho é recuperação, e a primeira checagem é a curadoria do acervo (H2) antes de mexer no retrieval.
O conteúdo está certo, mas forma, estilo ou formato falham? Se o erro persiste com contexto e instrução corretos, fine-tuning é candidato, mas só depois de provar que instrução e exemplos não bastam. Esse "provar" é o tema de um dos próximos artigos da série.
A tarefa exige cálculo, consulta a um sistema ou ação? Prefira uma ferramenta que consulte a fonte autoritativa a uma resposta baseada em texto.

O passo zero vem primeiro porque corrigir a especificação da tarefa é o mais barato e porque nenhuma capacidade compensa uma tarefa mal especificada. Depois de cada correção, reavalie a falha original antes de seguir. E se nenhuma pergunta receber "sim", a conclusão é voltar ao diagnóstico: a falha pode ter mais de uma causa, ou a causa pode ainda não ter sido identificada.

Aplicando ao nosso cenário. A tabela mostra como quatro falhas hipotéticas do assistente de ADRs percorreriam a árvore. São exemplos ilustrativos, não resultados.

Falha observada	Teste diagnóstico	Caminho na árvore	Intervenção
O ADR que substituiu o padrão antigo nunca foi indexado	Com o ADR novo no contexto, o modelo acerta	Passo 1: sim	Indexar e corrigir o processo de ingestão
O ADR antigo, "superseded", é recuperado no lugar do novo	O modelo acerta quando só o ADR vigente é fornecido	Passo 1: sim	Curadoria: status e relação de substituição, filtro na recuperação
O modelo recebe o ADR certo e ainda recomenda o padrão antigo	Com contexto e instrução claros, o erro persiste, ou some com uma instrução melhor?	Passo 0 primeiro; depois passo 2	Reforçar a instrução de priorizar a decisão vigente; fine-tuning só se persistir
A pergunta é se uma API ainda está ativa hoje	A fonte de verdade é o catálogo, não um documento	Passo 3: sim	Ferramenta que consulta o catálogo de APIs

Observe o que as quatro linhas têm em comum: nenhuma pede, como primeiro passo, que se escolha entre RAG e fine-tuning. Três delas se resolvem sem tocar nos pesos do modelo. É exatamente o que a tese do artigo antecipa, mas vale repetir o limite: são quatro cenários escolhidos para ilustrar o procedimento, e não uma estimativa de com que frequência cada causa aparece na prática.

Checklist antes de agir. Em qualquer equipe, antes de aprovar uma intervenção, vale conseguir responder:

Qual é a falha, e ela está registrada com entrada, saída esperada e saída obtida?
Qual teste diagnóstico confirmou a categoria da causa?
Qual é a alternativa mais barata que já foi tentada?
Como saberemos que a intervenção funcionou, com qual conjunto de avaliação e qual critério definido antes de rodar?

8. O princípio de engenharia

Voltemos, uma última vez, ao time que viu o assistente recomendar um padrão arquitetural abandonado. Na versão da conversa que começa pela técnica, eles saem com uma decisão: fine-tuning ou RAG. Na versão que começa pela falha, saem com uma pergunta respondida: o que, exatamente, deu errado nessa resposta? A segunda versão é mais lenta no primeiro dia e mais barata em todos os outros.

O princípio que este artigo propõe cabe em uma frase: diagnostique a falha antes de escolher a técnica. Para aplicá-lo, três ideias:

Separe saber, comportar-se e fazer. Conhecimento, comportamento e execução são problemas diferentes (H1), e cada um aponta para uma capacidade diferente: recuperação, adaptação do modelo ou ferramentas. Antes deles, confirme que a tarefa está bem especificada.
Cure o acervo antes de culpar o modelo. Uma parte das falhas de conhecimento é falha de curadoria (H2): o acervo contém, por desenho, o vigente e o obsoleto, e nenhuma técnica sobre o modelo distingue um do outro sem status, datas e relações explícitas.
Exija evidência antes de intervir. Registre a falha, confirme a categoria com um teste diagnóstico, tente a alternativa mais barata e defina, antes de rodar, como saberá que funcionou.

Uma ressalva final, por coerência com o que o artigo pede. H1 e H2 são hipóteses de trabalho, não resultados: a pesquisa que revisamos mostra que as técnicas atuam em lugares diferentes, mas nenhum dos estudos testa a distinção entre decisão vigente e obsoleta, e a árvore de decisão é uma síntese do autor. O valor dela está em oferecer um procedimento que o seu time pode testar e corrigir com os seus próprios dados, não em substituir esse teste.

A pergunta "RAG ou fine-tuning?" não está errada por ser inútil. Está errada por chegar cedo demais. Quando o diagnóstico vem antes, ela volta como uma pergunta melhor: qual destas capacidades a minha falha está pedindo?

A série Beyond the Model

Este é o primeiro artigo da série Beyond the Model, sobre as decisões que transformam modelos de linguagem em sistemas de software confiáveis. Nos próximos, a série aprofunda os dois pontos que ficaram em aberto aqui:

Stop Adding RAG to Everything detalha a taxonomia de falhas: como uma resposta errada se classifica em conhecimento, recuperação, instrução, raciocínio, ferramentas ou comportamento, e por que cada causa aponta para uma intervenção diferente.
Before You Fine-Tune an LLM, Prove That You Need To mostra como transformar a decisão em experimento: baseline, conjunto de avaliação, métricas e critério de decisão definidos antes de treinar.

Se você já passou por uma conversa como a do início deste artigo, conte nos comentários qual foi a falha que motivou a discussão e qual intervenção o time escolheu. Esses casos são exatamente o material de que os próximos artigos precisam.

Referências

Barnett, S. et al. (2024). Seven Failure Points When Engineering a Retrieval Augmented Generation System. arXiv:2401.05856
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020
Hu, E. J. et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685
Ovadia, O. et al. (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. arXiv:2312.05934
OpenAI. Optimizing LLM Accuracy
Gekhman, Z. et al. (2024). Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?. EMNLP 2024
Yang et al. (2026). Fine-Tuning vs. RAG for Multi-Hop Question Answering with Novel Knowledge. arXiv:2601.07054 (preprint)
Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 Nov 2011
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 199–220
Pan, S. et al. (2024). Unifying Large Language Models and Knowledge Graphs: A Roadmap. IEEE TKDE (arXiv:2306.08302)
Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130
Zhang, T. et al. (2024). RAFT: Adapting Language Model to Domain Specific RAG. arXiv:2403.10131 (preprint)
Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629 (ICLR 2023)
Schick, T. et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761
Model Context Protocol. Specification. (revisão 2026-07-28)
Zaharia, M. et al. (2024). The Shift from Models to Compound AI Systems. BAIR Blog, 18 Feb 2024
Anthropic (2024). Building Effective Agents. 19 Dec 2024
Soudani, H., Kanoulas, E., Hasibi, F. (2024). Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge. arXiv:2403.01432
Balaguer, A. et al. (2024). RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture. arXiv:2401.08406 (preprint)
Abonizio, H., Almeida, T. S., Lotufo, R., Nogueira, R. (2025). Comparing Knowledge Injection Methods for LLMs in a Low-Resource Regime. arXiv:2508.06178 (preprint)
Mecklenburg, N. et al. (2024). Injecting New Knowledge into Large Language Models via Supervised Fine-Tuning. arXiv:2404.00213 (preprint)
Liu, N. F., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP 2023 (arXiv:2304.09848)
OWASP GenAI Security Project. LLM08:2025 Vector and Embedding Weaknesses
Anthropic. Model deprecations. (consultado em 2026-10-10)
OpenAI. Deprecations. (consultado em 2026-10-10)