Классический RAG-пайплайн упирается в потолок, когда запрос требует анализа сотен документов. Контекстное окно LLM физически не вмещает все релевантные чанки, а увеличение параметра top-k превращает поиск в лотерею: модель получает шум вместо сигнала, точность ответа падает, а затраты на токены растут линейно. Task-Aware Knowledge Compression (TAKC) решает эту проблему радикально - предварительным сжатием базы знаний в задачно-ориентированные представления. Вычислительная нагрузка смещается с этапа инференса на этап подготовки данных, и аналитический запрос, который в классическом RAG требовал бы обработки 500 чанков, выполняется на 8–64 раза более компактном представлении без потери смысловой полноты.
Референсная реализация TAKC с открытым исходным кодом разворачивается на AWS за 30 минут через CDK и использует связку Lambda, Amazon Bedrock и ElastiCache Serverless. Четырёхуровневая система сжатия - от удаления стоп-слов до создания задачно-ориентированных эмбеддингов - позволяет выбрать баланс между точностью и скоростью под конкретный сценарий. Динамический роутер автоматически направляет фактологические запросы в классический RAG, а аналитические - в сжатые представления. Результат: полная обработка базы из 10 000 документов на аналитическом уровне сжатия 64x укладывается в бюджет контекстного окна стандартной LLM.
Почему классический RAG не справляется с аналитикой на сотнях документов
RAG отлично находит иголку в стоге сена - конкретный факт, абзац, определение. Запрос «Какова стоимость лицензии на продукт X?» отрабатывается безупречно: retrieval возвращает 3–5 релевантных чанков, генератор синтезирует ответ. Проблема возникает, когда стог сена сам становится объектом анализа. Запрос «Какие ценовые тренды прослеживаются по всем продуктам за последние два года?» требует агрегации информации из десятков или сотен документов.
Прямолинейное решение - увеличить top-k до 100, 200, 500 - не работает по трём причинам. Во-первых, контекстное окно: даже Claude 4 с окном 200K токенов не вместит 500 полновесных чанков с метаданными. Во-вторых, качество: с ростом k retrieval возвращает всё менее релевантные фрагменты, размывая сигнал. В-третьих, экономика: каждый лишний токен на входе увеличивает счёт за инференс, а ценность дополнительного контекста убывает экспоненциально. Практические замеры на датасетах вроде MuSiQue показывают, что при переходе от 10 к 100 чанкам recall растёт на первые 5–7%, а затем выходит на плато, тогда как latency и стоимость удваиваются.
Аналитический запрос принципиально отличается от фактологического. Ему нужен не точечный факт, а распределение фактов по всей коллекции. RAG с его архитектурой «найти несколько релевантных кусков и скормить модели» для этой задачи не предназначен. Отсюда и падение точности: модель пытается сделать статистический вывод по неполной выборке, что ведёт к галлюцинациям или тривиальным ответам. Подробный разбор четырёх этапов пайплайна RAG, где рождаются галлюцинации - от парсинга до генерации - мы давали в статье «Четыре кита Context Engineering: почему RAG галлюцинирует, даже если промпт идеален».
Что такое Task-Aware Knowledge Compression и как он меняет подход
TAKC инвертирует логику RAG. Вместо того чтобы на лету искать релевантные чанки под каждый запрос, система заранее сжимает всю базу знаний в несколько представлений разной степени детализации. Каждое представление оптимизировано под определённый класс задач. Когда приходит запрос, роутер выбирает подходящий уровень сжатия, и генератор работает с уже подготовленным, семантически плотным контекстом.
Аналогия: классический RAG - это библиотека, где на каждый вопрос вы бежите к полкам, хватаете первые попавшиеся книги по теме и несёте их читателю. TAKC - это заранее подготовленные дайджесты библиотечного фонда: краткий каталог, тематические обзоры, аналитические сводки. Вопрос «Что почитать о микросервисах?» идёт к каталогу, а «Как менялся интерес к темам за последний год?» - к аналитической сводке.
Ключевой выигрыш - в плотности информации. Сжатое представление уровня 64x содержит только те сущности, отношения и паттерны, которые релевантны для аналитических запросов. Шум удалён на этапе preprocessing, а не на этапе retrieval. Модель получает не 100 потенциально релевантных чанков с избыточностью 70%, а компактный срез всей базы знаний, где каждый токен работает на ответ.
Четыре уровня сжатия: от 8x до 64x
Система предлагает четыре уровня компрессии - выбор зависит от требуемой точности ответа и допустимой задержки. Каждый следующий уровень увеличивает степень сжатия ценой частичной потери деталей, но сохраняет семантическую структуру, критичную для аналитики.
Level 1 (8x) - очистка и нормализация. Удаление стоп-слов, приведение терминов к единому регистру и базовым формам, отсев дубликатов. Этот уровень сохраняет исходную структуру документов и подходит для гибридных сценариев, где нужна высокая точность фактологического поиска с элементами агрегации. Полезна для задач вроде «найди все упоминания инцидента X и сгруппируй по датам».
Level 2 (16x) - экстракция сущностей и отношений. На этом уровне из документов извлекаются именованные сущности, связи между ними и ключевые атрибуты. Результат - структурированный граф знаний, очищенный от нарратива. Запрос «Какие контрагенты фигурируют в отчётах чаще всего?» обрабатывается не по текстам отчётов, а по заранее построенному графу, что сокращает объём обрабатываемых данных в 16 раз.
Level 3 (32x) - суммаризация документов. Каждый документ сжимается в абстрактное резюме из 3–5 предложений через вызов LLM на этапе preprocessing. Суммаризация сохраняет смысловое ядро, но отбрасывает примеры, обоснования и второстепенные детали. Этот уровень - рабочий инструмент для периодической аналитики: квартальных обзоров, трендовых отчётов, дайджестов.
Level 4 (64x) - задачно-ориентированные эмбеддинги. Максимальное сжатие: вся база знаний преобразуется в набор плотных векторных представлений, оптимизированных под конкретный класс аналитических задач. Вместо хранения текстов система хранит эмбеддинги, которые кодируют не содержание документов, а их аналитические характеристики - тренды, распределения, аномалии. Запрос «Какие темы показали наибольший рост в этом квартале?» выполняется сравнением эмбеддингов без обращения к исходным текстам.
Динамическая маршрутизация запросов: когда использовать сжатые данные, а когда полные
Роутер - компонент, который классифицирует входящий запрос и направляет его по оптимальному пути. Классификатор анализирует формулировку, ключевые слова и синтаксическую структуру, определяя тип запроса: фактологический или аналитический.
Фактологический запрос - «Сколько стоит услуга X?», «Кто автор документа Y?», «Какая версия API актуальна?» - идёт в классический RAG-пайплайн с поиском по полным текстам. Здесь важна актуальность и точность, а не полнота охвата. Аналитический запрос - «Какие услуги чаще всего покупают вместе?», «Как менялась тональность отзывов по месяцам?», «Какие темы доминировали в отчётах за квартал?» - направляется к сжатым представлениям TAKC.
Роутер не бинарный: он может комбинировать пути. Для запроса «Найди все инциденты, связанные с компонентом X, и покажи тренд по времени» система сначала извлекает релевантные инциденты через RAG, а затем применяет аналитический модуль TAKC для построения временного ряда. Такая архитектура напоминает подход AgenticRetrieveStream, который мы разбирали в статье «Многошаговый семантический поиск: как AgenticRetrieveStream меняет подход к работе с неструктурированными данными» - там планировщик на базе LLM разбивает сложный запрос на подзадачи и итеративно уточняет результаты.
Архитектура TAKC на AWS: Lambda, Bedrock и ElastiCache Serverless
Референсная реализация построена на полностью бессерверном стеке AWS. Выбор сервисов продиктован требованиями к стоимости и масштабируемости: оффлайн-пайплайн сжатия запускается периодически и не потребляет ресурсы в простое, онлайн-обработка запросов масштабируется автоматически под нагрузку.
Оффлайн-контур. AWS Lambda-функции, триггерясь по расписанию или событию обновления данных в S3, выполняют четырехуровневое сжатие базы знаний. Для суммаризации (Level 3) и создания эмбеддингов (Level 4) используется Amazon Bedrock с моделями Claude и Titan Embeddings. Результаты сжатия сохраняются в Amazon ElastiCache Serverless - это критично для онлайн-контура, поскольку задержка при доступе к сжатым представлениям должна быть минимальной. ElastiCache Serverless обеспечивает субмиллисекундный latency без необходимости управлять кластером.
Онлайн-контур. API Gateway принимает запрос, роутер на Lambda классифицирует его и направляет либо к индексу полных текстов в OpenSearch Serverless, либо к сжатым представлениям в ElastiCache. Генератор на Bedrock получает контекст и синтезирует ответ. Вся цепочка укладывается в 1–3 секунды для аналитических запросов, которые в классическом RAG потребовали бы десятков секунд или просто не выполнились бы из-за ограничений контекстного окна.
Схематично архитектура выглядит так: S3 с исходными документами → Lambda-функции сжатия → Bedrock (суммаризация и эмбеддинги) → ElastiCache Serverless (хранение сжатых представлений). Параллельно: API Gateway → Lambda-роутер → OpenSearch Serverless (для RAG) или ElastiCache (для TAKC) → Bedrock (генерация) → ответ. База знаний Amazon Bedrock Managed Knowledge Base может использоваться как источник документов - мы подробно разбирали её настройку и интеграцию в «Полном руководстве по Amazon Bedrock Managed Knowledge Base для агент-ориентированного поиска в 2026 году».
Развертывание за 30 минут с AWS CDK
Референсная реализация TAKC доступна на GitHub под лицензией MIT. Развёртывание через AWS CDK занимает три шага:
- Клонирование репозитория:
git clone https://github.com/example/takc-reference(замените на актуальный URL репозитория проекта) - Настройка переменных окружения в файле
.env: указать регион AWS, идентификаторы моделей Bedrock, параметры кластера ElastiCache - Деплой:
cdk deploy- CloudFormation развернёт Lambda-функции, кластер ElastiCache Serverless, API Gateway и необходимые IAM-роли
После деплоя в консоли появится URL API Gateway - это точка входа для запросов к TAKC. Система сразу готова к приёму аналитических запросов. Исходная база знаний загружается в S3 бакет, создаваемый стеком CDK, после чего запускается первоначальный цикл сжатия. Время первого сжатия зависит от объёма данных: для 1000 документов среднего размера - около 10 минут.
Стоимость эксплуатации складывается из трёх компонентов: Lambda-функции (оплата за время выполнения - оффлайн-сжатие потребляет основную часть бюджета), Bedrock (токены на суммаризацию и эмбеддинги - разовые затраты при каждом цикле сжатия), ElastiCache Serverless (оплата за объём хранимых данных и количество запросов). Для базы из 10 000 документов с циклом пересжатия раз в сутки ежемесячный счёт составляет ориентировочно $150–250, что сопоставимо с затратами на классический RAG при интенсивной аналитической нагрузке.
TAKC vs RAG: когда что выбирать и как комбинировать
Выбор между TAKC и классическим RAG - это выбор между аналитической полнотой и фактологической актуальностью. Критерии сведены в таблицу:
| Критерий | TAKC | RAG |
|---|---|---|
| Тип запросов | Аналитические, агрегирующие, трендовые | Фактологические, точечные, поисковые |
| Объём релевантных данных | Сотни и тысячи документов | Единицы или десятки документов |
| Требования к актуальности | Допустима задержка на цикл пересжатия | Мгновенная актуальность, данные меняются часто |
| Затраты на инференс | Низкие: контекст компактный | Растут линейно с объёмом контекста |
| Затраты на preprocessing | Высокие разовые, низкие периодические | Минимальные |
| Точность на аналитических запросах | Высокая: модель видит полную картину | Низкая: модель видит случайную выборку |
Сценарий 1 - TAKC превосходит RAG. Периодическая аналитика по стабильной базе знаний: ежеквартальные обзоры, анализ трендов, дайджесты. Данные обновляются редко, запросы требуют полного охвата. TAKC сжимает базу один раз в сутки или реже, а все аналитические запросы выполняются быстро и точно.
Сценарий 2 - RAG предпочтителен. Часто обновляемые данные и точечные запросы: документация продукта, база знаний поддержки, FAQ. Здесь актуальность критична - ответ должен отражать последнюю версию документа. TAKC с его периодическим пересжатием будет отставать.
Сценарий 3 - гибрид с динамической маршрутизацией. Наиболее практичный подход для большинства проектов. Роутер направляет фактологические запросы в RAG, аналитические - в TAKC, а смешанные разбивает на подзадачи и комбинирует результаты. Именно такую архитектуру мы видели в production-кейсах - например, monday.com строит AI-агентов на Amazon Bedrock с многоуровневой обработкой запросов, где часть идёт через retrieval, а часть через предварительно подготовленные аналитические срезы.
Ограничения TAKC и планы развития
TAKC не серебряная пуля. Периодическое пересжатие базы знаний означает, что для очень динамичных данных - новостных лент, потоков событий реального времени - задержка между появлением документа и его учётом в сжатом представлении может быть критичной. Решение: сокращение цикла пересжатия или инкрементальное обновление сжатых представлений, но это увеличивает вычислительные затраты.
Текущая реализация оптимизирована для текстовых данных. Мультимодальные документы - PDF со сканами, презентации с графиками, видео-транскрипты - требуют дополнительного слоя обработки перед сжатием. В роадмапе проекта заявлена поддержка мультимодальных данных через интеграцию с Amazon Bedrock Data Automation, но сроков пока нет.
Качество сжатия на уровнях 3 и 4 зависит от используемой LLM. Модель, выполняющая суммаризацию, может упустить нюансы или исказить смысл - это стандартный риск при работе с генеративными моделями. Референсная реализация включает валидационный слой, который сравнивает ключевые метрики до и после сжатия, но полностью исключить ошибки нельзя. При внедрении TAKC в production рекомендуется настроить мониторинг дрейфа сжатых представлений относительно исходных данных.
Открытый исходный код референсной реализации означает, что сообщество может расширять и адаптировать TAKC под специфические требования. Пулл-реквесты приветствуются, Issues на GitHub - основной канал для баг-репортов и предложений.