Зменшення витрат на RAG на Amazon Bedrock завдяки інтелектуальному стисненню

Вступ до проблем витрат RAG

У сучасному світі генеративного штучного інтелекту архітектури пошуку та доповненої генерації (RAG) стали основою корпоративних застосунків, які потребують точних та контекстних відповідей. Однак, оскільки ці системи розвиваються та широко впроваджуються, витрати, пов'язані з обробкою токенів, зростають експоненціально. Кожен запит, надісланий до моделі великої мови програмування (LLM), споживає значну кількість токенів, і в контексті RAG отримані документи можуть додавати тисячі додаткових токенів до кожного запиту. Ця економічна реальність швидко стає серйозною проблемою для компаній, які прагнуть масштабувати рішення штучного інтелекту, не витрачаючи при цьому свій бюджет на хмарну інфраструктуру.

Компанія Amazon Web Services визначила цю критичну проблему та розробила інноваційне рішення, доступне на платформі Amazon Bedrock : контекстно-залежне стиснення, також відоме як стиснення з урахуванням запитів . Ця технологія революціонізує спосіб керування отриманими документами в системах RAG, видаляючи нерелевантну інформацію та зберігаючи лише вміст, необхідний для генерації відповіді. Результатом є різке скорочення кількості оброблюваних токенів, що безпосередньо призводить до суттєвої економії коштів без шкоди для якості чи точності відповідей, згенерованих на основі моделі.

Що таке стиснення з урахуванням запитів і як воно працює?

Фундаментальний принцип контекстного стиснення

В основі стиснення з урахуванням запитів лежить елегантний принцип: не вся інформація в отриманому документі є релевантною для заданого запиту. Традиційно системи RAG надсилають весь вміст отриманих документів до мовної моделі, незалежно від того, яка частина цього вмісту фактично сприяє відповіді. Такий підхід не тільки дорогий, але й потенційно шкідливий для якості відповідей, оскільки моделі LLM можуть відволікатися на нерелевантну інформацію або страждати від явища, відомого як «втрата посередині» , коли інформація в середині довгого контексту ігнорується або обробляється неправильно.

Стиснення з урахуванням запитів вирішує цю проблему за допомогою двоетапного процесу. На першому етапі система аналізує запит користувача та отримані документи, щоб визначити уривки з найвищою семантичною релевантністю. На другому етапі вона застосовує алгоритми стиснення, які усувають надлишковий або нерелевантний контент, залишаючи лише фрагменти, які з високою ймовірністю сприяють формулюванню правильної та повної відповіді. Такий підхід значно зменшує кількість токенів, що надсилаються до моделі LLM, зберігаючи при цьому семантичну точність наданого контексту.

Технічна архітектура рішення на Amazon Bedrock

Технічна реалізація стиснення з урахуванням запитів (Query-Aware Compression) на Amazon Bedrock передбачає використання спеціалізованої моделі стиснення, яка виступає посередником між кроком пошуку та кроком генерації в конвеєрі RAG. Ця модель стиснення, часто менша та економічно ефективніша мовна модель, оцінює кожен текстовий сегмент у отриманих документах та призначає йому оцінку релевантності відносно поточного запиту. Сегменти з оцінками нижче певного порогу відкидаються, а решта об'єднуються та надсилаються до основної моделі генерації.

В екосистемі Amazon Bedrock ця архітектура виграє від вбудованої інтеграції з такими сервісами, як Amazon Bedrock Knowledge Bases , Amazon OpenSearch Serverless та Amazon S3 . Потік даних починається зі зберігання документів у S3, їх індексації в OpenSearch Serverless за допомогою вбудовування, згенерованих моделями, доступними в Bedrock, отримання відповідних документів під час запиту, стиснення отриманого контексту та, нарешті, надсилання стиснутого контексту до моделі LLM для генерації остаточної відповіді. Кожен компонент у цьому конвеєрі управляється та автоматично масштабується інфраструктурою AWS, забезпечуючи комплексний досвід без операційних перешкод.

Кількісно вимірні економічні вигоди від інтелектуального стиснення

Зменшення витрат за допомогою токенівКонтекстне вікно

