От линейных цепочек к Flow Engineering: как эволюционирует RAG

«RAG не мертв, он просто пахнет странно», — утверждает Лэнс Мартин, предвещая радикальную трансформацию архитектуры ИИ-систем. В то время как GPT-4 теряет точность при поиске фактов в огромных контекстах, на смену простым цепочкам приходит Flow Engineering — проектирование циклических графов, способных к самокоррекции. Будущее генеративного поиска теперь зависит не от длины промпта, а от сложности логической архитектуры, превращающей LLM в полноценного агента рассуждений.

🛠 Основы RAG: от приватных данных к интеллектуальному поиску 0:00

Retrieval Augmented Generation (RAG) — одна из самых востребованных концепций в современной разработке систем на базе больших языковых моделей (LLM). Как отмечает Лэнс Мартин (Lance Martin), инженер LangChain, несмотря на то что современные модели обучаются на колоссальных объемах публичных данных (от 1,5 триллионов токенов и выше), большая часть действительно важной информации в мире остается приватной . Это могут быть личные документы, корпоративные базы данных или закрытые архивы, которые никогда не попадали в обучающую выборку GPT-4 или Claude 3.

Основная мотивация использования RAG заключается в том, чтобы объединить вычислительную мощность и «здравый смысл» LLM с актуальными специфическими знаниями пользователя . Если раньше контекстные окна моделей ограничивались 4–8 тысячами токенов (всего десяток страниц текста), то сегодня они расширяются до миллиона токенов и более. Это позволяет передавать моделям тысячи страниц внешних данных «на лету» . В этой архитектуре LLM выступает в роли центрального процессора новой операционной системы, а RAG обеспечивает эффективную подачу данных из «внешней памяти» для обработки .

Индексация и магия векторных эмбеддингов 6:03

Процесс RAG начинается с подготовки данных, или индексации. Лэнс Мартин выделяет три ключевых этапа: индексация, извлечение (retrieval) и генерация . Задача индексации — превратить неструктурированный текст в формат, удобный для быстрого поиска.

Для этого документы сначала разбиваются на части (сплиттинг). Это необходимо, так как модели эмбеддингов имеют свои ограничения по длине контекста — обычно от 512 до 8000 токенов . Затем каждый фрагмент текста преобразуется в числовой вектор — эмбеддинг.

Существует два основных подхода к созданию таких векторов:

1. Статистические методы (Sparse Vectors): Традиционные подходы (например, от Google), где векторы строятся на основе частоты встречаемости слов . Они называются разреженными (sparse), потому что большинство позиций в огромном словаре заняты нулями, так как конкретный документ содержит лишь малую часть доступных слов .
2. Машинное обучение (Dense Embeddings): Современные модели сжимают семантический смысл текста в вектор фиксированной длины . Например, модель от OpenAI преобразует любой текст в вектор длиной 1536 чисел .

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

Retrieval: поиск смысла в многомерном пространстве 10:56

Когда пользователь задает вопрос, система должна найти среди тысяч фрагментов именно те, которые помогут дать ответ. Процесс извлечения (retrieval) основан на поиске сходства в векторном пространстве.

Лэнс Мартин предлагает наглядную аналогию: представьте, что каждый фрагмент текста — это точка в трехмерном пространстве . Положение точки определяется семантикой: документы со схожим смыслом будут располагаться близко друг к другу. Когда поступает вопрос пользователя, он точно так же переводится в вектор и «приземляется» в ту же область пространства.

Ключевые аспекты этого процесса:

• Поиск ближайших соседей (KNN): Система находит $K$ фрагментов, которые находятся в непосредственной близости от вектора вопроса .
• Параметр K: В коде разработчик может жестко задать количество извлекаемых документов (например, k=1 или k=3), чтобы контролировать объем контекста, передаваемого модели .
• Косинусное сходство: Основная метрика, используемая для математического сравнения близости векторов в этом пространстве .

Благодаря такому подходу система способна находить релевантную информацию, даже если в вопросе и документе используются разные слова, но сохраняется общий смысл .

Генерация ответов и язык выражений LCEL 15:57

