---
id: "lib-2026-10-26-retrieval-s-bottleneck-is-moving-from-finding-to"
type: "library"
title: "Retrieval's bottleneck is moving from finding to selecting"
lang: "EN"
org: "kapa.ai"
source_type: "Practitioner post"
date: "2026-10-26"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-26-retrieval-s-bottleneck-is-moving-from-finding-to/"
original_url: "https://www.kapa.ai/blog/retrieval-bottleneck"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A clear diagnostic from retrieval vendor kapa.ai, tracing answer-critical chunks through a production pipeline on its own benchmark; useful framing, but self-reported numbers on an in-house dataset whose size is not given."
summary_basis: "full-text"
original_minutes: "8"
tags: ["ai technology", "future of work", "enablement", "business transformation", "retrieval", "rag", "support assistants"]
---

# Retrieval's bottleneck is moving from finding to selecting

Tier B (Useful, limited): A clear diagnostic from retrieval vendor kapa.ai, tracing answer-critical chunks through a production pipeline on its own benchmark; useful framing, but self-reported numbers on an in-house dataset whose size is not given.

Summary based on the full text.

## In short

A blog post (26 October 2026) by Matteo Bortoletto and Janis Fluri of kapa.ai, which sells retrieval-based assistants over company knowledge. They argue that search now finds most of what a question needs, and that answers fail increasingly because the pipeline drops needed chunks when deciding what the model gets to read. Showing the model more chunks raises recall but adds cost and noise; agentic retrievers move the same trade-off into their own context.

## Key numbers

- 34%: share of needed chunks that search found but that were never shown to the retriever (the selection gap)
- 80% to about half: share of failed cases caused by search not finding the chunk, about 18 months ago against today
- 14%: increase in questions where the answer model gets the needed chunks when going from top 5 to top 10 chunks per search
- one in twenty-five: chunks returned by a grep-based agent that the answer actually needs
- about two-thirds: share of query cost taken by retrieved chunks in the vendor's assistants

## What it reports

- About 18 months ago, about 80% of failed test cases came from search never finding the needed chunk; today it is about half, with the other half lost at reranking.
- Of the needed ("gold") chunks search found, 34% never reached the retriever.
- Moving from top 5 to top 10 chunks per search raises by 14% the share of questions where the answer model receives the needed chunks, with diminishing returns after that.
- Retrieved chunks are about two-thirds of the cost of a query in the vendor's assistants.
- A grep-based agent matches the vendor's deep retriever on recall, but only about one in twenty-five of its chunks is needed; the vendor's retriever returns about an eighth of the text at about six times the precision.

## How they got it

Gold chunks for each question in the vendor's Company Knowledge Bench were traced through a simplified pipeline: GPT-6 Luna for query decomposition, Voyage-3 reranking, 50 chunks retrieved and top 15 returned. Interchangeable gold chunks were ignored for simplicity.

## Limits

- The benchmark is the vendor's own; its size and question mix are not stated in the post.
- The illustrative pipeline is not the vendor's production agentic retriever.
- The comparison with grep favours the vendor's product and is not independently reproduced.

## Why it matters for companies

Teams evaluating internal knowledge assistants often report recall only, which rewards systems that dump more text into the model. This post makes the case for scoring precision and cost alongside recall, and for checking where needed documents are lost: at search or at selection. The fix differs, and adding more context is the expensive answer.

Original: https://www.kapa.ai/blog/retrieval-bottleneck