Почему бот не отвечает по базе знаний — и что с этим делать
·11 мин чтения
Почему бот не отвечает по базе знаний, хотя материалы загружены?
Коротко: почти всегда дело не в модели, а в данных — они либо не дошли до бота, либо лежат в виде, из которого ответ не извлекается, либо ответа там нет вовсе.
Самая частая жалоба звучит так: «Мы загрузили материалы, а бот всё равно отвечает ерунду». Дальше обычно следует вывод, что «ИИ не работает» или «нам продали плохого бота». Оба вывода преждевременны, потому что за одним и тем же симптомом стоят пять разных причин, и лечатся они по-разному.
Важно понять механику. ИИ-консультант не «знает» вашу компанию. Он не хранит в себе прайс и не помнит условия доставки. Он получает вопрос, ищет в ваших материалах фрагменты, из которых можно собрать ответ, и формулирует ответ по ним. Если подходящих фрагментов не нашлось, возможны только два исхода: он честно скажет, что не знает, либо — что хуже — достроит ответ общими словами. Второе и выглядит как «отвечает ерунду».
Отсюда первое практическое правило диагностики: не спрашивайте «что не так с моделью», спрашивайте «что бот видит по этому вопросу». Дальше в статье — пять причин по порядку, от самой частой, и что с каждой делать.
И одно замечание, почему это вообще стоит разбирать, а не списывать на плохой инструмент. По сводке MIT (проект NANDA, август 2025 года) около 95 % пилотных проектов генеративного ИИ не дают измеримого эффекта на финансовый результат — разбор Fortune, 18.08.2025. Первоисточник читался через разбор, поэтому приводим это как ориентир. Смысл цифры не в том, что технология бесполезна, а в том, что проекты разваливаются на данных и процессе, а не на модели. Gartner в июне 2025 года оценивал, что более 40 % проектов на агентном ИИ будут закрыты до конца 2027 года из-за растущих затрат и неясной бизнес-ценности — сводка прогнозов Gartner, Maven AGI, 2026. Тот же вывод: проблема не в ответе модели, а в том, чем её накормили.
Что значит «данные не загружены» и как это проверить?
Коротко: это когда нужный документ физически не попал в базу — на сайт загрузили страницы, а прайс живёт в таблице, условия — в PDF, а сроки знает только начальник производства.
Проверяется это за один вечер и без всякого ИИ. Возьмите тридцать последних обращений клиентов и выпишите вопросы, которые в них звучали. Затем по каждому вопросу честно ответьте на один вопрос: существует ли письменный ответ, и лежит ли он там, откуда бот его возьмёт?
Результат обычно выглядит так. Страницы сайта в базе есть, а актуальный прайс — нет, потому что он в Excel. Условия доставки — есть, но на странице, которую убрали из меню год назад. Сроки изготовления — не существуют нигде, кроме головы начальника производства. Про гарантию написан абзац, из которого непонятно, что именно покрывается.
Отдельно проверьте самое неприятное: не противоречат ли каналы друг другу. Если на сайте одна цена, в переписке менеджеры называют другую, а в договоре прописана третья — бот не виноват, что он запутался.
Практический вывод простой: база знаний — это не «сайт целиком». Это отобранный список того, на что консультант имеет право отвечать, с актуальными значениями. Если такого списка нет, его нужно составить — и он понадобится даже без всякого ИИ.
Что значит «данные не структурированы»?
Коротко: файл загружен, но это скан, фотография, многотомный документ без заголовков или таблица без подписей — из такого куска модель не может собрать точный ответ.
Загрузить файл и сделать данные пригодными — две разные операции. Во втором случае нужна работа, которую никто за вас не сделает автоматически.
Вот что чаще всего мешает:
Файл-картинка или скан. Текст на скане может распознаваться с ошибками, а таблица с ценами — превращаться в нечитаемую кашу. Ответ вроде бы есть, но достать его нельзя.
Один документ на сто страниц. Если весь регламент лежит единым текстом, нужный абзац тонет в остальном. Материалы лучше разбивать на небольшие смысловые блоки: один блок — один вопрос и один ответ.
Таблица без заголовков. Столбец с числами без названия бесполезен: непонятно, это цена в рублях, срок в днях или процент скидки.
Материал с противоречиями внутри себя. Когда в одном файле две версии условий, бот выберет любую.
Есть и самый частый вариант — «залили весь сайт». Вместе со страницами услуг в базу попадают новости полугодовой давности, страница с прошлогодней акцией и старый каталог. Бот послушно отвечает текстом старой новости. Подробнее про то, где чат-бот полезен, а где приносит вред, мы разбирали в отдельной статье.
Почему бот не узнаёт вопрос, заданный другими словами?
Коротко: поиск идёт по смыслу, а не по точному совпадению слов, и если у вас ответ сформулирован канцелярски, а клиент пишет разговорно, совпадение может не найтись.
Это самая недооценённая причина. Люди пишут не так, как пишут на сайтах.
Клиент пишет: «а доставка входит?». В базе лежит: «Стоимость доставки рассчитывается индивидуально согласно тарифам перевозчика». Смысл один, формулировки разные. Хорошая система это сопоставит, но чем дальше друг от друга живут формулировки, тем выше шанс промаха.
Другой пример: «есть в наличии?» против «уточните наличие на складе». Или «даёте гарантию?» против «гарантийные обязательства регулируются разделом 7 договора».
Что с этим делать практически:
собрать реальные формулировки клиентов — из переписки, почты, звонков — и добавить их в базу рядом с официальным ответом;
для каждого частого вопроса прописать два-три варианта, которыми его задают;
убрать из ответов канцелярит, который ничего не сообщает: «в индивидуальном порядке», «согласно регламенту», «уточняйте у менеджера».
Последний пункт полезен и сам по себе: если ответ невозможно понять человеку, его не стоит давать и боту.
Что делать, если ответа в материалах просто нет?
Коротко: признать это пробелом, научить бота передавать такой вопрос человеку и дописать ответ — а не пытаться закрыть дыру «общими знаниями модели».
Это единственная причина из пяти, которая не лечится настройкой. Ответа нет — значит, его нет.
Правильное поведение консультанта в такой ситуации: не выдумывать, а честно сказать, что уточнит у специалиста, и передать разговор человеку вместе с контекстом. Это не «плохо работающий бот» — это корректная работа. Плохо, когда он вместо этого называет срок, которого никто не подтверждал, или цену, которой нет в прайсе.
Дальше начинается работа, которую стоит сделать независимо от автоматизации. Выпишите вопросы, на которые в компании нет письменного ответа, и назначьте того, кто его напишет. Обычно это те же пять-семь тем: сроки, гарантия, возврат, условия работы с юридическими лицами, доставка в другой регион.
И отдельно — про ожидание, что «бот ускорит работу, и станет легче». Японское исследование Persol Research Institute (2026, национальная выборка) — FNN, 03.02.2026 — показало, что генеративный ИИ ускоряет отдельные задачи в среднем на 16,7 %, но рабочее время реально сократилось лишь примерно у 25,4 % пользователей, а 61,2 % высвобожденного времени вернулось в работу, и в основном в текущую рутину. Вывод для нашей темы: сам по себе инструмент не создаёт порядок в материалах. Если ответа нет, скорость ответа его не создаст.
Что делать, если в базе две конфликтующие версии?
Коротко: убрать дубли и назначить один актуальный источник — иначе бот будет выбирать версию случайно, а клиент цитировать ту, которая ему выгоднее.
Это самая дорогая ошибка из пяти, потому что она приводит не к неловкости, а к конфликту.
Типичная картина. На сайте страница с ценами, которую обновили в марте. Рядом — таблица прайса, которую обновили в июле. В базе знаний оказались обе. Бот отвечает то по одной, то по другой — в зависимости от того, как сформулирован вопрос. Клиент получает цену, приходит оформлять заказ, и выясняется, что она старая.
Формально прав клиент: ему так сказали. И компании приходится либо держать названную цену, либо объяснять, почему её слова расходятся с делом. Оба варианта дороже, чем навести порядок в материалах.
Что делать:
свести дубли. Выбрать одну актуальную версию каждого факта, остальные удалить из базы, а не «оставить на всякий случай»;
назначить владельца данных. Один человек, который отвечает за актуальность цен и условий. Без него база устареет за месяц-два — это не вопрос технологии, а вопрос ответственности;
зафиксировать дату. Если цена действует с определённого числа, это стоит написать прямо, чтобы устаревшая версия не гуляла по документам;
проверить, что говорят менеджеры. Если база говорит одно, а менеджеры другое, проблема не в базе.
Коротко: задать консультанту 30–50 реальных вопросов клиентов и сверить ответы с утверждёнными формулировками — до того, как он ответит первому живому посетителю.
Проверка занимает один вечер, но экономит репутацию. Порядок такой.
Шаг 1. Соберите вопросы. Тридцать–пятьдесят последних реальных обращений, как есть, живыми формулировками — включая неудобные и с ошибками. Не придумывайте вопросы сами: придумаете вы то, на что у вас уже есть ответы.
Шаг 2. Разделите их на две группы. Те, на которые консультант должен отвечать сам, и те, которые он обязан передать человеку: торг, нестандартная комплектация, жалоба, юридический вопрос.
Шаг 3. Проверьте ответы по четырём критериям. Точен ли ответ (совпадает с утверждённым), полон ли (не потерял важное условие), понятен ли человеку, и — самое важное — правильно ли он уходит к человеку там, где должен уходить.
Шаг 4. Отдельно проверьте отрицательные случаи. Спросите то, чего в базе нет. Спросите про конкурента. Напишите раздражённо. Консультант обязан не выдумывать и не спорить.
Шаг 5. Прочитайте логи после запуска. Первые две недели диалоги читают вручную. Спорные случаи находятся именно там, а не в тестах: тесты вы придумали сами, а люди пишут иначе.
Если на этом этапе выяснилось, что половина ответов неверна, — это хорошая новость. Вы нашли это до клиента, а не после.
Как вести список пробелов после запуска?
Коротко: раз в неделю читать диалоги и записывать каждый вопрос без ответа в отдельный список — это и есть план развития базы знаний на месяцы вперёд.
База знаний не бывает законченной. Она либо обновляется, либо устаревает, и второе происходит быстрее, чем кажется.
Практика, которая работает, выглядит так:
Журнал пробелов. Один документ, куда попадает каждый вопрос, на который консультант не смог ответить или передал человеку. Не «улучшить бота», а конкретно: какой вопрос, когда, чем закончилось.
Разбор раз в неделю. Полчаса. Смотрите частоту: если один и тот же вопрос встретился пять раз — он в начало списка независимо от того, кажется он важным или нет.
Ответы пишет тот, кто знает. Не «маркетинг придумает формулировку», а тот, кто отвечает за факт: цену подтверждает коммерческий отдел, сроки — производство.
Одна метрика. Доля обращений, которые консультант закрыл сам, без передачи человеку. Если она не растёт от недели к неделе — база не пополняется, и тогда всё остальное бессмысленно.
Список пробелов полезен и сам по себе. Он показывает, каких ответов нет в компании, — а это знание стоит дороже, чем любой бот. Клиент, который не получил ответа, не обязательно ушёл к конкуренту из-за бота; часто он ушёл потому, что ответа не существует ни у кого.
И последнее, про порядок работ. Сначала материалы, потом инструмент. Если у вас нет письменных ответов, ни один консультант их не создаст — он может только быстрее показать, что ответа нет. Про то, как скорость первого ответа влияет на судьбу обращения, мы подробно разбирали в статье про первую минуту, а про сравнение живого оператора и бота — в материале что дешевле: бот или живой оператор.
FAQ
«Бот отвечает не то, что написано в базе. Почему?»
Почти всегда потому, что в базе лежит несколько версий одного факта, либо рядом с ответом находится посторонний текст, который модель использует как источник. Проверьте по конкретному вопросу: что именно бот видит. Часто выясняется, что актуальный ответ есть, но не в том документе, который он выбрал.
«Мы загрузили весь сайт — этого достаточно?»
Нет. Сайт — это витрина, а не справочник: там есть новости, акции, устаревшие страницы. Из такого набора бот отвечает тем, что попалось. Нужен отобранный список фактов, на которые консультант имеет право отвечать, и этот список почти всегда меньше сайта.
«Можно ли просто поставить более умную модель?»
Если ответа в материалах нет или лежит он в нечитаемом виде, более сильная модель не поможет — она будет так же уверенно выдумывать. Смена модели помогает в другом: лучше понимает формулировки и аккуратнее сопоставляет смыслы. Это причина номер три из пяти, а не первая.
«Сколько вопросов должно быть в базе?»
Столько, сколько реально задают клиенты. Ориентир — покрыть большинство типовых обращений за последний месяц; на практике это несколько десятков вопросов, а не сотни. База из тысячи страниц, из которых бот не может достать ответ, хуже базы из пятидесяти аккуратных.
«Кто должен вести базу знаний?»
Один назначенный человек. Не «все вместе» и не «когда будет время». Его задача — следить за актуальностью фактов и вести журнал пробелов. Если владельца нет, база устаревает за месяц-два, и это самая частая причина, по которой проекты разваливаются.
«Бот не находит ответ на важный вопрос. Что делать?»
Сначала проверьте, существует ли ответ в письменном виде вообще. Если нет — его нужно написать, и это работа независимо от автоматизации. Если да — проверьте, в каком виде он лежит: скан, единый документ на сто страниц и таблица без заголовков остаются самыми частыми причинами.
Что вы можете сделать прямо сейчас, не покупая ничего: выписать тридцать последних вопросов клиентов и отметить, на какие из них в компании есть письменный ответ, а на какие нет. Второй список — это и есть ваш план работы с базой знаний.
Получить демо на своём сайте — пришлём ссылку на консультанта, обученного по материалам вашего сайта. Задайте ему свои самые неудобные вопросы и посмотрите, где он отвечает по делу, а где честно передаёт разговор человеку.
Павел Гмир, основатель LeanAgent. Пишу о том, как компании теряют заявки на скорости ответа и что из этого реально исправить. Обсудить можно в TenChat или в Telegram.
ПГ
Павел Гмир, основатель LeanAgent
Пятнадцать лет в производстве и операционном управлении, в том числе в японской компании. Пишу о том, как бизнес теряет заявки на скорости ответа и что из этого реально исправить.