ИИ-ассистент на сайт с обучением на базе знаний: как устроен

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

Что такое ИИ-ассистент с обучением на базе знаний и чем он отличается от обычного чат-бота

Обычный чат-бот, который я делал на aiogram несколько лет назад, работал по дереву сценариев: клиент нажал кнопку - получил заранее прописанный ответ. Расширить такого бота новым вопросом можно было только руками, добавив ветку в коде. Ассистент с обучением на базе знаний устроен иначе: он не хранит готовые ответы, а на лету находит релевантный кусок текста в базе документов и формулирует ответ через языковую модель - Claude или GPT.

Разница ощущается в объеме поддерживаемых тем. Дерево сценариев на 40-50 веток уже тяжело поддерживать, а базу знаний на 300-500 страниц документации ассистент индексирует за один прогон и отвечает по любому фрагменту без ручной настройки диалогов под каждый вопрос.

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

Архитектура: как ассистент ищет ответ в базе знаний

На практике собираю такую систему по схеме RAG (Retrieval-Augmented Generation) - генерация ответа с подмешиванием найденного контекста. Четыре шага:

• документы базы знаний режутся на фрагменты по 300-800 токенов - так модель получает связный кусок текста, а не обрывок фразы;
• каждый фрагмент превращается в вектор (embedding) - числовое представление смысла - и складывается в векторную базу вроде Qdrant, Pinecone или pgvector поверх обычного PostgreSQL;
• при вопросе пользователя система считает embedding самого вопроса и ищет ближайшие по смыслу фрагменты - это и есть retrieval;
• найденные 3-5 фрагментов вместе с вопросом уходят в языковую модель, которая формулирует ответ строго на основе присланного контекста.

Упрощенно вызов поиска и генерации выглядит так:

results = vector_db.query(embed(question), top_k=5)
context = "nn".join(r.text for r in results)

response = client.messages.create(
    model="claude-sonnet-5",
    system="Отвечай только на основе переданного контекста. Если ответа там нет — скажи, что не знаешь.",
    messages=[{"role": "user", "content": f"{context}nnВопрос: {question}"}]
)

Без жесткого требования отвечать только по контексту модель начинает домысливать детали - цены, сроки доставки, условия акций - и клиент получает уверенный, но неверный ответ. Этот момент чаще всего упускают, когда собирают бота через no-code конструктор без контроля промпта.

Из чего собирают базу знаний в реальных проектах

Статическая часть базы - это FAQ, документация, прайс, карточки товаров, регламенты поддержки, выгрузка из Confluence или Notion. Для интернет-магазина на WooCommerce беру описания и атрибуты товаров прямо из базы данных, и ассистент отвечает на вопросы вроде «чем модель А отличается от B» без участия оператора.

Но часть вопросов клиентов вообще не лежит в документах - «где моя посылка», «прошла ли оплата», «когда доставят». Такие ответы статическая база знаний не закроет никогда, потому что данные меняются в реальном времени. Здесь подключается function calling: модель по ходу диалога вызывает функцию, которая обращается к API СДЭК за статусом доставки или к вебхуку эквайринга (например, T‑Bank) за статусом платежа, и уже с этими данными формулирует ответ.

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

Где работает такой ассистент: сайт, Telegram, CRM

Логическое ядро - поиск по базе и генерация ответа - не зависит от канала, меняется только адаптер. На сайте это JS-виджет, встроенный скриптом в шапку или подвал (на Tilda такой скрипт - отдельная доработка, не входит в стоимость самого ассистента). В Telegram - бот на aiogram, использующий тот же бэкенд и ту же базу знаний, что и виджет на сайте.

Когда каналов больше одного - сайт, Telegram, WhatsApp через стороннего провайдера - оркестрацию беру на n8n: туда стекаются сообщения из всех источников, оттуда же уходят к языковой модели и обратно, плюс параллельно пишутся в Google Таблицы или CRM для истории. Часть готовых сценариев для такой маршрутизации в n8n у меня уже собрана и лежит в библиотеке готовых скриптов - можно адаптировать под свой набор каналов, не собирая пайплайн с чистого листа.

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

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

Цена зависит не от того, «Telegram это или сайт», а от того, сколько источников данных и функций нужно подключить.

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

Частые ошибки при внедрении ИИ-ассистента с обучением на базе знаний

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

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

Чем ИИ-ассистент с базой знаний отличается от обычного FAQ-бота на сайте?

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

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

Частично да - связка n8n и готовых нод для OpenAI или Claude API закрывает базовый сценарий. Но для продакшн-качества с логированием диалогов, порогом релевантности, function calling к внешним API и передачей на оператора без разработчика не обойтись - иначе бот будет либо галлюцинировать, либо теряться на нестандартных вопросах.

Сколько времени ассистент «учится» на новых документах?

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

Обязательно ли использовать именно Claude, можно на OpenAI?

Архитектура не меняется, меняется только вызов API. На практике часто комбинирую вендоров: embeddings считаю через OpenAI, а генерацию финального ответа делаю через Claude - модели разных производителей нормально работают в одном пайплайне.