Заключительный этап RAG — генерация ответа на основе найденных данных. Извлеченные документы «упаковываются» в контекстное окно модели вместе с вопросом пользователя . Для этого используются промпты со специальными заполнителями (placeholders), такими как context и question .

Для автоматизации этого процесса LangChain использует LCEL (LangChain Expression Language) — декларативный язык выражений, который позволяет легко собирать цепочки из промптов, моделей и парсеров .

Типичный рабочий процесс генерации выглядит так:

1. Создается словарь, где ключи соответствуют переменным в промпте.
2. LCEL-цепочка связывает воедино загрузчик документов, ретривер и чат-модель .
3. При вызове метода invoke система автоматически выполняет поиск, подставляет данные в шаблон и возвращает итоговый ответ .

В завершение обзора базового цикла RAG Лэнс Мартин упоминает, что реальные пользовательские запросы часто бывают неоднозначными. Для решения этой проблемы в более продвинутых сценариях применяются методы трансформации запросов, такие как Multi-query, которые будут подробно рассмотрены далее .

🛠️ Трансформация запросов: Multi-query, RAG Fusion и декомпозиция 25:01

На этапе продвинутого RAG простого поиска по сходству (similarity search) часто оказывается недостаточно. Лэнс Мартин (Lance Martin) переходит к детальному разбору техник трансляции запросов (Query Translation), которые позволяют оптимизировать ввод пользователя еще до того, как система обратится к векторному хранилищу . Эти методы решают проблему «неудачных формулировок» и помогают извлекать более релевантный контекст за счет изменения структуры и перспективы вопроса.

Multi-query: расширение поискового горизонта 25:14

Первая техника, которую разбирает Лэнс, — это Multi-query или многозадачное переписывание запроса. Проблема большинства RAG-систем в том, что пользовательский вопрос может быть сформулирован неоптимально для поиска по эмбеддингам . Чтобы обойти это ограничение, используется LLM, которая генерирует несколько вариаций одного и того же вопроса, рассматривая его с разных сторон.

Процесс выглядит следующим образом:

• Определяется промпт, который ставит перед моделью задачу перефразировать исходный вопрос на пять различных подвопросов .
• Для каждого из сгенерированных вопросов выполняется независимый поиск в векторной базе данных (например, Chroma) .
• Результаты всех поисков объединяются в единое множество уникальных документов (Unique Union), которые и становятся контекстом для финального ответа .

Использование LangSmith позволяет наглядно увидеть этот процесс «под капотом»: в интерфейсе отображается, как один входящий запрос превращается в пять, и как для каждого из них отрабатывает отдельный цикл извлечения данных . Это гарантирует, что система не пропустит важный фрагмент информации только из-за того, что в исходном вопросе использовались другие термины.

RAG Fusion и интеллектуальное ранжирование 28:27

RAG Fusion во многом похож на Multi-query, но добавляет критически важный этап — перевзвешивание результатов. Лэнс подчеркивает, что простое объединение документов не всегда эффективно, так как разные вариации запроса могут возвращать одни и те же документы с разной степенью уверенности .

Ключевым инструментом здесь выступает алгоритм Reciprocal Rank Fusion (RRF). Его задача — взять несколько списков документов, полученных по разным запросам, и сформировать из них один консолидированный список, где позиция документа зависит от его ранга во всех исходных списках .

В коде это реализуется через функцию ранжирования, которая агрегирует результаты:

1. Генерируются 4-5 вариаций вопроса .
2. Выполняется поиск для каждой вариации.
3. Алгоритм RRF вычисляет итоговый «вес» для каждого уникального документа .
4. В финальный промпт передается только топ наиболее релевантных документов (например, шесть лучших), что позволяет избежать зашумления контекста лишней информацией .

Декомпозиция сложных запросов на подзадачи 34:06

Если Multi-query и RAG Fusion направлены на перефразирование, то декомпозиция (Decomposition) нацелена на решение сложных, многосоставных задач. Лэнс ссылается на работы Google (например, Least-to-most prompting), где сложный вопрос разбивается на серию простых подпроблем .

Существует два основных подхода к декомпозиции:

