Новый менеджер может быть очень опытным, но в первый рабочий день он всё равно не знает, какие услуги продаёт компания, что входит в цену и кому нельзя обещать срочную доставку. ИИ-бот находится примерно в том же положении. Он умеет разговаривать, но без внутренних сведений о бизнесе вынужден опираться на общие знания и догадки.
База знаний для ИИ-бота решает именно эту проблему. Это набор проверенных материалов, из которых система получает факты о компании: товары, услуги, условия, ограничения, ответы на частые вопросы. Хорошая база не превращает модель в безошибочного эксперта, но резко сужает пространство для фантазии.
Не библиотека файлов, а рабочий источник
Базой знаний иногда называют папку, куда загрузили сайт, презентации, договоры и старые прайсы. Формально данных стало много, но пользоваться ими опасно. В одном документе цена действующая, в другом прошлогодняя; презентация обещает «быструю доставку», а внутренний регламент требует согласования сроков. Модель видит всё это как текст и не обязана угадать, какой файл главнее.
Рабочая база устроена иначе. В неё входят только сведения, которые компания считает актуальными и разрешает использовать в конкретной задаче. Это может быть не один документ, а несколько источников:
- описание компании и порядка работы;
- условия оплаты, доставки, гарантии и возврата;
- перечень услуг и ограничения;
- ответы на повторяющиеся вопросы;
- инструкции для типовых ситуаций;
- словарь терминов и разговорных названий;
- правила, по которым сложный вопрос получает сотрудник.
Объём здесь не главный показатель. Небольшой согласованный набор полезнее гигабайта документов, в которых никто не уверен.
Что знает модель и чего она не знает
Языковая модель обучена понимать речь и продолжать текст. Она способна объяснить, что такое порошковая покраска, чем отличаются виды страхования или зачем нужен аудит. Но из этих общих знаний не следует, что конкретная компания оказывает такую услугу, использует определённый материал или принимает оплату после выполнения работ.
Даже публичная информация не является надёжным источником сама по себе. Сайт может обновляться позже прайса, акция — закончиться, а условия одного филиала — не действовать в другом. Внутренние правила вообще могут нигде не публиковаться.
Если точного факта нет, модель часто формирует правдоподобное продолжение. Поэтому фраза «отвечай только правду» не заменяет данные. Системе нужно показать, что считается подтверждённым, а также разрешить ответ: «У меня нет актуальной информации по этому вопросу».
База знаний, каталог, инструкции и CRM — разные вещи
В разговоре эти понятия часто смешивают, хотя у каждого своя роль.
| Источник | Что в нём хранится | Для чего используется |
|---|---|---|
| Системные инструкции | Роль, тон, запреты и порядок действий | Определяют поведение бота |
| База знаний | Описания, условия, правила, FAQ | Даёт факты и объяснения |
| Каталог | Позиции, параметры, варианты, цены | Помогает подбирать и сравнивать |
| CRM | Клиенты, сделки, обращения, статусы | Связывает разговор с работой компании |
| Внешняя система | Наличие, расписание, текущий статус | Возвращает часто меняющиеся данные |
Например, вопрос «Какие варианты подходят для улицы?» требует каталога и описаний. Вопрос «Где мой заказ?» может потребовать доступа к конкретной записи. А правило «не обещать срок без подтверждения производства» относится не к фактам, а к поведению.
Один источник не заменяет остальные. CRM не становится базой знаний только потому, что в ней есть комментарии менеджеров, а длинный промт не превращается в каталог товаров.
Как бот получает нужный фрагмент
Клиент не должен ждать, пока модель прочитает все документы компании при каждом сообщении. Обычно система сначала определяет тему вопроса, затем выбирает связанные сведения и только после этого передаёт их модели.
Упрощённо процесс выглядит так:
- клиент задаёт вопрос;
- система понимает, о чём он;
- ищет подходящие материалы или запись в каталоге;
- добавляет найденное в контекст ответа;
- модель формулирует понятный текст;
- правила проверяют, можно ли отвечать или нужен сотрудник.
Если человек спрашивает о гарантии, нет смысла одновременно передавать модели весь каталог, инструкции по монтажу и архив акций. Лишний контекст затрудняет выбор нужного факта, увеличивает стоимость обработки и создаёт новые противоречия.
Поиск может быть смысловым, по ключевым словам, по структуре каталога или через внешний запрос. Конкретная технология вторична. Для бизнеса важнее, чтобы нужный источник находился стабильно и чтобы система не подменяла отсутствие ответа соседним текстом.
Текст подходит не для всех данных
Описание услуги удобно читать абзацем. Цена, артикул, размер и наличие лучше чувствуют себя в отдельных полях. Если три комплектации и четыре суммы спрятаны внутри рекламного буклета, бот может связать не ту цену не с тем вариантом.
Структурированные данные особенно полезны для:
- стоимости и единиц измерения;
- технических характеристик;
- размеров и комплектаций;
- артикулов;
- дат действия акции;
- доступности и статуса;
- региональных ограничений.
Текст нужен для объяснения смысла: кому подходит продукт, почему варианты различаются, как проходит работа. В хорошем ответе оба формата соединяются. Бот берёт точное значение из поля, а затем объясняет его нормальным языком.
Например, запись «цена от 50 000 ₽» сама по себе мало полезна. Рядом должно быть указано, что входит в минимальный вариант, от каких параметров зависит итог и кто подтверждает расчёт. Иначе модель будет вынуждена додумывать недостающую логику.
Как выглядит ответ, основанный на хороших данных
Предположим, клиент спрашивает: «Можно доставить в область и сколько это займёт?» В слабой базе есть только рекламная фраза «доставляем быстро по региону». Бот либо повторит её, либо придумает обычный срок.
В подготовленной базе отдельно записаны зона доставки, порядок расчёта стоимости и правило подтверждения срока. Тогда ответ получается полезным и аккуратным:
Доставка в область возможна, но стоимость и срок зависят от адреса и наличия. Укажите населённый пункт — я зафиксирую его для проверки.
Такой ответ не обязательно длиннее. Его качество определяется тем, что система знает границу: общий факт подтверждён, конкретный срок — нет. Хорошая база даёт не только сведения, но и правильный следующий шаг.
Она также помогает отвечать последовательно. Если клиент вернётся к вопросу через несколько сообщений, бот применит то же правило, а не выдаст новую версию в зависимости от формулировки.
Почему даже хорошая база не гарантирует идеальный ответ
Ошибиться может не только модель. Неверное значение бывает записано в самом источнике. Поиск может выбрать материал о другой услуге. Вопрос клиента может допускать два толкования. Наконец, правило компании бывает сформулировано настолько расплывчато, что люди понимают его по-разному.
Поэтому полезно различать причины:
- факта нет вообще;
- факт устарел;
- источники противоречат друг другу;
- выбран не тот фрагмент;
- условие относится к другой позиции или региону;
- модель неверно поняла найденный текст;
- бизнес-правило не определяет однозначного действия.
Если бот назвал старую цену из официального прайса, бесполезно только переписывать его ответ. Нужно убрать старый прайс или изменить приоритет источников. Если система не различает два похожих товара, потребуется исправить структуру каталога и тесты.
База знаний снижает риск, но работает только вместе с ограничениями, журналом диалогов и проверкой реальных сценариев.
Что делать, когда ответа нет
Отсутствие данных — нормальная ситуация, а не авария. Новые вопросы всё равно появятся после запуска. Важно заранее решить, как система на них реагирует.
Допустимый ответ может выглядеть так:
В базе нет подтверждённого срока для этой комплектации. Могу уточнить параметры и передать запрос специалисту.
В этом сообщении нет красивой импровизации, зато есть честная граница и следующий шаг. В зависимости от ситуации бот может задать уточнение, предложить связаться с менеджером или зафиксировать вопрос как пробел в знаниях.
Опасный вариант — взять отраслевую норму и представить её правилом компании: «Обычно это занимает неделю, значит и у нас так». Для клиента слово «обычно» часто звучит как обещание, особенно если его произносит официальный бот.
Повторяющиеся вопросы без ответа полезно собирать. Но автоматически добавлять в рабочую базу слова клиентов или черновики модели нельзя. Сначала человек проверяет факт, выбирает формулировку и только затем публикует обновление.
Актуальность — это отдельный процесс
Базу знаний нельзя один раз подготовить и забыть. Компания меняет ассортимент, цены, географию работы и правила. Даже номер телефона способен превратиться в источник десятков неправильных ответов, если его никто не обновил.
У каждого типа данных должен быть владелец. Коммерческий отдел отвечает за прайс, производство — за сроки, логистика — за доставку, сервис — за гарантийные условия. Технический специалист может внести изменение, но не должен сам решать, какое коммерческое правило правильное.
Частота обновления зависит не от календаря, а от событий. Изменился прайс — обновляется источник цен и связанные тесты. Закончилась акция — её условия перестают попадать в ответы. Появился новый регион — проверяются ограничения доставки и передачи менеджеру.
Полезно хранить дату актуальности и источник важных сведений. Тогда при споре видно, откуда бот взял ответ и кто должен подтвердить новую версию.
Как проверить базу до запуска
Чтения документов недостаточно. Нужно посмотреть, что происходит в разговоре. Один факт следует спросить несколькими способами: прямо, разговорно, с опечаткой, вместе с другим условием и после смены темы.
Обязательные проверки включают:
- существующий и несуществующий товар;
- актуальную и старую цену;
- вопрос без ответа;
- противоречивые сведения;
- неполную формулировку;
- просьбу «скажите хотя бы примерно»;
- неподдерживаемый регион;
- ситуацию, где должен подключиться менеджер;
- длинный диалог с исправлением параметров.
Оценивают не только факт. Ответ должен относиться к нужной позиции, учитывать условия и не добавлять лишних обещаний. Корректный отказ или уточнение тоже считаются успешным поведением.
После исправления сценарий запускают снова. Желательно проверить и соседние вопросы: изменение одного правила иногда меняет ответы в неожиданном месте.
Как база знаний используется в LEVBOT
LEVBOT позволяет настроить персонального бота на сведениях и правилах конкретного бизнеса. Данные, ограничения и ответы можно бесплатно проверять в тестовых диалогах и корректировать до получения готовой сборки.
Настройка и тестовые диалоги остаются бесплатными. Оплата нужна только при скачивании готовой настроенной сборки: одно скачивание стоит 6 000 ₽. Обязательной подписки LEVBOT, внутреннего баланса и оплаты токенов через сервис нет.
Сервер, домен и использование внешней языковой модели оплачиваются отдельно. CRM, каталоги, учётные системы и другие интеграции не подключаются автоматически: они являются отдельными техническими задачами и при необходимости оплачиваются отдельно.
Готовая сборка передаётся покупателю. Новая отдельно настроенная сборка считается отдельной покупкой. При этом ответственность за актуальность исходных сведений всё равно остаётся у бизнеса: никакая модель не может сама определить, какой из двух противоречащих прайсов является действующим.