Найбільш прямою та кількісно вимірною перевагою стиснення з урахуванням запитів є зменшення кількості вхідних токенів, що обробляються на запит. Великі мовні моделі, такі як моделі Claude від Anthropic або Titan від Amazon, зберігають вхідні та вихідні токени окремо. У типових RAG-застосунках вхідні токени переважно надходять з отриманих документів, які можуть становити 70-90% від загальної кількості токенів, що обробляються на запит. Стискаючи ці документи, організації можуть зменшити витрати на вхідні дані на 30-80% , залежно від типу документів та специфіки запитів.

Щоб зрозуміти фінансовий вплив у конкретних термінах, розглянемо типовий сценарій для підприємства: компанія обробляє 1 мільйон RAG-запитів на місяць, причому кожен запит отримує в середньому 5 документів із середньою кількістю 500 токенів на документ. Без стиснення це означає 2,5 мільярда щомісячних вхідних токенів лише з отриманих документів. Зі ступенем стиснення 60% ця цифра падає до 1 мільярда токенів, що призводить до суттєвої економії, яка може сягати десятків тисяч доларів на місяць, залежно від використовуваної моделі та її ціни за токен.

Покращення продуктивності затримки та якості відповіді

Окрім прямої фінансової економії, інтелектуальне стиснення приносить значні переваги з точки зору затримки та якості відповіді . Моделювання LLM послідовно обробляє токени, а коротший контекст означає менший час обробки. У корпоративних додатках, де затримка є критично важливою, таких як чат-боти підтримки клієнтів або системи допомоги в режимі реального часу, це зменшення затримки може значно покращити взаємодію з кінцевим користувачем і дозволити масштабування до більшої кількості одночасних користувачів без пропорційного збільшення інфраструктури.

Щодо якості відповідей, дослідження показали, що моделі LLM генерують відповіді вищої якості, коли наданий контекст є лаконічним та релевантним. Видалення інформаційного шуму з контексту RAG зменшує ймовірність того, що модель генеруватиме галюцинації або буде відволікатися суперечливою чи нерелевантною інформацією. Таким чином, стиснення з урахуванням запитів – це не лише оптимізація витрат, але й покращення внутрішньої якості системи RAG , що забезпечує подвійну цінність для інженерних команд та зацікавлених сторін бізнесу.

Практичне впровадження на Amazon Bedrock

Налаштування RAG-конвеєра зі стисненням

Впровадження стиснення з урахуванням запитів у базах знань Amazon Bedrock є напрочуд доступним навіть для команд, які не мають великого досвіду з оптимізацією RAG. AWS інтегрувала цю функціональність безпосередньо в існуючі API Bedrock, що дозволяє вмикати стиснення за допомогою простого налаштування параметрів. Процес налаштування включає визначення моделі стиснення, яка буде використовуватися для оцінки релевантності текстових сегментів, встановлення мінімального порогу релевантності для включення сегментів у стиснутий контекст та налаштування стратегії фрагментації для вихідних документів.

З точки зору коду, інтеграція здійснюється через AWS SDK популярними мовами, такими як Python, JavaScript або Java. Типовий приклад реалізації Python включає використання клієнта boto3 для виклику Bedrock API з параметрами стиснення, зазначеними в тілі запиту. Ключовим параметром є retrievalConfiguration , який приймає об'єкт конфігурації стиснення, що включає тип стиснення ( ENABLED або DISABLED ) та використану модель стиснення. AWS рекомендує використовувати меншу та ефективнішу модель для кроку стиснення, щоб підтримувати оптимальне співвідношення витрат і вигод по всьому конвеєру.

Розширені стратегії оптимізації стиснення

Для команд, які прагнуть отримати максимальну віддачу від стиснення, існує кілька передових стратегій, які варто дослідити. Перша стратегія — адаптивне стиснення на основі типу запиту : прості фактичні запити можуть отримати вигоду від більш агресивних коефіцієнтів стиснення, тоді як складні запити, що потребують синтезу кількох джерел інформації, можуть вимагати більш насиченого контексту. Впровадження класифікатора запитів, який динамічно налаштовує поріг стиснення, може додатково оптимізувати співвідношення вартості та продуктивності системи RAG.

