AI-чат-бот с обучением на инструкциях компании: как это работает

Когда клиент просит сделать AI чат-бот с обучением на инструкциях компании, обычно имеет в виду одно: бот должен отвечать не общими фразами из интернета, а по регламентам, прайсам и скриптам продаж именно этой компании. За два года интеграций через Claude API и OpenAI я собрал десятки таких ботов - для интернет-магазинов на WooCommerce, для служб поддержки на Tilda, для отделов продаж в Telegram. Расскажу, как это устроено технически и на что реально стоит рассчитывать по срокам и деньгам.

Что значит “обучение” чат-бота на инструкциях компании

Тут сразу разочарую тех, кто ждёт дообучения нейросети в классическом смысле - с изменением весов модели. Для 95% бизнес-задач это не нужно и не выгодно: файн-тюнинг GPT или Claude требует тысяч примеров диалогов, недель работы и десятков тысяч долларов на инфраструктуру. На практике “обучение” бота на регламентах компании - это RAG (Retrieval-Augmented Generation): модель не хранит инструкции в себе, а на каждый вопрос клиента подтягивает релевантные фрагменты из базы знаний и формирует ответ с их учётом.

Схема простая: вопрос пользователя превращается в embedding (числовой вектор), система ищет в векторной базе (Pinecone, Qdrant, pgvector) наиболее похожие по смыслу куски документации, эти куски вместе с вопросом отправляются в промпт модели, и она формулирует ответ строго на основе найденного контекста. Я обычно ограничиваю модель системным промптом типа “отвечай только на основе предоставленных материалов, если информации нет - скажи об этом прямо” - это отсекает выдумывание фактов, которое иначе случается у любой LLM.

База знаний: из чего собирать инструкции для ИИ-помощника

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

• Регламенты и скрипты продаж - документы, которыми пользуются живые операторы
• FAQ из тикетов поддержки за последние 6-12 месяцев (лучший источник реальных формулировок вопросов)
• Прайс-листы и описания услуг/товаров
• Политики возврата, доставки, гарантий
• Карточки товаров из CRM или каталога сайта

Важный момент, который клиенты почти всегда упускают: документы нужно нарезать на смысловые фрагменты по 300-800 токенов, а не заливать целиком. Если в базу попадает договор на 40 страниц одним куском, поиск по эмбеддингам находит его целиком по любому запросу, и модель захлёбывается контекстом. Я делю материалы по разделам, добавляю метаданные (категория, дата обновления, товарная группа) - это даёт фильтрацию перед поиском и сокращает количество нерелевантных попаданий процентов на 30-40 по моим замерам на прошлых проектах.

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

Технологии под капотом: embeddings, векторные базы, LLM

Стек, который я собираю чаще всего:

• Модель для генерации ответов - Claude API (Sonnet для баланса цены и качества, Haiku для простых FAQ-ботов с высокой нагрузкой) или GPT-4o/GPT-4o-mini от OpenAI
• Модель для эмбеддингов - text-embedding‑3 от OpenAI или voyage‑3 от Anthropic-совместимых провайдеров
• Векторное хранилище - pgvector, если проект уже на Postgres, или Qdrant для отдельного сервиса с высокой нагрузкой на поиск
• Оркестрация - либо собственный backend на Python/Node, либо n8n, когда клиенту важно самому дорабатывать логику без разработчика

n8n я использую там, где нужна быстрая сборка и прозрачность процесса для нетехнического заказчика: визуальные ноды показывают, как вопрос проходит через поиск по базе, обращение к модели и отправку ответа. Для нагруженных проектов с десятками тысяч диалогов в месяц перехожу на кастомный backend - n8n на такой объём начинает подтормаживать и усложняет мониторинг ошибок.

Отдельно про Telegram-ботов на aiogram: там RAG-логику встраиваю прямо в хендлер сообщений - бот получает текст, идёт в векторную базу, собирает контекст, отправляет в Claude API и возвращает ответ пользователю. Разница с обычным Telegram-ботом на сценариях (кнопки, меню) в том, что клиент может задать вопрос свободным текстом, и бот поймёт смысл, а не будет ждать точного совпадения с командой.

