Как маленькая модель ИИ отсеивает 68% контекста RAG без потери качества
KAPA.ai создаёт ИИ-ассистентов, которые ищут ответы в больших базах знаний: технической документации, API-справочниках, PDF, форумах. Компания столкнулась с проблемой, которая дорого стоит буквально: компоненты RAG-пайплайна доставляют генеративной модели десятки текстовых отрывков, но большинство из них не нужны для ответа. Каждый игнорируемый отрывок, это затраты на обработку токенов, ведь генератор платит за все прочитанные данные, неважно, пригодились ли они. В системах KAPA извлечённые отрывки составляют две трети стоимости запроса.
Команда испробовала несколько подходов. Реранкеры (модели переранжирования) не сработали, потому что оценивают каждый отрывок в изоляции, не видя, как он взаимодействует с другими, а релевантность часто зависит именно от контекста множества отрывков. Например, отрывок, который в отдельности выглядит как шум, может быть половиной ответа, если его прочитать рядом с предыдущим.
Решение, которое они развернули: добавить между поиском и генерацией третий шаг, вызов маленькой, дешёвой модели, которая видит вопрос и ВСЕ найденные отрывки сразу и оценивает каждый по пятиуровневой шкале. Отрывки выше порога выживают, остальные отбрасываются. На реальных данных: компрессия 68%, сохранено 96% полноты ответов, общее снижение стоимости запроса на 34%, добавляемая задержка, около 0,7 секунды. Так как маленькие модели примерно одинаковы по качеству, они выбрали самую быструю и дешёвую при низких затратах на рассуждение. Параметры: сама модель, порог оценки и keep-top-k (несколько лучших отрывков проходят в любом случае, защищая от ошибок оценки). Они развернули по умолчанию в SDK для построения агентов, где поиск по документам, один инструмент среди множества и контекст под давлением.
Ключевые факты
- Маленькая модель между retrieval и generation видит все отрывки сразу и оценивает каждый по 5-уровневой шкале (в отличие от pointwise реранкеров, которые оценивают отрывки отдельно)
- Результаты на реальных данных: 68% отрывков удалено, 96% полноты сохранено, стоимость запроса снизилась на 34% даже с учётом самого pruner'а
- Pointwise rerankers не работают, потому что релевантность часто зависит от контекста множества отрывков, а не от отрывка в отдельности
- Pruning добавляет ~0,7 секунды в общую задержку, но затем генератор получает меньше входных токенов и начинает быстрее
- Наиболее ценно в сценариях, когда поиск по документам, один инструмент среди десятков в агенте, и контекст под давлением
Почему это важно
В RAG-системах генератор платит за каждый отрывок, даже если он не нужен для ответа. В системах KAPA извлечённые отрывки составляют примерно две трети стоимости запроса, больше, чем сам ответ, история разговора и системный промпт вместе взятые. Даже 4% экономии за отрывок складывается. Между тем в агентах разные инструменты выливают свой вывод в один и тот же контекст, и он растёт быстро. Более плотные результаты поиска покупают место для всего остального, что должен держать агент.
Кому это важно
Командам, которые строят ИИ-ассистентов над большими базами знаний: документация, API-справочники, PDF, форумы, сотни тысяч отрывков. Особенно критично для агентов, где поиск по документам, один инструмент среди множества и окно контекста под давлением. Для single-shot retrieval добавляемая задержка может быть более значимой, но в многошаговых агентах она маргинальна.
Как это применить
Запустить между реранкером и генератором вызов маленькой модели (самой быстрой и дешёвой из доступных, на низких затратах на рассуждение). Модель получает вопрос и все извлечённые отрывки, оценивает каждый по пятиуровневой шкале, отрывки выше порога переходят дальше. Три управляющих параметра: сама модель, порог оценки (основной рычаг между компрессией и полнотой) и keep-top-k (несколько лучших переранжированных отрывков проходят в любом случае, защищая от ошибок). По умолчанию развёрнуто в SDK для агентов; опционально в retrieval API и MCP servers.
Можно ли доверять
Компания измеряла полнота (recall) на помеченном наборе реальных вопросов, где известно, какие отрывки нужны для ответа. Затем проверили компрессию, стоимость и задержку, переиграв каждую конфигурацию через месяц реальных production-разговоров на тех же отрывках. На выбранной точке (96% recall): 1 из 25 вопросов теряет отрывок, который был нужен; в обмен две трети контекста уходит и счёт за запрос падает на 34%.
Риски и подводные камни
Pruning добавляет ~0,7 секунды в критический путь. Генератор не ускоряется значительно: меньше входных токенов, ответ начинает быстрее, но на долю секунды. Для задержка-критичных single-shot путей это реальная цена. Второй риск: неправильный выбор модели или порога может привести к потере нужных отрывков. Требует тестирования на собственных данных. Третий: в сценариях, где полнота критична, даже 1 из 25 потерянных отрывков может быть недопустима, нужна более консервативная настройка с более низкой компрессией.
«Релевантность, это не свойство отдельного отрывка. Реранкеры оценивают каждую пару запрос-отрывок в изоляции, никогда не глядя на другие отрывки, которые были извлечены вместе с ним.»
— Lars Baltensperger, KAPA.ai