Друга вдосконалена стратегія — це ієрархічне стиснення , коли документи спочатку стискаються на рівні абзаців, а потім на рівні речень, застосовуючи подвійний фільтр релевантності. Цей підхід особливо ефективний для довгих, інформаційно щільних документів, таких як технічні звіти, юридичні контракти або медична документація. Третя стратегія передбачає використання зворотного зв'язку від моделі генерації для постійного вдосконалення моделі стиснення, створюючи цикл безперервного вдосконалення, який коригує пороги та стратегії стиснення на основі якості згенерованих відповідей.

Порівняння з альтернативними підходами до оптимізації витрат RAG

Стиснення з урахуванням запитів проти зменшення кількості отриманих документів

Поширений альтернативний підхід до зменшення витрат на RAG полягає в простому зменшенні кількості документів, що отримуються для кожного запиту, тим самим зменшуючи загальну кількість вхідних токенів. Ця стратегія проста в реалізації, але має фундаментальний недолік: вона знижує повноту системи , тобто ймовірність того, що відповідна інформація буде включена в контекст, наданий моделі. У корпоративних застосунках, де точність є критично важливою, зниження повноти не є прийнятним варіантом.

Стиснення з урахуванням запитів пропонує кращу альтернативу: замість зменшення кількості отриманих документів, ви отримуєте аналогічну або навіть більшу кількість документів, але стискаєте кожен документ, щоб витягти лише відповідну інформацію. Таким чином, ви зберігаєте або покращуєте повноту системи, одночасно зменшуючи кількість оброблених токенів . Це очевидна цінність, яка перевершує наївний підхід до скорочення кількості документів.

Стиснення з урахуванням запитів проти підсумовування документів

Ще один популярний метод оптимізації RAG полягає у попередній обробці документів шляхом створення резюме та зберігання цих резюме замість повних документів. Такий підхід зменшує витрати на пошук, але має свої обмеження: резюме створюються офлайн, без інформації про майбутні запити, і можуть пропускати певні деталі, що стосуються певних типів запитів. Крім того, створення резюме для великого корпусу документів вимагає значних початкових витрат і має повторюватися щоразу, коли документи оновлюються.

Стиснення з урахуванням запитів – це онлайн-адаптивний підхід : стиснення виконується під час запиту, з точним знанням запиту користувача, що дозволяє набагато точніше вибирати релевантну інформацію. Недоліком є ​​те, що це додає затримку та граничні витрати на етапі стиснення, але ці витрати, як правило, менші, ніж економія, отримана за рахунок зменшення кількості токенів, що надсилаються до основної моделі генерації.

Варіанти використання для підприємств та галузей

Застосування у фінансовій та юридичній сферах

У фінансовому секторі системи RAG використовуються для аналізу річних звітів, оцінки ризиків складних контрактів та відповідей на регуляторні питання. Документи в цих областях відомі своєю довжиною та щільністю інформації, що робить їх ідеальними кандидатами для інтелектуального стиснення. Інвестиційний банк, який щодня аналізує сотні звітів фінансового аналізу, може досягти скорочення витрат на 50-70% завдяки впровадженню стиснення з урахуванням запитів, зберігаючи при цьому точність відповідей, необхідну для прийняття критично важливих фінансових рішень.

У юридичній сфері юридичні фірми та юридичні відділи корпорацій все частіше використовують системи RAG для дослідження судової практики, аналізу контрактів та підготовки справ. Юридичні документи, з їхньою специфічною структурою та щільною технічною мовою, отримують величезну користь від контекстного стиснення. Можливість швидко витягувати відповідні пункти з контракту на сотні сторінок, без обробки всього документа за допомогою дорогої моделі LLM, являє собою фундаментальну трансформацію операційної ефективності в юридичній галузі.

Застосування в охороні здоров'я та наукових дослідженнях

У галузі охорони здоров'я системи RAG на базі Amazon Bedrock використовуються, щоб допомогти лікарям швидко знаходити відповідну інформацію з медичної літератури, клінічних рекомендацій та історій пацієнтів. Медичні статті та клінічні випробування – це надзвичайно щільні документи з розділами про методологію, результати та обговорення, які можуть бути або не бути релевантними до конкретного запиту. Стиснення з урахуванням запитів дозволяє медичним системам RAG швидко витягувати відповідну клінічну інформацію, зменшуючи витрати на обробку та покращуючи швидкість реагування в критично важливих ситуаціях.

