Задача выглядит одинаково почти в любой компании. Регламенты, инструкции, договоры и накопленная переписка лежат в трёх разных местах, поиск по ним работает по точному совпадению слов, и новый сотрудник вместо чтения документа идёт спрашивать коллегу. Коллега отвлекается.
RAG эту задачу закрывает. Но между «поставили систему» и «люди ей пользуются» лежит несколько решений, и принимать их нужно до старта, а не после.
Материал написан для руководителя. Если вам нужен технический разбор конкретного фреймворка с архитектурой и установкой, посмотрите отдельную статью про LightRAG. Здесь речь про то, зачем, сколько стоит и как проверить.
Что такое RAG за две минуты
Retrieval-Augmented Generation дословно значит «генерация, дополненная поиском». Работает в три шага:
- система находит в ваших документах фрагменты, относящиеся к вопросу;
- подкладывает их языковой модели как контекст;
- модель формулирует ответ на основании этих фрагментов и указывает источник.
Самое ценное свойство: знания не нужно встраивать в саму модель. Как формулируют в разборе Sber Pro, компания правит регламент, и после переиндексации система учитывает новую версию. Дообучение модели под ваши документы не требуется, и это принципиально удешевляет внедрение по сравнению с тем, как эти задачи решались раньше.
Проще всего думать о RAG как о сотруднике с доступом к вашей библиотеке. Обычная модель отвечает по памяти. Модель с RAG сначала идёт и смотрит.
Спрос на такие решения растёт: по оценке аналитической компании MarketsandMarkets, приведённой в том же материале, мировой рынок RAG в 2025 году составил 1,94 млрд долларов и к 2030 году может вырасти до 9,86 млрд.
Чего RAG не делает
Здесь придётся разойтись с большинством материалов по теме, где RAG подают как средство от галлюцинаций.
RAG привязывает ответ к вашим данным, но не гарантирует его истинность. Ошибиться могут три звена независимо друг от друга:
- источник. Регламент устарел, но лежит в индексе, и система честно цитирует неверную версию;
- поиск. Нашлись не те фрагменты, и модель отвечает уверенно на основании нерелевантного куска;
- модель. Фрагменты найдены правильно, но смысл прочитан неверно или два документа склеены в один вывод.
Именно поэтому ссылка на источник в ответе служит рабочим инструментом, а не украшением интерфейса. Она существует, чтобы человек мог за секунды проверить, откуда взялся ответ. Система без ссылок непроверяема, и доверия к ней быть не должно.
Ловушка объёма
Самая контринтуитивная вещь во всей теме, и о ней почти никто не пишет.
Естественный первый порыв: загрузить в систему всё. Всю вики, весь диск, весь архив почты. Логика понятна: больше данных, больше шансов найти ответ.
На практике происходит обратное. Автор практического разбора на Хабре описывает свой опыт прямо: с одним разделом вики система отвечала хорошо. После добавления вики целиком качество упало, причём и по тому разделу, который до этого работал.
Механика простая. Поиск отбирает фрагменты по смысловой близости. Чем больше в базе похожих, дублирующихся и устаревших документов, тем выше шанс, что в контекст попадут не те. Модель получает мешанину и отвечает соответственно.
Рабочий принцип формулируется так: минимально необходимый и внутренне непротиворечивый набор данных. Не самый большой, а самый согласованный.
Начинайте со списка вопросов
Отсюда следует практический порядок действий, обратный интуитивному.
Не «у нас есть данные, давайте всё загрузим», а «вот тридцать вопросов, которые сотрудники задают чаще всего, и вот документы, которые нужны, чтобы на них ответить».
Соберите реальные вопросы: из переписки в общих чатах, из обращений к руководителям отделов, из того, что спрашивают новички в первый месяц. Тридцать штук достаточно для старта. Дальше:
- каждый вопрос указывает на конкретный документ или раздел;
- набор документов получается заметно меньше, чем «всё хранилище»;
- этот же список превращается в тестовый набор для проверки качества;
- расширять базу дальше вы будете осознанно, по мере появления новых вопросов.
Побочная польза: часть вопросов окажется без ответа не потому, что поиск плохой, а потому что документа не существует. Это отдельная находка, которую стоит зафиксировать.
Какие документы подходят, а какие нет
Не всё содержимое хранилища одинаково пригодно для такой системы. Разница определяется тем, как документ устроен, а не тем, насколько он важен.
Работают хорошо: регламенты и инструкции с ясной структурой, ответы на типовые вопросы, описания продуктов и услуг, протоколы решений, справочные материалы. Общее у них одно: текст самодостаточен, и фрагмент сохраняет смысл в отрыве от остального документа.
Требуют подготовки: сканы без текстового слоя, таблицы со сложной вёрсткой, презентации, где смысл держится на схемах, документы с многоуровневыми перекрёстными ссылками. Их можно использовать, но сначала нужно распознавание и приведение к текстовому виду, и это отдельная работа с отдельным сроком.
Не подходят: файлы, где содержание держится на изображении или чертеже, и данные, которые правильнее доставать запросом к базе.
Отдельно про нарезку. Документы попадают в индекс не целиком, а фрагментами, и от способа нарезки качество зависит сильнее, чем от выбора модели. Разрезанная посередине таблица или оторванный от заголовка абзац дают фрагмент, который формально найдётся, но ответить по нему нельзя. Если система «почти работает», причина чаще всего здесь, а не в модели.
Права доступа
Пункт, который в материалах по RAG упоминают вскользь, а он определяет, можно ли вообще запускать систему.
Ошибка выглядит так: систему подключают к файловому хранилищу под общей учётной записью с полным доступом. Дальше любой сотрудник через чат получает то, что не открыл бы в интерфейсе хранилища: документы соседнего отдела, зарплатные данные, черновики договоров.
Правильное устройство: права проверяются на этапе поиска, а не на этапе показа ответа. Разница принципиальна. Во втором случае закрытый документ уже попал в контекст модели и мог просочиться в формулировку, даже если ссылку на него скрыли.
Что должно работать:
- система обращается к источникам от имени конкретного пользователя;
- смена роли или увольнение автоматически меняют доступ и в AI-инструменте;
- в журнале видно, кто какие документы получил через систему.
Тема шире одного раздела, подробно разбираю её в материале про безопасность LLM в компании.
Как это выглядит на практике
Gemini Light RAG 2.0. Наш проект командной базы знаний с AI-чатом для команд от двух до десяти человек. Индексация документов, ответы с отслеживанием источников, ролевой доступ на трёх уровнях. Задача, которую он закрывает: 2-4 часа в день, которые команда из пяти человек тратила на поиск по инструкциям и регламентам.
Ролевая модель заложена в него с самого начала, а не добавлена позже. Это тот случай, когда дописать потом дороже, чем спроектировать сразу: разграничение доступа затрагивает и хранение, и поиск, и журналирование.
Это собственный проект, а не клиентский кейс. Другие работы собраны в разделе кейсов.
Актуальность индекса
База знаний живёт: документы правятся, добавляются, устаревают. Система об этом не узнает сама.
Три вопроса, на которые нужен письменный ответ до запуска:
- Как правка документа попадает в индекс? Вручную по расписанию, автоматически по событию или никак. Третий вариант встречается чаще, чем хотелось бы.
- Что происходит со старой версией? Если она остаётся в индексе, система будет цитировать обе и противоречить сама себе.
- Кто отвечает за актуальность? У базы знаний должен быть владелец. Без него через полгода она превращается в архив.
Признак того, что процесс не выстроен: сотрудники начинают перепроверять ответы системы в первоисточнике. Как только это происходит, экономии больше нет.
Проверка качества до запуска
Тот самый тестовый набор, который получился из списка вопросов. Тридцать реальных вопросов с эталонными ответами и указанием, из какого документа ответ должен браться.
Что проверяем:
- нашёлся ли нужный документ. Если поиск не отдал правильный фрагмент, дальше смотреть нечего, проблема в индексе, а не в модели;
- соответствует ли ответ источнику. Модель не должна добавлять от себя;
- указан ли источник и правильный ли он;
- что происходит, когда ответа нет. Система обязана сказать «не нашёл», а не сочинить правдоподобное.
Последний пункт проверяйте отдельно и намеренно: задайте вопросы, ответов на которые в базе заведомо нет. Поведение системы в этой ситуации важнее, чем её точность на удобных вопросах.
Порог приёмки назначайте до тестирования, а не после. Иначе результат всегда окажется приемлемым.
Во что обходится эксплуатация
Разовым внедрением бюджет не заканчивается. Постоянные расходы складываются из четырёх статей:
- вызовы модели. Каждый ответ означает обращение к модели с довольно большим контекстом, потому что вместе с вопросом уходят найденные фрагменты;
- эмбеддинги и переиндексация. Каждое обновление документов оплачивается заново;
- хранение. Векторное представление документов занимает место и требует базы;
- поддержка. Кто-то следит за качеством ответов, добавляет документы, разбирает жалобы.
Порядок величин и методику расчёта разбираю в отдельном материале про стоимость внедрения LLM. Здесь важно одно: обращение к RAG-системе дороже обычного запроса к модели, потому что контекст больше.
Когда RAG не нужен
Три случая, когда стоит выбрать другое решение.
Документов мало и они стабильны. Если у вас двадцать страниц регламентов, которые меняются раз в год, дешевле положить их прямо в инструкцию модели. Поисковая часть здесь лишняя.
Нужен не ответ, а действие. Если задача не в том, чтобы рассказать сотруднику про порядок оформления заявки, а в том, чтобы её оформить, RAG сам по себе не поможет. Нужен процесс с доступом к системам, и это разговор про агентов и конвейеры.
Ответ должен быть точным вычислением. Остатки на складе, суммы по счетам, статусы заказов лежат в базах данных и достаются запросом. Пропустить это через языковую модель значит получить правдоподобное число вместо правильного.
Частые вопросы
Нужно ли дообучать модель под наши документы?
В большинстве случаев нет, и это главная экономия от такого подхода. Дообучение оправдано, когда требуется освоить специфический стиль или узкую терминологию, но знание фактов из ваших документов оно решает хуже: при каждом обновлении регламента переобучать модель заново непрактично.
Сколько документов нужно для старта?
Результат зависит не от количества, а от покрытия реальных вопросов. Тридцать вопросов и десяток документов, которые на них отвечают, дают работающий пилот. Тысяча разрозненных файлов не даёт ничего.
Можно ли обойтись поиском без языковой модели?
Иногда да, и это стоит проверить. Если сотрудникам достаточно найти нужный документ, хороший полнотекстовый поиск дешевле и предсказуемее. Модель нужна там, где ответ приходится собирать из нескольких источников.
Через сколько времени будет виден результат?
Быстрее всего эффект заметен там, где вопросы повторяются и ответ на них уже существует в документах. Если же ответы приходится сначала написать, основная работа окажется не технической, а редакторской, и срок определяется ею.
Коротко
- Начинайте со списка реальных вопросов, а не с загрузки всех документов.
- Больше данных не значит лучше ответы: избыток и противоречия ухудшают поиск.
- Права проверяйте на этапе поиска, а не показа.
- Ссылка на источник обязательна, иначе ответ непроверяем.
- Тестовый набор соберите до запуска, включая вопросы без ответов.
- У базы знаний должен быть владелец, иначе через полгода она устареет.
Общий контекст внедрения LLM в компании разобран в опорном материале: LLM для бизнеса.
Нужен корпоративный поиск по вашим документам?
На 30-минутном разборе определим, какие документы нужны для старта, как устроить права доступа и по какой метрике оценивать результат.
Напишите мне в Telegram: https://t.me/dtamarov
Подготовьте список вопросов, которые сотрудники задают чаще всего, и перечень систем, где сейчас лежат документы.
