RAG isn’t one thing

“RAG” gets used like a single product feature, but in practice it’s a pipeline with different failure modes:

  • Candidate retrieval: find a small set of potentially relevant text.
  • Chunking strategy: decide what a “unit of meaning” looks like for a given document.
  • Reranking / scoring: reorder those candidates so the right context wins.
  • Context packaging: present only what the model needs (and avoid drowning it).

If you tune only one step (usually embeddings + vector similarity) you often get retrieval that feels “mostly right” but fails on the moments that matter: decisions, obligations, defined terms, and “what changed since last week?”

That’s where document-type profiles change the game.

The RAG types you should actually know

Lexical retrieval (keyword / exact-term match)

Use this when the query’s exact tokens are meaningful:

  • Error codes and identifiers like ERR_CONNECTION_REFUSED
  • API paths like /api/purchase-orders
  • Domain terms that must match spelling

Lexical retrieval is strong at precision, but it can miss intent when the wording differs.

Semantic retrieval (vector / embeddings)

Use this when the user is asking by meaning:

  • “Where is this business rule documented?”
  • “Which architecture decision covers this?”

Semantic retrieval is strong at intent, but it can lose exact-term guarantees (the thing that makes legal/technical search “trustworthy”).

Hybrid retrieval (blend semantic + lexical)

Hybrid retrieval combines the strengths:

  • Semantic matches bring intent and conceptual similarity.
  • Exact-term lookup anchors you to identifiers, clause wording, and defined terms.

For enterprise knowledge, hybrid usually wins because users frequently mix intent with exact constraints.

Chunking: treat document type as an input, not an afterthought

Chunking decides what ends up in your retrieval candidates. If your chunks don’t match how humans use the document, reranking can’t fully compensate.

ContextHarbor’s approach is to apply document-type-aware chunking profiles:

  • Transcripts: topic-window chunking that extracts decisions and action items at ingest.
  • Contracts: clause-based splitting with defined terms carried into search.
  • Specs: requirement-oriented chunking so obligations stay intact.
  • Status reports: whole-document indexing with time decay so recent reports rank higher.
  • User stories: retrieval tuned for templated boilerplate without drowning signal.

Below is how to think about each type through the lens of both chunking and reranking.

Reranking strategies by doc type (what to boost, what to penalize)

When I say “reranking,” I mean the ordering step after you have candidates. It can be purely scoring/boost-based (often the fastest production option) or it can be model-based. In either case, you want reranking to reflect the kind of context a document type represents.

ContextHarbor positions reranking around hybrid retrieval plus doc-type boosts, so “what you care about” changes by document type.

1) Transcripts: decisions and action items first

Chunking strategy (what to extract):

  • Split into topic windows (the natural conversation units).
  • Ensure each chunk contains the decision moment and any follow-up commitments.

Reranking strategy (what to score):

  • Boost candidates that contain decision language and explicit action items.
  • Prefer chunks where the conversation is self-contained (decision + “who/what/when” together).
  • When the user question is about “what did we agree?” reranking should overweight decisions over background discussion.

Why this matters: transcripts are noisy. Without decision/action-item-aware ordering, you often retrieve “the right meeting” but the wrong part of it.

2) Contracts: clauses and defined terms must stay grounded

Chunking strategy (what to extract):

  • Split by clause boundaries rather than by arbitrary length.
  • Carry defined terms along with the clause so retrieval can respect the contract’s internal vocabulary.

Reranking strategy (what to score):

  • Use hybrid retrieval where exact terms matter (defined term matching is usually non-negotiable).
  • Boost clauses that match the defined terms present in the query.
  • When the query asks about obligations/permissions, reorder candidates so the most relevant clauses rise to the top (not the most “similar” paragraphs).

Why this matters: contracts fail in boring ways—if the clause doesn’t match the term, the answer looks plausible and is still wrong.

3) Specs: keep requirements intact so obligations don’t fragment

Chunking strategy (what to extract):

  • Chunk around requirements, not around lines of text.
  • Keep acceptance criteria, constraints, and “shall/must” statements together.

Reranking strategy (what to score):

  • When a query includes requirement-like phrasing (“must support…”, “shall be…”, requirement IDs), boost chunks that contain those obligation statements.
  • If the query is conceptual (“how should this behave?”), semantic retrieval can help—but reranking should still prioritize chunks that include the actual obligation content.

Why this matters: spec search isn’t “finding related ideas.” It’s finding the binding statements.

4) Status reports: recency is a first-class ranking signal

Chunking strategy (what to extract):

  • Whole-document indexing is often better for status reports because the document frequently contains: goals, current state, blockers, and outcomes in one narrative.
  • Apply a time-aware approach so newer reports don’t lose to older ones just because they are less similar.

Reranking strategy (what to score):

  • Apply time decay during scoring.
  • When the user asks “what’s the latest on X,” reranking should naturally favor the newest relevant evidence.
  • Keep semantic relevance, but don’t allow “old but embedding-similar” content to outrank “recent and relevant.”

Why this matters: time is context. Without time-aware reranking, status search becomes a historical archive, not an operations tool.

5) User stories: tame templated boilerplate without hiding real signal

Chunking strategy (what to extract):

  • User stories often follow templates (As a…, I want…, so that…).
  • Chunking and extraction should avoid turning repeated template boilerplate into the dominant retrieval signal.

Reranking strategy (what to score):

  • De-emphasize repeated fields that appear in many stories.
  • Boost story-specific content: the “intent” behind the story, the acceptance criteria, and any differentiators that answer the user’s question.
  • If the query asks “what will we do?” reranking should favor the fields that map to execution outcomes, not the generic template text.

Why this matters: boilerplate is cheap to match and expensive to ignore. Good reranking makes the system behave like a teammate who knows which parts are worth quoting.

Why this matters in production

Once you tune doc type chunking + doc type reranking, RAG stops being a generic “search over text” feature and becomes a knowledge layer that matches how work is actually documented.

That’s the promise ContextHarbor makes explicit:

  • Per-type hybrid weights plus boosts for decisions, action items, and defined terms.
  • Document-type profiles that apply the right chunking and intent handling for transcripts, contracts, specs, status reports, and user stories.
  • Retrieval that blends semantic meaning with exact-term anchoring—so the answer is both relevant and grounded.

If you’re evaluating private knowledge retrieval for teams (and you don’t want to rebuild the pipeline for every new document format), I can help you scope an approach that fits your environment.

Request a consultation

Continue the Discussion

If you want help designing retrieval that teams can trust (chunking profiles, hybrid weighting, and reranking signals), book a CTO consultation.

If you’re evaluating ContextHarbor, you can also start from the product page: /products/context-harbor/.