RAG простыми словами: как научить ИИ отвечать по вашим документам и собрать это без программирования

Представьте обычный рабочий день. На диске лежат десятки PDF, инструкции в Word, таблица с тарифами, база вопросов клиентов, регламенты и пара файлов с названиями вроде правила_финал_новые_точно2.pdf.

Сотрудник спрашивает нейросеть:

ИИ отвечает быстро, связно, уверенно. И ошибается.

Причина скучная: нейросеть не читала внутренние правила компании. Она знает много общедоступной информации, но понятия не имеет, что написано в вашем правила_финал_новые_точно2.pdf. Можно каждый раз вручную прикладывать нужный файл. С пятью документами это ещё терпимо. С пятьюстами уже начинается файловый квест.

Для таких задач и придумали RAG. Расшифровывается как Retrieval-Augmented Generation. По-русски встречаются переводы вроде «генерация с дополненным поиском» или «генерация с дополненной выборкой», но они мало что объясняют.

Мне больше нравится версия попроще:

сначала найди нужную информацию, потом отвечай.

И да, базовый RAG сейчас вполне способен собрать человек, который не пишет на Python и не знает, чем PostgreSQL отличается от Kubernetes. До серьёзной корпоративной системы без технических специалистов уже не добраться, но первый рабочий вариант — вполне.

Что такое RAG

Обычная языковая модель работает примерно так:

RAG добавляет перед ответом поиск:

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

Вы спрашиваете:

В инструкции написано:

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

Это и есть базовый RAG.

Зачем он нужен, если нейросеть и так умеет работать с файлами

Здесь легко запутаться. Если есть один отчёт на 20 страниц, никакую отдельную RAG-систему строить не надо. Файл можно загрузить в подходящий ИИ-сервис и спросить:

Готово. Проблема начинается, когда документов становится много.

Допустим, у производителя оборудования накопились:

• 180 инструкций;
• 50 сервисных бюллетеней;
• каталог на несколько тысяч позиций;
• гарантийные правила;
• FAQ техподдержки;
• история обновлений;
• внутренние регламенты.

Клиент пишет:

Модели не нужны все документы компании. Ей нужен маленький кусок инструкции именно про X120 и E17. RAG этот кусок ищет.

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

RAG не обучает модель вашим документам

Фраза «обучить нейросеть на своих документах» звучит удобно, поэтому её часто используют. Технически она сбивает с толку. При обычном RAG документы не записываются навечно «в мозг» модели. Модель обращается к ним во время ответа.

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

Отсюда приятное следствие. Изменился прайс? Обновили файл. Появилась новая инструкция? Добавили её в базу. Старый регламент отменили? Убрали. Не приходится переучивать всю модель из-за того, что бухгалтерия поменяла два пункта в правилах командировок.

Как RAG работает внутри

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

1. документы или другие источники;
2. разбиение текста на фрагменты;
3. индекс;
4. поиск;
5. языковая модель;
6. готовый ответ.

Разберём по очереди.

1. Система получает ваши документы

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

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

2. Большие документы режутся на фрагменты

Технический термин — chunking, а сами фрагменты называют chunks, или чанками. Звучит куда страшнее, чем выглядит.

Есть инструкция на 200 страниц:

1. Установка
2. Первое включение
3. Подключение к Wi-Fi
4. Приготовление напитков
5. Ошибки E01–E20
6. Очистка
7. Гарантия

Человек спрашивает:

Отправлять модели все двести страниц расточительно. Система заранее режет документ на небольшие смысловые части. Например:

Фрагмент 1: установка
Фрагмент 2: первое включение
Фрагмент 3: Wi-Fi
Фрагмент 4: ошибки E01–E05
Фрагмент 5: ошибки E06–E15
Фрагмент 6: очистка
...

По запросу про E14 в модель уйдёт пятый фрагмент, а не весь мануал.

Почему нельзя нарезать текст совсем мелко

Можно случайно разломать мысль. В документе написано:

Если первое предложение окажется в одном чанке, а второе в другом, поиск иногда принесёт только:

Формально правда. Но кусок условия потерялся, а вместе с ним изменился смысл ответа.

Огромные чанки тоже мешают

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

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

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

3. Текст превращается в математическое представление смысла

Вот тут появляется слово эмбеддинг. Спокойно. Формул не будет.

Возьмём два вопроса:

и

