RIG (Retrieval-Interleaved Generation) превращает retrieval из предварительного шага в часть генерации

Когда вокруг LLM говорят о производительности, разговор почти всегда уходит в модели и ускорители. Сколько параметров, сколько HBM, сколько GPU в стойке, какой interconnect между чипами. Это важные вопросы, но в прикладных системах быстро выясняется неприятная вещь: модель может быть очень мощной и все равно спотыкаться на базовых задачах, если ей нужен точный факт, свежая цифра или цепочка связей между несколькими источниками.

Именно здесь когда-то и выстрелил RAG. Retrieval-Augmented Generation решал понятную проблему: если модель знает не все, надо перед ответом достать релевантные документы из внешней базы и положить их в контекст. Для множества сценариев это действительно сработало. Но как только запросы стали сложнее, а системы — агентнее, линейная схема «сначала поиск, потом генерация» начала мешать сама себе.

RIG, Retrieval-Interleaved Generation, вырос как ответ на эту проблему. В нем поиск больше не живет отдельно от генерации. Он встроен прямо в ход ответа. Модель начинает формулировать мысль, доходит до места, где внутренней памяти уже не хватает, делает точечный вызов во внешнюю систему, получает конкретный факт, вставляет его в текущий контекст и продолжает. Не в начале. Не одним большим куском. По мере необходимости, шаг за шагом.

На бумаге разница кажется архитектурной мелочью. На практике она переворачивает требования ко всей инфраструктуре. В RIG хранилище перестает быть пассивной полкой с документами. Оно становится продолжением рабочей памяти модели. И если раньше bottleneck в ИИ-системах чаще связывали с вычислениями, то в контурах RIG и многоагентного инференса все чаще правит другое уравнение: inference = IOPS.

Иллюстрация того, как RIG подмешивает точные данные в ответ по ходу генерации
Источник: Google Research, Grounding AI in reality with a little help from Data Commons

 RAG vs RIG: почему одного RAG уже мало

Классический RAG хорош там, где запрос можно обслужить одним внятным походом во внешнюю базу. Пользователь задает вопрос, система ищет несколько релевантных фрагментов, добавляет их в prompt, и модель отвечает в рамках уже расширенного контекста. Это удобно, просто и довольно прозрачно.

Проблемы начинаются там, где ответ нельзя собрать одной порцией.

Например:

• вопрос требует multi-hop reasoning, то есть нескольких логических переходов между фактами;
• нужные данные относятся к разным источникам, структурам и форматам;
• модель по ходу ответа должна уточнять контекст, а не довольствоваться тем, что ей дали в самом начале;
• пользователю нужен не просто правдоподобный ответ, а проверяемый и по возможности цитируемый.

Это различие хорошо видно на сравнении RAG и RIG. У RAG поиск однократный и строго предшествует генерации. У RIG он итеративный, динамический и повторяется столько раз, сколько требует сама цепочка вывода. RAG обычно работает с крупными блоками текста, абзацами и кусками документов. RIG тяготеет к мелкой фактологической гранулярности: отдельным статистическим значениям, коротким фрагментам, узлам графа знаний, точечным ссылкам на источники.

С точки зрения нагрузки на инфраструктуру это два разных мира. В RAG у вас чаще один тяжелый запрос, где важны пропускная способность и скорость доставки довольно крупного контекста. В RIG у вас множество легковесных микро-запросов прямо во время генерации. И там уже решают сверхнизкая задержка, высокий IOPS и стабильная хвостовая латентность.

Как RIG работает на самом деле

Если упростить, RIG устроен как цикл из нескольких повторяющихся действий.

Сначала LLM начинает отвечать, опираясь на свои параметрические знания. Дальше она доходит до семантической точки неопределенности. Это может быть точная статистика, актуальный финансовый показатель, редкий справочный факт или связь между сущностями, которую модель не хочет додумывать. В этот момент она генерирует специальный токен-плейсхолдер или инициирует function call к внешней системе. После этого происходит точечный поиск: запрос уходит в векторную, графовую или реляционную БД, система возвращает нужный фрагмент данных, тот интегрируется в контекстное окно, и модель продолжает ответ уже с опорой на проверенный факт.

