Kapa строит AI-ассистентов, которые отвечают на сложные вопросы по большим базам знаний — технической документации, API-референсам, PDF, форумам и тикетам. Разработчики используют их retrieval API, чтобы дать агентам контекст о продукте, и тот же слой поиска питает собственных ассистентов Kapa.
В основе их подхода — классическая связка: ретривер находит релевантные куски (чанки) документации, а генератор (LLM) пишет ответ из них. Проблема в том, что ретривер настроен на максимальный реколл и часто выдаёт много лишнего. Генератор платит за каждый чанк, который вынужден читать: в их ассистентах чанки составляют около двух третей стоимости запроса, больше, чем сам ответ, история диалога и системный промпт вместе взятые. Каждый лишний чанк увеличивает цену примерно на 4%. А в агентах, где каждый вызов инструмента добавляет вывод в тот же контекст, объём растёт быстро — чем плотнее результаты поиска, тем больше места для всего остального.
Простое отсечение по топ-N или фиксированному порогу реранк-скоров не работает. Во-первых, реранк-скор — это порядок, а не абсолютная шкала, и единый отсекатель не подходит. Во-вторых, релевантность не свойство одного чанка: чанк может быть бесполезен сам по себе, но вместе с другим давать половину ответа. Только глядя на весь набор, можно понять, что нужно оставить.
Kapa добавила третий шаг между реранкером и генератором: маленькая дешёвая LLM получает вопрос и все чанки, оценивает каждый по пятиуровневой шкале от «ESSENTIAL» (без чанка ответ не собрать) до «UNRELATED». Модель видит всё сразу и может судить именно набор, а не изолированные куски. Порог отсечения настраивается, а также сохраняется топ-N самых рейтинговых чанков (страховка от ошибок оценки).
Результаты на реальных данных: при конфигурации, которую они выбрали, система выбрасывает около 68% контекста, сохраняя 96% реколла (в одном из 25 запросов теряется нужный чанк). Стоимость запроса падает примерно на 34% с учётом затрат на саму pruning-LLM. Латенси — около 0.7 секунды на запрос, что для чувствительных к задержке однопроходных сценариев ощутимо, но внутри агента, который и так делает несколько LLM-вызовов за шаг, это маржинально.
Прунинг включён по умолчанию в Knowledge Base Search их Product Agent SDK и опционален в retrieval API и MCP-серверах.