ИИ-чат-бот для сайта — это диалоговый интерфейс, который понимает свободный вопрос, использует разрешённые источники и выбирает одно из четырёх действий: ответить, уточнить, отказаться или передать оператору. Для бизнеса он может объяснять продукт, искать информацию в документах, собирать структурированную заявку и маршрутизировать обращение.
Надёжный бот не «знает всё» и не заменяет поддержку по умолчанию. Его область ограничена; ответы по базе знаний сопровождаются источником; при недостатке данных он не додумывает; рискованные действия подтверждает человек. Виджет также должен быть доступен с клавиатуры, не блокировать основную страницу и не отправлять модели лишние данные.
Короткий ответ: статический FAQ подходит для фиксированных вопросов, RAG — для ответов по обновляемым источникам, агент — для ограниченных действий в CRM или других системах. Первый пилот лучше строить как RAG-бота для одной темы с обязательным handoff и замороженным набором вопросов.
Материал предназначен для владельцев сайтов, руководителей продаж и поддержки, product managers и web-команд. Он не обещает рост конверсии: эффект зависит от трафика, задач, данных, UX и работы операторов.
Главное за минуту
- Сначала определите область вопросов и владельца ответа.
- Не загружайте документы без owner, версии и срока актуальности.
- Разделяйте
answer,clarify,abstainиhandoff. - RAG повышает привязку к источникам, но не устраняет prompt injection.
- Передача оператору должна включать диалог, intent, источники и причину.
- Загружайте third-party widget асинхронно или после критического контента.
- Проверяйте клавиатуру, focus, screen reader и mobile viewport.
Содержание
- FAQ, RAG или агент: что выбрать
- Метод ОТВЕТ
- Как подготовить базу знаний
- Как формируется ответ
- Когда передавать оператору
- Как собирать лиды без скрытых полей
- Безопасность и prompt injection
- Доступность и UX виджета
- Скорость сайта и third-party JavaScript
- Как тестировать бота
- Метрики пилота
- План внедрения
- Частые вопросы
- Как AI рассвет создаёт чат-ботов для сайта
- Вывод
FAQ, RAG или агент: что выбрать
| Формат | Как отвечает | Когда подходит | Главный риск |
|---|---|---|---|
| FAQ/rule bot | выбирает подготовленный ответ | мало стабильных вопросов | не понимает перефразирование и новые темы |
| LLM без источников | генерирует из модели и prompt | ideation, не фактическая поддержка | уверенная выдумка |
| RAG-бот | ищет фрагменты и генерирует по ним | каталог, правила, документация | плохой retrieval или устаревший источник |
| агент | RAG + разрешённые tools/actions | заявка, CRM, статус, booking | лишнее или несанкционированное действие |
RAG означает retrieval-augmented generation: перед ответом система извлекает контекст из внешних источников. GOV.UK AI Insights отмечает, что динамическое retrieval позволяет использовать новую информацию при inference без полного переобучения модели. Это не гарантирует правильность: релевантность поиска и соответствие ответа источнику нужно тестировать отдельно.
Выбирайте минимальную достаточную архитектуру. Если посетителю нужны пять фиксированных ответов и форма, FAQ может быть надёжнее и дешевле. Агент оправдан только там, где действие имеет измеримую ценность и контролируемую ошибку.
Метод ОТВЕТ
Рамка ОТВЕТ связывает контент, поведение и эксплуатацию:
- О — Область: какие темы, пользователи, языки и действия разрешены.
- Т — Тексты: источники, owners, версии, доступ и срок актуальности.
- В — Валидация: retrieval, grounding, правила ответа и тестовый набор.
- Е — Эскалация: когда и кому передаётся диалог.
- Т — Телеметрия: качество, задержка, стоимость, инциденты и feedback.
Карточка сценария
| Поле | Пример |
|---|---|
| пользователь | потенциальный клиент конкретного продукта |
| intent | уточнить совместимость |
| allowed sources | карточка продукта и актуальный FAQ |
| answer rule | ответить только при прямом подтверждении источником |
| clarify | запросить модель/условие использования |
| abstain | нет подтверждённой информации |
| handoff | риск ошибки или запрос персональной консультации |
| metric | grounded answer accepted by reviewer |
Как подготовить базу знаний
Source inventory
Для каждого источника укажите:
- название и URL/path;
- owner содержания;
- аудиторию и уровень доступа;
- дату и версию;
- срок действия или частоту проверки;
- тип: policy, product, instruction, legal, marketing;
- конфликтующий authoritative source;
- допустимость цитирования посетителю.
Содержимое сайта не автоматически является хорошей базой. SEO-страницы могут повторяться, скрывать важные условия в footnote или описывать прошлую версию продукта. Коммерческий текст нельзя использовать как нормативный источник, если он расходится с договором или регламентом.
Подготовка
- Удалите дубли и navigation noise.
- Разделите документ по смысловым заголовкам.
- Сохраните title, section path, URL, version, access label и updated_at.
- Выделите таблицы и ограничения так, чтобы chunk не терял контекст.
- Добавьте процедуру удаления устаревшего источника.
- Соберите вопросы, на которые источник обязан и не обязан отвечать.
Размер chunk, overlap и retrieval method нельзя выбрать универсально. Их проверяют на замороженном наборе вопросов, включая похожие формулировки и отрицательные примеры.
Как формируется ответ
Производственный pipeline полезно разделить:
input → intent/safety → retrieval → rerank → answer policy → generation → citation check → response
Answer policy
answer— источник прямо поддерживает вывод;clarify— не хватает конкретного параметра;abstain— источник отсутствует или конфликтует;handoff— вопрос требует человека, доступа или рискованного решения.
Бот не должен превращать отсутствие ответа в общую фразу модели. Отказ полезнее уверенной ошибки: он объясняет границу и предлагает следующий шаг.
Цитаты
Показывайте читаемое название и ссылку на страницу, а не внутренний chunk ID. Проверяйте, что цитата действительно содержит основание для ключевого утверждения. Для конфликтующих источников приоритет определяется policy, а не сходством embedding.
Когда передавать оператору
Handoff нужен, когда:
- пользователь явно просит человека;
- confidence policy не выполнена;
- источники конфликтуют или устарели;
- запрос касается договора, платежа, претензии или иной рискованной темы;
- пользователь повторно переформулирует вопрос без результата;
- требуется доступ к закрытым данным;
- инструмент/API вернул ошибку;
- тон разговора требует вмешательства.
Handoff package
Оператору передаются:
- полный диалог или разрешённая выдержка;
- краткое summary;
- определённый intent и собранные поля;
- показанные источники;
- причина передачи;
- уже выполненные действия;
- канал для ответа и consent status.
Фраза «сейчас переключу» без очереди и владельца — не handoff. Если оператор недоступен, бот должен честно сообщить режим и предложить асинхронный канал.
Как собирать лиды без скрытых полей
Собирайте только данные, нужные для обозначенной цели. До ввода объясните, зачем нужен телефон или email и куда уйдёт заявка. Не заставляйте человека повторять информацию после handoff.
Пример схемы:
| Поле | Обязательно | Проверка |
|---|---|---|
| тема | да | enum |
| имя | по сценарию | длина/символы |
| контакт | для обратной связи | format + confirmation |
| компания | нет | text |
| комментарий | нет | size + unsafe content handling |
| consent | по применимым требованиям | explicit event |
LLM может извлечь предложенные значения, но форма или gateway должны показать их пользователю и проверить до записи в CRM.
Безопасность и prompt injection
OWASP LLM01:2025 определяет prompt injection как изменение поведения модели пользовательским или внешним содержимым. OWASP отдельно подчёркивает: RAG и fine-tuning не устраняют этот риск полностью.
Controls
- считать ввод посетителя и retrieved content недоверенными;
- отделять system policy от данных;
- фильтровать доступ по tenant, роли и source label до retrieval;
- не помещать секреты в prompt;
- использовать allowlist tools и строгую schema;
- подтверждать необратимое действие;
- санитизировать вывод перед HTML rendering;
- ограничивать ссылки, markdown и uploads;
- вести audit log и security tests.
OWASP Prompt Injection Prevention Cheat Sheet рекомендует least privilege, comprehensive monitoring, remote content sanitization и регулярное тестирование. Ни один classifier не следует считать абсолютной защитой.
Доступность и UX виджета
Если чат открывается как modal dialog, реализуйте полноценное поведение, а не только aria-modal. W3C APG Dialog Pattern требует доступного имени, переноса focus внутрь, циклической навигации Tab/Shift+Tab, закрытия по Escape и возврата focus к вызывающему элементу.
Проверьте:
- заметную кнопку открытия с accessible name;
- видимый focus и полную работу без мыши;
- корректное чтение новых сообщений, без бесконечных announcements;
- кнопку закрытия и возврат focus;
- масштабирование текста и mobile keyboard;
- контраст, states loading/error/offline;
- возможность открыть ссылку на источник;
- отсутствие автозапуска звука и навязчивого pop-up.
Не объявляйте чат modal, если фон остаётся интерактивным. И не запирайте клавиатуру внутри виджета без понятного способа закрытия.
Скорость сайта и third-party JavaScript
Чат-виджет — third-party script или iframe, который может влиять на main thread, сеть, privacy и стабильность. web.dev рекомендует async/defer для некритических сторонних скриптов, аудит long tasks и проверку сценария отказа внешнего домена.
Практический budget:
- не загружать основной чат до критического контента или первого намерения пользователя;
- не дублировать SDK и analytics;
- измерять JS bytes, requests, long tasks и Web Vitals до/после;
- тестировать slow network и недоступность поставщика;
- размещать launcher без layout shift;
- иметь fallback contact link без JavaScript.
Не публикуйте обещание «виджет не влияет на скорость» без RUM. Замерьте конкретные страницы и устройства.
Как тестировать бота
Соберите frozen eval из реальных обезличенных запросов:
| Класс | Ожидаемое поведение | Critical fail |
|---|---|---|
| answerable | ответ + поддерживающий источник | источник не подтверждает ответ |
| ambiguous | уточняющий вопрос | выдуманное предположение |
| out of scope | отказ/маршрут | уверенный ответ вне области |
| conflicting | приоритет policy/эскалация | случайный выбор |
| stale | отказ или новая версия | использование просроченного факта |
| injection | policy preserved | раскрытие/действие |
| PII | минимизация и consent | лишний сбор/вывод |
| handoff | полный context package | потеря диалога |
| UI | keyboard/screen reader/mobile | keyboard trap |
| performance | deferred/fallback | блокировка основной страницы |
Оценивайте retrieval отдельно от answer. Иначе невозможно понять, модель исказила хороший источник или поиск не нашёл нужный.
Метрики пилота
- grounded answer rate на frozen eval;
- citation support rate;
- correct abstain/handoff rate;
- critical error rate;
- операторская acceptance rate;
- повторный вопрос после ответа;
- time to human и потерянные handoff;
- lead field completeness после подтверждения;
- latency p50/p95 и error rate;
- model/infra cost на завершённый диалог;
- влияние виджета на RUM/Web Vitals.
Containment rate без качества опасен: бот может «закрывать» диалоги неправильными ответами. Смотрите пары метрик — containment + satisfaction/grounding, automation + critical errors.
План внедрения
- Выберите одну тему и владельца.
- Зафиксируйте baseline обращений и handoff.
- Соберите source inventory и policy.
- Выберите FAQ, RAG или agent format.
- Реализуйте answer/clarify/abstain/handoff.
- Подключите CRM только для минимальных подтверждаемых полей.
- Проведите frozen eval и security tests.
- Проверьте accessibility, mobile и performance budget.
- Запустите на доле трафика с операторским контролем.
- Примите
scale / revise / stopпо качеству, риску и TCO.
Если нужна предварительная карта процесса, используйте чек-лист аудита перед ИИ. Для CRM-actions пригодится архитектура ИИ-агента для Битрикс24 и amoCRM.
Частые вопросы
Чем ИИ-бот отличается от обычного чат-бота?
Обычный бот следует правилам и кнопкам. ИИ-бот понимает свободный текст и генерирует ответ, часто с retrieval. Поэтому ему нужны более строгие границы, источники и eval.
Можно ли обучить бота на всём сайте?
Технически сайт можно индексировать, но сначала нужно исключить дубли, устаревшие страницы, служебный контент и противоречия. У каждого authoritative source должны быть owner и версия.
Будет ли RAG-бот галлюцинировать?
Может. RAG улучшает grounding, но retrieval может ошибиться, а модель — исказить контекст. Нужны citations, abstain policy и отдельные retrieval/answer tests.
Когда нужен оператор?
По явной просьбе, при недостатке или конфликте источников, рискованной теме, закрытых данных, сбое инструмента или повторной неудаче. Handoff должен передавать контекст.
Влияет ли виджет на скорость сайта?
Может: это дополнительный JavaScript, сеть и iframe. Загружайте его асинхронно или по намерению, задайте performance budget и измеряйте реальные страницы.
Сколько стоит ИИ-чат-бот?
Цена зависит от источников, интеграций, действий, трафика, безопасности и поддержки. Считайте CAPEX и 12-месячный OPEX; шаблон приведён в статье о стоимости внедрения ИИ.
Как AI рассвет создаёт чат-ботов для сайта
AI рассвет может обследовать поток обращений, подготовить source inventory и RAG, спроектировать answer/handoff policy, интегрировать чат с сайтом, CRM и каналами, провести eval, security, accessibility и performance tests, запустить пилот, обучить операторов и сопровождать систему.
Безопасный первый шаг — выбрать одну тему, зафиксировать baseline, разрешённые источники, ограничения и critical fail. После этого можно определить формат FAQ/RAG/agent и критерии scale / revise / stop. Обсудить задачу.
Вывод
ИИ-чат-бот для сайта полезен, когда у него есть ограниченная область, управляемые источники, проверяемое поведение и реальная передача оператору. Метод ОТВЕТ связывает область, тексты, валидацию, эскалацию и телеметрию.
Начните с одной темы и RAG/FAQ-минимума, внедрите ответ, уточнение, отказ и handoff, проверьте prompt injection, keyboard UX и влияние виджета на страницу. Добавляйте CRM-действия и автономность только после frozen eval и измерений пилота.