AWS додала функцію стиснення з урахуванням запиту (query-aware compression) до свого сервісу Bedrock, що дозволяє розробникам відсікати нерелевантні фрагменти документів перед тим, як вони потраплять до мовної моделі. Зменшуючи кількість токенів, які передаються моделі, ця функція може знизити витрати на обчислення для конвеєрів Retrieval-Augmented Generation (RAG).
Чому конвеєри RAG витрачають багато грошей
Системи RAG спочатку витягують текстові уривки з бази знань, а потім передають ці уривки генеративній моделі, щоб відповісти на запитання користувача. Більшість реалізацій відправляють кожен отриманий фрагмент безпосередньо до моделі, навіть якщо значна частина тексту не має жодного стосунку до запиту. Кожне зайве слово стає токеном, а кожен токен, який обробляє модель, збільшує вартість запиту до базового API. Для малих і середніх компаній, які використовують ботів підтримки або інструменти внутрішнього пошуку, витрати на токени можуть швидко перевищити вартість самих викликів моделі.
Що робить стиснення з урахуванням запиту
Нова можливість Bedrock додає етап фільтрації між етапами пошуку (retrieval) та генерації:
- Система все одно витягує той самий набір документів для запиту.
- Перед тим як модель побачить будь-який текст, легкий процесор оцінює кожен уривок на відповідність конкретному запитанню.
- Зберігаються лише ті частини, які визнані релевантними; все інше відкидається як шум.
Вам не потрібен новий індекс, модель ембедінгів (embedding model) або донавчена (fine-tuned) мовна модель. Зміна полягає лише в переналаштуванні конвеєра для виклику рівня стиснення.
Вплив на бізнес
Оскільки плата за токени зростає разом із обсягом тексту, що надсилається до моделі, видалення нерелевантних фрагментів може суттєво зменшити рахунок по кожній позиції. Компанії, які спостерігали, як їхні витрати на RAG стрімко зростали разом із масштабуванням використання, отримають найбільшу вигоду.
На що звернути увагу далі
- Протестуйте функцію на власних даних: Проведіть порівняльне тестування стандартного потоку RAG і потоку, що включає стиснення з урахуванням запиту. Виміряйте кількість токенів, затримку (latency) та релевантність відповідей.
- Прозорість постачальника: Оцінюючи сторонні RAG-платформи, запитуйте, чи використовують вони стиснення або фільтрацію у своїх конвеєрах пошуку. Постачальник, який передає сирі фрагменти (raw chunks), швидше за все, виставлятиме вищі щомісячні рахунки.
Підсумок
Невелика зміна в конвеєрі — фільтрація нерелевантного тексту перед тим, як він потрапить до моделі — може перетворити приховані витрати на керовану статтю бюджету. Для організацій, які вже використовують RAG на базі Bedrock, увімкнення стиснення з урахуванням запиту є експериментом із мінімальними зусиллями, проте будь-яка економія залежатиме від ваших конкретних даних.