Слов почти никаких общих. Человек всё равно видит связь.

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

«Как вернуть товар?»
→ [0.18, 0.72, -0.31, ...]

«Покупка мне не подошла»
→ [0.21, 0.69, -0.29, ...]

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

Точного совпадения фразы нет. Смысл совпал.

4. RAG ищет подходящие фрагменты

Пользователь задаёт вопрос:

Система ищет в базе наиболее близкие куски. Например:

Фрагмент A

Фрагмент B

Фрагмент C

Все три могут понадобиться для нормального ответа.

Векторный поиск — не единственный вариант

Точный поиск тоже никуда не делся. Если пользователь вводит:

системе выгодно заметить буквальное совпадение.

Поэтому RAG часто использует гибридный поиск: один механизм ловит совпадения слов, кодов и артикулов, второй смотрит на смысл. Такой подход особенно полезен в технических базах, где рядом живут разговорные запросы и обозначения вроде KM-X2-04.

5. Иногда результаты дополнительно пересортировывают

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

В более развитом RAG может работать reranker — дополнительный механизм, который ещё раз оценивает результаты и поднимает наверх самые полезные.

Для первого проекта знать внутренности reranking не требуется. Достаточно идеи:

6. LLM получает найденные факты и пишет ответ

Внутри запрос может выглядеть примерно так:

Вопрос пользователя:

После очистки кофемашина всё равно показывает E04.
Что делать?

Найденные материалы:

1. Ошибка E04 связана с подачей воды.
Проверьте кран, входной фильтр и давление.

2. Если E04 снова появляется после перезапуска,
обратитесь в авторизованный сервис.

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

Модель превращает инструкцию в более удобный ответ:

Вот здесь заканчивается поиск и начинается генерация. Отсюда название Retrieval-Augmented Generation: генерация получает помощь от найденных материалов.

Вся схема RAG целиком

Если убрать технические подробности, сначала база готовится:

А дальше начинается работа с вопросами:

В хорошей системе человек может проверить, откуда взялся факт. Это сильно меняет отношение к ответу.

«Так сказала нейросеть» — слабый аргумент. «Вот ответ, а вот конкретный пункт инструкции, на котором он основан» — уже рабочая история.

Можно ли собрать RAG без программирования

Да. Причём есть большая разница между «попробовать RAG» и «построить корпоративную систему на 50 тысяч документов».

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

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

В Yandex AI Studio есть File Search для AI-агентов. Он работает по RAG-принципу: агент ищет информацию среди загруженных материалов и использует её при генерации. В 2026 году File Search умеет работать в том числе с PDF, изображениями, таблицами, аудио и видео.

То есть самодельную векторную базу для первого знакомства можно спокойно оставить в покое. Лучше потратить вечер на настоящую задачу.

Практика: собираем RAG-помощника без кода

Допустим, компания продаёт кофемашины. Поддержка получает одни и те же вопросы:

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

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

Шаг 1. Выберите одну узкую задачу

Не начинайте с:

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

помощник службы поддержки по кофемашинам серии X.

Теперь понятно, какие документы ему нужны.

Шаг 2. Соберите документы

Допустим, получилось пять файлов:

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

Шаг 3. Уберите старые версии

Папка выглядит так:

Какой файл актуальный? Вы это, возможно, знаете. RAG — нет.

Если в одной версии гарантия 12 месяцев, а в другой 24, поиск способен найти любую. Поэтому лучше оставить что-то вроде:

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

Шаг 4. Проверьте структуру документов

Хороший документ:

# Гарантия

## Срок гарантии

## Какие случаи покрывает гарантия

## Какие случаи не покрывает гарантия

## Как обратиться в сервис

Хуже — 40 страниц непрерывного текста без заголовков. Ещё хуже — скан плохого качества, где половина текста живёт картинками.

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

Шаг 5. Загрузите документы в базу знаний

В выбранной платформе создаётся база знаний и добавляются файлы. Дальше сервис сам занимается технической кухней:

• извлекает текст;
• делит его на фрагменты;
• индексирует;
• готовит поиск.

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

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

Шаг 6. Дайте помощнику нормальную инструкцию

Например:

Ты — помощник службы поддержки CoffeeMaster.

Отвечай на вопросы о кофемашинах на основе базы знаний.

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

Если в базе нет ответа, скажи:
«В документации нет достаточной информации».

