Что такое RAG и как ИИ отвечает по вашим документам

Короткое объяснение

RAG - это подход, при котором ИИ сначала ищет нужные фрагменты в документах, а потом отвечает с опорой на найденный контекст. Расшифровка: Retrieval-Augmented Generation, то есть генерация, усиленная поиском.

Если совсем просто:

1. пользователь задает вопрос;
2. система ищет похожие фрагменты в базе знаний;
3. найденные фрагменты добавляются в промпт;
4. модель формирует ответ;
5. ответ можно сопроводить ссылками на источники.

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

Зачем нужен RAG

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

RAG решает несколько задач:

1. дает модели доступ к вашим документам;
2. снижает риск выдуманных ответов;
3. позволяет работать с актуальными данными;
4. помогает показывать источники;
5. уменьшает потребность вставлять огромные документы в промпт;
6. делает ответы полезнее для поддержки, обучения и внутреннего поиска;
7. отделяет знания от самой модели;
8. позволяет обновлять базу знаний без переобучения LLM.

Идея простая: модель не должна “угадывать” регламент, если его можно найти и передать в контекст.

Пример RAG на бытовом уровне

Представьте сотрудника поддержки. Клиент спрашивает:

Можно ли вернуть товар без упаковки?

Плохой AI-ответ без RAG может звучать уверенно, но быть выдуманным:

Да, товар можно вернуть без упаковки в течение 14 дней.

RAG-система работает иначе:

1. ищет фразу “возврат без упаковки” в базе знаний;
2. находит раздел регламента;
3. передает модели найденный фрагмент;
4. модель отвечает по этому фрагменту;
5. если ответа нет, честно пишет, что не нашла подтверждение.

Так ответ становится ближе к реальным правилам компании.

Как работает RAG

Классический RAG состоит из двух этапов: подготовка базы и ответ на вопрос.

Подготовка базы:

1. собрать документы;
2. извлечь текст;
3. очистить лишний мусор;
4. разбить документы на фрагменты;
5. создать embeddings;
6. сохранить фрагменты и метаданные в индекс;
7. настроить обновление базы.

Ответ на вопрос:

1. принять вопрос пользователя;
2. превратить вопрос в embedding или поисковый запрос;
3. найти релевантные фрагменты;
4. отфильтровать по правам доступа;
5. выбрать лучшие фрагменты;
6. передать их модели;
7. сгенерировать ответ;
8. показать источники или основания.

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

Что такое retrieval

Retrieval - это поиск нужных фрагментов перед генерацией ответа. Это первая буква R в RAG.

Retrieval может быть разным:

1. keyword search - поиск по точным словам;
2. semantic search - поиск по смыслу через embeddings;
3. hybrid search - сочетание ключевых слов и смысла;
4. metadata filtering - фильтрация по дате, разделу, правам, продукту;
5. reranking - повторная сортировка найденных кандидатов;
6. agentic retrieval - когда агент сам уточняет, где и как искать.

Для бизнес-документов часто нужен hybrid search: смысловой поиск хорошо понимает формулировки, а keyword search ловит артикулы, номера договоров, названия функций и точные термины.

Что такое embeddings

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

Пример:

1. в документе написано “оформление возврата”;
2. пользователь спрашивает “как вернуть товар”;
3. точные слова отличаются;
4. embeddings помогают понять, что смысл похожий;
5. RAG находит нужный фрагмент.

Embeddings не “понимают” документ как человек, но позволяют сравнивать тексты по близости в векторном пространстве.

Что такое векторная база

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

В векторной базе обычно хранят:

1. текст chunk;
2. embedding;
3. URL или путь к источнику;
4. название документа;
5. раздел;
6. дату обновления;
7. права доступа;
8. продукт или категорию;
9. язык;
10. служебные поля для фильтрации.

Популярные варианты: Qdrant, Weaviate, Pinecone, Chroma, Redis Vector Search, pgvector. Но выбор базы - не первый вопрос. Сначала важнее качество документов, chunking и тесты.

Что такое chunking

Chunking - это разбиение длинного документа на фрагменты. RAG редко отправляет модели документ целиком. Он ищет и передает несколько релевантных частей.

Хороший chunk должен:

1. быть достаточно коротким для контекста;
2. сохранять смысл;
3. не обрывать важное правило;
4. включать заголовок или метаданные;
5. не смешивать разные темы;
6. быть удобным для поиска;
7. иметь ссылку на источник.

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

Что такое reranker

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

Схема:

1. retriever нашел 30 фрагментов;
2. reranker перечитал их внимательнее;
3. выбрал 5 лучших;
4. эти 5 попали в контекст модели.

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

RAG и длинный промпт

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

Минусы длинного промпта:

1. расходует много токенов;
2. стоит дороже;
3. работает медленнее;
4. содержит лишний шум;
5. может не поместиться в контекстное окно;
6. сложнее обновлять данные;
7. выше риск утечки лишней информации;
8. модель может упустить важное среди мусора.

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