1. Последовательное решение (Sequential): Ответ на первый подвопрос передается в контекст для решения второго. Это напоминает Chain of Thought, совмещенный с поиском (IRC — Interleaved Retrieval/CoT) . Например, при вопросе о компонентах LLM-агентов система сначала ищет, что такое LLM-технология, затем — что такое агенты, и только потом объединяет эти знания .
2. Параллельное решение: Подвопросы решаются независимо, а их ответы просто склеиваются в конце. Это эффективно, когда части задачи не зависят друг от друга .

Лэнс демонстрирует в LangSmith, как система постепенно «наращивает» решение: для второго вопроса в цепочке промпт содержит уже не только результаты нового поиска, но и пару «вопрос-ответ» из предыдущего шага .

Step-back Prompting: переход к абстракции 40:45

Step-back Prompting — это интуитивно понятная, но мощная техника, представленная исследователями DeepMind. Вместо того чтобы дробить вопрос или искать синонимы, модель делает «шаг назад», формулируя более общий, абстрактный вопрос .

Пример из практики: если пользователь задает очень специфический вопрос о конкретном физическом явлении, система сначала спрашивает: «Каковы фундаментальные принципы, лежащие в основе этого явления?» .

• Модель генерирует «step-back question» через few-shot промпты .
• Поиск выполняется одновременно по двум направлениям: по конкретному вопросу и по абстрактному концепту .
• Оба набора документов объединяются для формирования ответа.

По мнению Лэнса Мартина, этот метод незаменим при работе с технической документацией или учебниками, где детали реализации часто опираются на фундаментальные концепции, описанные в других главах . Это позволяет системе не терять контекст «большой картины» при ответе на узкоспециализированные запросы.

🧭 Маршрутизация и продвинутая структура запросов: от гипотез к точным фильтрам 50:01

На этапе, когда базовые механизмы поиска и генерации уже освоены, перед инженером встает вопрос точности и эффективности. Лэнс Мартин (Lance Martin) подчеркивает, что реальные данные редко бывают однородными, а пользовательские запросы — идеально сформулированными для поиска по сходству. Чтобы преодолеть эти барьеры, в RAG-системы внедряются механизмы «интеллектуальной прослойки»: от генерации гипотетических ответов до жесткой логической маршрутизации запросов между различными типами баз данных.

HyDE: поиск через гипотетические документы 50:15

Одним из элегантных способов повысить качество извлечения является метод HyDE (Hypothetical Document Embeddings). Его суть заключается в том, что вместо поиска документов напрямую по вопросу пользователя, система сначала просит LLM создать «примерный» или гипотетический ответ .

Как объясняет Лэнс Мартин, это решает проблему семантического разрыва: короткий вопрос пользователя может быть не похож на развернутые фрагменты текста в базе по векторному расстоянию. Однако гипотетический ответ, сгенерированный моделью, по своей структуре и лексике гораздо ближе к реальным документам в индексе . В LangChain этот процесс выглядит как цепочка: вопрос → генерация текста через ChatOpenAI → использование этого текста как поискового запроса к вектору. Хотя в простых случаях базовый поиск справляется не хуже, Мартин отмечает, что HyDE показывает отличные результаты в специфических предметных областях и определенно стоит того, чтобы с ним экспериментировали .

Логическая и семантическая маршрутизация 52:16

Когда проект перерастает одну векторную базу, возникает необходимость в «диспетчере» — механизме маршрутизации (Routing). Лэнс выделяет два основных подхода к этой задаче:

1. Логическая маршрутизация. Здесь LLM выступает в роли классификатора. Ей предоставляется информация о доступных источниках данных — например, базе документации по Python, JS и Go . С помощью механизма вызова функций (function calling) модель анализирует вопрос и возвращает структурированный объект (Pydantic), указывающий на нужный источник . Это позволяет системе строго направить запрос: если пользователь спрашивает про библиотеки Python, запрос уйдет именно в Python-индекс, минуя все остальные .
2. Семантическая маршрутизация. Этот метод более гибкий и не требует от модели «рассуждений». Мы заранее создаем набор эталонных промптов (например, «математический» и «физический») и переводим их в эмбеддинги . Когда поступает вопрос пользователя, система сравнивает его вектор с векторами этих промптов и выбирает наиболее похожий. Таким образом, вопрос «Что такое черная дыра?» автоматически направит систему к «физическому» промпту и соответствующим данным .