Если найденные документы противоречат друг другу,
сообщи об этом.

Для технических проблем давай действия по шагам.

По возможности указывай документ,
на основании которого дан ответ.

Здесь есть полезная деталь: помощнику явно разрешено не знать. Без этого модели иногда начинают заполнять пробелы наиболее правдоподобным ответом.

Получается гладко. Только неправильно.

Шаг 7. Проверьте сам поиск

Первый вопрос:

Нашёлся правильный кусок инструкции? Хорошо. Теперь:

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

И:

Формулировки становятся всё менее похожими на текст инструкции. Именно так обычно пишут реальные люди.

Смотрите не только на ответ

Это критично. Если платформа показывает найденный фрагмент, открывайте его.

Пользователь спросил про гарантию. RAG нашёл раздел о возврате. Модель поверх него написала роскошный, аккуратный, совершенно неправильный ответ.

Проблема здесь не в стиле ответа. Проблема случилась этажом ниже: поиск принёс не тот материал.

Я бы даже записал это как главное правило отладки RAG:

Сначала проверяйте, что система нашла. Потом смотрите, что из этого написала модель.

Шаг 8. Задайте вопросы, ответа на которые нет

Предположим, модели CoffeeMaster Z500 вообще не существует. Спрашиваем:

Нормальный результат:

Плохой:

Откуда взялись 24 месяца? Система нашла общие гарантийные условия и сама приклеила их к выдуманной модели. Вот такие тесты особенно полезны.

Шаг 9. Возьмите настоящие вопросы пользователей

Не сочиняйте только аккуратные запросы вроде:

Люди так почти не разговаривают. Из поддержки скорее прилетит:

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

Как оценить качество без сложных метрик

Для первого проекта хватит обычной таблицы. Возьмите 30–50 вопросов и отмечайте:

После 30 вопросов картина уже начинает проявляться. Допустим:

• 26 ответов хороших;
• 2 частично правильных;
• 2 неправильных.

Можно разбирать ошибки. А если неправильных 12, но все написаны прекрасным уверенным русским языком? Такого помощника рано выпускать к клиентам.

Где RAG приносит пользу в обычной работе

Сам по себе RAG никому не нужен. Никто не приходит утром в офис с мыслью:

Нужна решённая проблема. Вот с проблемами у RAG как раз всё неплохо.

Поддержка клиентов

Наверное, самый очевидный сценарий. В базе:

• инструкции;
• FAQ;
• описание ошибок;
• гарантийные условия;
• правила возврата;
• документация по продукту.

Клиент пишет:

RAG находит нужный раздел. Модель переводит технический текст на нормальный язык и выдаёт шаги.

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

Внутренняя база знаний

Классика офиса:

Ответы существуют. Просто живут в пяти папках, двух корпоративных системах и памяти Олега, который сегодня в отпуске.

В RAG-базу можно собрать HR-политики, инструкции, правила закупок, IT-регламенты и FAQ. Сотрудник задаёт вопрос обычным языком. Система ищет нужный раздел и отвечает.

Олег наконец отдыхает.

Продажи

Допустим, компания продаёт промышленное оборудование. Клиент пишет:

Менеджеру приходится сравнивать каталоги. RAG может отобрать подходящие страницы и подготовить выжимку:

Здесь уже критично показывать источник. Одна придуманная техническая характеристика способна превратить удобный AI-инструмент в очень дорогой генератор приключений.

Онбординг сотрудников

Новичку в первый день обычно выдают десяток ссылок и бодро говорят:

Он спрашивает. Много.

Где заказать пропуск? Как оформить отпуск? Когда приходит зарплата? Куда отправлять чек? Как получить доступ к аналитике?

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

Работа с технической документацией

Есть 700 страниц руководств. Инженер спрашивает:

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

Но версии придётся маркировать аккуратно. Иначе на вопрос про версию 6.2 внезапно приедет инструкция из 4.8.

Маркетинг и редактура

Тут сценариев много. В базу можно положить:

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

После этого редактор спрашивает:

Или:

Или:

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

Аналитика исследований

Допустим, накопилось 40 интервью с клиентами и несколько больших отчётов. Вопрос:

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

Если вопрос звучит как «сколько процентов клиентов думают X», нужны данные и расчёты, а не литературная ловкость LLM.

Руководители и проектные команды

За квартал проект оставляет после себя целый цифровой чердак:

