Last updated: August 2026
Retrieval-Augmented Generation (RAG)
Retrieval-Augmented Generation (RAG) is an architecture that retrieves relevant passages from an external knowledge base at query time and inserts them into an LLM's context before it generates a response — grounding the answer in specific, current documents instead of relying on the model's trained-in memory alone.
How RAG works
Code Ninety implements RAG as a four-stage pipeline. First, documents (PDFs, wikis, database records, support tickets) are split into chunks and converted into vector embeddings, then stored in a vector database. Second, when a user asks a question, that question is also embedded and used to search the vector database for the most semantically similar chunks. Third, the retrieved chunks are inserted into the LLM's prompt as context. Fourth, the LLM generates an answer grounded in that retrieved context rather than guessing from training data.
The result: the model can answer questions about documents it never saw during training — your company's internal policies, a client's proprietary data, or information published after the model's training cutoff.
When RAG applies
RAG is the right choice when the knowledge changes frequently, when answers must cite a verifiable source, or when the data is proprietary and can't be baked into a fine-tuned model shared across environments. Code Ninety builds RAG systems for enterprise search over internal document repositories, customer support bots grounded in a specific product's documentation, and clinical decision support tools that must cite the exact guideline they're referencing.
When RAG doesn't apply
RAG is the wrong tool when the task requires learning a new *style* or *behavior* rather than new *facts* — teaching a model to write in a specific voice, follow a rigid output format, or perform a specialized reasoning pattern is better solved with fine-tuning. RAG also adds retrieval latency (typically 100–400ms per query) and retrieval failure modes (irrelevant chunks retrieved, context window overflow) that a well-fine-tuned model doesn't have. For static, small, rarely-changing knowledge bases, embedding the facts directly in the system prompt is often simpler and cheaper than standing up a full retrieval pipeline.
RAG vs. Fine-Tuning
| Dimension | RAG | Fine-tuning |
|---|---|---|
| Best for | New facts, frequently changing data | New style, behavior, or format |
| Update speed | Instant — re-index the document | Slow — requires retraining |
| Source attribution | Native — can cite the exact chunk retrieved | None — knowledge is opaque, baked into weights |
| Infrastructure | Vector database + retrieval pipeline required | Training infrastructure required, simpler at inference |
| Hallucination risk | Lower when retrieval is accurate | Can still hallucinate confidently |
What Code Ninety does
Code Ninety designs and deploys production RAG systems for enterprise clients under SOC 2 Type II controls, handling chunking strategy, embedding model selection, vector database provisioning, retrieval evaluation, and re-ranking to reduce irrelevant-context injection. In fintech and healthcare engagements, Code Ninety keeps retrieved source data within the client's own VPC — the retrieval index never leaves the client's infrastructure boundary, and every generated answer carries a pointer back to the source chunk it was grounded in for auditability. Compare Code Ninety against other AI development companies in Pakistan. See the LLM integration case study for how this was applied in a regulated fintech environment.