RAG или обычный поиск

RAG (retrieval-augmented generation, генерация с опорой на извлечённые данные) — это не продукт и не отдельная система, а способ соединить две уже существующие вещи: поиск по вашим документам и языковую модель. Сначала система находит фрагменты, потом модель формулирует по ним ответ.

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

Четыре уровня, из которых обычно выбирают

Между «поиск по ключевым словам» и «ИИ отвечает на вопрос» есть несколько ступеней, и они отличаются не качеством, а тем, какую задачу решают.

Переход на следующий уровень имеет смысл только тогда, когда предыдущий измеримо не справляется. Обратный порядок — сразу строить генерацию, не проверив поиск — обходится дорого: команда месяцами настраивает промпты там, где проблема была в нарезке документов.

Когда генерация ответа не нужна

Генерация добавляет к системе три вещи: стоимость каждого запроса, задержку и риск правдоподобной ошибки. Иногда всё это платится зря.

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

Из чего состоит конвейер и где он ломается

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

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

Как измерять качество: две метрики вместо одной

Оценка «нравится / не нравится» не показывает, что чинить. Мы разделяем измерение на два независимых уровня и меряем их отдельно.

1. Качество извлечения. Готовится набор из 30–50 реальных вопросов, к каждому заранее указан документ и фрагмент, который считается правильным источником. Метрика — доля вопросов, для которых верный фрагмент оказался среди первых k извлечённых; в литературе это Recall@k. Эта проверка не требует модели вообще.
2. Качество ответа. Считается на тех вопросах, где извлечение сработало, и отвечает на два разных вопроса: опирается ли ответ строго на переданные фрагменты (обоснованность) и верен ли он по существу (правильность).

Обе метрики условные: они меряют звено, а не систему. Поэтому рядом обязательно держится общая доля правильных ответов по всем вопросам набора — именно её чувствует пользователь, и именно она не даст улучшать одно звено за счёт другого.

Разделение даёт понятный вывод. Провал на первом уровне — это работа с документами, нарезкой и индексом. Провал только на втором — работа с инструкцией модели и форматом ответа. Без разделения обе проблемы выглядят одинаково: «ИИ отвечает неправильно».

Отдельно фиксируется доля вопросов, на которые система обязана отказаться отвечать: данных в базе нет. Готовность честно сказать «не нашёл» — такое же требование, как и правильный ответ, и его нужно проверять специально подготовленными вопросами.

Чего RAG не чинит

• Противоречия в документах. Если действуют два регламента с разными правилами, система покажет оба или выберет один — но не решит, какой верен. Это управленческая задача, и её нужно закрыть до внедрения.
• Отсутствие актуальных версий. Там, где нет признака «действует / отменён», ответы будут собираться и по отменённым документам.
• Права доступа. Поиск обязан учитывать, что можно видеть конкретному сотруднику. Права нельзя добавить после запуска: они влияют на устройство индекса.
• Знания, которых нет в документах. Если правило существует только в голове у опытного сотрудника, извлекать нечего. Сначала оно должно быть записано.

Что это значит для проекта

Порядок работ, который мы считаем правильным: сначала измерить, что находит обычный поиск по вашему набору вопросов, и только потом решать, нужна ли генерация. Часто оказывается, что первый же честный замер извлечения объясняет все жалобы на «глупый ИИ», и следующий шаг — работа с документами, а не выбор модели.

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

Куда идти дальше

• Корпоративный поиск и база знаний — внедрение: что нужно от компании, как устроен пилот и по каким метрикам он принимается.
• Повышение производительности сотрудников — направление, к которому относится задача поиска знаний.
• Разработка и внедрение ИИ-агентов — что меняется, когда системе мало найти ответ и нужно выполнить действие.
• Данные и безопасность AI-проекта — правовое основание, обезличивание и выбор провайдера модели.