База знаний для AI-агента: что собрать и как проверить, что он отвечает по ней

Клиентские менеджеры МТС готовились к встречам через Telegram-бота: разведка по ИНН, подбор продуктов, шаблонные подсказки. Исследование отдела продаж показало, что больше всего времени уходит на подготовку к разговору с клиентом, и команда CVM B2B взялась за ассистента, который отвечает на вопросы по 100+ B2B-продуктам со ссылкой на источник в документации. Отвечает он только по тому, что лежит в базе знаний, которую для него собрали.

Первая версия часть данных брала из внешних порталов и веб-поиска. Но безопасники сказали, что данные извне брать нельзя, поэтому команда перешла на работу исключительно с внутренними источниками знаний.

Внутренняя база знаний в компании была, и у команды, которая её ведёт, был собственный поиск по ней. Но исходных данных она не отдавала, а API базы для этой задачи оказался бесполезен. Поэтому страницы пришлось разбирать парсером и собирать содержимое заново.

Почему справочник контактов отвечал на вопросы о продуктах

Устройство базы стало видно после выгрузки. У некоторых продуктов вложенность доходит до шести уровней, а рекорд команды с такой структурой: 77 подстраниц у одного продукта.

Поэтому структуру закрепили в самом тексте. Заголовок первого уровня в разметке равен продукту, ниже идёт вложенность страниц. К каждому фрагменту добавили «хлебные крошки», путь до раздела, чтобы фрагмент нёс с собой своё место в базе. Таблицы привели к единому виду, а ссылки из текста удалили как мусорные. Отдельным правилом записали, что делать, когда ответа нет: если данных нет на внутренних ресурсах, ассистент честно говорит «не нашёл».

Сама база тоже ломала ответы. Разделы без категории получали метку general, и справочник «Контакты» с телефонами выходил в топ на вопросы вида «чем X отличается от Y». Метрики по таким вопросам стремились к нулю: человек спрашивал про разницу двух продуктов, а получал телефонный справочник.

Проверяли это набором из 72 контрольных вопросов: три продукта из сотни, пять категорий. Часть вопросов составили руками, часть сгенерировали, ответы оценивала языковая модель-судья. Остальные продукты из сотни эти вопросы не затронули.

В рабочей версии результат разошёлся с тем, что получали на своей машине. Большинство метрик упало, выросла только достоверность ответа, и авторы объясняют это тем, что модель чаще отвечает «информация в документации не найдена».

Проверка базы знаний для AI-агента до запуска

У небольшой компании нет ни сотни продуктов, ни 77 подстраниц. Но три поломки повторяются и на десятке услуг: раздел, по которому непонятно, о чём он; таблица, разорванная на части; выдуманный ответ там, где в базе ничего нет.

Таблица, разорванная на границе фрагментов, даёт неверную цифру. В разборе помощника по 300+ регламентам агент назвал неверный срок подготовки коммерческого предложения: шапка таблицы попала в один фрагмент, а строки со сроками в другой. После структурной нарезки и глоссария аббревиатур оценка корректности на 20 вопросах в три прогона выросла с 0,377 до 0,586, и автор разбора сам предупреждает, что читать это как «агент верен на 58,6%» нельзя.

Контрольные вопросы не нужно сочинять. Они уже есть в переписке с клиентами и в вопросах новых сотрудников. Наберите столько, сколько закрывает ваши ходовые темы: у команды МТС на три продукта ушло 72 вопроса. На этом же наборе видны два признака, что база ещё не готова: агент отвечает «не нашёл» на вопрос, ответ на который в документах есть, и в ответ на вопрос о продукте выходит посторонний раздел. Пока держится хотя бы один из них, запускать агента на клиентов рано.

По словам разработчика хелпдеска, до запуска стоит ответить на один вопрос: сможет ли новый сотрудник работать только по имеющейся документации. Если нет, сначала приводят в порядок знания компании, и только потом ставят агента. Тот же разработчик замечает, что у маленьких компаний часто нет оцифрованных регламентов.

Файл в чате базой знаний не становится

Вторая линия техподдержки МТС Web Services начинала с выгрузки Confluence в JSON и загрузки этого файла в чат с моделью. Минусы вылезли сразу: каждый пользователь должен сам загружать файл, файл требуется обновлять, и есть ограничение на размер.

Вместо файла собрали базу с поиском: фрагменты по 2000-3000 символов с перекрытием 150-200, обновление раз в 30 минут и только изменённых страниц. Проверяли по списку запросов с эталонными ответами и ссылками, а сотрудники параллельно пользовались обычным поиском и заводили задачи на плохие ответы. Количественные метрики, по их словам, измерить пока сложно.

Кроме устаревших страниц в базе копятся дубли. В сервисе пополнения базы по обращениям в поддержку проба на 264 обращениях и базе из 54 фрагментов дала 191 кандидата: 33 новых, 93 на обновление, 35 уже покрытых, 30 на проверку. Редактор принял 33 новых, и база выросла до 87 активных фрагментов. На тестовой базе из 134 фрагментов нашлось 14 групп возможных дублей, но автоудаление включать не стали: ложное объединение опаснее пропущенного дубля.

Личная папка файлов, которую агент читает в начале работы, живёт по тем же правилам. Замеров у неё нет: инженерная команда, которая такую папку ведёт, прямо пишет, что формальных измерений сэкономленного времени пока не делала. Открытый вопрос у неё тот же, что у корпоративной базы: как находить устаревшие решения, чтобы агент на них не опирался.

Коротко

1. Решите, на что агент отвечает Выпишите темы и продукты, по которым он обязан дать ответ. Остальное в базу пока не кладите.
2. Соберите контрольные вопросы Возьмите реальные вопросы клиентов и новых сотрудников, запишите к ним верные ответы и проверяйте базу на этом наборе до запуска.
3. Подпишите каждый раздел У раздела должна быть тема и путь до него в базе, иначе справочник контактов вылезет в ответ на вопрос о продукте.
4. Приведите таблицы к одному виду Расшифруйте аббревиатуры рядом с таблицей и проверьте, что строка читается, даже когда шапка осталась в другом фрагменте.
5. Запретите агенту выдумывать Пропишите ответ «не нашёл» для случаев, когда в документах ответа нет, и проверьте это правило на своих вопросах.
6. Назначьте владельца базы Один человек отвечает за обновление и решает, что удалить. Автоудаление похожих фрагментов не включайте.