Most AI projects do not fail because the model is bad. They fail in the gap between a prototype that impresses a room and a system that still works when a real user asks something the demo never covered.
That gap is engineering work, and it is fairly predictable.
Retrieval is the hard part, not generation
When a domain assistant gives a wrong answer, the model is usually not at fault — it was handed the wrong context. Chunking strategy, embedding choice, hybrid search and reranking matter more than which frontier model you picked.
Two practical rules:
- Cite everything. If an answer cannot point at a source paragraph, treat it as a bug, not a feature.
- Measure retrieval separately from generation. Otherwise you cannot tell which half is broken.
You need an evaluation set before you need a better prompt
A golden set of fifty real questions with known-good answers is worth more than weeks of prompt tuning. Without it, every change is a guess and every regression is invisible until a client finds it.
Build it from questions people actually asked. Re-run it on every change. Keep the score in the pull request.
Cost is a design constraint, not an invoice surprise
Token spend scales with usage, and usage scales with success. Model the cost per transaction during the assessment, put a hard ceiling in the code, and log spend per feature so it can be attributed.
If you cannot say what one query costs, you do not have a production system yet.
Know when the answer is not AI
A rules engine, a fixed integration or a better report often beats a model on cost, latency and reliability. Recommending against a build is a normal outcome of our four-week assessment — and it is usually the cheapest advice a client gets all year.
If any of this maps onto something you are dealing with, tell us about it.