Ранее в разговоре упоминались методы декомпозиции и трансформации запросов, но маршрутизация делает следующий шаг: она определяет не как спрашивать, а где искать .

Query Construction: от естественного языка к фильтрам метаданных 59:19

Часто информация в базе данных снабжена метаданными: датой публикации, автором, рейтингом или жанром. Если пользователь просит «найти видео по LangChain, опубликованные после 2024 года», обычного векторного поиска будет недостаточно . Здесь в игру вступает Query Construction (конструирование запросов).

Процесс превращает неструктурированный ввод в Domain Specific Language (DSL) — структурированный запрос, понятный конкретной базе данных . Лэнс Мартин демонстрирует это на примере YouTube-транскриптов:

• Система получает описание доступных фильтров (длительность видео, количество просмотров, дата) .
• LLM, используя схему Pydantic, анализирует запрос и извлекает из него параметры фильтрации .
• На выходе мы получаем JSON-объект, который библиотека LangChain конвертирует в поисковый фильтр для векторной БД (например, Pinecone или Chroma) .

Это позволяет объединить мощь семантического поиска («о чем видео») с точностью структурированных запросов («когда оно вышло») .

Multi-representation: индексация через саммари 1:05:08

Последний важный архитектурный прием — разделение данных для поиска и данных для генерации. Традиционно мы разбиваем документ на куски (chunks) и ищем по ним. Однако Лэнс предлагает метод Multi-representation, вдохновленный идеей «пропозиционального индексирования» .

Идея проста:

• Для каждого крупного документа создается краткое резюме (summary), которое содержит ключевые слова и главные идеи .
• В векторной базе хранятся и индексируются только эти саммари — они компактны и оптимизированы для быстрого поиска .
• Сами же полные документы хранятся отдельно в DocStore.

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

🏗️ Иерархические индексы, токенизированный поиск и графы состояний 1:15:04

В этой части курса Лэнс Мартин (Lance Martin) переходит от базовых методов извлечения к продвинутым архитектурам, которые позволяют нейросетям работать с огромными массивами данных и сложной логикой принятия решений. Мы разберем, как индексировать документы иерархически, почему токенизированный поиск может быть точнее векторного и как превратить линейный RAG в гибкий граф состояний.

RAPTOR: Рекурсивное суммирование и кластеризация 1:15:17

Одной из самых мощных техник для работы с длинным контекстом является RAPTOR. Проблема стандартного RAG заключается в том, что при разбиении текста на мелкие куски (чанки) теряется общий смысл документа. RAPTOR решает это через создание многоуровневого дерева .

Процесс выглядит следующим образом:

1. Загрузка данных: Лэнс использует около 30 документов документации LangChain Expression Language (LCEL) .
2. Кластеризация: Документы группируются по схожести смыслов.
3. Суммирование: Для каждого кластера LLM (например, Claude или модели OpenAI) пишет краткое резюме (summary) .
4. Рекурсия: Эти резюме снова кластеризуются и суммируются. Процесс повторяется до тех пор, пока не будет достигнут верхний уровень абстракции. В примере Лэнса используется три уровня рекурсии .

В итоге в векторную базу сохраняются как исходные тексты («листья» дерева), так и все промежуточные резюме . Это позволяет системе отвечать на вопросы разного уровня детализации: от конкретных программных интерфейсов до общих архитектурных принципов. Лэнс подчеркивает, что с появлением моделей с контекстным окном в 100 000 и более токенов такой подход становится крайне эффективным, позволяя обрабатывать большие пласты информации без потери нюансов .

ColBERT: Токенизированное извлечение данных 1:19:22

Большинство систем RAG сжимают весь документ или чанк в один единственный вектор. Лэнс называет это «процессом чрезмерного сжатия», при котором могут теряться тонкие семантические различия . Альтернативой выступает ColBERT (Contextualized Late Interaction over BERT).

Вместо одного вектора на документ ColBERT создает вектор для каждого отдельного токена. Это обеспечивает более глубокое представление семантики . Когда пользователь задает вопрос, происходит следующее:

