“Гугл для ChatGPT”: как RAG учит ИИ вашим знаниям и проверяет его на прочность

За последние годы крупные языковые модели вроде GPT-4 многому нас научили – в том числе и тому, что у них отличная память... на выдумки. Термин «галлюцинации» плотно вошёл в обиход: ИИ-собеседник может уверенно сообщать факты, которых нет в природе. Особенно это заметно, когда модель пытается ответить на узкоспециализированный вопрос без соответствующих знаний. Решение появилось из довольно элегантной идеи: что если дать модели доступ к внешней базе знаний, чтобы она черпала реальные данные оттуда?

Так родился подход Retrieval-Augmented Generation, или просто RAG (источник habr.com) (источник astera.com). Его уже успели прозвать «новым искусственным интеллектом с памятью», на него возлагают надежды – от корпоративных ботов, которые знают всё о продуктах компании, до HR-ассистентов, автоматически отбирающих подходящие резюме. Но оправдана ли эта шумиха? Давайте разбираться, что такое RAG, как построить свою базу знаний для ИИ и как понять, насколько хорошо он справляется с задачей.

ИИ с подсказкой из базы знаний: что такое RAG

Саму идею RAG можно образно описать как гибрид Google и ChatGPT в одном флаконе. Когда поступает запрос пользователя, система сперва ищет нужную информацию во внешней базе (как поисковик), а затем генерирует финальный ответ на основе найденных данных (как языковая модель) (источник chatme.ai). По сути, RAG — это надстройка над уже обученной LLM (Large Language Model), позволяющая ей опираться на актуальные знания из подключённого хранилища данных. В отличие от классического чат-бота, отвечающего только тем, что “помнит” модель, RAG каждый раз подмешивает в контекст ответа свежие факты из базы знаний.

Принцип работы Retrieval-Augmented Generation: модель дополняется модулем поиска по базе знаний перед генерацией ответа. На входе – вопрос пользователя, на выходе – сгенерированный ответ с учётом извлечённых данных.

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

Кроме того, не надо дообучать саму модель под каждый новый корпус знаний – достаточно пополнить базу данными, и RAG начнёт их учитывать. Например, OpenAI при создании корпоративного чатбота может не трогать веса GPT-4 вовсе, а настроить RAG-пайплайн: подключить вашу базу документов, чтобы бот искал ответы там. Это быстрее и дешевле, чем fine-tuning, а главное – безопаснее, ведь исходные документы остаются контролируемым источником.

Важно понимать, что RAG – это не какое-то новое чудо-развитие “самосознания” ИИ, а технический трюк, расширяющий память модели. Он не делает модель умнее, он делает её осведомлённее в конкретной области. Зато в практических приложениях эффект разительный. Взять хотя бы поддержку пользователей: бот с RAG может отвечать на вопросы по продукту, опираясь на свежую документацию, тогда как обычная LLM начнёт импровизировать, если чего-то не знает. Есть и более экзотичные применения.

К примеру, HR-специалисты уже пробуют доверить RAG первичный подбор кандидатов. В недавнем эксперименте автор на Хабре загрузил сотни резюме Java-разработчиков в базу знаний и подключил её к LLM для ранжирования кандидатов (источник habr.com). Модель получила описание вакансии и на его основе оценила всех кандидатов, выставив каждому «оценку соответствия» и объяснив своё решение. Топ-результаты выглядели так: первые два кандидата получили ~9.5 из 10 (наличие почти всех требуемых навыков), а другие заметно отстали – 2/10 или даже 1.8/10, потому что у них не хватало ключевых технологий. Конечно, финальное решение остаётся за человеком, но сколько часов рутинного скрининга экономит такая система!

Как построить свою базу знаний для RAG

Секрет эффективности RAG – в качестве базы знаний. База знаний (БЗ) в этом контексте – вовсе не традиционная SQL-база или онтологический граф, а скорее коллекция текстовых фрагментов, покрывающих нужный вам набор фактов. Это может быть документация, архив писем, FAQ с форума – всё, что поможет отвечать на вопросы пользователей. Главное, чтобы информация была релевантна и актуальна, иначе модель уйдёт в галлюцинации или будет выдавать устаревшие советы. Как образно заметила команда Chatme.ai, без хорошей базы знаний RAG-приложение – это просто «ещё один текстовый генератор – ограниченный, обобщённый и ненадёжный».

Шаг 1. Сбор контента. Начинают с инвентаризации: какие вопросы будет покрывать система и какой контент для этого нужен. Например, для внутреннего помощника в IT-компании очевидны источники: техдокументация, внутренние wiki-страницы, база тикетов службы поддержки. А для HR-ассистента, как в примере выше, — это набор резюме кандидатов и описания вакансий.

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

