RAG (ответ нейросети по вашим документам): что это такое простыми словами, как работает и зачем нужен

Представьте: вы загрузили в нейросеть договор и спросили, какой срок оплаты в нём указан. Ответ пришёл мгновенно, уверенный и грамотный. Только в договоре стоит другое число. Нейросеть не соврала намеренно: она не видела вашего договора и сочинила то, что звучит правдоподобно. Это и называют галлюцинацией (когда модель подаёт выдуманное как факт).

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

Для таких случаев придумали RAG (Retrieval-Augmented Generation, по-русски нередко «генерация, дополненная выборкой»; по смыслу — ответ нейросети, дополненный данными, которые система предварительно нашла в ваших документах). Перед ответом система находит в вашей базе знаний нужные фрагменты и показывает их нейросети, как шпаргалку. Нейросеть отвечает уже по найденному, а не по памяти.

Эта статья — подробный разбор для владельца бизнеса и руководителя, у которых нет технического образования. Мы ответим на вопросы, которые люди задают чаще всего. Что такое RAG и что значит это слово. Зачем он нужен и какие проблемы решает. Как он работает шаг за шагом и из чего состоит. Что такое эмбеддинги и векторная база данных. Почему качество зависит от нарезки документов. Чем RAG отличается от дообучения и от обычного поиска. Какие технологии используют, где RAG применяют и где он не подходит. Как подготовить данные, как защитить их и как проверить, что система отвечает верно. Факты взяты из документации и публикаций производителей, из научных статей и учебных материалов, мы читали их целиком. Где источник говорит только о себе, мы так и пишем.

RAG простыми словами: что это такое, расшифровка и определение

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

Определения у разных производителей звучат по-своему, но смысл один. Облачный сервис Amazon (AWS) называет RAG процессом, в котором перед ответом большая языковая модель обращается к надёжной базе знаний за пределами обучающих данных. Компания (IBM) описывает его как архитектуру, которая улучшает работу модели ИИ (искусственного интеллекта), подключая её к внешним базам знаний. Корпорация (Oracle) пишет, что RAG оптимизирует ответы модели целевой информацией, не меняя саму модель. Энциклопедия (Википедия) отмечает: сначала модель обращается к выбранному набору документов и только потом отвечает на вопрос.

Что значит RAG в контексте ИИ и ИТ

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

Простая аналогия: судья и помощник

Компания (NVIDIA) объясняет RAG через суд. Судья решает дела на основе общего понимания закона. Но когда нужна узкая экспертиза, например по врачебной ошибке или трудовому спору, он отправляет помощников в юридическую библиотеку за прецедентами. У ИИ роль такого помощника играет RAG. А облачный сервис (AWS) предлагает ещё один образ: языковая модель похожа на нового сотрудника с чрезмерным энтузиазмом, который не следит за новостями, но на каждый вопрос отвечает с полной уверенностью. RAG выдаёт этому сотруднику папку с нужными документами.

Откуда взялся RAG: статья 2020 года

Термин ввела научная статья 2020 года, которую написала группа исследователей во главе с Патриком Льюисом из исследовательской лаборатории (Facebook AI Research). Статья подана 22 мая 2020 года и принята на научную конференцию (NeurIPS) 2020 года. Авторы описали модели, где «параметрическая память» (знания, зашитые в самой модели) соединена с «непараметрической» (внешним индексом, в их случае это векторный индекс Википедии). Они назвали RAG универсальным рецептом дообучения, который подходит почти любой модели и любому внешнему ресурсу. Сам автор позже признавался, что над названием не думали: никто не предполагал, что работа станет такой известной.

Корни идеи уходят глубже. По рассказу NVIDIA, системы «вопрос-ответ» прототипировали исследователи информационного поиска ещё в начале 1970-х, а в середине 1990-х их популяризовал сервис (Ask Jeeves). В 2011 году система (Watson) обыграла двух чемпионов в телеигре (Jeopardy!).

Зачем нужен RAG: какие проблемы нейросетей он решает

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

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

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

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

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

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

Что такое галлюцинация и почему она опасна

