База знаний ИИ-консультанта: что загружать и что вредит ответам

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

Эта статья — про содержание базы: что в неё класть, что выбрасывать и как проверить всё это до оплаты. Диагностику «почему бот не отвечает» мы разбирали отдельно — в статье про базу знаний и пять причин; здесь следующий шаг, редакторский.

Коротко: база — это набор фактов, на которые консультант имеет право отвечать. Чем полнее набор, тем больше вопросов закрывается в диалоге; чем больше пробелов, тем чаще разговор заканчивается передачей человеку.

Консультант не «знает» компанию: он получает вопрос, ищет в материалах фрагменты, из которых складывается ответ, и формулирует по ним. Закрытый вопрос чаще заканчивается контактом, пробел — передачей человеку или отказом.

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

Коротко: страницы сайта, прайс и каталог, FAQ и переписка поддержки, инструкции для клиента, договор и оферта, карточки товара. Годится источник, у которого есть владелец, дата и один актуальный вариант.

Страницы сайта. Услуги, доставка, оплата, гарантия, возврат. Годится страница, написанная для клиента и обновляемая.

Прайс и каталог. Цены, характеристики, наличие. Годится, если версия одна: как только рядом появляется «тот же прайс, но в Excel», начинаются расхождения.

FAQ и переписка поддержки. Ценность переписки — в формулировках: так спрашивают люди. Ответы берутся только утверждённые: переписка показывает вопрос, а не истину.

Инструкции для клиента. Как оформить возврат, как получить счёт, куда приехать. Годится инструкция для покупателя, а не внутренний регламент для сотрудников.

Договор и оферта. Источник границ: что компания обязана сделать, а что нет. Полезен как формулировка условий, но не как энциклопедия.

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

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

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

1. Устаревшие цены и условия. Старая акция, прошлогодний прайс, сроки «до конца месяца», который давно прошёл. Опасность не в том, что бот ошибётся, а в том, что он будет прав — по документу.

2. Противоречия между документами. На сайте одна цена, в прайсе другая, в переписке менеджер называет третью. Консультант выберет одну случайно, и это будет лотерея.

3. «Вода». «Индивидуальный подход», «гибкие условия», «широкий ассортимент». Такие фразы не отвечают на вопрос и занимают место там, где должен быть конкретный ответ.

4. Маркетинговые обещания. «Номер один», «быстрее всех». Это не факты, а оценки; в базе знаний они превращаются в обязательства, которые компания не собиралась давать.

5. Внутренние тексты. Регламенты для сотрудников, таблицы с маржой, телефоны, куски переписки с персональными данными. Это не должно попадать в ответ клиенту.

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

Коротко: ответ строится на фрагментах ваших документов, а не на общих знаниях модели. Если факта в материалах нет, бот не достраивает его «по смыслу», а передаёт разговор человеку.

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

Второй элемент — оркестрация нескольких моделей: под разные задачи система выбирает разные модели. Конкретные названия не публикуем: они быстро устаревают.

Третий элемент — границы. Стоп-темы определяют, что консультант не обсуждает вообще: торг, скидки вне прайса, гарантийный спор. На такие темы он передаёт человеку вместе с контекстом. Плюс база обновляется автоматически — по данным сайта и диалогам (заявлено платформой; на клиентских внедрениях мы это не замеряли).

И честная граница. RAG снижает риск выдумки, но не отменяет правило «что положили, то и получили». Если в базе две цены, бот выберет одну — и будет прав по документу. Автообновление подхватывает изменения, но не решает, какая цена верна: это решение остаётся за человеком.

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

Карточки товара живут в каталоге, цены — в Excel у коммерческого отдела, условия доставки — в PDF на сайте, сроки — в переписке менеджеров. Формально материалы есть, фактически ответить нечем: консультанту нужен не десяток источников, а один, где у каждого факта одна версия.

Часть работы берём мы: вытаскиваем цены из таблиц, переносим ключевые факты из PDF в текст, убираем устаревшие версии. По объёму это обсуждается до старта — заранее цены и сроки не называем. От клиента нужна проверка фактов и то, чего нет в документах: актуальные цены, условия, границы.

Ориентир темпа: около двадцати позиций вносится вручную примерно за час. Это пример скорости работы, а не обещание срока.

Коротко: тест на сайте до оплаты с замером «точки А» и «точки Б» — состояния до и после. Платить до проверки не нужно.

Консультант ставится на ваш сайт в тестовом режиме. Сначала фиксируется «точка А» — как обращения обрабатываются сейчас. Потом включается консультант, и через сопоставимый период фиксируется «точка Б». Разница между замерами и есть результат.

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

До теста — демо на 15 минут: его можно провести на ваших материалах. Как устроена приёмка ответов по пунктам — в статье про приёмку чат-бота.

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

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

Нет маршрута на человека — система вреднее тишины. Без маршрута клиент получает неверный срок и строит на нём план.

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

Если обращений единицы, дешевле обрабатывать руками. Если нужен только сбор контактов без разговора — дешевле форма. Если сайта нет, работать не с чем. Если некому подтверждать факты, через месяц-два бот начнёт называть устаревшее — и это хуже, чем его отсутствие.

Нет. Сборка — наша работа: собираем материалы из каталога, прайсов, PDF и переписки, сводим в один источник. От вас нужны доступ к материалам и человек, который подтвердит цену, срок и условия.

Частично: сканы — слабый источник, таблица с ценами в них превращается в кашу. Ключевые факты переносим в текст и сверяем с вами.

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

Да: тест на сайте с замером «точки А» и «точки Б», плюс демо на 15 минут на ваших материалах. Платить до проверки не нужно.

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

Получить демо на своём сайте — консультант будет обучен по материалам именно вашего сайта.

Читайте также: Почему бот не отвечает по базе знаний · Приёмка чат-бота: что проверить перед запуском · Сколько стоит ИИ-консультант · Чат-бот на сайте · Все статьи блога

Павел Гмир, основатель LeanAgent. Пятнадцать лет на производстве, запуск RAV4 на «Тойота СПб», два цеха. Разбираю, как компании теряют обращения на входе в поток. Обсудить можно в Telegram или в TenChat.

Источники: LeanAgent, главная страница: описание продукта, демо и тест на сайте до оплаты — https://leanagent.ru/ · LeanAgent, «Почему бот не отвечает по базе знаний»: механика ответа по материалам — https://leanagent.ru/pochemu-bot-ne-otvechaet-po-baze-znanij · LeanAgent, «Приёмка чат-бота» — https://leanagent.ru/priemka-chat-bota · B24U, описание платформы (заявлено платформой; на клиентских внедрениях не замеряли) — https://b24u.ru/ · Сроки запуска (около часа), длительность демо (15 минут) и темп ручной сборки (около двадцати позиций за час) — данные LeanAgent, подтверждены владельцем 25.10.2026; это наш процесс, а не независимый замер