49% or 67%: reranking is a second stage, not a setting

Contextual Retrieval can reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%. The two figures sit in one sentence, which makes them read as a single upgrade with a toggle at the end. They are not. One changes what you store before any query runs; the other changes what happens after the search returns candidates. Costing them as one project is how the second half never ships.

Two numbers, two builds

The 49% belongs to the chunking change on its own: the stored representation changes, so documents have to be reprocessed before a single query improves. The 67% belongs to that change plus reranking, a stage that scores candidates after vector search hands them over. The gap between the figures is not a measurement of the reranker in isolation, because the published number is for the combination. If you want the reranker's own contribution on your corpus, measure it there.

Write-time and query-time are different budgets

Reprocessing chunks is paid once per document, and again every time you re-chunk. On a platform publishing 8 SEO articles every day across 7 languages, as the Tatano Energy build does, that cost recurs with every ingest rather than once at launch. Reranking is paid on every query instead, in added latency and in an extra scoring call. Decide which budget has room before deciding which stage to add.

A reranker only reorders what it is handed

By default, pgvector performs exact nearest neighbour search, which provides perfect recall; adding an index trades some recall for speed. With HNSW, the dynamic candidate list for search is 40 by default. A second stage cannot recover a chunk that never entered that list, so the candidate count and the reranked top-k are one decision, not two independent settings. Tune them together or the reranker inherits the first stage's misses.

Order-blind metrics hide a reranker

The published figures use 1 minus recall@20: the percentage of relevant documents that fail to be retrieved within the top 20 chunks. Reranking mostly changes order inside that window, so a harness that only asks whether a document was retrieved at all will under-report it. If the prompt receives fewer chunks than the window you measure, the improvement you record is not the one you ship. Fix the window first.

Exact matches are not an ordering problem

Embedding models excel at capturing semantic relationships but can miss crucial exact matches, and a reranker does not repair that: it reorders what arrived. Postgres full-text search answers a different question, with tsvector storing preprocessed documents and tsquery representing processed queries, optionally sorted by relevance. Where product codes, part numbers or names decide correctness, the fix is a second retrieval path rather than a better scorer at the end.

Check whether retrieval is load-bearing at all

If the knowledge base is smaller than 200,000 tokens, about 500 pages of material, the whole thing can go into the prompt with no need for RAG. Neither chunking changes nor reranking has anything to improve in that case. Both interventions assume retrieval is doing real work. The RAG authors also note that providing provenance for decisions and updating world knowledge remain open research problems, which is reason enough to keep retrieved rows inspectable.

Treat the two figures as a sequence, not a bundle. Measure the corpus first; if it fits in the prompt, skip both and revisit when it stops fitting. Otherwise ship the storage-side change, measure with the window you actually pass to the model, then add reranking and measure again on the same harness. Keep the candidate list and the reranked top-k as one pair, and keep a separate path for exact matches.

Sources

pgvector (GitHub) — Open-source vector similarity search for Postgres — https://github.com/pgvector/pgvector

arXiv — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., arXiv:2005.11401) — https://arxiv.org/abs/2005.11401

Anthropic — Introducing Contextual Retrieval — https://www.anthropic.com/engineering/contextual-retrieval

PostgreSQL 18 Documentation — Full Text Search: 12.1. Introduction — https://www.postgresql.org/docs/current/textsearch-intro.html

Neurolinks case study — Four markets, one codebase — https://neurolinks.be/work/tatano-energy