Один из первых вопросов, который я слышу при обсуждении ИИ-ассистента: «а если он наговорит клиенту лишнего?»
Вопрос обоснованный. Языковая модель продолжает текст правдоподобно, а не сверяется с фактами. Если нужного факта в её распоряжении нет, она всё равно может сформулировать правдоподобный ответ — и звучать он будет уверенно. Именно это и приходится учитывать при сборке.
Выбор модели сам по себе задачу не решает. Основа — две вещи: утверждённый материал, на который ассистент опирается, и понятная граница поведения, когда ответа в нём нет. Ниже — из чего собирается первое, как задаётся второе и что проверить перед запуском.
Что такое база знаний для чат-бота
Чат-бот с базой знаний — это не «загрузили сайт в нейросеть». Это короткий утверждённый набор фактов, из которых ассистент строит ответы: что вы делаете, что входит в стоимость, что считается отдельно, от чего цена растёт, за какие сроки, какие есть примеры работ.
Ключевое слово — утверждённый. Всё, что там лежит, вы прочитали и подтвердили.
И сразу оговорка, без которой остальное читается неправильно: база знаний не делает выдуманный ответ невозможным. Хорошо собранное решение не должно позволять ассистенту спокойно додумывать недостающий факт — при нехватке данных он уточняет вопрос, честно отказывается или передаёт разговор человеку. Это снижает риск и делает поведение предсказуемым, а не отменяет саму природу модели.
Шесть блоков
Первые пять — это материал. Шестой — правила, и технически он живёт не там же, но готовить его надо вместе с остальными.
1. Цены и тарифы. Главное требование не к содержанию, а к источнику: он должен быть один. У меня цены попадают в базу знаний из того же файла, из которого печатаются на страницах сайта, — руками в текст для модели они не вписываются вообще. Иначе появляется риск, что бот и сайт начнут показывать разные суммы, — и заметит это клиент, а не вы.
2. Что входит в стоимость и что считается отдельно. Этот блок обычно приходится собирать отдельно: целиком его может не оказаться ни на одной вашей странице. Собран он должен быть явно — «в базовую стоимость входит вот это, отдельно считается вот то». Без него ассистент создаёт ложные ожидания вежливым тоном, а разбираться с ними придётся менеджеру.
3. От чего цена растёт. Список факторов: число ролей, каналов, интеграций, объём каталога, сложность дизайна. Это позволяет отвечать «зависит от» осмысленно, а не отделываться фразой «рассчитывается индивидуально». Человек, который слышит, от чего зависит цена, может сам прикинуть, в какую сторону его случай.
4. Сроки. По направлениям, теми же словами, что на сайте. Именно теми же: если страница говорит «1–2 недели, если контент готов», а ассистент — «около недели», вы получите спор на ровном месте.
5. Примеры работ. Два-три близких по механике, и здесь у меня есть правило, которое стоит объяснить. Для публичного консультанта на сайте: он не должен раскрывать о клиентах и проектах больше, чем вы готовы опубликовать для любого посетителя. У меня в базе примеры описаны ровно так же, как на главной, — без цифр результата, которых нет на публичных страницах. Для внутреннего ассистента с авторизацией правило другое, но там и доступ к данным другой. С цифрами он звучал бы весомее ровно до первого вопроса «а можно подробнее?».
6. Правила ответов и границы. Что нельзя называть (у меня это точная цена и точный срок — только предварительный диапазон с оговоркой), на какие страницы можно ссылаться, что делать при нехватке данных. Технически это часть настройки, а не базы, но пункт того же разговора: одного материала мало, модель должна ещё понимать, что делать, когда ответа в нём нет.
Откуда брать материал
Со своих страниц. Это звучит скучно, но у правила есть причина: клиент читает те же страницы глазами, и расхождение между сайтом и ассистентом он заметит мгновенно. У меня в файле базы знаний источник указан прямо у каждого направления — с какой страницы взято.
А вот с чего я бы не начинал — с автоматической загрузки всего сайта. Вместе с полезными фактами туда легко попадут дубли, старые формулировки и тексты, которые писались для поиска, а не как правила для консультанта. Порядок я предпочитаю обратный: сначала короткий утверждённый набор фактов, а потом уже решать, какие источники подключать дополнительно.
Отдельно про объём: моя база знаний — несколько страниц текста, а не том. Против вас работает не полнота, а неуправляемый объём: чем больше материала свалено в одно место без владельца и версии, тем выше шанс, что внутри найдутся два утверждения, противоречащих друг другу, — и ассистент выберет то, которое вам не понравится.
Почему в модель уезжает не вся база
Это техническая деталь, но она объясняет, почему объём вообще важен.
Кэш промпта есть не у всех провайдеров. Там, где его нет, всё отправленное вместе с вопросом оплачивается заново на каждом сообщении диалога — а не один раз за диалог. Поэтому в запрос идёт не вся база, а срез — только то, что нужно на текущем шаге разговора. Человек спрашивает про сайты — уезжают тарифы сайтов, а не приложений.
Экономия тут прямая. Плюс в промпте остаётся меньше постороннего материала, на который модель могла бы опереться.
Почему в моём ассистенте пока нет векторного поиска
Стандартный ответ на вопрос «как создать ИИ-агента» звучит так: векторная база, индексация, поиск по смысловой близости. Для больших и разнородных данных это рабочий подход. В моём случае он пока не понадобился, и объяснение простое.
База небольшая и уже разбита по направлению и этапу разговора. Код заранее знает, какой набор фактов нужен сейчас: человек выбирает формат сайта — уезжают тарифы сайтов. Отдельный слой поиска в такой схеме заметной задачи не решает, но добавляет ещё одну систему, которую надо настраивать, обновлять и тестировать.
Если база вырастет до большого каталога, документации или множества разнородных документов, к поиску имеет смысл вернуться. Точный порог зависит не только от объёма, но и от структуры данных и сценария работы. Практический вывод для разговора с подрядчиком: если вам предлагают такой слой поверх трёх страниц фактов, спросите, что именно он собирается индексировать и какую задачу это закрывает.
Пять проверок на приёмке
База собрана, ассистент запущен. Прежде чем показывать чат-бот с базой знаний клиентам, задайте ему пять вопросов сами.
- То, чего в базе точно нет. «Вы работаете по субботам?», если этого нигде не написано. Хороший результат — ассистент признаёт, что данных нет, и предлагает следующий шаг. Плохой — уверенно придумывает ответ.
- Точную цену по неполным вводным. Если у вас услуга с индивидуальным расчётом, спросите «сколько будет стоить именно мой случай?». Правильное поведение — диапазон с оговоркой или объяснение, каких данных не хватает. Сумма, названная до разбора, — это ваше обязательство. (У магазина с фиксированными ценниками проверка обратная: цена товара должна называться точно.)
- Ссылку. Попросите отправить страницу с условиями. Адрес должен открываться. Придуманная ссылка выглядит для клиента как обман, а не как сбой.
- Услугу, которой у вас нет. «А вы делаете вот такое?» Отказ — правильный ответ. Готовность взяться — повод остановить запуск.
- Одно и то же разными словами. Задайте один вопрос тремя формулировками. Ответы не обязаны совпадать дословно, но противоречить друг другу они не должны. Если противоречат — надо разбираться: либо в базе лежат конфликтующие данные, либо система по-разному выбирает материал для одного и того же вопроса.
Эти пять проверок стоит повторять после каждого заметного обновления базы: противоречия появляются именно при пополнении. Для базы, которая меняется часто, можно начать с ежемесячной проверки и дальше подобрать частоту по числу изменений.
База знаний устаревает
Про это думают в последнюю очередь — а зря. Ассистент, который в июне отвечал точно, в декабре начинает уверенно отвечать устаревшими данными — не потому, что модель испортилась, а потому, что поменялись цены, ушла услуга, появилось новое условие, а в базе всё по-старому.
Причём выглядит это хуже, чем незнание. На вопрос «сколько стоит» он уверенно называет прошлогодний диапазон — и человек приходит к менеджеру с этой цифрой в голове.
Поэтому у обновления должен быть хозяин и повод. Хозяин — конкретный человек, а не «мы». Повод — событие, а не календарь: поменяли цену, добавили услугу, изменили условия доставки. Плюс стоит периодически просматривать реальные диалоги, особенно после изменений в услугах и ценах: вопросы, на которые ассистент отвечал уклончиво, — это и есть список того, чего в базе не хватает. Частоту разумно привязать к тому, как часто меняется сам бизнес.
Кто это готовит
Честный ответ: это работа заказчика, которую подрядчик может организовать, но не может сделать за него. Цены, состав, условия, исключения — всё это знаете вы.
Хорошая новость в том, что для небольшой сервисной компании исходный материал обычно уже существует: он лежит на сайте, в прайсе, в скриптах менеджеров и в переписке. Основная работа не в том, чтобы придумать его заново, а в том, чтобы свести в одну согласованную структуру.
Плохая — блок «что входит и что отдельно», скорее всего, придётся писать заново: целиком он записан не везде. У меня было так же.
Что дальше происходит с этой базой, сколько стоит внедрение и где ИИ ошибается даже с хорошей базой — я разбирал в статье про чат-бота для сайта. Чем мы занимаемся в части ИИ помимо ассистентов — на странице ИИ-решений для бизнеса.
Заберите структуру
Я собрал шесть блоков в одностраничный рабочий лист: поля под каждый блок, чек-лист источников (откуда что брать) и те же пять приёмочных проверок, чтобы их можно было пройти по списку.
Оставьте задачу в форме ниже — пришлю лист вместе с разбором. Если удобнее в мессенджере, напишите слово «база» в Telegram или Max, контакты в подвале сайта.
А если заполните и пришлёте обратно, скажу, чего в листе не хватает и какие вопросы я бы обязательно проверил на таком наборе данных.