Как мы сделали AI-навигатор на сайте INSAL и быстро поняли, что без базы знаний он не поедет (7 серия)

Так мы в CompanionAI собрали на сайте INSAL первый публичный AI-слой. Не ради модного слова и не ради красивого виджета в углу экрана. Задача была практической: помочь человеку сориентироваться, определить его сценарий, дать предварительный расчет и не потерять его между страницами, услугами и формами.

На старте это работало. Но очень быстро вскрылось главное: без накопленных знаний компании даже хороший бот остается красивой оболочкой. Именно этот этап и привел нас к базе знаний.

Когда стало ясно, что сайту нужен не только контент, но и быстрый вход в диалог

После переезда сайта на Wagtail управлять структурой, страницами и контентом стало заметно проще. Но довольно быстро стало видно: одного “хорошего сайта” недостаточно.

Сайт может быть логичным. Статьи могут быть полезными. Услуги могут быть описаны нормально. Но человек все равно приходит с коротким и очень бытовым запросом: “Мне что вообще нужно?”, “Это про меня или нет?”, “Сколько это примерно стоит?”, “Куда нажать, чтобы не ошибиться?”

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

Так и появилась идея сделать на сайте не просто еще один раздел, а быстрый вход в разговор.

Почему мы разделили аудиторию INSAL на два главных сценария

На тот момент основная аудитория INSAL делилась довольно ясно на две большие группы.

Первая — те, кому нужна доставка из Китая.
Вторая — те, кому нужны услуги фулфилмента.

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

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

Как мы в CompanionAI собрали AI-контур для сайта INSAL

В основе был базовый менеджер. Он встречал посетителя, коротко объяснял, чем занимается INSAL, подсказывал, что можно почитать, помогал сориентироваться и принимал заявку с отправкой в CRM.

Дальше подключались два профильных сценария.

Один — по доставке.
Второй — по фулфилменту.

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

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

Почему каждый сценарий получил свой инструмент, а не просто набор ответов

На одних ответах такой слой быстро бы уперся в потолок. Поэтому у профильных сценариев были свои прикладные инструменты.

Для доставки был подключен калькулятор расчета из CRM.
Для фулфилмента — свой расчетный инструмент.

Все расчеты были предварительными и не считались офертой. Это важно. Мы не пытались подменить живую коммерческую работу компании автоматом. Но дать человеку быстрый ориентир — да, это было полезно.

Именно здесь AI-слой переставал быть декоративным. Он не просто разговаривал, а помогал сделать следующий шаг.

Почему безопасность пришлось закладывать сразу

Чатовая панель была открыта для всех посетителей сайта.

А значит, не только для тех, кто реально хотел услугу. Всегда находятся и те, кто приходит поиграться, проверить границы, вывести систему в бессмысленный диалог или попробовать ее сломать. У открытого AI это не побочный эффект. Это нормальная часть жизни.

Поэтому безопасность пришлось закладывать сразу.

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

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

Что работало на старте, а что быстро уперлось в потолок

На старте все выглядело вполне рабочим.

• Роутинг работал.
• Разговор был бесшовным.
• Предварительные расчеты давали пользу.
• Человек быстрее попадал в нужный сценарий.

То есть сама схема не развалилась.

Но довольно быстро вскрылся ее потолок. У ботов катастрофически не хватало реальных знаний компании.

• Да, у них были промпты.
• Да, были системные инструкции.
• Да, была логика диалога и переключения.
• Но этого оказалось мало.

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

Где бот начинал буксовать

Самая большая проблема была не в самом диалоге, а в глубине ответа.

Бот мог сориентировать человека по общему сценарию. Мог помочь выбрать направление. Мог дать предварительный расчет. Но как только разговор уходил чуть глубже, начинались пробелы.

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

То есть проблема была не в том, что бот “тупой”. Проблема была в том, что компании самой пока не хватало собранных знаний, на которые он мог бы опираться.

Почему без данных бот бесполезен, даже если у него хорошие промпты

Вот здесь и произошел самый важный поворот.

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

Не станет.

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

Бот без знаний — как машина без топлива. Стоит красиво. Все на нее смотрят. Но не едет.

Именно в этот момент стало ясно, что главный дефицит — не в модели, не в интерфейсе и не в количестве сценариев. Главный дефицит — в данных.

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

Как именно этот этап привел нас к созданию базы знаний

После этого вывод был уже неизбежным.

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

• Услуги.
• Процессы.
• Правила.
• Типовые вопросы.
• Сценарии общения.
• Материалы для клиентов.
• Материалы для команды.

Все это должно было стать не просто контентом, а топливом для следующего уровня AI-логики.

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

Что этот этап дал INSAL

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

Компания получила не просто публичный AI-слой. Она получила очень полезное управленческое понимание: AI не работает в пустоте.

Нельзя заменить знания хорошим промптом.
Нельзя построить полезного помощника только на системных инструкциях.
Нельзя сделать зрелый AI-контур, если компании самой нечем его кормить.

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

А это уже совсем другой уровень зрелости.