• Вопрос также разбивается на токены, для каждого создается вектор.
• Для каждого токена вопроса вычисляется максимальное сходство со всеми токенами документа (MaxSim) .
• Финальный скор документа — это сумма этих максимальных сходств .

Хотя такая архитектура требует больше вычислительных мощностей и может иметь задержки (latency) в продакшене , она показывает очень высокие результаты точности. Для работы с ColBERT Лэнс рекомендует библиотеку RAGatouille, которая легко интегрируется в LangChain как стандартный Retriever .

LangGraph и концепция State Machines 1:26:44

Стандартный поток RAG линеен: Вопрос → Поиск → Генерация. Но реальные задачи требуют циклов и проверок. Если найденные документы бесполезны, их нужно отбросить и попробовать другой путь. Для таких сценариев LangChain представил LangGraph — инструмент для построения систем в виде графов состояний (State Machines) .

Ключевые идеи LangGraph:

• State (Состояние): Это общий объект (обычно словарь/dict), который передается между узлами и содержит текущие данные: вопрос, список документов, сгенерированный ответ .
• Nodes (Узлы): Функции, которые принимают текущее состояние, что-то делают (например, ищут в базе или вызывают LLM) и возвращают обновленное состояние .
• Edges (Ребра): Логические переходы между узлами. Они могут быть условными — например, если LLM решила, что документов недостаточно, граф направит поток в узел веб-поиска .

Лэнс называет этот подход «инженерией потоков» (flow engineering) . Вместо того чтобы просто писать длинные промпты, разработчик проектирует логическую схему работы агента.

Corrective RAG (CRAG) и внешние источники 1:29:46

В качестве примера реализации графа Лэнс разбирает метод Corrective RAG (CRAG). Эта система умеет оценивать релевантность найденных документов и «исправлять» ситуацию, если данные не подходят для ответа .

Алгоритм CRAG в LangGraph выглядит так:

1. Retrieve: Поиск документов в локальной векторной базе (например, ChromaDB) .
2. Grade: Узел-оценщик проверяет каждый документ на релевантность вопросу. Лэнс использует Pydantic-модель, чтобы LLM выдавала строго «да» или «нет» .
3. Decision: Если хотя бы один документ релевантен, система идет к генерации. Но если есть сомнения (или все документы не подошли), запускается узел трансформации запроса и веб-поиска через инструмент Tavily .
4. Generate: Финальный ответ формируется на основе очищенных локальных данных и результатов поиска в сети .

Пример работы системы: при вопросе «как работает память агента?» CRAG сначала ищет в локальных блогах. Если часть информации нерелевантна, он отфильтровывает её, переписывает запрос и идет в Google (через Tavily), чтобы дополнить контекст актуальными данными об архитектуре памяти . Весь этот процесс можно детально отследить в LangSmith, где видны переходы между узлами графа и логика принятия решений на каждом этапе .

🔄 Adaptive RAG и мощь специализированных моделей (Command R) 1:44:14

Переход от простых последовательных цепочек (chains) к сложным итеративным потокам (flows) открывает новую эру в разработке ИИ-систем. Лэнс Мартин подчеркивает, что использование графовых структур позволяет кодировать сложную логику рассуждений в чистом и инженерно выверенном виде . Ключевым воплощением этого подхода становится Adaptive RAG — архитектура, которая не просто извлекает данные, а динамически управляет процессом поиска, оценки и генерации ответа, адаптируясь к сложности каждого конкретного запроса.

Adaptive RAG: Динамическое управление и «Unit-тесты» в реальном времени 1:44:14

Adaptive RAG объединяет в себе две фундаментальные идеи: продвинутый анализ запросов и «проектирование потоков» (flow engineering). Как отмечает Лэнс Мартин, это своего рода «фронтенд» и «бэкенд» вашей RAG-системы . Ранее в курсе обсуждались методы переписывания запросов (Query Analysis) и маршрутизация, но Adaptive RAG выводит их на новый уровень, превращая весь цикл генерации в самокорректирующуюся систему.