Компания (IBM) определяет галлюцинации ИИ как ситуации, когда система выдаёт то, что звучит правдоподобно, но фактически неверно, нерелевантно или выдумано. Это может быть выдуманный факт, исследование или несуществующая ссылка. Причина в устройстве: модель обучена предсказывать следующее слово по образцам, а не знать, что истинно. Она оптимизирует правдоподобие, а не верность фактам о мире. Поэтому галлюцинации можно уменьшить, но нельзя полностью устранить.

IBM выделяет разные виды. Фактическая галлюцинация — когда ИИ утверждает неверное о мире. Контекстная — когда он должен отвечать по документу, но опирается на общие данные. Согласованности — когда модель противоречит сама себе в одной беседе. Здесь RAG и нужен: он заставляет брать ответы из доверенных источников, а не «свободно ассоциировать».

Что даёт RAG: восемь выгод

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

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

Как работает RAG: принцип работы шаг за шагом

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

Часть первая: подготовка базы знаний

Производители называют её по-разному: приём данных, индексация, загрузка. По существу это четыре действия.

Первое: собрать документы. Источниками могут быть файлы, страницы сайтов, базы данных, письма, внутренние вики, сервисы по программному интерфейсу (API — способ, которым одни программы обращаются к другим). Многое из этого неструктурированные данные, то есть обычный текст без разметки по полям. Нужен формат, понятный системе: чаще всего это текст, а документы преобразуют в него и очищают.

Второе: нарезать на куски. Документ разрезают на небольшие фрагменты, которые называют чанками. Зачем, мы объясним в отдельном разделе.

Третье: превратить куски в числа. Особая модель переводит каждый кусок в набор чисел — эмбеддинг, который передаёт смысл текста. Чем ближе по смыслу два текста, тем ближе их числа.

Четвёртое: сохранить. Числа и исходные тексты кладут в хранилище, которое быстро ищет похожее, — векторную базу данных.

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

Часть вторая: ответ на вопрос

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

Пример от AWS: вопрос об отпуске

Что видит нейросеть на самом деле

Нейросеть не «знает» вашу базу: она получает в запросе вопрос и выбранные фрагменты. Дополненный запрос выглядит как короткая инструкция. Образец из материалов компании (Pinecone): вот вопрос, вот контекст, ответь по контексту, а если ответа в контексте нет, скажи, что не знаешь. Такая формулировка побуждает модель использовать найденные факты и снижает вероятность выдумки.

Из чего состоит RAG-система: компоненты и технологии

Любая RAG-система собирается из одних и тех же частей. Компания (IBM) называет четыре основных. База знаний — внешнее хранилище данных системы. Поисковик (retriever) — модель, которая ищет в базе нужное. Слой интеграции — часть, которая координирует работу всего и собирает запрос. Генератор — языковая модель, пишущая ответ по вопросу и найденному. Дополнительно бывают ранжировщик, который упорядочивает найденное по важности, и обработчик вывода, который оформляет ответ.

Яндекс Облако описывает то же проще: RAG-система состоит из двух частей — поискового индекса (структуры, которая позволяет быстро искать) и языковой модели, которые работают по очереди. Поисковик находит данные, модель использует их для ответа. А библиотека (LlamaIndex) делит процесс на пять стадий: загрузка, индексация, хранение, запрос и оценка. Оценку часто забывают, и зря: она показывает, насколько ответы точные, верные и быстрые.

Из чего собирают на практике

Строить всё с нуля не нужно. Для связки частей используют открытые библиотеки: библиотека (LangChain) соединяет модели, эмбеддинги и базы знаний, а библиотека (LlamaIndex) создана специально под конвейеры RAG. Облачные платформы предлагают готовые сервисы: Amazon Bedrock Knowledge Bases (управляемая база знаний от облачного сервиса AWS) подключает модель к вашим данным за несколько щелчков, а в Яндекс Облаке, Сбере и Cloud.ru есть свои решения для российского рынка. Подробнее о выборе — в отдельном разделе.

Эмбеддинги и векторная база данных: простыми словами

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

Главное свойство такое: тексты близкого смысла получают близкие числа. Производитель (Red Hat) приводит пример: слова «кофе» и «чай» окажутся рядом, «горячий напиток» тоже будет близко, а «телевизор» — далеко. Компания (IBM) показывает то же на словах «кошка» и «собака». Эмбеддинги учатся из данных, а не задаются людьми вручную, и бывают для слов, текстов, изображений, звука и графов.

