RAG против обычного поиска: когда нужен каждый подход

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

Самое очевидное решение — поиск. Пользователь вводит запрос, система находит подходящие документы и показывает результаты. Такой механизм существует десятилетиями и во многих случаях прекрасно справляется со своей задачей.

С развитием генеративного ИИ появился другой подход — RAG. Теперь система может не просто найти несколько документов, а попробовать самостоятельно сформировать ответ на вопрос пользователя на основе корпоративной базы знаний.

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

Что мы называем обычным поиском

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

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

Механизм поиска при этом может быть достаточно сложным. Современные системы умеют учитывать морфологию, опечатки, синонимы, релевантность и другие параметры. Поиск давно не обязательно означает буквальное совпадение введённых слов с текстом документа.

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

Что меняется с появлением RAG

RAG расшифровывается как Retrieval-Augmented Generation — генерация с дополненным поиском.

Если сильно упростить механику, система сначала ищет релевантную информацию в подключённой базе знаний, а затем передаёт найденные фрагменты языковой модели. Модель использует их как контекст и формирует ответ пользователю.

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

Разница заключается в том, что пользователю необязательно самостоятельно открывать найденные документы и собирать из них ответ. Это делает модель.

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

RAG особенно полезен, когда пользователь не знает, что именно искать

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

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

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

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

Когда обычный поиск работает лучше

Однако далеко не каждый запрос требует генерации ответа.

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

Человеку, который вводит «Договор №1547», скорее всего, нужен сам договор, а не пересказ его содержания языковой моделью.

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

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

RAG полезен для вопросов, а поиск — для объектов

Это, конечно, упрощение, но оно хорошо помогает определить первоначальное направление.

Если пользователь ищет конкретный объект, обычный поиск зачастую подходит лучше:

• товар по названию или артикулу;
• документ по номеру;
• сотрудника;
• заказ;
• статью;
• инструкцию с известным названием;
• страницу сайта.

Если же пользователь пытается получить ответ на вопрос, RAG становится значительно интереснее.

Например: «Какие документы нужны для подключения нового контрагента?», «Можно ли вернуть этот товар после вскрытия упаковки?», «Какие ограничения действуют для этой категории клиентов?»

В таких случаях ценность заключается уже не в нахождении документа как такового, а в извлечении из него конкретного знания. Тут RAG существенно сэкономит время на изучение документов и составление резюме.

Особенно заметна разница при работе с несколькими источниками

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

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

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

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

Но качество RAG напрямую зависит от поиска

Генеративная модель не может корректно ответить, если система не нашла нужную информацию.

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

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

Хорошая генерация не исправит плохой retrieval.

Есть ещё проблема актуальности информации

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

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

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

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

Источники ответа лучше показывать пользователю

Одна из полезных возможностей RAG-системы — не только сформировать ответ, но и показать, на основании каких материалов он получен.

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

Для корпоративных решений это особенно важно. Чем серьёзнее последствия решения, которое человек принимает на основании ответа системы, тем важнее возможность проверить информацию.

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

Стоимость запросов тоже отличается

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

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

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

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

Не забываем о риске ошибок

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

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

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

Иногда лучший вариант — использовать оба подхода

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

Представим корпоративную базу знаний. Пользователь может ввести название документа и получить обычную поисковую выдачу. А может задать вопрос естественным языком — и получить сформированный RAG-ответ со ссылками на источники.

Другой вариант — система сама определяет тип запроса. Если человек ввёл номер договора, артикул или точное название, используется обычный поиск. Если запрос сформулирован как вопрос и требует анализа информации, подключается RAG.

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

Как выбрать подход для своего проекта

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

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

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

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

RAG — не замена поиску, а следующий слой работы с информацией

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

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

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