Особое внимание Лэнс уделяет концепции онлайн-тестирования в пайплайне. Ссылаясь на работы Хамиля Хусейна (Hamil Hussein), он выделяет критическую важность «автоматических повторных попыток во время инференса» . В традиционном ПО unit-тесты проводятся до релиза, но в Adaptive RAG они встроены непосредственно в процесс работы модели:

• Проверка релевантности: Если извлеченные документы не соответствуют вопросу, система не пытается генерировать ответ, а автоматически переключается на альтернативный источник, например, веб-поиск .
• Контроль галлюцинаций: После генерации ответа модель-грейдер проверяет, подтверждается ли ответ фактами из документов.
• Оценка полезности: Финальный этап проверяет, действительно ли полученный текст отвечает на исходный вопрос пользователя.

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

Оптимизация RAG с моделями Command R 1:47:56

Для реализации таких сложных графов требуются модели, обладающие специфическими характеристиками. Лэнс Мартин выделяет модель Command R от компании Cohere как одно из лучших решений для построения Adaptive RAG . Несмотря на относительно небольшой размер (35 миллиардов параметров), эта модель оптимизирована под конкретные задачи, критически важные для RAG-циклов.

Основные преимущества Command R для Adaptive RAG:

1. Нативная поддержка вызова инструментов (Tool Use): Модель отлично справляется с маршрутизацией запросов и выбором между различными базами данных или веб-поиском .
2. Эффективная работа с длинным контекстом: Окно в 128 000 токенов позволяет загружать значительные объемы документов без потери качества.
3. Скорость и доступность: Модель достаточно быстра для работы через API и при этом имеет открытые веса (open weights), что позволяет запускать её локально .
4. Специализированная настройка: Command R была обучена именно для сценариев RAG, что делает её крайне точной в задачах оценки релевантности и генерации ответов на основе контекста.

Лэнс демонстрирует использование функции with_structured_output, которая принуждает модель возвращать данные строго в формате Pydantic-объектов . Это критично для логики графа: грейдер должен выдавать четкое «да» или «нет» (бинарную оценку), чтобы система могла принять решение о следующем шаге без лишнего текстового шума от LLM .

Анатомия графа: Узлы и условные ребра 1:56:09

Реализация Adaptive RAG в LangGraph строится на разделении логики на «узлы» (nodes) и «ребра» (edges). Каждый круг в схеме потока — это функция-узел (например, поиск в векторе, веб-поиск или генерация), а каждый ромб — условное ребро, принимающее решение о направлении движения .

Процесс начинается с узла-маршрутизатора (Router). На основе анализа запроса он решает, куда отправить пользователя:

• В локальную векторную базу данных (если вопрос касается специфических тем, таких как агенты или промпт-инжиниринг) .
• В веб-поиск (если это общий или событийный вопрос, например, о драфте НФЛ) .
• На прямой ответ модели (LLM fallback), если ни один инструмент не подходит.

Особенность архитектуры в том, что даже после успешного роутинга в векторную базу, путь не является линейным. Если узел grade_documents помечает результаты как нерелевантные, граф перенаправляет поток на веб-поиск . Только после прохождения всех «контрольных пунктов» (отсутствие галлюцинаций и соответствие вопросу) система выдает финальный ответ . Лэнс наглядно показывает это на примерах: вопрос о драфте НФЛ мгновенно уходит в веб-поиск, в то время как технический вопрос о памяти агентов обрабатывается через локальный индекс с мгновенной верификацией .

🤖 Будущее архитектуры: смерть RAG или эволюция контекста? 2:05:20

Завершая практическую демонстрацию агентного RAG, Лэнс Мартин (Lance Martin) подчеркивает, что современные системы становятся всё более «саморефлексивными». Использование LangGraph позволяет создавать надежные потоки с четкими правилами («guardrails»), что делает систему предсказуемой даже при использовании небольших и быстрых моделей, таких как Command R (35 млрд параметров) . В то время как полноценные автономные агенты подходят для открытых задач, требующих глубокого рассуждения, для большинства производственных систем RAG предпочтительнее использовать структурированные графы состояний из-за их высокой воспроизводимости и низкой задержки (всего 5–7 секунд на весь цикл проверок) .

Крах иллюзии: почему миллионные контексты не убили поиск 2:12:09