Как сравнивают числа

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

Векторная база данных: что это и чем отличается от обычной

Векторная база хранит эмбеддинги и умеет быстро искать самые похожие. Компания (IBM) описывает её как хранилище, которое хранит, индексирует и ищет многомерные векторы. Рядом с каждым эмбеддингом лежат метаданные: название документа, источник, время, категория. Эмбеддинги считают заранее, поэтому при запросе их не нужно пересчитывать, а результаты возвращаются за миллисекунды. Поиск по сходству можно сочетать с фильтрами, например брать только документы за нужный период.

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

Выбор у компаний есть: отдельные векторные базы, открытые решения, расширения существующих баз и поисковые системы с поддержкой векторов. Например, расширение (pgvector) добавляет векторный поиск в базу данных (PostgreSQL), и компания может обойтись знакомым инструментом.

Смысловой поиск и поиск по словам: в чём разница

Обычный поиск работает по точным совпадениям: запрос «смартфон» найдёт только страницы со словом «смартфон». Векторный поиск вернёт и «мобильное устройство». Это называют смысловым поиском. Он понимает намерение и контекст запроса, а не только слова. Материал Red Hat приводит пример: запрос «отпуск мечты» система поймёт как идеальный отпуск, а не как рассказ о снах.

Смысловой поиск находит документы даже тогда, когда точных слов запроса в тексте нет. Ещё один пример от Microsoft: человек спрашивает про «PTO» (сокращение для оплачиваемого отпуска), а в документах написано «отпуск», «удалённая работа» и «новички». Обычный поиск такие документы не свяжет. Смысловой поиск понимает, что это про одно и то же: по запросу «подбор персонала» он найдёт «найм», а ещё умеет сопоставлять содержимое на разных языках.

Нарезка документов (чанкинг): почему от неё зависит качество

Чанкинг — это разбиение большого текста на небольшие сегменты, чанки. Это один из самых важных шагов всей системы: от того, как вы режете документы, напрямую зависит качество ответов. Плохая нарезка подсовывает нейросети нерелевантный контекст и приводит к неверным ответам. Один из производителей (Weaviate) замечает: когда RAG работает плохо, проблема часто не в поиске, а в кусках. Идеальный поиск бессилен над плохо подготовленными данными.

Зачем резать вообще

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

Не слишком мелко и не слишком крупно

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

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

Какого размера бывают куски

Размер куска измеряют в токенах: так называют части текста, с которыми работает модель, — слово или его часть, в среднем три-четыре символа.

Единого правильного размера нет. Документация Яндекс Облака называет «на практике» от примерно 128 до примерно 1000 токенов; чем больше контекста допускает модель, тем крупнее может быть кусок. Для русского языка Яндекс использует около 700 токенов с перекрытием около 300 и тут же оговаривает, что параметры надо проверять на своих данных. Weaviate предлагает стартовую настройку 512 токенов и перекрытие 50–100, а OpenAI по умолчанию режет на 800 токенов с перекрытием 400. Расхождение показательно: у каждого свои значения, и верное нужно найти опытом.

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

Способы нарезки: от простых к сложным

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

Нужна ли нарезка вообще

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

Особый случай: PDF и таблицы

PDF — визуальный формат: колонки, таблицы и сканы мешают извлечению текста. Для сканов нужно распознавание текста. Надёжнее всего сначала перевести PDF в структурированный формат (Markdown — простой формат разметки с заголовками и списками) и резать уже его.

Как подобрать нарезку для своих данных

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

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

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

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

Гибридный поиск: смысл плюс точные слова

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

Решение — запускать оба поиска параллельно и объединять результаты. У двух методов взаимодополняющие сильные стороны, и вместе они дают точнее каждого по отдельности. Pinecone объясняет, зачем это нужно: люди не всегда говорят о теме одними словами (тогда выручает смысловой поиск), но часто используют внутренние сокращения, названия продуктов или команд (тогда нужен лексический).

Объединять результаты нужно умно: простое склеивание списков не работает, потому что у методов разные системы оценок. Для этого применяют метод взаимного слияния рангов (RRF). Он считает счёт по месту куска в каждом из списков: кусок, который высоко стоит в обоих, поднимается наверх.

