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

Источник: https://www.youtube.com/watch?v=sVcwVQRHIc8
Канал: freeCodeCamp.org
Опубликовано: 17.04.2024

---

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

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

[[JUMP:00:00]]

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

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

### Индексация и магия векторных эмбеддингов
[[JUMP:06:03]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*   Определяется промпт, который ставит перед моделью задачу перефразировать исходный вопрос на пять различных подвопросов [25:53].
*   Для каждого из сгенерированных вопросов выполняется независимый поиск в векторной базе данных (например, Chroma) [26:19].
*   Результаты всех поисков объединяются в единое множество уникальных документов (Unique Union), которые и становятся контекстом для финального ответа [26:32].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*   Система получает описание доступных фильтров (длительность видео, количество просмотров, дата) [1:01:47].
*   LLM, используя схему Pydantic, анализирует запрос и извлекает из него параметры фильтрации [1:02:53].
*   На выходе мы получаем JSON-объект, который библиотека LangChain конвертирует в поисковый фильтр для векторной БД (например, Pinecone или Chroma) [1:03:18].

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

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

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

Идея проста:

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

Когда система находит нужное саммари, она по связанному ID извлекает из хранилища *весь* исходный документ и передает его в LLM для генерации ответа [1:07:50]. Этот подход особенно эффективен для моделей с большим окном контекста: нам не нужно дробить документ на мелкие части и терять связность, достаточно эффективно найти документ целиком с помощью его сжатого представления [1:08:03]. Это гарантирует, что у модели будет максимум информации для точного ответа [1:11:27].

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

[[JUMP:1:15:04]]

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

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

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

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

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

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

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

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

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

*   Вопрос также разбивается на токены, для каждого создается вектор.
*   Для каждого токена вопроса вычисляется максимальное сходство со всеми токенами документа (MaxSim) [1:22:29].
*   Финальный скор документа — это сумма этих максимальных сходств [1:22:54].

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

### LangGraph и концепция State Machines
[[JUMP:1:26:44]]

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

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

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

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

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

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

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

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

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

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

[[JUMP:1:44:14]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[JUMP:2:05:20]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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