> ## Documentation Index
> Fetch the complete documentation index at: https://retrievalcontextprotocol.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The retrieval pipeline

> RCP is shaped around the canonical production RAG pipeline — each stage maps to a protocol surface a server can offer independently.

RCP is shaped around the canonical production RAG pipeline, so **each stage maps
to a protocol surface**. A server implements whichever stages it offers, and a
client either calls one stage at a time or lets a single `retrieve` run the whole
thing.

```
query ─▶ [transform] ─▶ [retrieve: dense|sparse|hybrid] ─▶ [fuse]
      ─▶ [rerank: cross-encoder|colbert] ─▶ [diversify: mmr]
      ─▶ [pack + cite] ─▶ hits
```

## Stage → surface map

| Stage                           | Method / option                                    | Capability                            |
| ------------------------------- | -------------------------------------------------- | ------------------------------------- |
| Query transformation            | `query/transform`, or `retrieve.rewrite`           | `transform`                           |
| Candidate retrieval             | `retrieve` with `mode` = `dense`/`sparse`/`hybrid` | `retrieve`                            |
| Embedding (for client-side ANN) | `embed`, `embed/sparse`, `embed/multi`             | `embed`, `sparseEmbed`, `multiVector` |
| Fusion                          | `retrieve.fusion` = `rrf`/`weighted`               | (part of `retrieve.hybrid`)           |
| Reranking                       | `rerank` (`method` = `cross-encoder`/`colbert`)    | `rerank`                              |
| Diversification                 | `retrieve.mmr`                                     | `retrieve.mmr`                        |
| Graph retrieval                 | `graph` (`op` = `local`/`global`/`drift`)          | `graph`                               |
| Indexing                        | `index/add`, `index/delete`                        | `index`                               |

## Stage by stage

Every stage except **recall** is optional and independently negotiated — a
server advertises only what it implements, and a client sees the rest as absent.

<Steps>
  <Step title="Transform — sharpen the query" icon="wand-magic-sparkles">
    Rewrite, expand, or decompose the raw query before recall: HyDE (embed a
    hypothetical answer), multi-query (fan out into paraphrases), step-back
    (generalise), or decomposition (split a multi-hop question into parts).
    Exposed as `query/transform`, or folded into a `retrieve` call via
    `retrieve.rewrite`. *Capability:* `transform`.
  </Step>

  <Step title="Recall — cast a wide net" icon="magnifying-glass">
    Fetch a large candidate set cheaply. `mode` picks the matcher: `dense`
    (bi-encoder semantic search), `sparse` (BM25 or learned-sparse / SPLADE
    lexical), or `hybrid` (both at once). This is the one stage always present.
    *Capability:* `retrieve`.
  </Step>

  <Step title="Fuse — merge the lists" icon="code-merge">
    When recall runs more than one matcher, their scores are not comparable, so
    the ranked lists are merged by **rank**: reciprocal-rank fusion (`rrf`) or a
    `weighted` blend. Controlled by `retrieve.fusion`. The exact algorithm is
    available as a reference primitive —
    [`rrf_fuse` / `weighted_fuse`](/features/federation#the-fusion-primitive-rrf-fuse)
    — in every SDK, so client-side fusion matches server-side byte-for-byte.
  </Step>

  <Step title="Rerank — score precisely" icon="arrow-down-wide-short">
    Rescore the surviving candidates with an expensive, accurate model: a
    cross-encoder, ColBERT late interaction (MaxSim), or an LLM judge. Available
    standalone as [`rerank`](/methods/rerank) or inside `retrieve`.
    *Capability:* `rerank`.
  </Step>

  <Step title="Diversify — cut redundancy" icon="shapes">
    Maximal Marginal Relevance (MMR) trades a little relevance for novelty so the
    final set isn't five paraphrases of one passage. Controlled by
    `retrieve.mmr`. *Capability:* `retrieve.mmr`.
  </Step>

  <Step title="Pack + cite — assemble the answer" icon="quote-left">
    Return the best `k` hits, each with its `citation`, `trust` signals, and
    enough chunk context to ground a generation step.
  </Step>
</Steps>

## Beside the pipeline

Three surfaces sit next to the linear flow rather than inside it:

<CardGroup cols={3}>
  <Card title="Graph" icon="diagram-project" href="/methods/graph">
    Local (entity-anchored), global (community-summary), or DRIFT search over a
    knowledge graph — GraphRAG.
  </Card>

  <Card title="Index" icon="database" href="/methods/index">
    Mutate the corpus the pipeline runs over with `index/add` and `index/delete`.
  </Card>

  <Card title="Embed" icon="vector-square" href="/methods/embed">
    Expose the server's vectors so a client can build its own ANN index.
  </Card>
</CardGroup>

## Two ways to drive it

<CardGroup cols={2}>
  <Card title="Let the server run it" icon="wand-magic-sparkles">
    A client that just wants "the best hits for this query" calls `retrieve` and
    lets the server run its full pipeline — transform, recall, fuse, rerank, MMR,
    cite. One request, one ranked list.
  </Card>

  <Card title="Orchestrate it yourself" icon="sliders">
    A client building an agentic loop calls the stages individually —
    `query/transform` to plan, `embed` for a client-side ANN index, `rerank` to
    rescore, `graph` to walk relationships.
  </Card>
</CardGroup>

## The funnel invariant

The three result-size knobs on `retrieve` form a funnel and **MUST** satisfy:

```
candidateK  ≥  rerank.topN  ≥  k
```

The recall stage produces `candidateK` candidates, the reranker rescores the top
`rerank.topN` of them, and the server returns the best `k`. This is why a good
`retrieve` implementation is *cheap-and-wide then precise-and-narrow*.

<Card title="See it end to end" icon="play" href="/methods/retrieve">
  The `retrieve` method drives every stage of this pipeline through one call.
</Card>