Переранжирование: сначала много, потом лучшее

Даже гибридный поиск иногда ставит менее подходящий кусок первым. Поэтому добавляют ещё один шаг — переранжирование: найденное отдают модели-оценщику, и она упорядочивает куски по важности для вопроса. Компания (Pinecone) объясняет причину так. Эмбеддинги сжимают смысл текста в один вектор и теряют часть информации, поэтому нужное нередко оказывается ниже отсечки, и документ в выдачу не попадает. Просто взять больше документов нельзя: у нейросети есть предел окна контекста, а забивание контекста ухудшает её способность находить нужное и следовать инструкциям.

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

Цена такого шага — небольшая задержка: нужен баланс между точностью и скоростью.

Контекстный поиск: вернуть куску его адрес

При нарезке кусок теряет связь с документом. Возьмём пример из публикации компании (Anthropic). Кусок гласит: «выручка компании выросла на 3 % по сравнению с прошлым кварталом». Но какой компании и какого периода? Из куска это не видно, найти его по вопросу о росте выручки условной компании «Альфа» во втором квартале трудно, да и пользоваться им неудобно.

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

В экспериментах авторов публикации контекстные эмбеддинги снизили долю неудачных поисков на 35 % (с 5,7 до 3,7 %), добавление контекстного поиска по словам довело снижение до 49 %, а с переранжированием — до 67 % (с 5,7 до 1,9 %). Автор подчёркивает: все выгоды складываются. Кроме того, эмбеддинги вместе со словесным поиском работают лучше одних эмбеддингов, а передавать модели двадцать кусков эффективнее, чем десять или пять. Но и тут есть предел: больше кусков может отвлекать модель. Главный совет автора — всегда проводить оценки на своих данных.

RAG, дообучение, длинный контекст и обычный поиск: что выбрать

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

Главное отличие от дообучения

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

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

Может, достаточно положить всё в запрос

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

Когда RAG не подходит

Технологии RAG: на чём собирают систему

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

Облачные платформы с готовой базой знаний. Сервис (Amazon Bedrock Knowledge Bases) позволяет встроить собственную информацию в приложения ИИ: база знаний ищет в ваших данных нужное, а найденное улучшает ответ. Есть два вида: управляемая база, которую ведёт сам сервис, и база, которую вы настраиваете сами. Управляемая подключается к облачным хранилищам и сервисам документов вроде Google Диска и применяет права доступа на уровне документов при поиске. У Google есть сервис (RAG Engine), в котором шесть шагов: приём данных, преобразование, эмбеддинги, индексирование, поиск и генерация, а данные берут из локальных файлов, облачного хранилища и Диска. У Microsoft похожие возможности входят в сервис (Azure AI Search).

Для российских проектов. Яндекс Облако создаёт текстовые, векторные и гибридные индексы и подключает их к ассистенту. Сбер в конструкторе чат-ботов (SaluteBot) даёт блок ответа нейросети из базы знаний, который выдаёт ответ на основе загруженных документов; при личных ключах доступа для него обязательно подключать модель векторного представления текста, иначе база знаний работать не будет. А у Cloud.ru есть сервис (Managed RAG) для запуска RAG-систем на ваших данных, с руководствами по созданию базы знаний из файлов Markdown и подключению сервера по протоколу MCP (стандарту подключения внешних данных к ИИ). Доступность иностранных сервисов в России мы в этом материале не проверяли, поэтому для российского бизнеса сначала смотрите российские платформы.

Хранилища для эмбеддингов. Векторные базы и поисковые системы с поддержкой векторов описаны в разделе про эмбеддинги.

Свой интерфейс поиска. Компания (OpenAI) предлагает интерфейс для смыслового поиска по вашим данным: файлы добавляют в хранилище векторов, и оно само режет, превращает в эмбеддинги и индексирует их. Поддерживаются PDF, текстовые документы и презентации.

Какую технологию взять

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

Для каких задач подходит RAG: примеры применения

