Перед разработкой бота заказчик почти всегда спрашивает, что нужно подготовить. Короткий ответ «ваши документы» верен наполовину. Бот на языковой модели отвечает тем, что нашел в базе знаний. Если в базе две версии тарифа, он может процитировать старую. Если нужного документа нет, он откажет или, хуже, соберет ответ из похожих фрагментов. Разберем, что собрать до разработки, что в базу класть не стоит, как проверить ее готовность и кто будет вести базу после запуска.
Качество ответов ограничено тем, что лежит в базе
ИИ-чат-бот с ответами по документам работает в два шага. Поиск находит в базе знаний фрагменты, подходящие к вопросу. Модель составляет по ним ответ и ссылается на источник. Модель можно заменить на более сильную, поиск — настроить точнее, но ни то ни другое не поможет, если правильного ответа в базе нет.
Поэтому база знаний — не приложение к проекту, а его основа. В нашем проекте поиска по документам корпорации система работает с тысячами файлов в Word, Excel, PowerPoint и PDF. Ответ приходит за 5–10 секунд, точность ответов — до 90%, а к каждому ответу приложена цитата из документа-источника. Такие цифры возможны, только когда в базе есть что цитировать.
Ответы живут не только в документах
Первый шаг — инвентаризация: где в компании сейчас находятся ответы на вопросы, которые будет получать бот. Официальные документы — только часть картины.
- Регламенты, инструкции, прайсы, договоры и их приложения.
- Материалы службы поддержки: шаблоны ответов, частые вопросы, заметки во внутренней базе.
- Переписка с клиентами: в ней видно, как на самом деле звучат вопросы и что на них отвечают.
- Таблицы, которые сотрудники ведут рядом с системами: условия для отдельных клиентов, исключения, контакты.
- Знания опытных сотрудников, которые нигде не записаны.
По каждому источнику фиксируют три вещи: что в нем лежит, кто за него отвечает и насколько он актуален. Последний источник в списке самый неудобный. Если правило знает только руководитель смены, бот его не узнает, пока кто-то его не запишет.
Такие знания собирают на интервью. Опытного специалиста просят ответить вслух на десяток частых вопросов, а аналитик записывает ответы вместе с условиями и исключениями. Час такого разговора часто дает больше, чем день поиска по папкам.
Начните с вопросов, а не с документов
Самая частая ошибка — собирать все документы подряд. База получается большой, а ответов на частые вопросы в ней нет: регламенты написаны для сотрудников, а клиенты спрашивают о другом.
Правильный порядок обратный. Сначала собирают реальные вопросы: выгрузку обращений в поддержку за 2–3 месяца, обезличенную и разложенную по темам. Потом для каждой темы ищут документ, который на нее отвечает. Получается карта покрытия: какие темы закрыты документами, какие — частично, а для каких документа нет вовсе.
Практический прием: возьмите случайную выборку из нескольких сотен обращений и разметьте темы вручную. Обычно небольшое число тем покрывает большую часть потока, а дальше тянется хвост редких вопросов. Те же обращения пригодятся для проверочного набора на приемке, поэтому выгрузку стоит сделать один раз и аккуратно.
Большая база не значит хорошая
Загрузить в бота все файловое хранилище — быстрый способ получить плохие ответы. Чем больше в базе похожих документов разного возраста и статуса, тем чаще поиск находит не тот фрагмент. Модель отвечает строго по найденному, и ошибка выглядит как ответ со ссылкой на источник.
Небольшая база из действующих документов и коротких ответов на частые вопросы работает лучше, чем выгрузка всего, что накопилось за десять лет. Расширять ее разумно по карте покрытия: добавлять документы под темы, которые бот пока не закрывает, а не все подряд.
Пробелы закрывают до разработки
Темы без документа — главный результат карты покрытия. По каждой есть три решения: написать короткий ответ, найти документ в другом источнике или явно исключить тему из зоны бота. В последнем случае бот на такой вопрос сразу передает диалог оператору, а не пытается собрать ответ из похожих фрагментов.
Короткие ответы пишут специалисты, которые сейчас отвечают на эти вопросы. Формат простой: вопрос, ответ, условия, при которых ответ верен, дата, с которой он действует, и владелец записи. Такие записи бот находит и цитирует лучше, чем длинный регламент, где нужный абзац спрятан в середине раздела.
Условный пример записи. Вопрос: можно ли изменить адрес доставки после оплаты. Ответ: да, через личный кабинет или оператора, пока заказ не передан в службу доставки. Условия: только для курьерской доставки. Действует с 1 сентября 2026 года. Владелец — руководитель поддержки.
Если карта покрытия показала, например, 30 тем без документа, на короткие ответы по ним уйдет несколько дней работы двух-трех специалистов. Это условная оценка для планирования, но время в любом случае лучше выделить до начала разработки. Иначе прототип будут проверять на базе с дырами, и его результаты покажут пробелы в документах, а не качество бота.
Что в базу класть не стоит
- Черновики и проекты документов без пометки статуса.
- Устаревшие версии рядом с действующими.
- Дубли: одна и та же инструкция в трех папках с разными датами.
- Внутренние документы, если бот отвечает клиентам: служебные записки, условия для отдельных контрагентов, внутренние нормативы.
- Персональные данные клиентов и сотрудников: базе знаний они не нужны, а требования 152-ФЗ к ним действуют и здесь.
- Рекламные тексты с обещаниями, которых нет в договоре.
Последний пункт неочевиден. Страницу сайта с фразой «доставка за один день» бот процитирует клиенту как условие. Если в договоре срок другой, спор пойдет о том, что пообещал бот.
У каждого документа одна действующая версия
Бот не отличает действующий регламент от отмененного, если ему об этом не сказать. Поэтому у каждого документа в базе должны быть статус и даты: действует с, действовал до, чем заменен. Поиск учитывает эти поля и по умолчанию берет только действующие версии.
Есть тонкость, которая видна только на клиентских вопросах. Клиент с договором прошлого года работает по прошлогодним условиям, и если удалить старую версию, бот ответит ему по новым. Поэтому старые версии не выбрасывают, а переводят в архив с датами действия. Если бот знает дату договора клиента, например из CRM, он ищет условия, которые действовали на эту дату.
То же с изменениями, которые вступят в силу позже. Новый тариф с 1 декабря загружают заранее, но с датой начала действия. До этой даты бот отвечает по старому тарифу и может предупредить, что с декабря условия изменятся.
Противоречия находят до запуска или после жалобы
В любой базе из нескольких сотен документов есть противоречия: в прайсе одна цена, в ответах поддержки другая, в регламенте третья. Человек знает, какому источнику верить. Поиск найдет все три фрагмента, а модель выберет один из них или смешает их.
Искать противоречия удобно по карте покрытия: если по одной теме нашлось несколько документов, их сверяют. Для каждого типа сведений назначают главный источник: цены — прайс, сроки — договор, порядок действий — регламент. Остальные документы ссылаются на главный, а не пересказывают его.
Часть противоречий всплывет только на проверке. Если два специалиста дают на один вопрос разные эталонные ответы, проблема не в боте, а в документах, и чинить надо документы.
Как писать документы, которые бот прочитает правильно
Требования к подготовке файлов — разбор таблиц, статусы, сохранение структуры — мы описывали в статье о выборе между RAG и дообучением. Здесь — о том, как писать новые документы и короткие ответы, чтобы бот не ошибался на них.
- Один факт — в одном месте. Если срок возврата указан в пяти документах, после изменения он останется старым хотя бы в одном.
- Условия — явно и рядом с фактом: «для юрлиц», «при оплате картой», «с 1 декабря». Фрагмент без условия бот применит ко всем.
- Без отсылок к соседним разделам. Фраза «в этом случае действует порядок из раздела 3» бесполезна, если раздел 3 не попадет в тот же запрос.
- Сокращения расшифрованы хотя бы один раз в каждом документе.
- Числа — с единицами и точкой отсчета: «5 рабочих дней с даты оплаты», а не «5 дней».
Эти правила полезны и людям. Документ без двусмысленностей одинаково хорошо работает и для бота, и для нового сотрудника.
Права доступа хранятся в базе, а не в инструкции
Если бот отвечает сотрудникам разных отделов, у каждого документа в базе должна быть пометка, кому он доступен. Поиск идет только по документам, которые пользователь и так может открыть. Ограничение в инструкции для модели вроде «не показывай документы руководства» не работает: модель не может определить, какой фрагмент к ним относится, а инструкцию можно обойти формулировкой вопроса.
Для клиентского бота правило проще: в его базе только то, что можно показать любому клиенту. Внутренние документы живут в отдельной базе для ассистента сотрудников.
Пометку доступа ставят при загрузке документа, а не потом. Исправлять права задним числом в базе из тысяч файлов долго, а пропущенный документ обнаруживается только после неприятного ответа.
Как проверить, что база готова к разработке
- Есть карта покрытия: для частых тем есть документ или короткий ответ, а темы вне зоны бота перечислены явно.
- У каждого документа есть статус, даты действия и владелец.
- Противоречия по частым темам найдены, и для каждого типа сведений назначен главный источник.
- Внутренние и клиентские документы разделены, персональных данных в базе нет.
- Назначен владелец базы и согласован порядок обновления.
Если по любому пункту ответ «нет», разработка все равно возможна, но прототип покажет качество базы, а не качество бота. Это тоже полезный результат, только получить его лучше осознанно.
Кто ведет базу после запуска
Документы меняются: выходят новые тарифы, правила, продукты. Через полгода без присмотра бот уверенно отвечает по прошлогоднему прайсу и ссылается на источник, которому пользователь поверит. Поэтому у базы должен быть владелец с вашей стороны. Подрядчик автоматизирует переиндексацию, но решать, какой документ действует, может только тот, кто отвечает за содержание.
На практике это три роли.
- Владелец базы знаний решает, что входит в базу и что из нее убирается, и следит за сроками обновления.
- Авторы по направлениям отвечают за свои документы: юрист — за договоры, продуктовый специалист — за тарифы, руководитель поддержки — за ответы на частые вопросы.
- Операторы отмечают ошибки бота и вопросы, на которые он не нашел ответа.
Самая полезная регулярная работа — разбор вопросов, на которые бот ответил «не нашел» или которые передал оператору. Это готовый список пробелов: каждый повторяющийся вопрос превращается в новый короткий ответ или в правку документа.
Обновление базы — часть изменения правил
Самый надежный способ держать базу актуальной — встроить ее обновление в процессы, которые меняют правила. Новый тариф, новая форма договора или другой порядок возврата не считаются введенными, пока в базе не обновлен документ и не снята старая версия.
Для этого в порядок согласования изменений добавляют один пункт с ответственным. Это дешевле любых проверок: база меняется в тот же день, что и правило, а не через месяц после первой жалобы.
Признаки, что база стареет
- Растет доля ответов «не нашел» на темы, которые раньше были закрыты.
- Операторы все чаще исправляют ответы бота по одной и той же теме.
- Бот цитирует документы, которые давно никто не открывал и не обновлял.
- В базе появились документы без владельца — их загрузили «на время» и забыли.
- Тариф или правило уже изменились, а в базе об этом нет ни слова.
Каждый из этих признаков виден в журнале диалогов, если его ведут. Владельцу базы достаточно раз в неделю смотреть на несколько цифр и разбирать выборку диалогов, чтобы заметить старение раньше, чем его заметят клиенты.
Сколько времени это занимает
Инвентаризация источников и карта покрытия занимают одну-две недели частичной загрузки владельца базы и руководителя поддержки. Сроки закрытия пробелов зависят от их числа: иногда это несколько дней, иногда отдельная работа по описанию процессов.
После запуска первые два-три месяца самые плотные: живые пользователи задают вопросы, которых не было в выборке, и разбор идет каждый день. Потом работа переходит в регламентный режим — обновление при изменениях и еженедельный разбор отказов. Это время стоит сразу заложить в расходы на эксплуатацию, а не обнаруживать после запуска.
Что база дает, кроме бота
Порядок в документах полезен сам по себе. Противоречия разрешены, у каждого документа есть владелец, на частые вопросы есть короткие ответы. Новые сотрудники находят ответы быстрее, а споры о том, какая версия правильная, заканчиваются.
Бывает и обратный честный вывод. Если знания в компании не записаны и записывать их некому, бот на старте будет почти все передавать операторам. Тогда первым этапом должно стать описание процессов, а не разработка, и мы скажем об этом на диагностике.
Сроки, бюджет и команда
Прототип на части документов — от 600 тыс. ₽ и до двух недель: берем частые темы, собираем базу и меряем долю верных ответов и корректных отказов на реальных вопросах. Пилот — 1,5–3,5 млн ₽ и 3–6 недель: вся база, каналы, передача оператору и регламент обновления.
С нашей стороны работают ML-инженер, бэкенд-разработчик и аналитик, который помогает собрать карту покрытия. С вашей нужны владелец базы знаний, руководитель поддержки и авторы документов по направлениям.
Коротко
- Бот отвечает только тем, что лежит в базе, поэтому ее качество ограничивает качество ответов.
- Начинайте с реальных вопросов: карта покрытия показывает, каких документов не хватает.
- Пробелы закрывают короткими ответами до разработки, а темы вне зоны бота перечисляют явно.
- У каждого документа — статус, даты действия и владелец, у каждого типа сведений — главный источник.
- Права доступа хранятся в базе, внутренние и клиентские документы разделены.
- После запуска базу ведет ваш владелец, а разбор отказов бота показывает, что дописать.