Языковая модель из коробки знает многое об окружающем мире и ничего — о вашей компании. Она не читала ваш прайс, регламент возвратов, договор с поставщиком и инструкцию для новых сотрудников. Поэтому первая попытка «подключить ИИ к бизнесу» часто заканчивается одинаково: модель отвечает гладко, уверенно и мимо. RAG — способ исправить это без дорогого дообучения: модель отвечает не из памяти, а по вашим документам, которые ей подкладывают в момент вопроса.
В этой статье — как RAG устроен на уровне, достаточном для принятия решений, какие документы для него подходят, где он ломается и как понять, что система отвечает правильно.
Как работает RAG, если объяснять без формул
RAG расшифровывается как retrieval-augmented generation — генерация с подстановкой найденного. Схема в четыре шага.
- Подготовка. Документы компании разбивают на фрагменты по несколько абзацев. Каждый фрагмент переводится в числовое представление смысла — вектор — и складывается в специальное хранилище: Qdrant, Pinecone или аналог.
- Вопрос. Сотрудник или клиент задаёт вопрос. Он тоже переводится в вектор.
- Поиск. Система находит фрагменты, ближайшие по смыслу к вопросу. Не по совпадению слов — по смыслу: вопрос «можно ли вернуть товар через месяц» найдёт пункт «срок возврата составляет 14 дней», даже если слово «месяц» в нём не встречается.
- Ответ. Найденные фрагменты вместе с вопросом передаются модели (GPT-5, Claude, Gemini или открытой Llama, Qwen) с инструкцией отвечать только на их основе и указывать источник.
Главное свойство этого подхода: знания живут в документах, а не внутри модели. Обновили документ — обновился ответ. Не нужно ничего переобучать.
Чем RAG отличается от «просто вставить всё в промпт»
Для маленьких объёмов — одна инструкция на пять страниц — RAG не нужен: весь текст можно передать модели целиком. Современные модели принимают сотни страниц за раз. Но у этого подхода три предела.
- Стоимость. Каждый запрос оплачивается по объёму переданного текста. Передавать 300 страниц на каждый вопрос «какой у нас график работы» — дорого.
- Точность. Чем больше нерелевантного текста в контексте, тем выше шанс, что модель зацепится за неправильный фрагмент.
- Разграничение доступа. Если одни документы можно показывать клиентам, а другие — только сотрудникам, нужен поиск с фильтрами. Это как раз RAG.
Ориентир: до нескольких десятков страниц можно обходиться без RAG. От сотни страниц и выше, особенно при регулярных обновлениях, он нужен.
Какие документы подходят, а какие надо сначала привести в порядок
Качество ответов определяется качеством корпуса документов сильнее, чем выбором модели. Хорошо работают:
- регламенты, инструкции, политики с чёткой структурой и заголовками;
- описания услуг и тарифов, условия договоров;
- внутренние FAQ и разобранные кейсы поддержки;
- протоколы встреч и решения, если они записаны в единообразном виде.
Плохо работают без предварительной обработки:
- сканы без распознанного текста — их сначала нужно прогнать через OCR;
- таблицы со сложной структурой в PDF — при нарезке теряется связь между ячейками;
- несколько версий одного документа, когда непонятно, какая актуальна;
- переписка в чатах, где решение размазано по десяткам сообщений.
Типичная ситуация в компании из 15–40 человек: регламенты лежат в Google Docs, часть — в Notion, прайс в Excel, а самые важные договорённости — в головах. Перед запуском RAG нужен один-два дня на инвентаризацию: что актуально, что удалить, кто владелец каждого документа. Этот этап нельзя пропускать, иначе система будет отвечать по устаревшей версии прайса 2024 года, которую кто-то забыл убрать.
Где RAG ломается на практике
Разберём типичные сбои и что с ними делать.
Нарезка документов режет смысл
Если фрагмент начинается с «в этом случае сумма возвращается в полном объёме», а условие осталось в предыдущем фрагменте, система выдаст ответ без условия. Лечится нарезкой по смысловым границам — заголовкам, пунктам — и небольшим перекрытием соседних фрагментов.
Нашлось не то
Вопрос про «оплату» находит фрагменты и про оплату клиентами, и про оплату поставщикам. Помогает гибридный поиск: смысловой плюс по ключевым словам, а также метаданные — тип документа, отдел, дата. Часто имеет смысл отдельный шаг переранжирования найденных фрагментов.
Модель отвечает уверенно, когда ничего не нашлось
Самая опасная ситуация. Если релевантных фрагментов нет, модель склонна достроить ответ из общих знаний. Защита — жёсткая инструкция «если в предоставленных фрагментах нет ответа, скажи об этом» плюс проверка порога похожести: ниже порога система не отвечает, а передаёт вопрос человеку. Подробнее — в статье о галлюцинациях ИИ.
Вопрос требует вычислений, а не поиска
«Сколько мы заработали в марте» — это не поиск по документам, а запрос к базе данных. RAG здесь не подходит, нужен агент с доступом к учётной системе или BI. Полезно на старте разделить вопросы на «ищем в текстах» и «считаем по данным».
Сценарии применения в малом и среднем бизнесе
Внутренний помощник для сотрудников. Ответы по регламентам, отпускам, оформлению документов. Самый безопасный первый проект: ошибки видят свои, а не клиенты. Подробнее — в статье про AI-агента для HR.
Поддержка клиентов. База знаний по условиям, тарифам, инструкциям. Здесь важнее всего разграничение: клиентская часть корпуса отделена от внутренней.
Юридическая или бухгалтерская фирма. Поиск по собственным шаблонам, прошлым заключениям, типовым позициям. Экономит часы на «мы же уже писали что-то похожее».
Производство и сервис. Инструкции по оборудованию, регламенты обслуживания, история ремонтов. Техник в поле задаёт вопрос голосом в Telegram и получает ответ с ссылкой на раздел инструкции.
Отдел продаж. Быстрые ответы по характеристикам продукции, условиям для разных категорий клиентов, аргументам против конкурентов — всё из внутренних материалов.
Как проверять, что система отвечает правильно
Перед запуском нужен тестовый набор: 50–100 реальных вопросов с известными правильными ответами. Их собирают из переписки, из вопросов новичков, из обращений клиентов. Затем прогоняют через систему и смотрят на три вещи: нашёлся ли нужный фрагмент, правильно ли сформулирован ответ, указан ли источник. После каждого изменения — нарезки, модели, инструкций — прогон повторяют. Без такого набора любая настройка превращается в гадание.
После запуска полезно собирать обратную связь прямо в интерфейсе: кнопки «помогло» и «не помогло» с возможностью написать правильный ответ. Эти случаи раз в неделю разбирают и либо правят документы, либо добавляют новые.
Данные, доступ и выбор модели
Два вопроса, которые стоит решить до начала работ. Первый — где хранятся документы и вектора: в облаке провайдера или на собственном сервере. Для большинства компаний облачный вариант приемлем, но для медицины, финансов и юристов часто требуется локальное размещение с открытой моделью. Разбор вариантов — в статье о безопасности данных при внедрении ИИ.
Второй — права доступа. Если бухгалтер и стажёр задают один и тот же вопрос, они должны получать разные ответы или разный объём информации. Это решается метаданными на фрагментах и фильтрацией поиска по роли пользователя. Заложить это на старте дешевле, чем переделывать потом.
С чего начать
- Выберите один домен знаний — например, регламенты для сотрудников или условия для клиентов. Не всё сразу.
- Проведите инвентаризацию документов: актуальность, владелец, кому можно показывать.
- Соберите 50 реальных вопросов с правильными ответами — это ваш тестовый набор.
- Запустите первую версию в закрытом режиме для нескольких сотрудников на две недели.
- По результатам поправьте документы и нарезку, затем расширяйте аудиторию.
Мы в AiKrok обычно собираем первую рабочую версию RAG-помощника за две недели, и больше половины этого времени уходит не на код, а на работу с документами клиента. Это нормально: именно там создаётся качество ответов.