RAG Development Services

Retrieval quality is decided before any question is asked. Ingestion means extracting clean text from PDFs, Office files, HTML pages, wikis and ticket systems - including tables, headings and scanned pages that need OCR - and attaching metadata such as source, owner, date, product and access rights. Poor parsing, such as a table flattened into a run of loose numbers, is a common cause of wrong answers.

Chunking splits content into passages the retriever can match. Fixed-size chunks are a starting point, but structure-aware chunking that follows headings, sections and list items usually works better, and prefixing each chunk with its document title and section path gives it context on its own. We test several chunk sizes and strategies against your real questions rather than picking one by default.

Vector search finds passages with similar meaning, but it can miss exact terms - product codes, error messages, names, clause numbers. Keyword search such as BM25 catches those. Hybrid retrieval runs both and merges the results, while metadata filters narrow the search by product, region, date or document type.

A re-ranking model then scores the top candidates against the question and keeps only the best few, which improves precision and keeps the prompt short. For vague or multi-part questions, query rewriting or splitting a question into sub-queries can help. Each step adds latency, so we add it only where evaluation shows a gain.

A RAG system is only as current as its index. We build incremental pipelines that pick up new, changed and deleted documents from each source - through change feeds, webhooks or scheduled syncs - and re-embed only what changed. Deletions matter as much as additions: a withdrawn policy that is still retrievable is worse than no answer.

Each chunk keeps a version and last-updated date, so answers can prefer current material and show when a source was last revised. Changing the embedding model requires a full re-index, so we treat it as a controlled migration with side-by-side evaluation before switching over.

In a company knowledge base, not everyone may see everything. Access rights from the source system - SharePoint, Google Drive, Confluence, a CRM - are captured at ingestion and enforced as filters at query time, so a user can only retrieve passages they could open in the original system. Filtering after generation is not enough, because by then the model has already read the restricted text.

Permission changes need to flow through as promptly as content changes, and we test the boundary explicitly, with users of different roles, as part of the evaluation set.

When a RAG answer is wrong, the cause is either retrieval - the right passage was never found - or generation - it was found but misused. We measure the two separately. Retrieval metrics such as recall and precision at k and mean reciprocal rank show whether the right passages come back. Answer metrics check faithfulness to the retrieved sources, completeness, citation correctness, and whether the system correctly declines when the answer is not in your content.

The test set is built from real questions with known source passages and is rerun after every change to chunking, embeddings, retrieval settings or the model.

RAG suits questions answered by a few passages of text. It struggles with questions that need aggregation across many records - totals, trends, rankings - which are better served by having the model generate a query against a database, or by a conventional report. If your whole corpus is small and stable, placing it directly in the model's context may be simpler. And if the problem is a consistent format or behaviour rather than missing knowledge, retrieval will not fix it. We say so when we see these cases.