ИИ-ассистенты и RAG: как дать модели отвечать на основе ваших данных

Большая языковая модель умеет хорошо работать с текстом, но сама по себе не является базой знаний вашей компании. Она не знает ваши внутренние регламенты, актуальные инструкции, каталог товаров, условия договоров или историю конкретного клиента, если эти данные не были переданы ей в запросе или через подключённый источник.

Именно эту проблему решает RAG (Retrieval-Augmented Generation) — подход, при котором перед генерацией ответа система сначала находит релевантную информацию во внешнем источнике, а затем передаёт найденный контекст языковой модели.

Идея RAG не новая: термин и базовая архитектура были формализованы в работе Patrick Lewis и соавторов в 2020 году. В исходном исследовании авторы показали, что сочетание генеративной модели с внешним механизмом поиска позволяет получать более конкретные и фактически ориентированные ответы на задачах, требующих работы с внешними знаниями.

Но в реальных ИИ-ассистентах RAG — это далеко не просто «положить документы в векторную базу и сделать поиск».

Что такое RAG простыми словами

В обычном сценарии пользователь задаёт вопрос непосредственно языковой модели:

Пользователь → LLM → Ответ

Модель использует знания, полученные во время обучения, и текущий контекст запроса.

Для корпоративного ассистента такой схемы обычно недостаточно. Нужна другая цепочка:

Пользователь
    ↓
Поиск по базе знаний
    ↓
Релевантные фрагменты
    ↓
Контекст + вопрос
    ↓
LLM
    ↓
Ответ

То есть модель не должна самостоятельно «вспоминать» внутреннюю информацию компании. Система сначала извлекает нужные данные, после чего модель использует их для формирования ответа.

Это и есть принцип Retrieval-Augmented Generation: retrieval отвечает за поиск знаний, generation — за формирование ответа.

Когда RAG действительно нужен

RAG особенно полезен там, где информация находится во внешних источниках и регулярно меняется.

Например:

• база знаний службы поддержки;
• техническая документация;
• внутренние инструкции и регламенты;
• документы и договоры;
• каталог товаров и описания;
• корпоративная Wiki;
• FAQ;
• нормативные документы;
• информация о продуктах и тарифах.

Главное преимущество здесь не в том, что модель внезапно становится «умнее». Она получает доступ к информации, которой не должна хранить только внутри своих параметров.

При изменении документа не требуется переобучать саму языковую модель. Достаточно обновить индекс или другой используемый механизм поиска. Именно возможность работать с внешней и обновляемой памятью была одной из основных идей исходного подхода RAG.

При этом RAG не является гарантией правильного ответа. Если система нашла неправильный фрагмент, устаревший документ или вообще ничего релевантного не нашла, языковая модель всё равно может сформировать убедительно звучащий ответ.

Поэтому качество RAG-системы определяется не только выбранной LLM.

Из чего состоит RAG-пайплайн

Упрощённо систему можно разделить на два больших контура.

Офлайн-контур подготавливает знания:

Документы
    ↓
Очистка и нормализация
    ↓
Разбиение на chunks
    ↓
Embeddings
    ↓
Индекс

Онлайн-контур обрабатывает запрос пользователя:

Запрос
    ↓
Поиск
    ↓
Фильтрация / объединение результатов
    ↓
Reranking
    ↓
Формирование контекста
    ↓
LLM
    ↓
Ответ

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

Подготовка базы знаний

Первый этап — превратить исходные данные в форму, пригодную для поиска.

Документы могут поступать из разных источников:

• Markdown и HTML;
• PDF;
• DOCX;
• базы данных;
• CMS;
• API;
• корпоративной Wiki;
• файловых хранилищ.

Но нельзя просто взять весь документ и превратить его в один embedding.

Большие документы обычно разбиваются на отдельные фрагменты — chunks. Такой подход позволяет находить не весь документ целиком, а конкретный участок, относящийся к вопросу пользователя. В современных RAG-системах размер, границы и overlap этих фрагментов рассматриваются как отдельные параметры, которые необходимо подбирать под конкретные данные и запросы.

Например, документацию интернет-магазина можно разбить по логическим разделам:

Документ
 ├── Доставка
 │    ├── Сроки доставки
 │    ├── Стоимость
 │    └── География
 │
 ├── Возврат
 │    ├── Условия возврата
 │    └── Сроки
 │
 └── Оплата
      ├── Банковские карты
      └── СБП

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

Почему chunking важнее, чем кажется

Одна из распространённых ошибок — считать chunking чисто техническим этапом.

На самом деле граница фрагмента влияет на весь дальнейший поиск.

Слишком маленький chunk может потерять смысл. Например:

Срок действия договора составляет 12 месяцев.

Сам по себе этот фрагмент не говорит, о каком договоре идёт речь.

Слишком большой chunk, наоборот, содержит много лишней информации. Даже если нужный факт внутри него есть, поиск и последующая генерация работают с большим количеством шума.

Именно поэтому современные рекомендации по RAG рассматривают размер chunk, границы и overlap как параметры, которые необходимо проверять экспериментально, а не как универсальную константу.

Отдельный интерес представляет подход Contextual Retrieval, описанный Anthropic. Перед индексацией к каждому chunk добавляется краткое описание его места и смысла в исходном документе, после чего уже этот контекстуализированный фрагмент индексируется. В опубликованном эксперименте Anthropic контекстуализация вместе с BM25 и последующим reranking заметно снизила долю случаев, когда нужный фрагмент не попадал в top-20 результатов.

Это хороший пример важного принципа: качество RAG начинается до первого запроса пользователя.

Embeddings и векторный поиск

После разбиения текста фрагменты преобразуются в числовые представления — embeddings.

Embedding кодирует смысл текста в виде вектора. Поэтому два фрагмента, сформулированные разными словами, могут оказаться близкими в векторном пространстве.

Например:

"Как вернуть товар?"

и

"Условия оформления возврата покупки"

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

Это главное преимущество семантического поиска.

Но у него есть слабое место — точные идентификаторы.

Например, пользователь может спросить:

Что означает ошибка TS-999?

Для такого запроса важно найти именно TS-999, а не просто документы про ошибки.

Anthropic отдельно приводит подобный пример и показывает, почему классический лексический поиск BM25 может находить точные термины лучше, чем один только semantic search.

Почему одного vector search часто недостаточно

В production-системах всё чаще используется гибридный поиск — комбинация семантического и лексического поиска.

Условно:

Query
 ├── Vector Search
 │
 └── BM25 / Full-text Search
          ↓
      Объединение
          ↓
       Reranking
          ↓
       Top-K

Vector search хорошо работает с перефразированными и смысловыми запросами.

BM25 хорошо работает с:

• артикулами;
• кодами ошибок;
• названиями продуктов;
• аббревиатурами;
• именами;
• точными терминами.

Гибридный поиск позволяет использовать преимущества обоих подходов. Такой архитектурный паттерн прямо рекомендуется и описывается в современных RAG-инструментах и архитектурных руководствах.

Reranking: ещё один важный этап

После первоначального поиска система может получить, например, 20–50 потенциально релевантных фрагментов.

Но первоначальный retrieval оптимизируется скорее на recall — лучше вернуть больше кандидатов и не потерять нужный документ.

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

Поэтому используется reranking.

Его задача — повторно оценить найденные документы уже относительно конкретного запроса и поднять наиболее релевантные результаты наверх. Microsoft описывает типовой production-подход как последовательность retrieve → merge → rerank → truncate, после чего в модель передаются только лучшие фрагменты.

Pinecone также рассматривает reranking как один из наиболее прямых способов повысить качество retrieval в RAG-пайплайне.

Цена этого улучшения — дополнительная задержка и вычислительная стоимость.

Поэтому реальная архитектура обычно выглядит как компромисс:

Быстрый retrieval
        ↓
Большой набор кандидатов
        ↓
Более дорогой reranker
        ↓
Небольшой набор лучших chunks
        ↓
LLM

Генерация ответа на основе контекста

После поиска и reranking формируется prompt для языковой модели.

Условно:

Вопрос пользователя:
...

Контекст:
[фрагмент 1]
[фрагмент 2]
[фрагмент 3]

Инструкция:
Отвечай только на основании предоставленного контекста.
Если информации недостаточно — сообщи об этом.

Такой подход не превращает модель в базу данных. Он лишь даёт ей релевантную информацию в момент генерации.

Для корпоративного ассистента это принципиально важно: модель должна понимать разницу между тем, что содержится в retrieved context, и тем, что она «знает» из общего языкового контекста.

Практически это означает, что в prompt и логике приложения стоит явно задавать поведение при отсутствии ответа.

Например:

Если в предоставленном контексте нет достаточной информации
для ответа, не придумывай данные и сообщи, что информации недостаточно.

Но одной инструкции недостаточно, чтобы полностью исключить ошибки. Исследования и практические руководства по RAG отдельно подчёркивают необходимость оценки и проверки качества всей системы.

Почему RAG не решает проблему галлюцинаций полностью

Распространённый маркетинговый тезис звучит так:

«Добавим RAG — и модель перестанет галлюцинировать».

Это неправильно.