Это и есть interleaving. Не однократное «обогащение» prompt, а постоянное переплетение генерации и retrieval внутри одной сессии вывода.

Вот пример: семейство моделей DataGemma от Google, в том числе оптимизированные версии RIG-27B-IT. Они используют Data Commons, то есть граф знаний, из которого умеют динамически подставлять точные статистические значения прямо по ходу ответа. Модель не просто пишет, что доля возобновляемой энергии «растет». Она может на лету заменить приблизительное число на конкретное, привязанное к источнику.

Родственные схемы идут еще дальше. IRCoT, Interleaved Retrieval with Chain-of-Thought, чередует поиск и структурированное рассуждение, когда evolving trace сам направляет следующие запросы. ReClaim делает то же на уровне отдельных предложений и параллельно встраивает библиографические ссылки, повышая проверяемость результата.

Если нужен короткий вывод, он такой: RIG не просто улучшает retrieval. Он меняет саму динамику вывода.

RAG vs RIG: как меняется нагрузка на storage и инфраструктуру

В теории это красиво. На практике у такой архитектуры есть очень дорогой побочный эффект: генерация начинает зависеть от скорости инфраструктуры почти на каждом шаге.

Почему ИИ-инференс упирается в I/O, IOPS и storage

С приходом RIG и многоагентных систем узкое место смещается от чистой вычислительной мощности к подсистемам ввода-вывода и памяти.

Во время обучения больших моделей профиль нагрузки был относительно предсказуемым. Длинные, последовательные чтения огромных массивов данных. Это мир, где диски, кэши и каналы можно оптимизировать под крупные линейные потоки.

Инференс в режиме RIG выглядит иначе. Нагрузка становится случайной, мелкоблочной и сильно завязанной на поведение пользователя и логику самих агентов. Более того, в многоагентной системе один запрос легко раскладывается в fan-out из десятков агентов. Каждый из них:

• генерирует собственные промпты;
• вытягивает свой контекст;
• пишет промежуточные рассуждения в scratchpads;
• вызывает внешние tools;
• производит JSON-, HTML- и другие артефакты;
• синхронизируется с коллективной памятью других агентов.

Если 10 агентов генерируют по 5000 токенов контекста и по 10 МБ инструментального вывода, системе уже нужно оперативно перебрасывать сотни мегабайт данных между узлами. Когда агентов становится сотня, это превращается в гигабайтные транзакции случайного доступа. И вот в этот момент дорогостоящие GPU начинают делать самое неприятное, что только можно придумать: простаивать в ожидании данных.

Упрощенная схема того, как multi-agent контур начинает опираться на общую память, внешние вызовы и слой хранения
Источник: WEKA, Multi-Agent AI: Why Data Movement Matters More Than Just Compute and Memory

KV-кэш в LLM: почему он становится проблемой для ИИ-инференса

Когда обсуждают инференс, многие по привычке смотрят на размер модели. Но в архитектурах RIG часто не меньше боли приносит KV-кэш.

Во время генерации LLM сохраняет тензоры ключей и значений из attention-механизма для уже обработанных токенов, чтобы не пересчитывать их заново. В обычной длинной генерации это уже чувствительно. В RIG ситуация жестче, потому что контекстное окно постоянно расширяется новыми вставками из внешнего retrieval. Значит, объем KV-кэша растет вместе с каждой дополнительной итерацией поиска.

Рост может быть линейным, а в отдельных сценариях и квадратичным по длине последовательности. Итог понятен: HBM на ускорителях заканчивается слишком быстро.

Отсюда и внимание к KV Cache Offloading. ClusterKV, FreeKV и DynaKV как раз пытаются решить эту проблему через динамическую выгрузку полного или частичного KV-кэша на NVMe или в расширенные пулы памяти. Особенно интересен FreeKV, потому что он использует спекулятивное извлечение и гибридную компоновку данных в оперативной и видеопамяти, стараясь вынести работу с кэшем за пределы critical path.

