AWS Machine Learning Blog подробно описал технику снижения расходов на retrieval-augmented generation (RAG) системы, построенные на Amazon Bedrock. Подход, названный query-aware compression, фильтрует найденные фрагменты текста относительно конкретного запроса пользователя перед их отправкой в базовую языковую модель — вместо того чтобы передавать целиком найденные документы или их части как есть.
Большинство RAG-систем извлекают фиксированное количество фрагментов документов на каждый запрос и передают все их в контекстное окно модели, независимо от того, насколько этот текст релевантен вопросу. Это раздувает количество токенов на запрос — а поскольку Bedrock и большинство хостируемых LLM берут плату за токен, это напрямую увеличивает счёт. Метод AWS оценивает и обрезает найденный контент до частей, которые действительно важны для конкретного запроса, снижая количество токенов, отправляемых модели, без необходимости менять индекс поиска или базовую модель.
Это важно операционно, потому что RAG стал архитектурой по умолчанию для AI-ботов поддержки, внутреннего поиска по знаниям и ассистентов для продаж в малых и средних компаниях — систем, которые отвечают на вопросы, извлекая данные из документов компании, тикетов или мануалов продукта, а не полагаясь исключительно на обучающие данные модели. По мере масштабирования использования от пилота до полного развёртывания расходы на токены из-за раздутых контекстных окон часто становятся крупнейшей статьёй затрат, превышающей стоимость самих вызовов модели.
Для B2B-компании с 10-200 сотрудниками, уже использующей или пилотирующей RAG-инструмент поддержки или поиска на Bedrock, эта техника применима напрямую: это модификация конвейера, а не смена архитектуры, и в посте AWS есть механика, необходимая для внедрения. Компаниям, оценивающим поставщиков решений по автоматизации AI-поддержки, также стоит спрашивать, применяет ли уже конвейер извлечения поставщика сжатие или аналогичную фильтрацию — разница проявится в ежемесячном счёте, а не на демо.
В посте AWS не приведены цифры по стоимости, бенчмарки задержки или данные о внедрении помимо архитектурного описания; командам стоит считать масштаб экономии зависящим от нагрузки и неподтверждённым, пока не протестируют метод на собственном корпусе данных для извлечения.