RAG & Knowledge Systems
Outcomes
Answers instead of search results
People ask a question in their own words and get a direct answer with a link to the paragraph it came from. The citation matters as much as the answer, because it lets someone verify in five seconds rather than trust blindly.
Institutional knowledge stops walking out the door
Documentation nobody reads becomes documentation the system reads. The knowledge that lived with three long-tenured people becomes accessible to everyone.
Support and internal query load drops
A meaningful share of internal questions are re-asks of things already documented. Deflecting them frees the people who currently answer them.
Accuracy you can measure
We build an evaluation set of real questions with known correct answers, and report retrieval and answer quality as numbers. Systems without this are trusted on vibes until the first bad answer destroys that trust permanently.
What we build
Ingestion pipeline. Connectors to where your content actually lives — Confluence, SharePoint, Google Drive, Notion, Zendesk, S3, your database, PDFs on a file share. Incremental sync so answers reflect current content, not a snapshot from launch day.
Document processing. The unglamorous work that determines whether the system succeeds: parsing PDFs that are really scans, preserving table structure, keeping headings attached to their content, handling multi-column layouts. Most RAG failures are document processing failures wearing a retrieval costume.
Chunking and indexing. Structure-aware chunking rather than fixed character counts, with metadata for filtering. Hybrid search combining semantic and keyword retrieval, because pure vector search reliably fails on exact terms — product codes, error numbers, policy references.
Reranking and query handling. Retrieve broadly, rerank precisely. Query rewriting for vague or conversational questions. Handling for questions that span multiple documents, which naive implementations answer confidently and wrongly.
Answer generation with citations. Every claim traceable to a source passage. Explicit refusal when the corpus does not contain the answer — a system that says "this is not covered in the documentation" is more valuable than one that improvises.
Permission-aware retrieval. Users see answers only from documents they are entitled to read. Enforced at retrieval, not filtered afterwards. This is a hard requirement in most enterprises and a common reason pilots fail their security review.
Evaluation harness. A question set with known answers, measuring retrieval recall, answer accuracy, citation correctness and refusal behaviour. Run on every change so improvements are demonstrable and regressions are caught.
How it works
Week 1 — Corpus assessment. We examine what you actually have. Volume, formats, quality, duplication, contradictions, how current it is. Contradictory documentation is extremely common and the system will surface it, so we plan for that rather than being surprised by it.
Week 1–2 — Evaluation set. Fifty to two hundred real questions with verified correct answers, drawn from your support tickets, internal chat, or subject-matter experts. Built before the system, because it defines what "working" means.
Weeks 2–4 — Pipeline build. Ingestion, processing, chunking, indexing, retrieval. Measured against the evaluation set from the first working version.
Weeks 4–6 — Retrieval tuning. Where the quality is won. Chunking strategy, hybrid weighting, reranking, query rewriting, metadata filters. Iterated against measurements, not impressions.
Weeks 6–8 — Interface and access control. The surface people use — web, Slack, Teams, or embedded in an existing tool — plus permission enforcement and feedback capture.
Weeks 8–10 — Pilot and iteration. Real users, real questions. Failure cases collected and added to the evaluation set. This phase reliably reveals question types nobody anticipated.
Ongoing. Content sync, periodic re-evaluation, tuning as the corpus grows. RAG systems degrade quietly as content drifts; ownership is not optional.
Technology
Vector stores: Postgres with pgvector where you already run Postgres and volume is moderate — often the right answer and rarely the recommended one. Qdrant, Weaviate or Pinecone at larger scale or where managed operation matters.
Search: hybrid retrieval with BM25 alongside dense vectors. Elasticsearch or OpenSearch where you already run them.
Models: embedding model selected by benchmark against your corpus rather than by reputation. Generation via Claude, GPT, Gemini, or open-weight models self-hosted where data residency requires it.
Document processing: layout-aware parsing, OCR for scanned material, table extraction. This layer usually needs the most custom work.
Frameworks: LlamaIndex or LangChain where they help, direct implementation where they add indirection without value. We are not committed to either.
Where this applies
Strongest where a large, reasonably well-maintained corpus exists and people repeatedly need answers from it.
Weakest where documentation is thin, badly out of date, or contradictory. RAG surfaces the state of your content; it does not improve it. If the corpus is poor, fixing it comes first, and we will say so rather than build a system that confidently returns wrong answers.
Frequently asked questions
The system searches your documents for passages relevant to a question, then asks a language model to answer using only those passages. The model contributes language understanding; your documents contribute the facts. That is why answers can cite sources and why they stay current as your content changes.
RAG for knowledge that changes or requires citation, which is most business use cases. Fine-tuning for teaching a model a style, format or specialised task. They are not alternatives so much as different tools, and they are frequently combined. If someone recommends fine-tuning for a knowledge problem, ask how they will handle a document being updated.
Well-built systems constrain answers to retrieved content, cite sources, and refuse when the corpus lacks the answer. Fabrication risk is real but manageable, and it is measurable — our evaluation harness tests refusal behaviour explicitly. Any vendor claiming zero hallucination is overselling.
As current as your sync. Incremental ingestion typically runs hourly or daily; real-time is possible where the source supports it. Stale content is the most common cause of trust loss, so sync design gets real attention.
Yes, and it must. Retrieval is filtered by the requesting user's entitlements before generation, so a user cannot receive an answer derived from a document they cannot open. We integrate with your existing identity and permission model.
Then the system will reflect that, and the assessment in week one will tell you so directly. Sometimes the right recommendation is to fix a subset of content first. That is a cheaper conversation now than after launch.
Text formats are straightforward. PDFs vary enormously — a text-native PDF is easy, a scanned one needs OCR, and a scanned one full of tables needs real work. We assess your actual files rather than assuming.
Measured retrieval accuracy, answer accuracy, and citation correctness against the evaluation set, plus in-product feedback and query logs showing what people ask and where the system fails. You get numbers, not impressions.
More AI services
AI Strategy Consulting
Turn scattered AI ambition into a sequenced, costed plan. We decide what to build, what to buy, what to ignore, and in what order.
AI Readiness Audit
A 3–4 week assessment of your data, systems and processes that returns a ranked, costed list of AI use cases and an honest verdict on what you can deploy now.
Agentic AI Automation
We build AI agents that complete multi-step work inside your systems — with defined scope, human checkpoints, and evaluation. Deployed to production, not demos.