• протоколы;
• отчёты;
• исследования;
• решения;
• планы;
• презентации.

Через три месяца возникает вопрос:

Если решения нормально фиксировались, RAG способен найти обсуждения и вернуть контекст. Это уже интереснее бесконечного поиска по названиям файлов вроде meeting_notes_final3.

Юридические документы

RAG может помочь найти:

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

Где RAG ломается

У технологии есть слабое место, которое невозможно заклеить ещё одним модным AI-термином:

качество ответа зависит от качества найденной информации.

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

В базе нет нужного документа

Искать нечего. Если гарантийные условия не загрузили, RAG не сможет достать их из воздуха.

Хотя языковая модель иногда попытается. Отсюда и требование явно разрешать ей отвечать «не знаю».

Документ устарел

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

Получается очень эффективная доставка устаревшей информации. Поэтому база знаний требует хозяина. Кто-то должен добавлять новые версии и убирать старые.

Документы противоречат друг другу

В одном:

В другом:

Что считать правильным? Ответа у RAG нет. Лучше заставить систему показывать конфликт, а не самостоятельно выбирать более симпатичную цифру.

Плохо распознался PDF

Особенно весело со сканами, сложными таблицами, схемами и многоуровневой вёрсткой. Человек смотрит на страницу и всё понимает. Система извлекла текст примерно так:

Гарантия устройство срок
24 исключение месяцев аккумулятор

Дальше чудес ждать трудно. Некоторые современные платформы умеют OCR и обработку сложных форматов. Например, Managed RAG от Cloud.ru поддерживает отдельные экстракторы для PDF, Word, Excel, изображений и других типов файлов. Но результат всё равно стоит проверять.

Чанки получились неудачными

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

Вот тут RAG постепенно перестаёт быть историей «загрузил файл и забыл».

Поиск выбрал похожий, но неправильный текст

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

Поэтому набор тестовых вопросов нужен даже маленькому проекту.

Модель неправильно пересказала правильный фрагмент

Да, бывает и так. Retrieval сработал. Источник отличный. А LLM неверно поняла условие или добавила лишний вывод.

RAG снижает риск галлюцинаций, но не отменяет его.

Как подготовить документы, чтобы RAG отвечал лучше

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

Оставьте только актуальные версии

Вместо:

лучше:

Дата в названии иногда полезнее десяти настроек retrieval.

Делайте понятные заголовки

# Возврат товара

## Срок возврата

## Исключения

## Повреждение при доставке

## Как оформить заявку

Такую структуру проще читать и человеку, и системе.

Не прячьте ключевые правила в картинках

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

Разделяйте разные темы

Один файл на 600 страниц может работать. Но иногда удобнее:

Так проще обновлять данные и разбираться в ошибках.

Ставьте даты внутри документов

Не только в имени файла. Например:

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

Назначьте человека, который отвечает за базу

Не обязательно отдельного администратора RAG. Просто кто-то должен понимать:

• какие документы актуальны;
• какие пора удалить;
• кто утверждает новую версию;
• откуда берутся данные.

Без этого база медленно превращается в музей. С хорошим поиском.

RAG не всегда нужен

После такого длинного текста возникает соблазн прикрутить RAG вообще ко всему. Не надо.

Есть один PDF на семь страниц? Загрузите его в подходящий ИИ-сервис и задайте вопрос.

Нужно один раз разобрать договор? Тоже незачем поднимать отдельную базу знаний.

RAG становится интересным, когда совпадают несколько условий:

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

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

пора хотя бы попробовать RAG.

Чем RAG отличается от обычного поиска

Обычный поиск отвечает:

RAG идёт дальше. Он находит фрагменты, передаёт их языковой модели, и та собирает ответ.

Например, поиск вернул бы:

Дальше открывай и читай. RAG может вернуть:

И рядом — ссылки на использованные документы. Это уже другой пользовательский опыт.

Какие русскоязычные сервисы подойдут

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

SaluteBot — для первого RAG-бота

SaluteBot подойдёт, если хочется собрать чат-бота по русскоязычным документам без написания собственного retrieval-механизма. В платформе можно сформировать базу знаний из PDF и использовать найденный контекст для ответа бота.

Хороший сценарий:

Yandex AI Studio — для AI-агента со своей базой

