Choosing an Architecture by How It Fails
Architecture comparisons are usually run on accuracy, cost, and latency. Failure mode belongs on that list and is often the criterion that should decide it, because a system’s worst day matters more than its average day. Two designs with the same accuracy can be completely different products: one tells the user it does not know, the other invents something plausible.
Here is how to make that a first-class selection criterion instead of an afterthought.
The three properties of a failure that matter
Is it visible to the user? A search page that returns nothing useful communicates its own failure. A generated paragraph does not. Visible failure means users self-correct and you get feedback; invisible failure means quiet erosion of trust, discovered late and all at once.
Is it visible to you? Some failures show up in metrics and logs. Others — the right passage existed but was not retrieved, the answer was fluent and wrong — require deliberate measurement or you will never see them. An architecture that fails invisibly to both parties needs the quality-measurement staffing described in the team you need to run retrieval in production, and if you cannot fund that, choose differently.
How long is the fix? Minutes, days, or a training cycle. This is the property that determines what your worst day looks like when someone escalates.
How each option fails
Keyword search. Fails by returning nothing, or by returning documents that contain the words in an irrelevant sense. Visible to the user immediately. Diagnosable in one query. Fix time: minutes, usually a synonym or an index setting. The most benign failure profile of any option here, which is why it is worth more than its reputation.
Semantic retrieval with a results page. Fails by ranking the right document below the fold, or by returning things that are topically near but not answering. Still largely visible — a user scanning a list can tell it is a bad list. Diagnosis is harder because “why did this rank here” is not a question dense retrieval answers legibly. Fix time: hours to days.
Retrieval plus generation. Fails by producing a confident, well-formatted, plausibly cited answer built from the wrong material. Invisible to the user by construction; that is what fluency means. Invisible to you unless you measure. Fix time varies from a prompt change to discovering that your chunking has been wrong since launch. This is the profile you are accepting when you choose RAG, and it is the strongest argument in do you need generation, or just better search?.
Documents in the prompt, no retrieval. Fails by the model using the wrong part of a long context, or ignoring material that is present. Uneven use of very long contexts is a well-observed phenomenon — often discussed as the lost-in-the-middle effect — and the practical consequence is that adding material does not reliably improve answers. But it removes an entire failure category: the right passage cannot fail to be retrieved, because everything was there.
Fine-tuning. Fails by stating an outdated or invented fact with no source to check, and the fix requires another training run. Worst fix time of any option, and the failure is maximally invisible because there is no retrieved passage to inspect. See RAG versus fine-tuning as an architecture decision.
Tool calls against a live system. Fails by calling the wrong function, passing a wrong argument, or erroring out. Overwhelmingly the most legible failure in the set: an error is an error, and a wrong argument is inspectable in a log. And the answer, when it works, is as correct as the underlying system.
| Option | Visible to user | Visible to you | Fix time |
|---|---|---|---|
| Keyword search | Yes | Yes | Minutes |
| Retrieval, results page | Mostly | With effort | Hours to days |
| Retrieval plus generation | No | Only if measured | Days to weeks |
| Documents in the prompt | No | Only if measured | Minutes — edit the document |
| Fine-tuning | No | Rarely | A training cycle |
| Tool calls | Yes, as errors | Yes, in logs | Minutes to hours |
Matching the profile to the stakes
The right question is not “which fails least” but “which failure can this use case absorb.”
When a wrong answer is cheap and self-correcting — a documentation assistant for engineers who will notice, an internal search tool over material users know well — invisible failure is tolerable, and you can take the accuracy and convenience of generation.
When a wrong answer is expensive and the user cannot check it — anything customer-facing that states a policy, a price, an entitlement, a deadline — invisible failure is the risk, not the inconvenience. Prefer architectures that surface the source document, or put a human between the answer and the user. The sizing exercise for this is in the cost of being wrong.
When the answer is a fact with a system of record — an order status, a balance, a renewal date — choose tool calls, because the failure is an error rather than a fabrication, and because you inherit the correctness of a system somebody already maintains.
When you cannot measure quality yet, choose visible failure on purpose. This is the case that most often gets decided wrongly, because generation demos better. A results page that is honestly mediocre beats a chatbot that is invisibly mediocre, and it converts to a chatbot later with the retrieval work already done.
The composite that is usually right
The strongest designs mix profiles rather than picking one, and route by the stakes of the question:
- Facts with a system of record go to tool calls.
- Exact identifiers go to keyword search.
- Everything else goes to retrieval, and the answer shows its sources prominently enough that a user can verify in one click.
- Anything above a stakes threshold — a refund, a legal commitment, a medical or safety topic — refuses and hands off, rather than answering well.
Point four is a product decision that engineering cannot make alone, and it is the one that most reliably prevents your worst day. Deciding it requires naming the categories of question your system will decline to answer, in writing, before launch.
The recommendation
Add failure mode as an explicit column in your architecture comparison, and weight it by whether your users can verify the answer. If they cannot, discount generation heavily relative to options that put a source document in front of them.
Prefer legible failure while you are learning your domain, and buy invisibility only once you have the measurement capability to see through it. The cost of a quality function is the price of admission to generated answers; if it is not funded, the architecture choice is already made.
The threshold that flips it: when your quality measurement can reliably tell you the fabrication rate on real traffic, invisible failure stops being a governance problem and becomes an engineering number you can drive down. Until you can produce that number, choose the architecture that fails out loud. Then price the whole thing properly: what a RAG system actually costs to run.