Один из самых острых вопросов в индустрии ИИ сегодня: «Мертв ли RAG?». С появлением моделей Claude 3 и Gemini с контекстными окнами в миллионы токенов возник соблазн просто «загружать всё в модель» . Однако Лэнс Мартин доказывает, что огромный контекст не является автоматической заменой системы извлечения данных.

RAG — это не просто способ «впихнуть» данные в модель, а процесс рассуждения и извлечения над множеством фрагментов информации. Чтобы проверить возможности больших контекстных окон, Лэнс совместно с Грегом Кэмероном провел серию тестов под названием «Multi-needle in a Haystack» (Множество иголок в стоге сена) . В отличие от стандартных тестов на одну «иголку» (факт), этот эксперимент имитировал реальный сценарий RAG, где для ответа нужно найти и связать несколько разных фактов.

В тесте использовались ингредиенты для пиццы (инжир, прошутто, козий сыр), разбросанные в разных частях контекста объемом 120 000 токенов . Результаты показали два критических фактора:

1. Сложность масштабируется нелинейно: точность извлечения резко падает при увеличении количества искомых фактов .
2. Рассуждение усложняет задачу: если попросить модель не просто перечислить факты, а выполнить над ними логическую операцию (например, вывести первую букву каждого ингредиента), процент ошибок возрастает .

Эффект «забывания» и смещение недавности 2:18:18

Исследование выявило систематическую проблему длинных контекстов: «провалы» в памяти модели. Оказалось, что факты, расположенные в самом начале документа, теряются гораздо чаще, чем те, что находятся в конце . Это явление часто называют «Lost in the Middle», но в случае с GPT-4 оно проявляется как явное «смещение недавности» (recency bias) .

Модели склонны уделять больше внимания токенам, которые находятся ближе к моменту генерации ответа. Это делает «набивку контекста» (context stuffing) ненадежной стратегией для критически важных данных. Лэнс призывает к скептицизму в отношении маркетинговых графиков от провайдеров моделей: в реальных условиях, когда «иголки» (факты) не так сильно выделяются на фоне «сена» (остального текста), производительность оказывается значительно ниже заявленной .

Переход к документ-центричному RAG 2:21:26

«RAG не умер, он просто начал иначе пахнуть», — шутит Лэнс, цитируя Фрэнка Заппу . Парадигма поиска неизбежно меняется. Традиционный подход с жестким делением на мелкие чанки (фрагменты) по 500 токенов и подбором параметра «K» становится слишком хрупким и сложным в поддержке .

Будущее — за документ-центричным RAG. Вместо того чтобы искать крошечные абзацы, системы будут извлекать целые документы, используя возможности расширенного контекста для качественной генерации. Это решает сразу несколько проблем:

• Стоимость: «набивка» 100 000 токенов в GPT-4 обходится примерно в $1 за каждый запрос, что неприемлемо для массовых сервисов .
• Безопасность: при использовании RAG гораздо проще управлять правами доступа на уровне документов, чем при попытке фильтровать огромный общий контекст .
• Управляемость: поиск по целым документам позволяет избежать потери важного контекста, который обычно отсекается при агрессивном чанкинге.

В этом контексте по-прежнему актуальны методы анализа запросов, маршрутизации и построения метаданных. Ранее упомянутые в курсе стратегии индексации через саммари (Multi-representation) или иерархические деревья (RAPTOR) становятся связующим звеном: мы используем сжатые представления для эффективного поиска, но отдаем модели полный текст документа для финального рассуждения . Такой подход объединяет точность классического поиска с мощью современных длинных контекстов.

🚀 Будущее RAG: От простых цепочек к Flow Engineering 2:30:41

Завершая глубокое погружение в архитектуру современных ИИ-систем, Лэнс Мартин (Lance Martin) подводит итог эволюции, которую прошел поиск с дополнением генерацией. Если на заре развития технологии RAG представлял собой линейную и довольно жесткую последовательность действий, то сегодня индустрия стоит на пороге перехода к гораздо более сложным и гибким структурам. Лэнс Мартин подчеркивает, что этот сдвиг фундаментально меняет подход разработчиков к проектированию LLM-приложений .

Переход к парадигме потоков (Flow Paradigm) 2:32:38

