Первый честный тест любого корпоративного бота выглядит так. Спрашиваешь: «какая отсрочка платежа у нас для новых клиентов из розницы?». Модель отвечает уверенно, красиво и неправильно. В договоре стоит 14 дней, бот сказал 30.
Врать он не собирался. Языковая модель предсказывает правдоподобное продолжение текста, а не сверяется с вашими файлами. Ваших договоров она никогда не видела. Из тысяч чужих договоров она усвоила, что «30 дней» встречается чаще, и выдала статистику вместо факта.
RAG чинит ровно эту дыру.
Что это за схема
Аббревиатура расшифровывается как retrieval-augmented generation: генерация с подтягиванием найденного. Смысл проще названия. Перед тем как ответить, система лезет в вашу библиотеку, находит подходящие куски текста и вкладывает их в запрос модели вместе с инструкцией: отвечай только по этому, чего нет, скажи «не нашёл».
Важный момент, который снимает половину вопросов на переговорах: модель при этом ничему не учится. Никакого дообучения нейросети не происходит. «Обучить ИИ на наших документах» на практике значит собрать и разметить базу знаний. Меняется библиотека, а не мозг.
Отсюда приятное следствие. Поменялся прайс, вы заменили файл и переиндексировали раздел. Через пять минут ассистент отвечает по-новому. С дообучением моделью пришлось бы гонять целый цикл заново.
Четыре шага под капотом
Сбор. Файлы стаскиваются в одно место: договоры, регламенты, прайсы, инструкции, переписка по типовым вопросам. Формат тут вторичен, важна актуальность.
Нарезка. Документ режется на фрагменты по 300-800 слов, обычно с перехлёстом в пару предложений. Слишком мелкие куски теряют контекст, слишком крупные тянут в ответ мусор. Хороший ориентир: фрагмент должен читаться самостоятельно.
Индексация. Каждый фрагмент превращается в вектор, набор чисел, отражающий смысл. Рядом обычно держат обычный текстовый индекс BM25, потому что по артикулу ВГ-125 или номеру приказа он находит лучше любой векторной магии. Гибрид из двух поисков работает надёжнее каждого по отдельности.
Ответ. На вопрос система поднимает 5-10 самых близких фрагментов, отдаёт их модели и получает формулировку. К ответу прикладывается ссылка: файл, раздел, страница.
Есть пятый шаг, про который забывают на старте, а он решает половину проблем. К каждому фрагменту стоит прицепить метки: отдел, тип документа, дата редакции, срок действия. Тогда поиск можно сузить до нужного среза и не тащить в ответ прошлогодний прайс. Без меток библиотека на тысячу файлов превращается в лотерею уже через квартал.
Цитата-источник это не украшение
Правило, которое мы держим железно: ни одного числа в ответе без ссылки на документ. Оно родилось на платформе для инженеров по надёжности оборудования, где ошибка в цифре стоит дорого. Там отдельный контролёр трассирует каждое утверждение базы до исходного файла, а покрытие проверяется автотестами, их набралось 187.
Зачем это бизнесу попроще. Ссылка превращает ассистента из оракула в справочник. Сотрудник видит: ответ взят из «Регламент отгрузки, редакция от марта, пункт 4.2». Сомневается, открывает и проверяет за десять секунд.
Без источников люди либо верят всему подряд, либо перестают пользоваться после первой ошибки. Оба варианта плохие.
Во внутреннем ассистенте строительной группы мы собрали 798 фрагментов из 155 файлов, разложили по отделам и закрыли доступ между ними. Снабжение не видит документы юристов, юристы не видят закупочные цены. Проверка изоляции была отдельной задачей, и это правильно: одна утечка внутри компании убивает доверие к системе быстрее, чем десять неточных ответов.
Что портит качество: пять реальных бед
Сканы. PDF, который на самом деле фотография бумаги. Текста внутри нет, индексировать нечего. Лечится распознаванием, но тут закопаны грабли. Мы потеряли время на битой русской модели Tesseract из набора tessdata_fast: движок молча срывался на английский и выдавал латинскую кашу вместо слов. Помог полный набор tessdata_best плюс предобработка картинки, чёрно-белый режим и увеличение вдвое. Мелкий шрифт из старой копии без этого не читается.
Таблицы. Excel и табличные PDF при тупом извлечении превращаются в поток чисел без заголовков. Ассистент потом честно находит фрагмент «125 4 320 нет» и не может сказать, что это. Таблицы надо разбирать отдельно, построчно, подставляя названия колонок в каждую строку.
Дубли регламентов. Самая частая беда живых компаний. В папке лежат три версии одного приказа, две без даты. Поиск находит все три, модель выбирает случайную. Правило простое: одна действующая редакция в базе, архив отдельно и вне индекса.
Грязные справочники. В номенклатуре 1С мы ловили позицию «Сгон» с латинской C в начале. Глазами не отличить, поиск молча не находит. Перед индексацией такие гомоглифы приходится нормализовать, иначе часть базы существует, но недоступна.
Устная традиция. Половина знаний компании нигде не записана. Ассистент физически не найдёт того, чего нет в файлах. Обычно первый месяц проекта уходит не на код, а на то, чтобы люди выгрузили из головы хотя бы топ-30 вопросов с ответами.
Как понять, что база работает
Соберите 30-50 настоящих вопросов, которые сотрудники задают друг другу в чатах. К каждому запишите правильный ответ и файл, где он лежит. Получится тест.
Дальше прогоняете его после каждого изменения базы и смотрите три цифры:
- сколько ответов совпало с эталоном;
- сколько раз система честно сказала «не нашёл» (это не провал, а нормальное поведение);
- сколько раз ответ был уверенным и неправильным.
Прогонять тест надо не один раз. Библиотека живёт: приходят новые прайсы, отменяются условия, меняются люди. Мы ставим переиндексацию по расписанию и раз в месяц смотрим на тот же список вопросов. Просело качество, значит в базу заехало что-то лишнее или кто-то положил вторую редакцию поверх первой.
Третья цифра важнее всех. Она должна быть нулём или близко к нулю. Уверенная ложь опаснее отказа, потому что её никто не перепроверяет.
Где RAG не работает
Он не считает. Вопрос «сколько всего договоров с отсрочкой больше 30 дней» это не поиск по смыслу, это запрос к базе. Поиск найдёт пять похожих договоров и сложит их как получится. Такие вещи решаются связкой с SQL или выгрузкой из учётной системы, а не эмбеддингами.
Он не отвечает на слишком общие вопросы. «Расскажи про нашу работу с поставщиками» это не вопрос, под него подходит половина библиотеки. Ассистент выдаст размытую сводку, и вы решите, что система плохая.
Он не читает рукописное. Пометки на полях, подписи от руки, заполненные ручкой бланки остаются вне игры. Локальные модели зрения с этим тоже не справляются, проверяли.
Он не заменяет порядок в документах. Если у вас нет хозяина у папки с регламентами, через полгода в базе снова окажутся три редакции одного приказа. Технология не лечит организационный бардак, она его подсвечивает.
И последнее, неприятное. RAG не даёт стопроцентной точности. На хорошо собранной базе доля верных ответов на типовых вопросах высокая, но остаток всегда есть. Поэтому в ответственных сценариях ассистент готовит черновик и показывает источник, а решение принимает человек. Такой же принцип мы применяем к ИИ-агентам с правом действовать в системах.
Три провала на живых базах
Слишком крупные куски. Первую версию мы нарезали по две тысячи слов: казалось логичным, что чем больше контекста, тем лучше. Получилось наоборот. В найденный фрагмент попадал весь раздел договора, модель тонула в тексте и цепляла соседний пункт вместо нужного. Порезали до 400-600 слов с перехлёстом в два предложения, и точность выросла без единой правки промпта.
Архив почты в базе. Идея звучала красиво: вся переписка отдела за три года, там же все ответы. На практике поиск начал находить отменённые договорённости и черновики, которые никто не согласовывал. Отличить живое от мёртвого система не могла, а сотрудники получали ответ со ссылкой на письмо, где условия обсуждались, но не были приняты. Почту из базы убрали. Вместо неё завели раздел с выжимками: типовой вопрос и утверждённый ответ, десять строк вместо трёх тысяч писем.
Двухколоночный PDF. Отраслевой регламент был свёрстан в две колонки. Извлечение текста шло построчно, и строки двух колонок склеивались в одну. Фрагменты получались бессмысленными, а поиск исправно их находил. Помог разбор с учётом координат блоков через pymupdf. Мораль: перед индексацией стоит глазами посмотреть, что вытащилось из десятка случайных файлов, а не сразу гнать всю папку.
С чего начать у себя
Возьмите один отдел и один тип вопросов. Не «вся база компании», а, скажем, условия работы с клиентами: прайс, шаблон договора, регламент отгрузки, десять частых вопросов. Пять-семь файлов достаточно для первого запуска.
Дальше по шагам:
- Выделите ответственного за содержимое, без него база протухнет за квартал.
- Почистите дубли и пометьте действующие редакции датой в имени файла.
- Соберите тестовый список вопросов, пока не написана ни одна строка кода.
- Запустите пилот на этих файлах и дайте его пяти сотрудникам на неделю.
- Соберите вопросы, на которые он ответил плохо, и расширяйте базу по ним.
Такой пилот занимает 2-4 недели вместе с интеграцией в Телеграм или внутренний портал. Дольше обычно тянется не разработка, а сбор файлов на стороне заказчика.
Короткие ответы на частые вопросы
Сколько документов нужно для старта? Пяти-семи хватает, чтобы получить работающий пилот. Тысяча файлов на старте вредит: вы месяц собираете папку, а потом выясняется, что половина устарела. Растите базу по реальным вопросам, на которые ассистент не смог ответить.
Наши файлы попадут в обучение чужой нейросети? При правильной схеме нет. Фрагменты подкладываются в запрос, модель их не запоминает и никуда не сохраняет. Если требования жёстче, вся обработка переносится на ваш сервер, про это писал в разборе про локальную LLM.
Можно ли подключить к базе 1С или CRM? Можно, но это другая механика. Регламент ищется по смыслу, а остаток на складе берётся запросом к системе. Обычно ассистент умеет и то и другое: сначала решает, что перед ним, потом идёт в нужный источник.
Как закрыть документы, которые не всем можно видеть? Правами на уровне фрагмента. У каждого куска стоит метка отдела, поиск фильтруется по правам сотрудника. Проверять изоляцию нужно отдельным тестом, а не на честном слове разработчика.
Как быстро база узнаёт про новый прайс? Переиндексация раздела занимает минуты. Мы обычно вешаем её на расписание плюс кнопку «обновить сейчас» для ответственного.
Собранные контуры и метрики лежат в кейсах, а про расходы на токены, сервер и поддержку я отдельно посчитал в статье про стоимость внедрения. Хотите проверить свою библиотеку до разработки, приходите на AI-аудит: посмотрим, что у вас за файлы, и скажем честно, если половину придётся сначала перенабрать.