Стоимость RAG определяется не только ценой основной модели. Не менее важно, сколько найденного контекста она вынуждена читать при каждом вызове. AWS предлагает сжимать этот контекст с учётом конкретного запроса, но превращать компрессию в обязательный этап для всего трафика не стоит: на узких вопросах она экономит токены, на широких может лишь добавить ещё один вызов модели и задержку.
Что предлагает AWS
Обычный RAG-пайплайн находит top-k фрагментов, иногда ранжирует их, склеивает в промпт и отправляет основной модели. По данным AWS Machine Learning Blog, ретриверы часто настраивают на высокий recall, чтобы нужный материал наверняка оказался среди результатов. Поэтому при 5–20 фрагментах контекст в технических и юридических сценариях может занимать несколько тысяч входных токенов на запрос.
В опубликованной AWS архитектуре после поиска появляется дополнительный этап. Небольшая модель получает пользовательский вопрос и все найденные фрагменты, а затем возвращает только дословные отрывки, относящиеся к вопросу. Уже этот сокращённый контекст читает основная модель и формирует ответ.
В примере AWS роль компрессора выполняет Anthropic Claude Haiku, а итоговый ответ генерирует Anthropic Claude Sonnet. Оба вызова проходят внутри одной AWS Lambda через Amazon Bedrock Converse API. Сверху можно оставить существующий ретривер, включая Amazon Bedrock Knowledge Bases. AWS также пишет, что паттерн совместим с prompt caching, Intelligent Prompt Routing и Rerank API.
Экономика проста только на схеме. Маленькая модель сначала должна прочитать весь найденный контекст и записать сокращённую версию. Экономия появляется, если стоимость этого вызова ниже суммы, которую команда перестаёт платить за входные токены основной модели. Поэтому результат зависит от соотношения цен моделей и фактической степени сжатия.
Где компрессия имеет смысл
Лучший кандидат, на мой взгляд, это узкий запрос к широкому набору найденных документов. Ретривер ради полноты возвращает много материала, но для ответа нужны несколько конкретных фрагментов. В таком случае Haiku читает всё, зато Sonnet получает заметно меньше текста. Именно на дорогом вызове и возникает экономия.
Есть и побочный эффект: AWS отмечает, что удаление нерелевантного контекста уменьшает поверхность для галлюцинаций. Это не гарантия правильного ответа. Но основной модели действительно сложнее отвлечься на соседний раздел документа, если этот раздел до неё не дошёл.
Хуже схема выглядит для широких, сравнительных и обзорных вопросов. Если полезна значительная часть найденных фрагментов, компрессор почти не уменьшит контекст. Команда всё равно оплатит его чтение маленькой моделью, затем передачу сокращённого результата и только после этого вызовет большую. Формально пайплайн стал умнее, практически получил дополнительный счёт и ещё одну точку задержки.
Поэтому query-aware здесь должно означать не только сжатие относительно текста запроса. Тип запроса должен определять, запускать ли компрессию вообще. Для точечного вопроса фильтр может быть выгоден. Для запроса, который требует собрать картину по всему документу, разумнее проверить прямую передачу контекста или другой top-k. Единое правило для всего трафика снова превращает оптимизацию в ритуал.
Что добавляется в продакшен
AWS называет compression call единственным новым этапом стандартного RAG-потока, но для оператора это не мелочь. Нужны вторая модель, доступ к ней в Amazon Bedrock, IAM-права для Lambda, отдельный промпт компрессора и обработка его результата. Главное, появляется ещё одно место, где можно потерять важный фрагмент до того, как его увидит основная модель.
Значит, проверять нужно не среднюю экономию по датасету, а минимум три показателя по классам запросов: долю удалённых входных токенов, качество итогового ответа и добавленную задержку. Среднее легко скроет неудачный сегмент: десятки дешёвых точечных вопросов компенсируют несколько широких запросов, где компрессия не дала ничего или вырезала необходимый контекст.
Практический вывод для российских команд не зависит от перехода на Bedrock. Сам архитектурный рецепт можно воспроизвести в собственном RAG-контуре: дешёвая модель фильтрует найденные фрагменты перед дорогой. Но считать выгоду нужно на реальном распределении запросов, а не на цене токена в прайс-листе.
Маркер успеха простой: после разбиения трафика по типам вопросов должен появиться класс, где стоимость полного ответа устойчиво снижается, а качество не проседает с учётом добавленной задержки. Если такого сегмента нет, компрессор не оптимизирует RAG. Он просто стал ещё одним обязательным участником каждого запроса.