Основной вектор развития RAG сегодня — это отказ от «наивной» модели «промпт-ответ» в пользу так называемой «парадигмы потоков» (Flow Paradigm) . Ранее системы строились по принципу простых цепочек (chains), где данные передавались строго последовательно. Однако практика показала, что такие решения остаются слишком хрупкими и часто пасуют перед вопросами, выходящими за рамки узкого домена обучающих данных или индекса.

Будущее — за системами, имеющими циклическую структуру (cyclic flow) . В такой архитектуре процесс не заканчивается на выдаче ответа. Система может возвращаться на предыдущие этапы, перепроверять себя и уточнять запросы. Лэнс Мартин отмечает, что мы уже наблюдаем этот тренд в области генерации кода, и теперь он неизбежно переносится на RAG . Flow Engineering подразумевает создание интеллектуальных графов, где каждый узел отвечает за определенный этап рассуждений, а переходы между ними зависят от промежуточных результатов.

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

Рассуждение (Reasoning) как надстройка над поиском 2:30:55

Ключевым элементом Flow Engineering является «наслоение» логических рассуждений (reasoning) на процесс извлечения данных . Лэнс Мартин выделяет два критических этапа, где рассуждение модели меняет правила игры:

1. Pre-retrieval reasoning (Рассуждение до поиска): Это стадия подготовки, включающая в себя глубокий анализ вопроса, его маршрутизацию в нужную базу данных и правильное конструирование поискового запроса . Несмотря на развитие моделей, задачи анализа и маршрутизации запросов остаются крайне актуальными .
2. Post-retrieval reasoning (Рассуждение после поиска): Когда документы уже извлечены, система не просто передает их в генератор, а проводит «оценку качества». Это включает проверку на галлюцинации и оценку того, действительно ли найденный контекст отвечает на поставленный вопрос .

В качестве примера такой надстройки Лэнс Мартин упоминает концепцию Corrective RAG (которую ранее разбирали как метод самокоррекции), где в случае нерелевантности локальных документов система инициирует веб-поиск . Это служит своего рода «страховочной сеткой», позволяющей выйти за границы индекса, если вопрос пользователя касается тем вне основного домена знаний системы . Подобные методы превращают RAG из пассивного поисковика в активного исследователя.

RAG в эпоху длинных контекстных окон 2:32:00

Одним из самых частых вопросов является жизнеспособность RAG в условиях, когда контекстные окна современных LLM (например, Gemini или модели от Anthropic) достигают сотен тысяч и миллионов токенов. Лэнс Мартин уверен: RAG никуда не исчезнет, но его фокус сместится .

В режиме работы с длинным контекстом (Long Context regime) традиционное дробление документов на мелкие фрагменты (chunking) становится менее критичным. Инженеры получают возможность работать с полнотекстовыми документами, что, по мнению Мартина, является более оптимальным подходом по Парето . Тем не менее, потребность в умной индексации — будь то иерархические методы или мульти-представления документов — сохраняется, так как это позволяет эффективно ориентироваться в огромных массивах информации .

Рассуждения и логические проверки, выполняемые поверх извлеченных данных, остаются независимыми от размера контекстного окна . Даже если модель способна «проглотить» всю библиотеку сразу, ей все равно требуются механизмы верификации, маршрутизации и защиты от галлюцинаций, которые и обеспечивает современный Flow Engineering.

Автономность и локальный запуск 2:31:21

Важной особенностью новых подходов, таких как циклическое рассуждение и самокоррекция, является их демократичность. Лэнс Мартин подчеркивает, что подобные сложные архитектуры отлично работают не только с гигантскими проприетарными моделями, но и с открытыми решениями.

В ходе демонстрации Мартин запускал описанные системы на базе Mistral 7B локально на своем ноутбуке . Это доказывает, что будущее RAG — это не только «битва контекстных окон», но и интеллектуальное использование небольших, эффективных моделей, объединенных в сложные управляемые потоки.

Завершая лекцию, Лэнс Мартин призывает разработчиков не ограничиваться простыми скриптами, а смотреть на RAG как на динамическую систему рассуждений, способную к самосовершенствованию и адаптации в реальном времени .