Как подготовить базу знаний, чтобы по ней отвечал бот

Бот отвечает по тому, что лежит в базе знаний, и качество ответов определяется документами, а не настройками модели. Ниже — что сделать с материалами до запуска, чтобы ответы были точными.

Соберите реальные вопросы

Начинать надо не с документов, а с вопросов. Выгрузите переписку первой линии за месяц: открытые линии, чат поддержки, письма. Обычно выясняется, что основной поток — это десять-пятнадцать повторяющихся вопросов, и именно под них нужны материалы.

Список таких вопросов пригодится дважды: сначала как план по документам, потом как тестовый набор для проверки бота.

Уберите противоречия

Самая частая причина неверных ответов — две версии одного документа. Регламент 2023 года и обновлённый лежат рядом, в обоих указаны разные суммы согласования, и оба выглядят действующими.

Устаревшие версии надо архивировать. В Базе знаний 2.0 это важно и технически: метод note.document.tree.list, которым бот получает дерево документов, архивные страницы в ответ не включает. То есть после архивации документ пропадает из источника автоматически.

Проверить на всякий случай: в ответе note.document.get есть признаки isArchived и isTrashed. Если вы строите индекс сами, по ним фильтруйте.

Перенаберите таблицы текстом

Матрицы скидок, условия тарифов и схемы процессов часто вставлены скриншотами. Человек такое читает, бот — нет: встроенный AI-агент изображения и вложенные документы не анализирует.

Страница с картинкой выглядит наполненной, а отвечать по ней нечем. Таблицу надо перенабрать в текст — в Markdown они поддерживаются и остаются структурой, по которой модель отвечает корректно.

То же касается PDF-файлов, прикреплённых к странице: содержимое внутри вложения для бота невидимо.

Добавьте короткие ответы в начало длинных документов

Положение о командировках на четырёх листах содержит ответ на вопрос «сколько суточных в Москве», но он лежит в третьем разделе между формулировками про приказ и авансовый отчёт. Модель найдёт его не всегда.

Решение простое: в начале документа блок из нескольких прямых вопросов и коротких ответов. Это помогает и боту, и людям — чаще всего в документ заходят ровно за одной цифрой.

Разделите базы по доступу

Если первая линия отвечает клиентам, внутренние регламенты не должны лежать в том же месте, откуда бот берёт ответы. Иначе клиент получит в чат маржинальность или порог скидки, который согласуют без руководителя.

Правильный способ — отдельная база знаний для внешних ответов, в которой лежит только то, что можно показывать наружу. Инструкция боту «не рассказывай про скидки» таким ограничением не является.

Для внутреннего помощника разграничение работает само: note.document.search.list выдаёт документы тех баз, к которым у пользователя есть доступ.

Пишите заголовки так, как спрашивают

«Порядок взаимодействия с контрагентами при возникновении задолженности» — заголовок, который никто не ищет. «Что делать, если клиент не платит» — ищут.

Заголовок в Markdown — это первое, за что цепляется и поиск, и модель. Если переименовать документ нельзя по формальным причинам, добавьте человеческий подзаголовок первой строкой текста.

Держите документы короткими

Один документ — одна тема. Сводный файл «Всё о работе с клиентами» на тридцать страниц плох тем, что в ответ попадает фрагмент не из того раздела.

В Базе знаний 2.0 документы организованы деревом: родительская страница и вложенные. Это удобный способ разложить большой регламент на части, сохранив структуру.

Сколько материалов выдержит бот

Вопрос «не слишком ли большая у нас база» сейчас почти снят. У агентных моделей BitrixGPT 5.6 и 6.0 контекст — 1 048 576 токенов, это порядка тысячи страниц текста и больше. База знаний средней компании занимает сотни страниц, то есть помещается целиком, без нарезки на фрагменты и векторного поиска.

Значит, сокращать документы ради экономии контекста не нужно. Сокращать стоит ради людей — чтобы ответ находился, а не тонул в формулировках.

Проверьте на своих вопросах

Возьмите список реальных вопросов, собранный на первом шаге, и прогоните его через бота целиком. Смотреть надо не на то, звучит ли ответ уверенно, а на то, совпадает ли он с документом.

Каждое расхождение — это правка в документе. Соблазн поправить промпт вместо документа большой, но так вы чините один вопрос и ломаете соседние.

Заведите журнал промахов

После запуска собирайте случаи, когда бот ответил «не знаю» или ответил неверно. Через месяц такой журнал превращается в план работ по базе знаний: становится видно, по каким темам документов нет вообще.

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

Сколько это занимает

Настройка бота — день-два. Разбор материалов — от недели до месяца, в зависимости от объёма и степени запущенности. Пропорция не меняется: основное время уходит на документы.

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