Что такое RAG: как не позволить чат-ботам выдумывать факты о компании
Практическое руководство по работе с конвейером RAG: загрузчики, разбиение на части, эмбеддинги, хранилища векторов, переранжирование, гибридный поиск и RRF, а также ситуации, когда вообще не стоит использовать механизм поиска.
Типичное задание для ранних чат-ботов выглядит так: отвечать на вопросы, основанные на корпоративных документах. Быстрый прототип часто кажется совершенным — но при этом выдумывает факты. Он может утверждать, что предоставляется «поддержка 24/7 в 12 странах», хотя на самом деле поддержка существует только в одной стране, и то в рабочее время, причем лишь тогда, когда доступен определённый сотрудник IT.
Именно такая проблема и является сутью технологии RAG (Retrieval-Augmented Generation): модель, которая может сгенерировать ответ, — это не то же самое, что модель, у которой есть реальные данные организации. Без связи с реальными данными такие модели ведут себя как уверенные родственники, выдумывающие историю семьи на свадьбе: примерно сорок процентов ответов верны, но они на сто процентов уверены в своей правоте.
Часть 1: Что же такое RAG?
RAG означает Retrieval-Augmented Generation. Идея проста.
Вместо того чтобы просить модель отвечать исключительно на основе данных из обучения, система сначала загружает соответствующий материал, а затем запрашивает ответ, ограниченный этим материалом.
Рассматривайте текстовую модель как очень способного, но чрезмерно уверенного стажера: он отлично пишет, но плохо помнит политику HR за 2023 год. Задача технологии RAG — подать стажеру нужную страницу до того, как он начнет отвечать.
Без RAG: ответы основаны на памяти (устаревшей, общей или не учитывающей особенности компании). С RAG: ответы основаны на памяти плюс файлах, загруженных для данного вопроса.
Краткая формула, которая всегда работает:
Правильная информация × Правильный контекст × Правильное задание = Правильный ответ
Часть 2: Процесс работы RAG
Технология усиления за счет поиска — это не один магический вызов. Это многоступенчатый процесс: если какая-либо ступень срывается, ответы поступают с опозданием или неверно.
Этап 1 — Источники знаний
Где хранится материал? PDF-файлы, документы Word, страницы Notion, таблицы SQL, экспорт данных из Slack и забытые таблицы расчетов — всё это считается источниками знаний.
Этап 2 — Загрузчики документов (получение данных ВНУТРЬ)
Процесс обработки преобразует файлы PDF/HTML/CSV и т. д. в чистый, унифицированный формат — обычно что-то вроде:
Document(
page_content="The quick brown fox...",
metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)
Игнорирование тщательной загрузки и прямое вставление необработанных байтов PDF в поток данных часто приводит к тому, что заголовки и подзаголовки становятся «фактами» («Согласно странице 47 из 92…»). Никто не просил информацию о форматировании страницы.
Урок: грязная обработка данных приводит к грязному поиску и некорректным ответам. Необходимо соблюдать чистоту на начальном этапе.
Этап 3 — Разбиение на части (или «нарезка пиццы»)
200-страничный PDF нельзя просто вставить в запрос. Окна контекста ограничены, и загрузка в модель всего кулинарного справочника при запросе на один рецепт снижает точность ответов.
Документы поэтому делятся на сегменты.
Распространённые стратегии:
- Разделение фиксированного размера — разрезка каждые N токенов. Быстро, но происходит разрезка посеред предложения.
- Разделение фиксированного размера с перекрытием — те же разрезки, но с небольшим перекрытием, чтобы контекст границы сохранялся. Распространённый стандартный вариант.
- Иерархическое/рекурсивное разделение — учёт разделов и абзацев перед разрезкой.
- Семантическое разделение — группировка предложений на одну тему с помощью эмбеддингов. Более умный подход, но требует больше вычислительных ресурсов.
- Разделение на основе LLM / агентного подхода — запрос модели о том, где следует производить разрезки. Дорого, но полезно для юридических/медицинских текстов.
Практическое правило, сформулированное после наблюдения за тем, как в контракте фраза «shall NOT be liable» оказывается после «shall» при разделении на сегменты: начинайте с фиксированного размера плюс перекрытие; добавляйте сложность только тогда, когда качество поиска действительно плохое.
Этап 4 — Эмбеддинги (преобразование слов в GPS-координаты)
Эмбеддинг преобразует предложение в список чисел, отражающий смысл, а не орфографию. Предложения с похожим смыслом находятся рядом друг с другом даже при отсутствии общих слов.
Фразы «Как сбросить пароль?» и «Забыты учетные данные для входа» практически не имеют общих элементов, но означают почти одно и то же. Поиск по ключевым словам упускает эту связь; эмбеддинги выявляют её путем сравнения смысла.
История развития прошла от метода «мешок слов» (учет только количества) → TF-IDF → Word2Vec → BERT → современных API эмбеддингов и открытых моделей (OpenAI, Cohere, BGE, E5 и др.), учитывающих контекст.
Аналогия: Метод «мешок слов» — это машинный перевод слово в слово. Современные эмбеддинги ближе к человеку, который знаком с обеими культурами и понимает намерение.
Этап 5 — Хранилища векторов (библиотека, где хранятся все эти списки чисел)
Когда сегменты превращаются в векторы, требуется быстрое хранение и поиск: Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS и подобные системы.
При поступлении запроса возвращаются K лучших сегментов, векторы которых находятся ближе всего к вектору запроса. Варианты индексации включают:
- Грубая сила — сравнение всего. Точный метод, но медленный при больших объемах.
- ANN (приблизительный ближайший сосед) — менее точный, но значительно быстрый. Хороший стандартный вариант.
- IVF — сначала кластеризация; поиск только в перспективных кластерах.
- HNSW — быстрый поиск в графе соседей. Широко используется в производственных решениях типа RAG.
Использование грубой силы для обработки миллионов векторов «для полной точности» может превратить запросы, занимающие миллисекунды, в задержки длительностью во время перерыва на чай. Подбирайте индекс в зависимости от размера данных, а не из-за гордыни.
Шаг 6 — Получение данных (поиск по сходству)
Когда поступает вопрос, его встраивают с использованием того же модели, что и для файлов — смешивание моделей является классической ошибкой, — затем извлекают топ-K похожих фрагментов.
Косинусное сходство — это стандартный показатель: степень совпадения направлений двух векторов без учета длины. Это стабильный параметр, работающий при различной длине текста.
Этап 7 — Дополнение (предоставление интерну правильного файла)
Извлеченные фрагменты вставляются в промпт вместе с вопросом пользователя. Это и есть этап «дополнения»:
System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?
Этап 8 — Генерация (LLM наконец высказывается)
Только тогда модель формирует окончательный ответ, основанный на извлеченном контексте, а не на субъективных ощущениях.
Часть 3: Факторы, отличающие «это работает» от «это хорошо работает»
Учебные материалы часто ограничиваются базовым алгоритмом работы. Для качественных реальных систем обычно требуется больше.
Переупорядочивание — потому что первый результат поиска не всегда является лучшим
Метод би-кодировщиков для поиска работает быстро, но имеет грубую точность: запрос и документ кодируются отдельно, затем сравниваются. Он отлично подходит для сокращения миллионов элементов до примерно 50 кандидатов.
«Быстро и примерно верно» не всегда означает «действительно верно», поэтому более медленный кросс-кодировщик для переупорядочивания оценивает запрос и документ одновременно, учитывая нюансы, отрицания и контекст. Он работает только с отобранным списком, повышая качество настоящих лучших результатов.
Аналогия: би-кодировщики быстро просматривают резюме для формирования короткого списка; кросс-кодировщики проводят собеседование.
В боте с частыми вопросами в медицинской области без переранжирования вопрос о взаимодействии с алкоголем может привести к показу другого лекарства, которое лишь совпадает по словарному составу. Переранжировщик с использованием кросс-кодера обычно сразу устраняет эту проблему. Когда важна точность (в юридической, медицинской или финансовой сферах), переранжирование является обязательным, а не факультативным.
Гибридный поиск — потому что как лексический, так и векторный поиск сами по себе немного несовершенны
Векторный поиск улавливает смысл, но может пропустить точные токены — коды SKU, идентификаторы ошибок, собственные имена. Лексический поиск BM25 точно находит строго определенные строки, но не учитывает синонимы.
Гибридный поиск сочетает в себе метод BM25 и векторный поиск: точность ключевых слов плюс семантическая воспроизводимость. Когда нет уверенности, гибридный подход является хорошим стандартным решением — редко даёт худшие результаты, чаще — лучшие.
Слияние данных RAG — объединение нескольких мнений, как в групповом проекте (но на этот раз это действительно работает)
Несколько поисковых алгоритмов (плотный, на ключевые слова, специфичный для домена) генерируют несколько ранжированных списков. RAG Fusion объединяет их с помощью Reciprocal Rank Fusion (RRF).
Идея проста, даже если формула кажется сложной: документ, занимающий высокие позиции в нескольких независимых методах, скорее всего, является релевантным. RRF стимулирует согласованность между списками, а не просто чистые оценки, которые невозможно сравнивать между разными поисковыми алгоритмами.
RRF(d) = Σ 1 / (k + rank_i(d))
Здесь значение k обычно составляет 60 — это отраслевая традиция, а не выведенная константа.
Метаданные — метки, которые спасут вам жизнь позже
Метаданные — это данные о данных: название, автор, дата, источник, уровень доступа. Они кажутся бесполезными до появления правила доступа — «никогда не показывать внутренние документы HR внешним пользователям» — и тогда теги access_level: internal вдруг становятся важными.
Метаданные позволяют использовать фильтры, усиление ранжирования, контроль доступа и отладку («Почему документ 2019 года ответил на вопрос 2026 года?» → отсутствие фильтров по дате).
Память и кэширование — потому что никто не хочет дважды платить за одни и те же вычисления
Два понятия, которые часто путают:
- Память = долгосрочное хранение предпочтений, прошлых запросов и постоянных фактов.
- Кэширование = краткосрочное повторное использование дорогостоящих результатов (ответов модели, результатов поиска) при повторных запросах.
Память делает помощников последовательными в действиях. Кэширование делает их быстрыми и экономичными. Сочетание этих методов — например, кэширование предпочтений с временем жизни в десять минут — может привести к тому, что имя пользователя исчезнет посреди чата. Сохраняйте разделение этих концепций.
Часть 4: Когда не следует использовать RAG?
Метод усиления через поиск не является универсальным решением.
Избегайте использования RAG, когда:
- Вопрос относится к общим знаниям, с которыми модель уже справляется («столица Франции» не требует векторного поиска).
- Факты постоянно меняются (цены, прямые результаты матчей) — лучше использовать API.
- Задача имеет исключительно творческий характер (поэзия, мозговой штурм) — поиск редко помогает.
- Корпус достаточно мал, чтобы его можно было просто включить в запрос.
- Ультракороткие задержки не позволяют допускать дополнительных этапов поиска.
Иногда решением является правильная формулировка запроса или финтунинг, а не полноценный векторный подход. Выберите инструмент до того, как начнете его настраивать.
Часть 5: Лучшие практики, выученные на собственном опыте
- Делайте куски разумно, а не слишком маленькими. Слишком мелкие фрагменты теряют контекст; слишком большие — точность. Лучше использовать перекрытие фрагментов.
- Используйте один инструмент встраивания для файлов и запросов. Смешивание моделей приводит к измерениям в несовместимых единицах.
Команды, которые рассматривают процесс извлечения информации как второстепенный аспект, обычно снова сталкиваются с теми же проблемами: незаметные изменения структуры данных в загрузчиках, границы блоков, разделяющие отрицательные фразы, несоответствия между моделями ввода-вывода при офлайн-индексации и онлайн-запросах, а также панели управления, которые измеряют только «время ответа», игнорируя при этом качество результата. Эффективная практика RAG рассматривает каждый этап работы как отдельный продукт с ответственными лицами, тестами и планами возврата к предыдущему состоянию — особенно когда ассистент работает с клиентами или в рамках регулируемых процессов.
При оценке изменений предпочтительнее использовать парные эксперименты: один и тот же набор вопросов, одна и та же шкала оценки, сравнение показателей Recall@k и степени обоснованности ответов до и после внесения изменений в разбиение данных на блоки или алгоритмы их ранжирования. Небольшие улучшения в процессе извлечения информации часто эффективнее значительных изменений, связанных только с формулировкой запросов, поскольку генератор не может ссылаться на то, что никогда не попадало в окно контекста.
Мантра RAG
Правильная информация → правильный контекст → правильное задание → правильный ответ.
RAG — это технология, а не магия. Чистый источник данных, разумный процесс извлечения информации, честное дополнение данных и точно сформулированное задание превращают чрезмерно уверенного пользователя в хорошо подготовленного специалиста, который сначала ознакомляется с документом, — и тем самым прекращаются попытки создать вымышленную круглосуточную глобальную поддержку, которой на самом деле не существует.