К этому моменту мы установили несколько важных фактов.
Во-первых, большая языковая модель не является поисковой системой.
Во-вторых, её знания зафиксированы на момент окончания обучения.
В-третьих, регулярное переобучение модели практически невозможно из-за высокой стоимости, сложности и риска потери уже усвоенных знаний.
Если посмотреть на эти ограничения вместе, возникает интересный вопрос.
Почему мы вообще пытаемся заставить модель помнить всё?
Может быть, сама постановка задачи неверна?
Две совершенно разные задачи
Рассмотрим библиотеку крупного университета.
Предположим, что в ней хранится десять миллионов книг.
Перед библиотекарем стоят две разные задачи.
Первая задача — найти нужную книгу.
Вторая задача — объяснить студенту её содержание.
Интуитивно понятно, что это разные виды деятельности.
Поиск книги требует хорошего каталога, классификации, индексов и системы хранения.
Объяснение материала требует понимания предметной области, способности рассуждать и формулировать мысли.
Нет никакой причины ожидать, что один и тот же механизм должен одинаково хорошо выполнять обе задачи.
Тем не менее именно этого долгое время пытались добиться от больших языковых моделей.
Мы хотели, чтобы они одновременно:
- хранили знания;
- искали знания;
- понимали знания;
- объясняли знания.
На практике оказалось, что эти задачи лучше разделить.
Принцип разделения ответственности
В инженерии программного обеспечения существует фундаментальный принцип.
Каждый компонент системы должен выполнять одну основную функцию.
Например, в типичном веб-приложении:
- база данных хранит информацию;
- веб-сервер принимает запросы;
- приложение реализует бизнес-логику;
- браузер отображает интерфейс.
Никто не пытается заставить базу данных рисовать пользовательский интерфейс, а браузер — выполнять SQL-запросы.
Разделение ответственности делает систему проще, надежнее и легче в сопровождении.
Точно такой же принцип оказался применим и к большим языковым моделям.
Вместо одной системы, которая должна делать всё сразу, архитектуру можно разделить на две независимые части.
Первая часть отвечает за поиск информации.
Вторая — за её анализ и генерацию ответа.
Именно эта идея лежит в основе Retrieval-Augmented Generation.
Что означает название Retrieval-Augmented Generation
Название технологии состоит из трёх слов.
Retrieval
В переводе с английского — извлечение или поиск.
Речь идет о поиске информации во внешнем источнике.
Важно подчеркнуть: это не обязательно Интернет.
Источником могут быть:
- PDF-документы;
- исходный код проекта;
- база знаний компании;
- Wiki;
- Confluence;
- Notion;
- электронная почта;
- база данных;
- файловая система;
- Git-репозиторий;
- научные статьи;
- техническая документация.
На этом этапе нас интересует лишь одно.
Необходимо найти информацию, относящуюся к вопросу пользователя.
Augmented
Это слово переводится как дополненная или расширенная.
Здесь скрывается ключевая идея всей архитектуры.
Мы не изменяем модель.
Мы дополняем её входные данные.
То есть перед тем как попросить модель ответить на вопрос, мы сначала предоставляем ей дополнительный контекст.
Другими словами, модель получает не только запрос пользователя, но и найденные документы.
Generation
Последний этап — генерация ответа.
Получив дополнительную информацию, модель может использовать её так же, как человек использует открытую книгу на столе.
Она читает найденный текст, анализирует его и формулирует ответ.
Именно поэтому RAG иногда образно называют «open-book exam» — экзаменом с открытой книгой.
LLM больше не пытается отвечать исключительно по памяти.
Она отвечает, имея перед собой необходимые материалы.
Первая архитектура RAG
Теперь объединим всё сказанное в единую схему.
Вопрос пользователя
│
▼
┌──────────────────────┐
│ Retrieval (Поиск) │
└──────────────────────┘
│
Найденные документы
│
▼
┌──────────────────────┐
│ LLM (Generation) │
└──────────────────────┘
│
▼
Ответ пользователю
На первый взгляд архитектура выглядит удивительно простой.
Но именно эта простота оказалась её главным преимуществом.
Почему это оказалось настолько эффективным
Представим врача.
Без доступа к медицинской карте пациента он вынужден опираться только на общие знания и собственный опыт.
Теперь представим, что перед консультацией ему автоматически предоставили:
- историю болезни;
- результаты анализов;
- снимки МРТ;
- назначения других врачей;
- последние лабораторные исследования.
Очевидно, что качество консультации резко возрастёт.
Важно понимать, что врач не стал умнее.
Он просто получил больше релевантной информации.
С LLM происходит то же самое.
Мы не улучшаем саму модель.
Мы улучшаем условия, в которых она принимает решение.
Это принципиально разные вещи.
Почему RAG оказался лучше постоянного обучения
После появления первых успешных систем стало ясно, что такой подход имеет сразу несколько преимуществ.
Актуальность знаний
Если изменился документ, достаточно обновить его в хранилище.
Модель остаётся прежней.
При следующем запросе она автоматически получит уже новую версию.
Отсутствие переобучения
Нет необходимости запускать дорогостоящее обучение.
Меняется база знаний.
Модель остаётся неизменной.
Прозрачность
Если модель дала неправильный ответ, можно посмотреть, какие документы были найдены.
Если нужный документ отсутствовал, проблема находится в системе поиска.
Если документ был найден, но модель его проигнорировала, проблема уже относится к генерации.
Такое разделение значительно упрощает диагностику.
Контроль источников
Можно не только получить ответ, но и показать пользователю, на основании каких документов он был сформирован.
Например:
Согласно инструкции Deployment Guide v4.2, перед обновлением необходимо выполнить резервное копирование базы данных.
Такой ответ вызывает гораздо больше доверия, чем утверждение без указания источника.
Именно поэтому современные корпоративные RAG-системы почти всегда возвращают ссылки на документы, фрагменты текста или номера страниц.
Но всё ли так просто?
После знакомства с базовой схемой может возникнуть ощущение, что задача уже решена.
Достаточно выполнить поиск, передать найденный текст модели — и качественный ответ гарантирован.
К сожалению, практика показала, что это лишь начало.
Очень быстро выяснилось, что эффективность RAG зависит от десятков факторов:
- как именно разбивать документы на части;
- как преобразовывать текст в векторы;
- какую модель эмбеддингов использовать;
- как организовать поиск по миллионам документов;
- сколько фрагментов передавать модели;
- как отсортировать найденные результаты;
- как удалить шум;
- как сформировать итоговый контекст.
Каждый из этих вопросов способен кардинально изменить качество ответа.
Именно поэтому современный RAG — это уже не простая схема из двух блоков, а целая экосистема взаимосвязанных компонентов.
В следующих разделах первой главы мы постепенно усложним эту архитектуру, чтобы увидеть, как из простой идеи «найти документы и показать их модели» выросли современные промышленные RAG-системы, способные работать с миллиардами документов и обслуживать тысячи пользователей одновременно.