Yandex AI Studio стоит посмотреть, если нужен не только диалог по документам, но и дальнейшее развитие в сторону AI-агента. Встроенный File Search использует RAG и умеет добавлять загруженные данные в контекст агента. Среди поддерживаемых источников есть документы, таблицы, изображения, аудио и видео.

Например:

Just AI — для более сложных сценариев

В Just AI Agent Platform RAG-базы можно подключать к AI-агентам через Jay Knowledge Hub. Агент получает релевантные фрагменты или ответ из базы и использует их в своём сценарии. Это уже удобно для цепочек вроде:

Cloud.ru Managed RAG — когда проект вырос

Cloud.ru Managed RAG рассчитан уже на более технические и корпоративные сценарии. Там можно создавать версии базы знаний, переиндексировать документы, настраивать retrieval и обращаться к базе через API. Есть и песочница для запросов.

Для первого эксперимента это, пожалуй, тяжеловато. А вот когда RAG становится частью корпоративной системы — другое дело.

Что выбрать человеку без технического опыта

Я бы шёл примерно так.

Хочу понять принцип. Берём 5–10 документов и собираем небольшой бот в SaluteBot.

Хочу своего AI-помощника и возможность развивать сценарий дальше. Смотрим Yandex AI Studio.

Хочу соединять RAG с бизнес-логикой и другими действиями агента. Можно изучать Just AI Agent Platform. Где проходит граница между автоматизацией и настоящим агентом — в статье ИИ-агенты простыми словами.

Нужна инфраструктура для серьёзного корпоративного решения. Тогда уже имеет смысл смотреть на Managed RAG, API и подключать техническую команду.

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

А что с конфиденциальными документами

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

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

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

Для домашнего FAQ риск один. Для базы договоров на несколько миллиардов рублей — немного другой жанр.

Как сделать первый рабочий RAG за вечер

Без погружения в эмбеддинги. Без собственной базы данных. Без попытки автоматизировать всю компанию сразу.

1. Найдите раздражающую повторяющуюся задачу

Например:

Или:

2. Возьмите 5–10 актуальных документов

Не сто. Не тысячу. Пять хороших файлов.

3. Приведите их в порядок

Уберите старые версии. Проверьте заголовки. Посмотрите, читается ли текст.

4. Создайте базу знаний

Для первого опыта подойдёт SaluteBot или Yandex AI Studio.

5. Задайте правило «не знаешь — скажи»

Например:

Отвечай только на основании базы знаний.

Если точных данных нет, сообщи об этом.

Не придумывай факты.

Если источники расходятся, укажи на противоречие.

По возможности называй источник ответа.

6. Соберите 30 настоящих вопросов

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

Последние часто оказываются самыми интересными.

7. Разберите ошибки

Для каждой ошибки спросите:

Если нет — проблема в данных. Если был:

Если нет — проблема в поиске или подготовке документов. Если нашёл:

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

Когда понадобится разработчик

Для первых экспериментов — необязательно. Дальше всё зависит от аппетита.

Появились тысячи документов. Нужно автоматически забирать новые файлы из корпоративного хранилища. Разным сотрудникам положены разные документы. RAG должен работать внутри CRM. Нужен поиск сразу по базе данных, PDF и внутреннему порталу. Требуется мониторить качество, скорость и стоимость.

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

Появятся API, модели эмбеддингов, reranking, права доступа, логирование, мониторинг. Нормально.

Сайт-визитку тоже можно собрать самостоятельно, а банковскую систему почему-то всё-таки поручают разработчикам.

Самое полезное в RAG вообще не связано со словом «нейросеть»

После всей этой истории с эмбеддингами легко решить, будто главный герой здесь LLM. Я бы поспорил.

Часто RAG впервые заставляет компанию разобраться с собственными знаниями.

Какая инструкция актуальная? Почему существуют четыре версии прайса? Кто отвечает за FAQ? Где зафиксированы решения? Почему половина правил лежит в голове у одного сотрудника?

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

Вместо:

спросить:

Вместо:

спросить:

Вместо поиска по сорока отчётам:

Вот ради этого RAG и стоит попробовать. Не ради слова Retrieval-Augmented Generation в презентации.

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

Если через неделю люди перестали копаться в папках и начали получать нормальные ответы со ссылками на источники — отлично, эксперимент удался. Если ничего не изменилось, тоже полезно. Значит, космолёт пока не нужен. Хватит обычного поиска.