Это не «мелкая оптимизация». От того, насколько быстро система умеет вернуть релевантный кусок KV-кэша мелкими блоками, зависят метрики, которые пользователь ощущает напрямую:

• TTFT, time to first token;
• TPOT, time per output token.

Когда RIG начинает вызывать хранилище буквально по ходу мысли, медленное storage бьет уже не по бэкэнду, а по ритму текста на экране.

СХД для RIG: требования к IOPS, latency, NVMe и storage

С точки зрения железа RIG неприятен тем, что не прощает даже маленьких задержек. Если поиск интерполирован в авторегрессионную генерацию, то любая пауза на стороне накопителя напрямую превращается в паузу перед следующим словом в ответе.

Бенчмарки MLPerf Storage v2.0s показывают профиль, который сейчас встречается снова и снова: высокая интенсивность запросов, низкая глубина очереди, массовый параллелизм и очень жесткие требования к tail latency. Иначе говоря, мало просто выдать красивый peak throughput. Нужно еще не проваливаться на хвостах.

Базовая аппаратная ставка здесь делается на NVMe SSD уровня PCIe Gen5 и уже нацеленные в продакшн Gen6-устройства. Кейс KIOXIA: эмуляция SSD, способного достигать 100 миллионов IOPS на случайном чтении блоков по 512 байт. Это уже почти лабораторный предел, но направление движения понятное. Аналогично под такие задачи затачиваются продукты вроде Micron 9550 и Solidigm D5-P5336.

Есть и менее очевидная проблема. Чтобы хранить огромные объемы векторных данных, инфраструктура тянется к QLC NAND из-за плотности. Но QLC хуже переносит случайную запись и слабее по endurance. Поэтому возникают решения на уровне хоста. Один из примеров — CSAL, Cloud Storage Acceleration Layer в составе SPDK. Этот слой старается преобразовать случайные записи в более последовательные паттерны. А вариант CSAL с Core Scaling для RAID5F убирает классическую write hole-проблему и снижает накладные расходы read-modify-write. Результат: до 2x роста пропускной способности и примерно 30% снижения write amplification.

CXL в ИИ-инфраструктуре: как решить проблему памяти и KV-кэша

Если NVMe решает вопрос емкости и скорости, то CXL атакует другую боль: разрыв между тем, что помещается в локальную память ускорителей и серверов, и тем, что реально нужно RIG-системам.

Если большие векторные базы и связанные структуры выгрузить из DRAM на обычные NVMe-накопители, задержка доступа может вырасти в 100-10000 раз. Это слишком дорого для сценария, где поиск идет по ходу генерации.

CXL, Compute Express Link, пытается стереть часть этой границы. Он позволяет подключать пулы памяти и акселераторы через PCIe с поддержкой когерентности кэша, то есть строить более гибкие, гетерогенные memory-fabric конфигурации.

На стенде с MemVerge Memory Machine X использовали 1024 ГБ DRAM и 128 ГБ CXL-памяти на отдельных NUMA-узлах. При hardware interleaving между DRAM и CXL в пропорции 9:1 и пороге активации 1024 МБ система на датасете Cohere с 10 млн векторов размерности 768 выдала 693 QPS. Для сравнения, чистая DRAM-конфигурация показала 585 QPS. То есть прирост составил 18.5%, а p99 удержался на уровне 17 мс.

Это важный момент. Здесь речь уже не о теоретическом удобстве архитектуры, а о вполне приземленном балансе между стоимостью и производительностью.

Следующий шаг еще интереснее. Подходы вроде Scalable Processing-Near-Memory выносят часть вычислительной логики прямо на CXL-модули. За счет этого массивы KV-кэша не нужно бесконечно гонять обратно в GPU.

RDMA и NVMe-oF: почему сеть становится частью памяти ИИ

Как только хранилище выносится за пределы локального сервера, сеть перестает быть нейтральным фоном. В RIG она становится частью memory path.