RAG уменьшает зависимость ответа от внутренних знаний модели, но не гарантирует правильность результата.

Проблема может возникнуть на любом этапе:

Плохой документ
      ↓
Плохой chunking
      ↓
Плохой retrieval
      ↓
Нерелевантный context
      ↓
Неверная генерация

Поэтому нужно отдельно проверять:

1. нашёл ли retrieval нужный фрагмент;
2. насколько найденный контекст релевантен;
3. использовала ли модель этот контекст;
4. соответствует ли итоговый ответ источнику.

Для оценки RAG существуют отдельные метрики и подходы, которые рассматривают retrieval и generation как разные части системы. Среди них встречаются оценки релевантности контекста, корректности ответа и faithfulness — соответствия ответа предоставленному контексту.

Как оценивать RAG до запуска в production

Одна из самых полезных практик — не оценивать систему субъективно по нескольким вопросам.

Нужно собрать собственный набор тестовых запросов.

Например:

Вопрос
→ какой документ должен быть найден
→ какой chunk должен быть найден
→ какой ответ считается правильным

После этого можно отдельно измерять retrieval и generation.

Например:

Retrieval
- найден ли нужный документ?
- попал ли нужный chunk в top-K?
- насколько релевантен контекст?

Generation
- отвечает ли модель на вопрос?
- соответствует ли ответ контексту?
- добавляет ли модель факты, которых нет в источниках?

Такой подход позволяет понять, где именно находится проблема.

Если правильный документ не найден — бессмысленно менять prompt.

Если документ найден, но модель отвечает неправильно — проблема уже находится на уровне генерации или структуры контекста.

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

RAG — это не обязательно сложная инфраструктура

Для небольшой базы знаний можно построить достаточно простой pipeline:

Документы
   ↓
Chunking
   ↓
Embeddings
   ↓
Vector DB
   ↓
Top-K
   ↓
LLM

Для более серьёзной системы архитектура может постепенно усложняться:

Источники данных
       ↓
Ingestion
       ↓
Parsing / Cleaning
       ↓
Chunking
       ↓
Embeddings
       ↓
┌─────────────────────┐
│ Vector Search       │
│ BM25 / Full-text    │
│ Metadata filters    │
└──────────┬──────────┘
           ↓
      Result Fusion
           ↓
       Reranking
           ↓
      Context Builder
           ↓
          LLM
           ↓
      Answer / Sources

На этом уровне уже появляются вопросы, которые невозможно решить одной настройкой модели: обновление индексов, versioning документов, ACL, фильтрация по tenant, кеширование, latency, стоимость retrieval и generation, мониторинг и оценка качества.

Где RAG особенно полезен бизнесу

Для бизнеса ценность RAG обычно заключается не в самом факте использования векторной базы.

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

Например, вместо общего вопроса:

Расскажите о компании.

пользователь может задать конкретный:

Какие документы нужны для возврата товара
после истечения 14 дней?

Ассистент должен найти соответствующее правило во внутренних документах и дать ответ на его основании.

В другом сценарии менеджер может спросить:

Какие условия действуют для этого клиента?

И тогда источником знаний может быть уже не PDF-файл, а CRM, внутреннее API или база данных.

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

Что важно учитывать при проектировании

Хороший RAG начинается не с выбора векторной базы.

Сначала нужно определить:

• какие данные должен использовать ассистент;
• насколько часто они обновляются;
• какие запросы будут задавать пользователи;
• нужны ли точные совпадения терминов;
• требуется ли фильтрация по пользователю или организации;
• насколько критична ошибка ответа;
• какая допустима задержка;
• какие данные нельзя передавать внешним моделям.

Только после этого имеет смысл выбирать конкретные технологии для embeddings, поиска, reranking и генерации.

Для одной системы может быть достаточно обычного vector search. Для другой потребуется hybrid search, metadata filtering, reranking и отдельный контур оценки качества.

Итог

RAG — это не «подключение ChatGPT к базе документов».

Это целый pipeline:

Данные
→ подготовка
→ chunking
→ embeddings
→ retrieval
→ hybrid search
→ reranking
→ context
→ LLM
→ оценка ответа

Именно поэтому качество ИИ-ассистента нельзя оценивать только по выбранной языковой модели.

На практике результат определяется всей системой: качеством исходных данных, способом их разбиения, поиском, фильтрацией, reranking, формированием контекста и контролем ответа.

Для небольших проектов достаточно начать с простого RAG. Но по мере роста базы знаний и требований к точности обычно приходится переходить к гибридному поиску, reranking и формальной оценке качества. Такой эволюционный подход лучше, чем сразу строить избыточную инфраструктуру.