All services

Retrieval you can measure.

Most RAG systems are never measured, which is why most of them quietly return the wrong passage. We build retrieval against a labelled set drawn from your real questions, so recall is a number you can look at. Hybrid search where keywords still matter, reranking where meaning does, chunking tuned to your documents rather than to a default, and a refusal path when nothing relevant is found.

80–90%
Less time per full profile
Weekshours
ESG extraction cycle
40%98%
Five-part template adherence

Built for production, not the demo.

01 / RAG

Retrieval over your own data, for answers that have to come from it.

For answers that have to come from your data. Hybrid search, reranking and chunking tuned against a real eval set, built to refuse rather than improvise.

Usually shipped with

  • Document extraction
  • Data pipelines for AI
  • LLM evaluation

Not a bundle to buy. Whichever you start from, the engagement covers what the build actually needs.

02 / Scope

What we build.

  • Hybrid search blending semantic and keyword retrieval
  • Reranking tuned against a labelled set from your real questions
  • Chunking strategies fitted to your documents, not a library default
  • Recall measured at k, so retrieval quality is visible before generation
  • A refusal path when the index holds nothing relevant
  • LlamaIndex or a hand-built pipeline over pgvector or Qdrant, chosen on the corpus rather than on habit

03 / Outcomes

What you can ship.

  • Question answering over internal knowledge
  • Retrieval that reports its own accuracy
  • Grounded assistants that decline instead of guessing

04 / Deliverables

Artefacts, not activities.

  • The retrieval pipelineIngestion, chunking, embedding, hybrid search and reranking, running against your corpus.
  • A labelled eval setReal questions with correct passages, and the recall numbers measured against it.
  • The grounding layerPrompting, citation format and refusal behavior, tested against the same set.

05 / Stack

What it is built on.

Retrieval
Hybrid search / Reranking / Vector DBs / LlamaIndex / pgvector / Qdrant / Weaviate
Embeddings
Text embeddings / Late interaction
Models
Claude / GPT / Open models
Evaluation
Recall@k / Faithfulness checks

06 / Why us

We measure recall before we touch the prompt

Most RAG debugging is prompt work on what is actually a search problem. Splitting the two saves weeks: if recall at ten is seventy percent, no model can exceed seventy percent, and swapping models will not help.

Refusal is a feature we build deliberately

On Brandiligence the model may only cite firm-approved authorities, enforced by a validator rather than by instruction. A system that cannot decline is a system that will invent.

Chunking is fitted, not defaulted

On DocVerse, filings are chunked so a metric keeps the page it came from. Character-count chunking would have severed exactly the lineage the client needed.

A path from your problem to production.

  1. Week 1

    Build the eval set first

    Fifty to a hundred real questions with the passages that answer them. Without this there is no accuracy number, and every later change is a guess.

  2. Week 1-3

    Get retrieval right before generation

    Hybrid search, chunking fitted to your documents, and reranking, tuned until recall at k is where it needs to be. No prompt fixes a passage that was never fetched.

  3. Week 3-4

    Then tune the answer

    Grounding instructions, citation format, and a refusal path when the index holds nothing relevant.

  4. Week 4-6

    Wire it to the index that will actually run

    Incremental reindexing, freshness, and the monitoring that tells you when retrieval quality drifts.

Retrieval is two pipelines, not one box.

The corpus lane runs once, offline: chunk, embed, and build an index that holds both keyword and vector representations, because pure vector search misses exact terms your users actually type. The query lane runs per request: rewrite the question, retrieve candidates, rerank them with a cross-encoder, and ground the answer so every claim cites its span. Most failed RAG builds have collapsed these two into one.

YOUR CORPUSSCRUBsecrets never indexedCHUNK & EMBEDsplit · vectoriseHYBRID INDEXBM25 + vectors + ACLsbuilt once, offlineA QUESTIONIDENTITYscoped tokenREWRITEexpand · decomposeRETRIEVEfiltered to the callerIN YOUR SCOPE?RERANKcross-encoderGROUND & CITEanswer ← spansGUARDRAILSbefore it is returnedA CITED ANSWERrun per requestone index, many scopesTHE SET NARROWSretrieved → reranked → keptWHAT WAS RETRIEVED, AND FOR WHOM
Translucent glass shelves receding in ordered rows

Production-proven

Built by engineers who've already shipped this in production.

The questions buyers actually ask.

How accurate will it be?

We cannot tell you before we measure, and anyone who does is guessing. The first two weeks produce a recall number against your own questions, and that number is the ceiling on answer accuracy.

Do we need a vector database?

Sometimes. Plenty of corpora are served better by a good keyword index with reranking. We pick after measuring, not before.

What if the answer is not in our documents?

It refuses. That is the behavior we build for deliberately, because a system that always answers is a system that invents when it should decline.

Can this run over data we cannot send to a provider?

Yes, with a data boundary in front or with open models on your own infrastructure. Both are things we build.

Let's scope your rag systems build.

Tell us where you are and what you're trying to ship. We'll come back with a concrete plan, the right engineers, and a path to production, not a generic pitch.