RAG нужен там, где ответ должен опираться на ваши документы и быть проверяемым. Производители называют одни и те же сценарии, и хорошо видно, что начинают почти всегда с чат-бота. Корпорация (Oracle) замечает: для многих организаций чат-бот — отправная точка RAG. Обычные боты обучены конечному числу намерений, а с RAG они отвечают и на вопросы вне списка.

Справочник для сотрудников

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

Поддержка и интернет-магазин

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

Отчёты и работа с документами

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

Отраслевые примеры

Если нужна помощь, RAG и база знаний — отдельная наша услуга: от подготовки документов до проверки ответов.

Какие данные нужны для RAG и как их подготовить

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

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

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

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

Как быть с персональными данными

Если в документах есть персональные данные, их обработку согласуйте с юристом заранее. Платформа (Databricks) отдельно называет этап подготовки, где такие сведения находят, фильтруют, удаляют или заменяют. А доступ к документам с чувствительными сведениями разграничивают на этапе поиска: об этом подробно в разделе про безопасность. Помочь с подготовкой данных могут очистка и сопоставление данных и извлечение данных из документов, а ещё документооборот для сбора файлов.

Безопасность и приватность RAG: что защищать

Система открывает модели доступ к данным компании, и защита здесь нужна особая. Это подтверждают все производители, и мы собрали основные пункты.

Данные у вас, а не у модели

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

Доступ проверяют в момент поиска

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

Векторную базу защищают как любую базу

Эмбеддинги не безобидны. По описанию IBM, если нешифрованную векторную базу взломают, злоумышленники могут восстановить исходные данные. Защита: шифрование хранилища, ограничение доступа и журнал запросов для мониторинга, безопасности и аудита.

Опасность скрытых команд в документах

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

Как проверить, что RAG отвечает верно: оценка качества

Фраза «нельзя улучшить то, что не измеряешь» из материалов сервиса (Hugging Face) подходит RAG лучше всего. Система собирается из нескольких частей, и ошибиться можно в каждой, поэтому проверка встроена в процесс. В схеме LlamaIndex оценка названа отдельной пятой стадией, а Microsoft требует структурированного процесса: оценивать каждый шаг отдельно, помня, что клиент видит итог.

Что измерять

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

Эталонный набор вопросов

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

Ссылки на источники как часть проверки

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

Ограничения и типичные ошибки RAG

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

Пять трудностей, которые называют чаще всего

Платформа (Databricks) перечисляет пять трудностей RAG в масштабе. Первая — качество поиска: если найдены нерелевантные документы, даже сильная модель отвечает плохо. Вторая — окно контекста: слишком много содержимого даёт обрезанные источники или размытые ответы. Третья — свежесть данных: индекс быстро стареет без регулярной загрузки. Четвёртая — задержка при больших данных. Пятая — оценка: нужны человек, оценки релевантности и проверки обоснованности. Ещё одна ловушка — завышенное ожидание: RAG пока лучше отвечает на вопросы, чем выполняет действия в реальном мире.

Агентный RAG и что будет дальше

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

Что это даёт, видно на примере Microsoft. Агентный поиск разбивает сложный вопрос на несколько подзапросов и выполняет их параллельно, а ещё учитывает историю беседы, поэтому уточняющие вопросы не теряют смысла. Pinecone добавляет: агент может уточнять запросы, пользоваться разными инструментами поиска и проверять найденное, а затем принимать или отбрасывать его.

Развитие видят и в других направлениях. Databricks пишет, что RAG из обходного приёма превращается в основу корпоративного ИИ и всё чаще сочетается с инструментами и агентами. MongoDB отмечает, что RAG пока лучше отвечает на вопросы, чем выполняет задачи, а память делает его интерактивнее: система помнит детали прошлых бесед. Яндекс Облако называет ещё одно направление: мультимодальный RAG, умеющий работать и с картинками, звуком, видео и таблицами, а не только с текстом.

Если вам нужен не только помощник, но и исполнитель, смотрите ИИ-агентов и ИИ-ассистента.

Как внедрить RAG в компании: этапы и с чего начать

Архитектура RAG проста, а вот проектирование и проверка требуют, по описанию Microsoft, строгого научного подхода. Поэтому внедрение делят на этапы, которые повторяют друг друга у разных производителей.

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

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

Что делать завтра: план на неделю

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

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