Шаг 2. Нарезка на фрагменты. Большие тексты разбиваются на небольшие куски – обычно пара абзацев или около того, чтобы каждый фрагмент помещался в контекст LLM. Это называется chunking (фрагментация) и делается по двум причинам. Во-первых, модель ограничена размером входящего окна (например, 4k или 8k токенов), так что длинное руководство целиком она бы не “прочла”. Во-вторых, мелкие тематические куски легче точно соотнести с запросом.

Представьте, что вы ищете в книжке ответ на конкретный вопрос: куда проще найти нужную главу, если у вас есть оглавление по темам. Правильно нарезанные фрагменты работают так же. Идеальный chunk самодостаточен по смыслу (например, описывает один метод API или одно правило из инструкции), чтобы затем модель могла понять, полезен он или нет. Размер кусков – тонкая грань: слишком большие фрагменты замедлят поиск и могут содержать лишний «вода текст», а слишком маленькие – распилят смысл и потеряют контекст. В практике RAG используют разные техники нарезки: кто-то режет по фиксированной длине в символах, другие – по смысловым разделителям (заголовкам, параграфам) или комбинируют подходы. Современные библиотеки типа LangChain уже имеют готовые инструменты для chunking’а – осталось только задать нужный параметр размера окна.

Шаг 3. Индексация: превращаем тексты в векторы. Каждый фрагмент отправляется в нейросетевой энкодер, чтобы получить его векторное представление (embedding). Идея в том, что похожие по смыслу тексты будут превращаться в близкие векторы в многомерном пространстве. Например, фразы «перезагрузить систему» и «restart the machine» выглядят по-разному, но после такой семантической векторизации окажутся рядом.

Векторизация – фундамент RAG, ведь именно так потом происходит поиск по смыслу: запрос пользователя тоже преобразуется в вектор и сравнивается со всеми хранящимися векторами фрагментов. Чтобы это работало быстро, применяется особое хранилище – векторная база данных. Она оптимизирована для поиска ближайших векторов (анализ окрестностей в пространстве) и способна выдавать топ-несколько подходящих кусочков за миллисекунды, даже если в базе сотни миллионов записей. Примеры популярных движков: Pinecone, Weaviate, Milvus, ChromaDB. По сути, векторная БД – это и есть ваша машина знаний: туда загружены все фрагменты и их векторы, и к ней обращается RAG-ретривер при каждом запросе.

Шаг 4. Ретривер: поиск кандидатов. Модуль извлечения (retriever) получает на вход вектор запроса и должен вернуть N наиболее релевантных фрагментов из базы (условно, “топ-5 ответов из поисковика”). Эти кусочки можно назвать кандидатами на ответ – именно из них потом модель сгенерирует финальный вывод. Ретривер обычно работает по принципу ближайшего соседа: находит самые близкие векторы к запросу. Но одного этого мало. Представьте, пользователь спросил: «Какое имя было у сына человека, победившего узурпатора Аллектуса?» – классическая задачка на несколько переходов (источник habr.com).

Простой RAG на векторном поиске растеряется: по отдельным ключевым словам он может вытащить текст про Аллектуса и текст про какого-то сына императора, но не поймёт связи между ними. Поэтому в продвинутых системах используются методы улучшения поиска: например, каскадный поиск с переформулировкой запроса, или комбинация векторного поиска со структурированной базой знаний. Так, исследователи из Microsoft недавно предложили подход GraphRAG: сначала с помощью LLM построить граф знаний по корпусу, а затем искать ответ не только по схожим текстам, но и по связям между сущностями. Это помогает в сложных вопросах, где факты разбросаны по разным документам. Но даже без графов ваш ретривер может стать умнее – например, ранжировать результаты по дате или источнику. Векторные базы позволяют накладывать фильтры по метаданным (источник, автор, раздел и т.д.), так что на запрос «последние правила безопасности» будут выбраны свежие документы, а не инструкции пятилетней давности.

Шаг 5. Генерация ответа. Последний этап: выбранные фрагменты-конкурсанты вместе с оригинальным вопросом склеиваются в один контекст, который подаётся в языковую модель. Модель читает всё это (вопрос + несколько извлечённых абзацев) и на этой основе генерирует ответ.

Зачастую ответ стараются делать максимально само-достаточным – чтобы пользователь мог не лезть в первоисточники. Поэтому LLM может перефразировать найденные факты, скомбинировать несколько частей, добавить связующих слов. Хорошая практика – выдавать в ответе ещё и ссылки на источники (как сделано и в этой статье), чтобы пользователь при желании проверил факты. К слову, так работает известный проект Bing Chat от Microsoft: это тоже RAG под капотом, где GPT-4 черпает информацию из веб-поиска и приписывает сноски на сайты.

Конечно, важно, чтобы модель не вышла за рамки контекста. Иначе мы снова получим выдумки, только теперь ещё и с псевдо-ссылками. Поэтому иногда на шаге генерации внедряют проверку “приверженности источникам” – например, запрещают модели использовать информацию не из списка данных, или отдельно проверяют факты ответа на присутствие в тексте документов.

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

