When a client asks us to add "AI" to their product, the first real engineering decision is almost never which model to use — it's whether the problem needs retrieval or fine-tuning. Getting this wrong is the single most common reason LLM projects stall.
The short version
- Retrieval-Augmented Generation (RAG) — pull relevant facts from your own data at query time and hand them to the model as context. Best when your underlying data changes often (support tickets, product catalogs, internal docs).
- Fine-tuning — retrain the model's weights on examples of the behavior you want. Best when you need to change how the model responds (tone, format, a narrow skill) rather than what it knows.
When we reach for RAG
Almost every client engagement starts here, because most "AI feature" requests are really "let the model answer questions about our own data" — and that data keeps changing. RAG means the knowledge base updates independently of the model: no retraining, no redeployment, and the model can cite its source.
The tradeoff is retrieval quality. A RAG system is only as good as its chunking strategy and embedding search — a bad retrieval step means the model confidently answers from irrelevant context.
When we reach for fine-tuning
Fine-tuning earns its cost when the ask is behavioral, not informational — a fixed output format, a specific voice, or a narrow classification task where in-context examples alone aren't reliable enough at production volume.
What we actually do
In practice, most production systems we ship end up being RAG with a lightly fine-tuned or well-prompted base model — retrieval handles the "what do we know," and prompting or a small amount of fine-tuning handles the "how do we say it." Treat them as complementary tools, not a single either/or choice.
Building something like this? Tell us what you're building and we'll scope it.