Проблема не только в пропускной способности. Для таких систем опаснее накопленная задержка. Каждая миллисекунда сериализации, каждая очередь на коммутаторе, каждый дополнительный round-trip складываются, пока модель ждет данные. И если retrieval вызывается не один раз, а много раз за одну сессию ответа, эффект быстро становится неприятным.

Отсюда и переход к RDMA. При обычном TCP/IP потеря даже одного пакета может запускать тяжелые механизмы повторной передачи вроде Go-Back-N. Для ИИ-инференса, чувствительного к задержке, это плохой сценарий. RDMA позволяет сетевым адаптерам напрямую читать и писать в удаленную память, обходя ОС и CPU там, где это критично.

На этой базе де-факто стандартом для подключения СХД к вычислительным узлам стал NVMe-over-Fabrics. Три основных транспортных варианта:

• InfiniBand (SRP/iSER). Старый добрый HPC-стандарт. Аппаратная маршрутизация без потерь, очень низкая задержка, поддержка in-network compute вроде SHARP. Хорош для больших кластеров.
• RoCE v2. RDMA поверх Ethernet. При правильно настроенном Lossless Ethernet и управлении перегрузками в storage-задачах может достигать производительности InfiniBand и местами превосходить ее на 5-10%.
• NVMe/FC. Логичный выбор для enterprise-сред с существующими SAN. Дает стабильность и high availability через ANA, но обычно уступает современным InfiniBand и RoCE по чистой пропускной способности.

Если смотреть на RIG прагматично, то вопрос здесь не столько «какой транспорт моднее», сколько «какой транспорт даст предсказуемую латентность под поток мелких запросов».

Файловые системы для AI: почему RIG требует высокой производительности I/O

Еще одна деталь, которую легко недооценить: агентные ИИ-системы генерируют огромное количество мелких объектов. Фрагменты контекста, checkpoints, scratchpads, промежуточные JSON, кэши инструментов, версии следов рассуждения. На таком профиле классические файловые системы часто упираются не в диски, а в метаданные.

Появляются параллельные и распределенные файловые системы нового поколения: WekaFS, DAOS, 3FS, а также облачные слои вроде Google Cloud Storage FUSE. Общая логика у них одна:

• убрать централизованный metadata server как hot spot;
• оптимизировать стек под NVMe и RDMA;
• дать единое пространство имен для очень разных типов доступа.

Конкретные цифры здесь тоже показательные. WekaFS в бенчмарках достигала 15,370.21 kIOP/s, то есть свыше 15 млн IOPS. Для сравнения, у Lustre было 1,739.90 kIOP/s. Это не значит, что Lustre «плохая» система. Просто она рождалась под другие задачи: крупные последовательные потоки, а не под мелкоблочное случайное чтение, которое стало нормой для RAG и особенно для RIG.

Поверх этого строятся уже более хитрые схемы вроде NeuralMesh от WEKA, где POSIX, S3, NFS и SMB сводятся в единое пространство имен, а KV-кэш можно передавать между storage и GPU через GPUDirect Storage или NIXL-плагины. В задачах инференса это снижало TTFT до 41 раза относительно неоптимизированных хранилищ. Если цифра и выглядит слишком красивой, смысл у нее все равно понятный: storage перестал быть просто backing store. Он теперь участвует в пользовательской скорости ответа.

Векторные БД для RAG и RIG: latency, IOPS и производительность

RIG держится на retrieval, а retrieval почти всегда начинается с векторной базы данных. A разные классы векторных БД дают очень разный баланс между удобством, масштабом и задержкой.

1. Специализированные standalone-движки

Сюда относятся Milvus, Pinecone, Qdrant. Они проектировались именно под тензорную математику и ANN-поиск. Для массивов порядка 10-100 млн векторов  ожидаемая задержка менее 10-50 мс. Отдельно отмечается, что Milvus с GPU-ускорением может доходить до 10 мс отклика, а Pinecone на 10 млн векторов размерности 768 работает в диапазоне 5-7 мс.

2. Векторные расширения реляционных БД