Метрики качества: как оценить RAG и не потерять хватку

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

Во-первых, оценивают качество поиска (retrieval). Насколько релевантные куски выбрал ретривер? Не упустил ли он что-то важное для ответа? Есть метрика контекстная полнота – она же recall, охватывает ли набор извлечённых фрагментов всю информацию, которая нужна для правильного ответа (источник llmarena.team).

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

Во-вторых, измеряют качество ответа (generation). Здесь на первом месте стоит фактическая корректность ответа, которую ещё называют верность (faithfulness) – то есть отсутствие галлюцинаций относительно предоставленного контекста. Проще говоря, ответ модели должен быть логически выведен из тех документов, которые она получила, а не противоречить им или содержать новые “факты”. Если ретривер сработал хорошо, но модель всё равно наврала, значит проблема именно в генераторе – возможно, стиль подсказки не направил её брать цифры из текста, или она решила домыслить связки.

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

Дополнительные критерии оценки ответа – релевантность (насколько по существу модель ответила на вопрос пользователя) и полнота ответа. Иногда их объединяют под термином «приемлемость» ответа: годится ли результат для конечного использования. В промышленном сценарии обычно определяют порог, например: не менее 90% ответов системы должны быть признаны экспертами приемлемыми.

И далее запускают серию тестовых вопросов, проверяют ответы и выдают процент успеха. Такой интегральный показатель полезен для бизнес-целей: скажем, если ваш бот по техподдержке с RAG правильно и полно отвечает в 9 случаях из 10, можно смело пускать его в продакшн. Но если этот процент ниже, надо разбираться, где узкое место – поиск или генерация.

Есть хороший подход, предложенный в OpenAI: разбить все неудачные кейсы на четыре категории. 1) Ретривер не нашёл правильную информацию, поэтому и ответ вышел неверным. 2) Ретривер не нашёл, но модель как-то выкрутилась и частично ответила (значит, надо улучшать покрытие базы и стратегию поиска – возможно, плохо нарезали тексты). 3) Ретривер нашёл всё верно, но модель дала неверный ответ (тут поможет настройка промпта или выбор другой модели). 4) Идеальный сценарий: поиск сработал правильно и ответ корректен – тут ничего править не надо.

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

Помимо перечисленных, существуют и кастомные метрики под задачи. Например, галерея метрик Galileo AI предлагает дополнительно измерять «долю использования контекстов» – сколько из выданных фрагментов модель реально включила в ответ. Или «тональность ответа» – подходит ли эмоциональная окраска под задачу (для客服-бота важно быть вежливым).

Для HR-применения может быть критична метрика смещения/предвзятости: не стал ли бот необъективно оценивать кандидатов из-за скрытых данных. В финансах – соответствие строгому формату (скажем, чтобы ответ всегда был JSON нужной схемы). Универсальные метрики RAG хороши на старте, но практики отмечают: чем специфичнее область, тем больше вам пригодятся собственные показатели успеха.

RAG – не панацея, но мощный инструмент

Подводя итог: Retrieval-Augmented Generation действительно изменил правила игры для корпоративного ИИ. Он позволил связать модели вроде GPT с актуальными данными, не дожидаясь, пока эти данные попадут в следующую версию модели (или не платя за дорогое обучение на них). База знаний стала новым “оружием” в арсенале бизнеса: у кого она богаче и чище, у того умнее AI-ассистент. Но и задач прибавилось – собирать, очищать, индексировать данные, следить за качеством ответов.

Как и любая технология, RAG не решает проблему разом, а меняет природу проблемы. Вместо вопроса «как научить ИИ новым фактам» мы теперь отвечаем на вопрос «как поддерживать знания в базе актуальными и достаточными». Вместо отладки одной нейросети – отлаживаем две части (поиск и генерацию). Зато и контроль больше: можно точечно обновить или исправить знания, не залезая в чёрный ящик модели.

Для компаний, которые внедряют RAG-ботов, на первом месте должно быть качество данных. Если база противоречива или не покрывает важные вопросы – никакой RAG не спасёт. Зато при хорошей базе система способна выдавать впечатляющие результаты. Вспомним эксперимент с автоподбором кандидатов: фактически, модель там за доли секунд сделала то, на что у рекрутёров уходили бы дни – прогнала все резюме по списку требований и расставила приоритеты.

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

RAG сегодня активно развивается. Появляются новые гибридные подходы, как тот же GraphRAG от Microsoft, чтобы модель умела делать выводы из нескольких источников сразу. Создаются фреймворки для удобной сборки RAG-пайплайна (LangChain, LlamaIndex) и даже стандарты метрик (пакет RAGAS предлагает готовый набор показателей для оценки ретривера и генератора). Но внедряя все эти новинки, не забывайте: лучший друг RAG – человек со здравым смыслом.

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