Запрос «сделайте бота, который знает всё про компанию» приходит регулярно. За ним обычно стоит понятная боль: документы разложены по десяткам папок и чатов, новый сотрудник неделями ищет актуальную инструкцию, а поддержка отвечает на одни и те же вопросы. Технология, которая закрывает такую задачу, называется RAG — генерация ответа с опорой на найденные документы. Разберём, как она устроена, где даёт результат и что придётся сделать до запуска.
Как устроен RAG и чем он отличается от обычного бота
Сценарный бот отвечает по заранее прописанным веткам: вопрос распознан — выдан заготовленный текст. Всё, что не предусмотрено сценарием, уходит оператору. Языковая модель без дополнений отвечает свободно, но опирается только на то, что было в обучении, и про внутренние регламенты конкретной компании ничего не знает.
RAG соединяет два этапа. Сначала система ищет в базе компании фрагменты, относящиеся к вопросу, затем передаёт их модели вместе с самим вопросом и просит сформулировать ответ строго по этим фрагментам. Поиск идёт не по точному совпадению слов, а по смыслу: документы заранее разрезаны на фрагменты и переведены в векторные представления, вопрос переводится так же, и система находит ближайшие по смыслу куски текста.
Практическое следствие: ответ бота можно проверить. К каждому ответу прикладываются ссылки на исходные документы, и сотрудник видит, откуда взята формулировка. Это принципиальная разница с моделью без источников, где проверить утверждение нечем.
Где такой бот действительно окупается
Мы берёмся за задачу, когда у неё есть измеримый повторяющийся объём. Если вопросов десяток в месяц, дешевле оставить всё как есть.
- Внутренняя база знаний. Регламенты, инструкции, ответы на типовые вопросы по кадрам и ИТ. Новые сотрудники перестают отвлекать коллег на поиск документов.
- Первая линия поддержки. Бот отвечает на повторяющиеся обращения по инструкции к продукту, сложное передаёт оператору вместе с историей диалога.
- Работа с договорами и коммерческими условиями. Менеджер спрашивает про условия конкретного типа договора и получает ответ со ссылкой на пункт, а не пересказ по памяти.
- Техническая документация. Инженер ищет параметр или порядок действий в сотнях страниц руководств.
- Справка внутри продукта. Пользователь задаёт вопрос прямо в интерфейсе и получает ответ по вашей документации, а не общий совет из интернета.
Что происходит на проекте по шагам
Порядок работ у нас устоялся и почти не меняется от проекта к проекту.
| Этап | Что делаем | Что получает заказчик |
|---|---|---|
| Разбор задачи | Собираем реальные вопросы сотрудников или клиентов, оцениваем состояние документов | Список сценариев и понимание, что вообще стоит автоматизировать |
| Подготовка базы | Приводим документы к единому виду, убираем устаревшие версии, размечаем разделы | Упорядоченная база знаний, полезная и без бота |
| Сборка поиска | Разрезаем документы на фрагменты, строим индекс, настраиваем выдачу | Поиск по смыслу с проверяемыми ссылками на источник |
| Прототип и проверка | Прогоняем набор контрольных вопросов, сравниваем ответы с эталонными | Понятная картина точности до внедрения |
| Внедрение | Подключаем к мессенджеру, порталу или интерфейсу продукта, настраиваем права доступа | Рабочий инструмент в привычной среде сотрудников |
| Сопровождение | Смотрим вопросы, оставшиеся без ответа, дополняем базу, правим настройки | Бот, который не деградирует через полгода |
Подготовка документов — основная часть работы
Ожидание «загрузим папку, и всё заработает» не оправдывается. Качество ответов определяется качеством базы, и на её приведение в порядок уходит заметная доля проекта.
Типичные проблемы, которые мы находим: несколько версий одного регламента без признака актуальности, сканы без текстового слоя, таблицы, вставленные картинками, документы с противоречащими друг другу условиями. Если в базе лежат две редакции одного правила, система честно найдёт обе и выдаст ту, что оказалась ближе по формулировке. Виноват при этом не алгоритм.
Отдельно разбираемся с правами доступа. Кадровые документы, данные о зарплатах и коммерческие условия не должны попадать в ответ сотруднику, у которого нет к ним доступа. Разграничение закладывается на уровне поиска, а не фильтрацией уже готового ответа.
Как мы проверяем точность
Перед запуском собираем набор вопросов с заранее известными правильными ответами — обычно их составляют те же люди, которые сейчас отвечают на эти вопросы вручную. Прогоняем и смотрим на три вещи: нашёлся ли нужный документ, соответствует ли ответ источнику и не добавила ли модель ничего от себя.
Разбор ошибок почти всегда упирается в поиск, а не в формулировку ответа: нужный фрагмент не попал в выдачу, потому что документ неудачно разрезан или в нём другая терминология. Лечится настройкой разбиения, словарём синонимов и переформулировкой запроса перед поиском. Отдельно настраиваем поведение при отсутствии ответа: бот должен сказать, что не нашёл, и передать вопрос человеку. Правдоподобный, но выдуманный ответ хуже честного отказа.
Где живёт бот и как им пользуются
Отдельный сайт с окном чата — не лучший вариант для внутренних задач: туда надо специально заходить, и через месяц про него забывают. Мы стараемся встроить помощника туда, где сотрудник уже работает: в корпоративный мессенджер, во внутренний портал, в интерфейс учётной системы. Для клиентской поддержки это виджет на сайте или тот же канал, через который обращения приходят сейчас.
Важна и форма ответа. Короткий ответ с цитатой и ссылкой на документ воспринимается как справка, длинный пересказ — как ещё один текст, который надо читать. Поэтому мы задаём модели жёсткие рамки: отвечать по найденным фрагментам, не пересказывать лишнее, приводить источник и признавать, когда данных не хватает.
Ограничения, о которых стоит знать заранее
- Бот не заменяет эксперта. Он находит и формулирует то, что уже записано, и не принимает решений.
- Устаревшая база даёт устаревшие ответы. Нужен человек, отвечающий за актуальность документов.
- Сложные расчёты и логика бизнес-процессов — это не про поиск по тексту, здесь нужны обычные интеграции с учётными системами.
- Если данные нельзя передавать наружу, модель разворачивается в закрытом контуре. Это влияет и на бюджет, и на требования к оборудованию.
- Первые недели после запуска нужно смотреть журнал обращений: реальные вопросы почти всегда отличаются от тех, что предполагали на старте.
Собрать такую базу знаний и посадить на неё исполнителя — это и есть разработка ИИ-агента: агент отвечает по вашим регламентам и прайсам, а не по интернету.
С чего начать
Начинать разумно с одного участка: одна тема, один отдел, ограниченный набор документов. На таком объёме видно и качество ответов, и реальную пользу, и объём работ по наведению порядка в базе. Расширять область проще, когда первый участок уже работает и им пользуются.
Расскажите, какая рутина отнимает у команды больше всего времени, и мы оценим, что для неё подойдёт: помощник по базе знаний, бот первой линии или поиск, встроенный в существующий продукт. Если задача выглядит подходящей, мы разработаем ПО с искусственным интеллектом под ваши документы и процессы — от подготовки базы до запуска и сопровождения.
Расскажите, какую рутину хочется убрать, — и мы прикинем, какие AI-ассистенты и агенты подойдут вашей команде и что нужно для запуска.
