Retrieval-augmented generation: architecture that holds up in production
A working retrieval pipeline is straightforward. Making it reliable enough to trust with business questions is where the engineering is.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Score value, feasibility and data readiness — all three.
- Narrow, repetitive, recoverable tasks are the best first candidates.
- The cost of being wrong changes the required accuracy dramatically.
- Agree success criteria before the proof of value, not after.
Score on three axes
Value: what changes if this works, expressed in money or time rather than in adjectives. Feasibility: is the task one that current techniques do reliably. Data readiness: does the data exist, is it accessible, is it labelled or labellable.
A use case scoring poorly on any one of the three is not ready, however appealing the others look.
Prefer narrow and repetitive
The best early candidates are high-volume, well-defined tasks where a modest improvement compounds and errors are recoverable. Classification, extraction, routing and summarisation of internal documents all fit.
The worst are broad, judgement-heavy tasks where errors are costly and the correct answer is contested even among experts.
Ask what happens when it is wrong
- Who notices, and how quickly?
- What is the cost of a false positive versus a false negative?
- Is there a human review step, and is it real?
- Can the decision be reversed?
Use cases where errors are invisible or irreversible need much higher accuracy and much stronger oversight, which changes the economics considerably.
Prove it before committing
Run a time-boxed proof of value on real data with success criteria agreed in advance and a genuine option to stop.
The criteria must be agreed before results appear. Deciding afterwards whether the outcome was good enough reliably produces a positive verdict, which is how projects proceed that should not have.
Building an evidence-based pipeline
Organisations that succeed with AI usually run several small assessments rather than one large programme. Maintain a ranked list of candidate use cases, revisited as data and capability improve.
Record why each was deferred. Use cases blocked by data availability often become viable once an unrelated data project completes, and without a record nobody reconnects the two.
Deliver something small and useful early. Credibility earned on a modest working system funds the ambitious one far more reliably than a business case does.
Frequently asked questions
Weeks rather than months. If it cannot be assessed in that time, the scope is too broad and should be narrowed.
That is a finding worth having early. Often a smaller, better-scoped problem is achievable now while data work proceeds for the larger one.
Buy where the capability is commoditised transcription, translation, general document extraction. Build where the value comes from your own data or process.
