Чат бот с AI на сайте: когда хватит FAQ, а когда нужен LLM

На сайте появляется виджет: «Спросите AI». Через месяц маркетинг радуется числу диалогов, а поддержка ругается: бот обещает сроки, которых нет в договоре, путает тарифы и уверенно отвечает на вопросы, которых нет в базе знаний. Клиенты пишут в чат живым людям: «ваш робот несёт чушь».

Другая крайность — вообще без бота. Менеджеры вручную отвечают на одни и те же вопросы про доставку, оплату и документы. Ночью заявки остывают. Конкурент с нормальным сценарием забирает лид, пока у вас «оставьте номер, перезвоним».

Вопрос не «нужен ли AI», а какой уровень автоматизации оправдан задачей. Сценарный FAQ, поиск по базе с генерацией ответа (RAG) и дообучение модели — разные по цене, рискам и эффекту решения. Путать их — самый быстрый способ сжечь бюджет на пилот без пользы.

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

Три уровня, которые путают на презентациях

Сценарный бот — это дерево вопросов, кнопки, формы и жёсткие ответы. Он отлично закрывает «как оформить возврат», «какой статус заказа», «какие документы нужны». Он предсказуем, легко аудируется юридически и почти не галлюцинирует. Минус — не понимает свободный текст за пределами сценария и быстро устаревает, если базу не обновляют.

RAG (retrieval-augmented generation) — модель ищет фрагменты в вашей базе знаний, регламентах, карточках товаров и формулирует ответ на их основе. Это уже «умный» помощник для сайта и внутренней поддержки. Он полезен, когда документов много, формулировки вопросов разные, а точный сценарий на всё не написать. Риск — плохая база даёт плохие ответы; без ограничений модель может додумать то, чего в документах нет.

Fine-tune и тяжёлые кастомные модели — имеют смысл, когда нужен устойчивый стиль, узкий доменный язык или работа в закрытом контуре с особыми требованиями. Для типичного FAQ на сайте это избыточно: дорого в сопровождении и редко окупается быстрее, чем хорошо собранный RAG поверх актуальных материалов.

Между этими уровнями есть промежуточные решения: умный поиск по FAQ без генерации, подсказки оператору в живом чате, классификатор темы с маршрутизацией на нужный отдел. Иногда именно они дают 80% эффекта за 20% стоимости «полноценного AI».

Где проекты обычно ломаются

Первая ошибка — купить «нейросеть», не описав сценарии и метрики. Без списка топ вопросов, без эскалации на человека и без критерия успеха бот становится игрушкой. Вторая — скормить модели сырой хаос: устаревшие PDF, противоречивые статьи, прайсы трёхлетней давности. Третья — пустить генерацию без ограждений: бот начинает давать юридические обещания, скидки и диагнозы, за которые отвечает уже компания.

Отдельно вредна мода «один бот на всё». Продажи, поддержка, HR и внутренние регламенты — разные тональности и разные риски. Лучше узкий помощник с понятной зоной ответственности, чем универсальный собеседник, который уверенно ошибается.

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

Как выбрать уровень под задачу

Начните с статистики обращений за квартал. Если 60–80% вопросов повторяются и ответы стабильны — хватит сценарного бота и умного поиска по FAQ. Подключите кнопки, сбор контакта, передачу в CRM и понятную ветку «свяжите с оператором». Это даёт быстрый ROI без драмы с моделями.

Если вопросы разнообразные, документы длинные, а операторы тратят время на «найти нужный абзац в базе» — смотрите на RAG. Сначала приведите знания в порядок: актуальные статьи, единые формулировки тарифов, явное разделение «можно / нельзя / уточните у менеджера». Затем настройте поиск по корпусу, шаблоны ответа, запрет выдумывать факты и логирование диалогов для разбора ошибок.

Fine-tune имеет смысл позже: когда корпус стабилен, сценарии ясны, а модель должна устойчиво говорить «на языке» продукта или работать в изолированной среде. Идти сразу в fine-tune «потому что конкуренты тоже AI» — почти всегда дороже и медленнее, чем порядок в базе знаний.

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

Практический порядок внедрения без хайпа

Соберите топ 30 вопросов и эталонные ответы, согласованные с продажами, поддержкой и юристом. Определите, что бот никогда не обещает сам: цены со скидкой, сроки «точно к среде», медицинские или юридические выводы. Настройте эскалацию: при неуверенности, при жалобе, при сумме выше порога — сразу человек.

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

Отдельно договоритесь о сопровождении базы знаний. Бот стареет вместе с документами. Без владельца контента через три месяца снова начнётся «робот врёт», хотя модель тут ни при чём — устарели факты.

• разделите сценарии «кнопки/FAQ» и «свободный вопрос к базе»;
• обновите и нормализуйте базу знаний до подключения LLM;
• задайте запреты и эскалацию на человека;
• логируйте диалоги и разбирайте ошибки еженедельно;
• считайте успех в снижении нагрузки и скорости ответа, а не в «вау» эффекте.

Какой результат ждёт бизнес

Правильный уровень автоматизации снижает стоимость первого контакта, ускоряет ночные и выходные ответы и разгружает операторов от однотипщины. При этом компания не рискует репутацией из-за «уверенного бреда» модели. Клиент получает быстрый и честный ответ; сложные кейсы по-прежнему ведёт человек.

Сценарный бот окупается быстрее всего на повторяющихся вопросах. RAG окупается там, где знания уже есть, но искать их вручную дорого. Тяжёлые модели окупаются редко и только при зрелой постановке задачи.

Для руководителя полезно смотреть на связку метрик: стоимость обработанного обращения, доля ночных лидов, дождавшихся ответа, и число инцидентов «бот пообещал лишнее». Если первые две растут в плюс, а третья близка к нулю — архитектура выбрана верно.

Если нужно спокойно выбрать архитектуру и внедрить помощника без хайпа — от FAQ до RAG — посмотрите направление AI-решений: сначала метрики и база знаний, потом модель, а не наоборот.

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