ainews
AWS показала, как сжать сотни документов для AI без потери смысла
Amazon представила технику task-aware knowledge compression (TAKC) — альтернативу классическому RAG для работы с сотнями документов одновременно. Вместо поиска похожих фрагментов система сжимает весь массив знаний в 8-64 раза под конкретную задачу, сохраняя связи между документами. Результат: финансовый аналитик может спросить про риски с учётом контрактов поставщиков и судебных дел — AI видит всю картину, а не топ-5 кусков текста.
Если вы строите enterprise AI на сотнях внутренних документов (финансы, контракты, комплаенс), это может решить главную боль RAG — неспособность находить связи между разными файлами. Плюс open-source референс от AWS, который можно адаптировать под свои задачи.
Когда RAG больше не справляется
Представьте: венчурный фонд анализирует сделку на $500 млн. В руках — финансовая отчётность 12 дочерних компаний за 5 лет, 200+ контрактов с поставщиками, отчёты о соблюдении экологических норм с 8 заводов и 50+ судебных дел. Аналитик спрашивает: «Какие финансовые риски с учётом условий поставщиков и текущих судебных разбирательств?» Классический RAG с similarity search тут беспомощен — нужная информация разбросана по сотням документов, а связи между ними не имеют лексического сходства.
Как работает TAKC
Task-aware knowledge compression от AWS решает проблему по-другому. Вместо поиска похожих фрагментов система заранее сжимает все документы под конкретную задачу с помощью LLM. Ключевое слово — «task-aware»: один и тот же годовой отчёт сжимается по-разному для финансового анализа (выручка, маржа, кэш-флоу) и для комплаенс-проверки (нормативные ссылки, нарушения).
Сжатие происходит офлайн, один раз на документ на тип задачи. При запросе система достаёт сжатую версию, а не оригинал. Степень сжатия — от 8x до 64x. Самое лёгкое (8x) сохраняет ~87,5% контекста и подходит для многошаговых рассуждений. Ультра-уровень (64x) убирает ~98,4% и годится для простых lookup-запросов.
Умная маршрутизация
Query complexity analyzer автоматически определяет сложность вопроса и направляет его на нужный уровень сжатия. Простые факты — из ultra-compressed кэша (дёшево), сложная аналитика — из lightly compressed (дорого, но только когда надо).
Архитектура на AWS
Реализация — два serverless-пайплайна на Lambda: один для ingestion (сжатие документов), второй для запросов. API Gateway для REST-эндпоинта, ElastiCache Serverless для кэша, Cognito для JWT-токенов. Amazon выложила полный open-source код для развёртывания в своём аккаунте.
Ключевое отличие от RAG: система видит весь сжатый knowledge base, а не топ-k чанков. Связи между документами сохраняются, потому что компрессия видит их вместе.
Ключевые выводы
- Классический RAG плох для задач, где ответ требует информации из сотен документов — similarity search не находит кросс-документные связи
- TAKC сжимает документы под конкретную задачу заранее: один документ может иметь разные сжатые версии для финансов, юридики, комплаенса
- Четырёхуровневая компрессия (8x/16x/32x/64x) с автоматическим роутингом: простые вопросы — дёшево из ultra-compressed кэша, сложные — из lightly compressed
- В отличие от RAG, система работает со всей сжатой базой знаний сразу, а не с топ-k фрагментами
- AWS опубликовала полную serverless-реализацию на Lambda/ElastiCache/API Gateway — можно развернуть в своём аккаунте
Автор: Анна Мельникова · Источник: aws.amazon.com
**Наконец-то кто-то честно сказал: RAG — не серебряная пуля.** Когда ответ зарыт в связях между десятками документов (а в enterprise это норма), similarity search просто не дотянется до нужной информации. TAKC от Amazon — это не революция, а эволюция: сжимай всё заранее под конкретную задачу, храни разные версии для разных use case, роутируй запросы по сложности. Звучит как здравый смысл, но реализовать это самому — боль.
**Что тут реально ценно:** AWS не просто анонсировала подход, а выложила полный рабочий код на serverless-стеке (Lambda, ElastiCache, API Gateway). Можно развернуть за вечер и потестить на своих документах. Вопрос на миллион — как эта штука переживёт обновление документов и версионирование промптов в проде. В посте упоминают Systems Manager Parameter Store для версионирования промптов, но деталей мало. Если у вас живая база из тысяч документов, которая постоянно меняется, надо продумать стратегию инкрементального ре-компресса. А так — добротный enterprise-подход для тех, кто уже упёрся в потолок обычного RAG.
Комментарии