Это pgvector и pgvectorscale в PostgreSQL. Исторически такой подход считали более медленным, зато удобным, потому что транзакционные данные и векторный поиск живут рядом. Но новые индексы заметно меняют картину. Пример pgvectorscale: 471 QPS при 99% recall на 50 млн векторов. Для сравнения, Qdrant на том же наборе показывал 41 QPS. Получается преимущество примерно в 11.4 раза.

3. In-memory платформы

Redis и SingleStore хороши там, где нужно выжать субмиллисекундную реакцию и объем данных еще контролируем. Но и здесь есть подводный камень. SingleStore держит 5-10 мс на чистых сценариях, а при смешивании векторных вычислений с SQL-join’ами может просесть до 20-100 мс.

Самое интересное начинается ниже уровня продукта, на уровне индекса.

HNSW остается практически стандартом отрасли. Он точен, понятен и эффективен, но любит RAM. Когда масштаб уходит в сотни миллионов векторов, этого уже мало. Тогда появляются DiskANN и похожие схемы, которые умеют эффективно жить на NVMe. В сочетании со statistical binary quantization это позволяет резко уменьшить объем данных без резкого падения recall и заметно улучшить p95.

Плюс есть еще техники сложного индексирования в духе RAPTOR и token-level matching, как в ColBERT. Они помогают качеству, но у них есть вполне материальная цена: в системе приходится хранить больше представлений одних и тех же данных. Значит, снова растут требования к емкости и скорости СХД.

GraphRAG: зачем ИИ нужны графовые БД и поиск по связям

Векторный поиск отлично находит близкие по смыслу куски текста. Но он часто бессилен там, где нужна «общая картина» и traversal по связям между сущностями.

Это та точка, где на сцену выходит GraphRAG. Это архитектура, которая структурирует знания через графовые БД, например Neo4j или TigerGraph. На этапе подготовки LLM извлекает сущности и отношения из документов и формирует граф из узлов и ребер. Затем граф можно кластеризовать, например через алгоритм Leiden, разбивая его на смысловые сообщества и агрегируя их в краткие резюме.

Во время инференса LLM уже не ищет просто «похожий абзац». Она может формировать запросы на Cypher или GSQL, проходить по ребрам, отслеживать причинно-следственные и косвенные связи. Для корпоративной аналитики это особенно полезно, потому что нужная связь часто вообще не лежит в одном документе и не встречается в одной формулировке.

В некоторых сценариях GraphRAG увеличивал точность ответов в 3.4 раза, а успешность решения сложных аналитических задач доходила до 80% против 50% у более традиционных RAG-схем.

Но GraphRAG не приходит бесплатно. Как только графовый обход тоже начинает interleave’иться с выводом, требования к storage снова растут.Отдельно нужно упомянуть динамические подходы вроде Graph-O1 и Think-on-Graph 3.0, где обход графа чередуется с выводами LLM. Это удобно, потому что можно на лету расширять или отсекать ветви. Но это значит, что под рукой должна быть инфраструктура, которая выдержит субсекундный доступ к графам с миллионами ребер. Без in-memory слоев или очень быстрых NVMe-кэшей здесь тяжело.

Speculative RAG: как снизить latency retrieval в ИИ-инференсе

Даже если у вас быстрые NVMe, RDMA-сеть, CXL-пулы и приличные базы, физику никто не отменял. Доступ к данным и сетевой round-trip все равно занимают время. Если делать retrieval строго синхронно на каждом шаге, накопленная задержка очень быстро делает систему вялой.

Именно поэтому так важен следующий слой оптимизации: speculative retrieval, или speculative RAG.

Одна из схем speculative retrieval, где часть поиска и подготовки контекста уходит в параллельный контур
Источник: Google Research, Speculative RAG: Enhancing retrieval augmented generation through drafting

Логика здесь простая и довольно изящная. Вместо того чтобы останавливать большую и дорогую LLM для каждого поискового вызова, рядом запускается меньшая модель-drafter. Она пытается предсказать, куда двинется контекст, делает approximate queries и параллельно набрасывает черновые варианты ответа. После этого большая модель-verifier получает и черновики, и уже подгруженные данные из БД, проверяет confidence scores и либо принимает лучшие куски, либо комбинирует их в финальный ответ.

