Service · published 23 Aug 2026
RAG systems that cite their sources.
We've built the same retrieval spine three times in production — aviation manuals, regulatory corpora, supplier data — and we run it daily. Hybrid search, reciprocal-rank fusion, LLM reranking, self-correcting retrieval, and answers that cite the exact source page.
RAG consulting is the design, build, and tuning of retrieval-augmented generation systems — the architecture where a language model answers from your documents, with retrieval quality, grounding, citations, and cost engineering deciding whether the system is trustworthy enough to use.
The architecture we've proven
Query routing, rewriting and expansion feed a hybrid search — dense retrieval on pgvector fused with Postgres full-text via reciprocal rank fusion — then an LLM reranker orders candidates before the answer streams back with inline citations beside the source document. A retrieval-sufficiency evaluator re-queries with sub-questions when context is weak instead of answering from bad ground. Parent–child chunking (small chunks for recall, large parents for context) and a 100-case golden eval set with LLM-as-judge scoring keep quality measurable. No LangChain — every stage is code we own and can trace.
Cost and observability are part of retrieval
Our production assistant traces every interaction to its tool calls, token usage, latency, and dollar cost — $0.006–0.02 per query, measured, not estimated. The corpus is an explicit, versioned ingestion set: documents are re-indexed deliberately, never silently. If your current RAG system can't tell you what a query costs or why it retrieved what it retrieved, that's usually the first thing we fix.
Questions we actually get
- What does a production RAG query actually cost?
- In our production system — hybrid search, LLM reranking, generation, and a sufficiency check included — $0.006 to $0.02 per query, measured across live traffic with per-query tracing. Costs concentrate in reranking and generation; embedding and retrieval are comparatively cheap.
- Do we need a vector database like Pinecone or Weaviate?
- Usually not to start. All five of our production systems run retrieval on pgvector inside Postgres — HNSW indexes, hybrid dense-plus-full-text search, and the operational simplicity of one database. Dedicated vector stores earn their place at scales and workloads most business corpora never reach.
- How do you stop a RAG system from hallucinating?
- Grounding is architectural, not a prompt instruction: retrieval-sufficiency checks that refuse to answer from weak context, inline citations to the exact source page so every claim is verifiable, an integrated document viewer so users check the source in one click, and an eval set that scores groundedness continuously. You can't make a model incapable of error — you can make errors visible and rare.
- Fine-tuning or RAG?
- For knowledge that changes — policies, manuals, regulations, catalogs — RAG, almost always: it updates by re-ingesting documents, cites sources, and doesn't require training runs. Fine-tuning earns its cost for style, format, or narrow classification tasks. Most teams asking this question need better retrieval, not a trained model.
- How long does a production RAG build take?
- A scoped assistant over a defined corpus typically ships to first production users in weeks, not quarters — but 'production' for us includes tests, ingestion management, cost tracing, and an eval set, because that's what makes week six calmer than week one. Discovery week establishes the real scope for your corpus and users.
- Can you fix an existing RAG system that performs badly?
- Yes — most underperforming RAG systems share the same three gaps: retrieval quality (no hybrid search or reranking), no evaluation set (so nobody can say what 'better' means), and no per-query observability. We audit against those first; often the fix is targeted rather than a rebuild.
The fastest way to find out if this fits: a free audit on one workflow — an honest answer on whether it's worth building, and a written summary you keep either way.