Интеграция с реальными системами: CRM, сайт, мессенджеры

Сам чат-бот с базой знаний редко живёт изолированно - почти всегда нужна связка с существующей инфраструктурой:

Сайты на Tilda и WordPress/WooCommerce

На Tilda подключаю бота через кастомный JS-виджет в футере сайта, который открывает окно чата и общается с backend через API. Для WooCommerce делаю плагин или скрипт, который дополнительно даёт боту доступ к статусам заказов клиента - тогда бот не просто отвечает “где мой заказ” по FAQ, а реально смотрит номер заказа в базе и говорит актуальный статус. Готовые заготовки для похожих интеграций (виджеты чата, скрипты для Tilda) можно посмотреть в библиотеке готовых скриптов - часть логики оттуда я адаптирую под конкретный проект вместо разработки с нуля.

Доставка и оплата

Если бот должен отвечать на вопросы про доставку, подключаю СДЭК API, чтобы он считал стоимость и сроки по реальным тарифам, а не выдавал усреднённые цифры из документа. Для интернет-магазинов с оплатой через Т‑Банк бот может подсказывать статус платежа или ссылку на повторную оплату, если запрос пришёл через вебхук эквайринга.

CRM и передача на живого оператора

Критичная часть любого продающего бота - понимать границы своей компетенции. Настраиваю триггеры: если вопрос выходит за пределы найденного контекста в базе знаний или клиент прямо просит человека, бот создаёт задачу в CRM (Bitrix24, amoCRM) и передаёт диалог оператору с кратким саммари переписки. Без этого механизма бот либо зависает в цикле извинений, либо начинает придумывать ответы - и то и другое портит впечатление от компании быстрее, чем просто отсутствие бота.

Сколько стоит и сколько занимает внедрение

Цена и сроки сильно зависят от объёма базы знаний и количества интеграций. По моей практике это выглядит так:

На рынке за похожие проекты студии и агентства часто просят заметно больше - там в смету закладывают менеджмент проекта и слои согласований, которых у меня как у частного разработчика просто нет. Ежемесячные расходы на API токены отдельно от разработки - обычно от 2 000 до 15 000 ₽ в месяц в зависимости от количества диалогов, это оплата напрямую провайдеру модели, не мне.

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

Частые ошибки при обучении бота на документах компании

За несколько проектов я вывел список повторяющихся проблем, которые убивают качество ответов:

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

Ещё отдельно скажу про безопасность: если база знаний содержит внутренние данные компании (условия для VIP-клиентов, себестоимость, персональные данные), нужно явно фильтровать, что попадает в контекст публичного бота. Я разделяю базу на “публичную” и “внутреннюю” части и даю клиентскому боту доступ только к первой - это снимает риск, что через хитро сформулированный вопрос пользователь вытащит из бота конфиденциальные цифры.

Частые вопросы

Можно ли обучить чат-бота на документах компании без программиста

Частично да - сервисы типа n8n или готовые no-code платформы позволяют загрузить документы и настроить базовый RAG-пайплайн без кода. Но интеграция с CRM, эквайрингом, кастомная логика передачи на оператора и тонкая настройка качества поиска обычно требуют разработчика, иначе бот выдаёт нестабильные результаты на реальном потоке вопросов.

Сколько документов нужно для базы знаний, чтобы бот отвечал качественно

Я запускал ботов с базой в 15-20 документов (для узкой тематики поддержки) и с базой в несколько сотен карточек товаров. Дело не в количестве, а в структуре: 20 хорошо размеченных документов работают лучше 500 хаотично залитых файлов. Для старта достаточно собрать основные регламенты, FAQ и прайс - остальное можно добавлять по ходу работы, глядя на логи реальных вопросов.

Чем RAG-бот отличается от обычного чат-бота с кнопками

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

Насколько безопасно доверять AI-боту ответы клиентам без модерации

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