RAG и память

RAG и память часто путают, но это разные вещи.

RAG отвечает на вопрос:

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

Память отвечает на другой вопрос:

1. что пользователь уже выбрал;
2. какие настройки сохранить;
3. какие предпочтения учесть;
4. что было решено в прошлой сессии.

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

RAG и галлюцинации

RAG снижает риск галлюцинаций, но не убирает его полностью.

Почему RAG помогает:

1. модель получает фактический контекст;
2. можно требовать ответ только по источникам;
3. можно показать ссылки на документы;
4. можно проверять groundedness;
5. можно сказать “ответ не найден”.

Почему риск остается:

1. поиск может найти не тот фрагмент;
2. нужный документ может отсутствовать;
3. база знаний может устареть;
4. модель может неправильно понять источник;
5. фрагменты могут противоречить друг другу;
6. права доступа могут быть настроены неверно;
7. prompt может разрешать домысливать.

Поэтому хороший RAG всегда проверяют тестами.

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

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

Примеры:

1. чат по базе знаний компании;
2. поддержка клиентов;
3. поиск по договорам;
4. внутренний helpdesk;
5. обучение сотрудников;
6. ответы по документации продукта;
7. поиск по статьям сайта;
8. подготовка коммерческих предложений;
9. анализ тендерной документации;
10. чат по юридическим документам;
11. ассистент для HR;
12. поиск по регламентам и инструкциям.

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

Когда RAG не нужен

RAG не стоит добавлять везде подряд.

Он может быть лишним, если:

1. задача творческая и не требует фактов;
2. вся нужная информация уже в коротком промпте;
3. документов мало и они редко меняются;
4. ответ не должен ссылаться на источники;
5. точность не критична;
6. нужно просто переписать текст;
7. пользователь сам вставляет весь нужный контекст;
8. нет базы знаний, которую можно поддерживать.

RAG - это не магическая добавка к модели, а отдельная система поиска и качества.

Что подготовить перед запуском RAG

Перед технической сборкой нужно привести знания в порядок.

Минимальный список:

1. список источников;
2. владельцы документов;
3. актуальные версии;
4. правила доступа;
5. формат документов;
6. политика обновления;
7. список частых вопросов;
8. критерии правильного ответа;
9. тестовые вопросы;
10. правила, когда отвечать “не найдено”.

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

Как оценивать качество RAG

RAG нужно тестировать отдельно от модели.

Основные метрики и проверки:

1. нашелся ли правильный документ;
2. попал ли нужный chunk в top 5;
3. ответ подтверждается источником;
4. модель не добавила лишние факты;
5. вопрос без ответа не вызвал выдумку;
6. права доступа соблюдены;
7. устаревший документ не использован;
8. источник показан пользователю;
9. ответ понятен;
10. задержка приемлемая.

Для старта достаточно набора из 30-50 реальных вопросов. После изменения chunking, embeddings или базы прогоняйте тесты снова.

Типичные ошибки в RAG

Чаще всего проблемы возникают не из-за модели, а из-за подготовки системы.

Ошибки:

1. загрузили грязные документы;
2. не удалили старые версии;
3. нарезали chunks случайно;
4. не добавили метаданные;
5. забыли права доступа;
6. использовали только semantic search для точных кодов;
7. не проверили retrieval;
8. не запретили модели домысливать;
9. не показали источники;
10. не сделали тесты на вопросы без ответа;
11. не настроили обновление индекса;
12. отправили слишком много фрагментов в контекст.

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

Мини-чеклист первого RAG

Для первой версии достаточно простой схемы:

1. выберите один набор документов;
2. удалите устаревшие и дубли;
3. разбейте документы на chunks;
4. добавьте метаданные;
5. создайте embeddings;
6. сохраните в векторную базу;
7. настройте поиск;
8. добавьте правило “не найдено”;
9. покажите источники в ответе;
10. прогоните 30 тестовых вопросов.

Если эта версия работает стабильно, можно добавлять hybrid search, reranker, права доступа и мониторинг.

Что изучать дальше

После RAG логично изучить:

1. embeddings;
2. vector database;
3. semantic search;
4. hybrid search;
5. reranker;
6. chunking;
7. metadata filtering;
8. groundedness;
9. evals для RAG;
10. память ИИ-агента.

Эти темы превращают “чат с документами” в нормальную поисковую систему для AI.

Частые вопросы

RAG - это обучение модели на документах?

Нет. RAG обычно не переобучает модель. Документы хранятся отдельно, система ищет релевантные фрагменты и передает их модели как контекст для ответа.

RAG полностью убирает галлюцинации?

Нет. RAG снижает риск, но не гарантирует идеальную точность. Поиск может найти не тот документ, база может устареть, а модель может неверно интерпретировать источник.

Чем RAG отличается от поиска по сайту?

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

Нужно ли сразу покупать векторную базу?

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

Какие документы подходят для RAG?

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