Именно это разделение на drafter и verifier это главный системно-алгоритмический трюк. Storage latency не исчезает, но значительная ее часть прячется за асинхронной предварительной выборкой.

И результат заметный не только на бумаге. На наборах PubHealth, TriviaQA и MuSiQue speculative RAG повышал фактологическую точность до 12.97% и одновременно сокращал общую latency системы на 51%.

Плюс есть соседние идеи. Например, система Proximity использует кэширование по семантической близости запросов и повторно использует уже извлеченные документы из быстрых слоев памяти. Это дает дополнительное снижение retrieval latency на 59% и заметно разгружает нижележащие векторные БД.

Архитектура ИИ-инфраструктуры для RIG: storage, memory и network

Главный вывод тут довольно приземленный. В системах RIG модель уже нельзя рассматривать отдельно от хранилища, сети, индексов и памяти. Это не «модель плюс внешняя база». Это единая вычислительно-памятная машина, где качество ответа и его скорость зависят от десятка связанных слоев.

Если собрать картину целиком, то рабочая архитектура под RIG все чаще выглядит так:

• память расширяется через CXL, чтобы не упираться в локальную DRAM и HBM;
• KV-кэш частично выгружается и возвращается через offloading-механизмы;
• быстрый слой хранения строится на NVMe Gen5/Gen6;
• сетевой доступ идет через RDMA и NVMe-oF, а не через обычный стек, если важна интерактивность;
• файловая система умеет жить с бурей мелких операций и не задыхается на метаданных;
• векторная БД настраивается не только на recall, но и на latency под реальный агентный профиль;
• для multi-hop reasoning поверх нее поднимается графовый слой;
• поверх всего этого добавляется speculative retrieval, чтобы скрывать latency хотя бы частично.

Это и есть сдвиг, который сейчас стоит держать в голове. На этапе pretraining главной валютой были FLOPS, тензорные ядра и межчиповые каналы. На этапе инференса с активным retrieval валютой становятся микросекунды, IOPS, TTFT, TPOT, p99 и поведение memory-fabric под реальной агентной нагрузкой.

Поэтому следующий большой разговор про ИИ-инфраструктуру будет не только про модели. Он уже про storage.

Ключевые источники и материалы

• Google Research. *Grounding AI in reality with a little help from Data Commons*: https://research.google/blog/grounding-ai-in-reality-with-a-little-help-from-data-commons/
• Google AI for Developers. *DataGemma*: https://ai.google.dev/gemma/docs/datagemma
• Google Research. *Speculative RAG: Enhancing retrieval augmented generation through drafting*: https://research.google/blog/speculative-rag-enhancing-retrieval-augmented-generation-through-drafting/
• WEKA. *Multi-Agent AI: Why Data Movement Matters More Than Just Compute and Memory*: https://www.weka.io/blog/ai-ml/multi-agent-ai-why-data-movement-matters-more-than-just-compute-and-memory/
• Meilisearch. *Speculative RAG: A faster retrieval-augmented generation*: https://www.meilisearch.com/blog/speculative-rag
• Micron. *Inference = IOPS: Why AI’s next frontier runs on storage*: https://www.micron.com/about/blog/storage/ai/inference-iops-why-ai-next-frontier-runs-on-storage
• Dell. *Vector Database infrastructure requirements*: https://www.delltechnologies.com/asset/en-us/products/storage/industry-market/vector-database-infrastructure-requirements.pdf
• NVIDIA Technical Blog. *How to Reduce KV Cache Bottlenecks with NVIDIA Dynamo*: https://developer.nvidia.com/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/
• NetApp. *When You’re Implementing NVMe Over Fabrics, the Fabric Really Matters*: https://www.netapp.com/blog/nvme-over-fabric/
• Google Research / EPFL materials on speculative retrieval and drafting, plus the figures and benchmark claims referenced in the original source set.

Автор: Андрей Гантимуров