Case Studies
All case studies
🔎

RAG Platform

Retrieval-augmented generation with grounded, cited answers instead of confident hallucinations.

AIArchitectureLLM
TypeScriptOpenAI/Claude APIVector DB (pgvector)Node.js

A retrieval-augmented generation pipeline that turns a document corpus into embeddings, retrieves relevant chunks per query, and asks the LLM to answer strictly from that context — with source citations attached to every claim.

Embeddings

Source documents are chunked using a semantic-aware splitter (targeting ~500 tokens per chunk with ~15% overlap) rather than naive fixed-length splitting, so chunks don't cut sentences or code blocks mid-thought. Each chunk is embedded and stored alongside its source document ID, section heading, and character offsets — the metadata needed to reconstruct a citation later.

Re-embedding is incremental: a content hash per chunk means only changed sections of a document are re-embedded on update, instead of re-processing the whole corpus on every content change.

  • Semantic chunking (~500 tokens, 15% overlap) instead of naive fixed-length splitting
  • Chunk metadata stores source doc ID, heading, and offsets for later citation
  • Content-hash based incremental re-embedding — only changed chunks are reprocessed

Retrieval

Retrieval is hybrid: a vector similarity search (cosine, top-20) is combined with a keyword/BM25 pass, then merged and re-ranked, because pure embedding search alone tends to miss exact-match queries (error codes, specific API names) that keyword search catches trivially.

The re-ranked top results are deduplicated by source document (capping how many chunks from a single doc can dominate the context window) before being passed to the LLM, to keep the context diverse rather than over-representing one long document.

  • Hybrid retrieval: vector similarity + BM25 keyword search, merged and re-ranked
  • Per-document cap on retrieved chunks to keep context diverse
  • Top-k tuned per query type — factual lookups use fewer, higher-precision chunks; broad questions use more

LLM integration

The system prompt constrains the model to answer only from the retrieved context and explicitly say when the context doesn't contain an answer, rather than falling back on parametric knowledge — this is the single biggest lever against hallucination. Retrieved chunks are injected with explicit source tags (e.g. [source:doc-14#section-3]) so the model can reference them directly in its answer.

Responses are streamed token-by-token to the client, with a lightweight post-processing pass that extracts citation tags from the completed answer and validates them against the actual chunks that were retrieved — if the model invents a citation that wasn't in context, it's flagged rather than shown as trustworthy.

  • System prompt enforces context-only answers with explicit 'not found in context' fallback
  • Retrieved chunks are tagged with source IDs the model can cite inline
  • Streamed responses with post-hoc citation validation against actually-retrieved chunks

Source citations

Every answer renders with inline, clickable citation markers that deep-link to the exact source document and section the claim came from — not just 'source: doc.pdf' but the specific paragraph. Citations that fail validation (referenced but not actually retrieved) are stripped before the answer reaches the user, so a visible citation is always a guarantee, not a suggestion.

  • Inline citations deep-link to the exact section/offset in the source document
  • Unvalidated or hallucinated citations are stripped before rendering — visible citations are always verifiable
  • Users can expand any citation to see the exact retrieved chunk the model was given