У наукових дослідженнях академічні установи та науково-дослідні компанії керують величезними корпусами наукових публікацій. Можливість ефективно запитувати ці корпуси з контрольованими витратами демократизує доступ до синтезу наукових знань та пришвидшує темпи відкриттів. Зменшуючи витрати на RAG за допомогою інтелектуального стиснення, установи з меншими бюджетами можуть отримати доступ до можливостей синтезу наукової літератури, які раніше були зарезервовані лише для організацій зі значними фінансовими ресурсами.

Міркування щодо впровадження у виробництво

Моніторинг та оцінка якості стиснення

Впровадження стиснення з урахуванням запитів у продакшені вимагає надійної стратегії моніторингу, щоб економія коштів не відбувалася за рахунок якості відповіді. AWS рекомендує впроваджувати систему оцінювання, яка одночасно вимірює вартість запиту, затримку, коефіцієнт стиснення та якість відповіді . Метрики якості можуть включати оцінки доповненої генерації пошуку (RAGAS), чіткі відгуки користувачів та автоматизовані оцінки на основі потужніших моделей LLM, що використовуються як оцінювачі.

Такі вбудовані інструменти AWS, як Amazon CloudWatch та AWS X-Ray , можна налаштувати для відстеження кожного етапу стиснутого RAG-конвеєра, забезпечуючи детальну видимість продуктивності системи. Автоматизовані сповіщення можуть повідомляти інженерні команди, коли коефіцієнти стиснення значно відхиляються від очікуваних значень або коли показники якості падають нижче попередньо визначених порогових значень, що дозволяє швидко втручатися для коригування параметрів стиснення.

Міркування щодо безпеки та відповідності

У корпоративних розгортаннях важливо забезпечити, щоб процес стиснення не створював вразливостей безпеки та не порушував вимог до відповідності. Усі дані, оброблені в рамках конвеєра RAG на Amazon Bedrock, отримують вигоду від шифрування під час передачі та зберігання , детального контролю доступу, що забезпечується AWS IAM , та повного аудиту через AWS CloudTrail . Організації в регульованих галузях, таких як фінанси чи охорона здоров'я, повинні забезпечити, щоб використовувана модель стиснення не розкривала конфіденційні дані, а вся обробка відбувалася в межах географічних та організаційних меж, встановлених чинними правилами.

Стиснення запитів з урахуванням запитів на Amazon Bedrock є важливим кроком у розвитку екосистеми RAG для використання в масштабах підприємства. Вирішуючи одну з найактуальніших проблем у впровадженні RAG-систем у великих масштабах, AWS надає організаціям конкретний інструмент для контролю витрат на генеративний штучний інтелект без шкоди для якості чи можливостей систем, які вони розгортають. Поєднання зниження вартості токенів, покращення затримки та підвищення якості відповіді робить цю техніку однією з найцінніших останніх інновацій у сфері інфраструктури генеративного штучного інтелекту.

Забігаючи вперед, еволюція методів контекстного стиснення принесе ще більше оптимізацій. Моделі стиснення, орієнтовані на предметну область, адаптивні алгоритми стиснення, які навчаються на відгуках користувачів, та інтеграція стиснення з розширеними методами повторного ранжування та семантичної фільтрації – це активні напрямки досліджень та розробок, які обіцяють ще суттєвіше зниження витрат. Для організацій, які інвестують у побудову інфраструктури RAG на Amazon Bedrock сьогодні, впровадження стиснення з урахуванням запитів – це не просто тактична оптимізація витрат, а стратегічне рішення, яке дозволяє цим організаціям ефективно та стабільно масштабуватися в епоху генеративного штучного інтелекту.

Зменшення витрат на обробку токенів до 80% шляхом впровадження стиснення з урахуванням запитів. Покращення якості відповідей шляхом видалення інформаційного шуму з контексту RAGS. Масштабування корпоративних RAGS-застосунків без пропорційного збільшення витрат на інфраструктуру. Користування перевагами власної інтеграції з екосистемою AWS для моніторингу та безпеки. Динамічне адаптування коефіцієнта стиснення залежно від типу та складності запитів. Підтримка відповідності галузевим нормам за допомогою власних засобів контролю безпеки AWS.