AI-агенты вместо саппорта: что стартап получил и что сломал

Схема, которую всё чаще собирают продуктовые команды: вместо найма ещё троих операторов на первую линию поддержки берут LLM-модель, подключают к ней базу знаний через RAG* и запускают агента, который сам ищет ответ, оформляет возврат или заводит тикет на инженера. Мы разберём типовой кейс такой миграции — не по имени конкретной компании, а по устройству, которое повторяется от проекта к проекту, — и посмотрим, где эта архитектура реально работает, а где выдаёт счёт, которого не ждали.

Важная оговорка сразу: «заменил отдел поддержки» — почти всегда преувеличение. На практике заменяется первая линия (типовые вопросы), а вторая линия и эскалации остаются на людях. Разница в том, сколько запросов удаётся закрыть без человека.

Что именно строят под капотом

Классическая связка выглядит так: канал общения (виджет на сайте, почта, Telegram) → маршрутизатор → LLM-агент с доступом к инструментам → база знаний и CRM. Агент — это не просто чат с моделью. Это модель, которой разрешено вызывать функции: посмотреть статус заказа, оформить возврат, создать тикет, передать диалог оператору.

Ключевых компонентов обычно четыре:

• Модель. Чаще всего GPT-, Claude- или локальная open-weight модель для запросов, где данные нельзя отдавать наружу.
• RAG-слой. Документация, FAQ и прошлые тикеты режутся на фрагменты, превращаются в векторы и подтягиваются в контекст под конкретный вопрос. Без этого модель отвечает «в общем», а не про ваш продукт.
• Инструменты (function calling). API, которые агент дёргает: получить заказ, отменить подписку, вернуть деньги. Здесь же — жёсткие ограничения на то, что агенту делать нельзя.
• Правила эскалации. Когда агент обязан передать диалог человеку: злой клиент, юридический вопрос, сумма выше порога, три неудачные попытки ответа.

Что получилось: цифры, которые стоит смотреть

Публичные кейсы вендоров поддержки заявляют разброс автоматизации первой линии от 30% до 70% обращений — но это цифры из маркетинга, и проверять их надо на своих данных, а не принимать на веру. Универсальной ставки «сколько закрывает AI» не существует: у документированного B2B-SaaS результат один, у маркетплейса с эмоциональными возвратами — совсем другой.

Что действительно меняется предсказуемо:

• Время первого ответа падает до секунд в любое время суток. Ночная смена больше не стоит денег.
• Пиковые нагрузки перестают ронять SLA: агент масштабируется без найма.
• Операторы переключаются с «где мой заказ» на сложные случаи, где человек добавляет ценность.

AI-поддержка экономит не на зарплатах, а на скорости и на масштабировании пиков. Если считать экономию только через сокращение штата — почти всегда разочаруетесь.

Где ломается

Три типовые точки отказа, о которых узнают уже в проде.

Галлюцинации на границе базы знаний

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

Стоимость токенов на длинных диалогах

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

Эмоции и репутация

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

AI-агент против классических решений

Кому это пригодится, а кому нет

Стоит внедрять, если у вас:

• много однотипных обращений — статус заказа, сброс пароля, условия тарифа;
• подробная и актуальная база знаний, которую есть кому поддерживать;
• чёткие API для действий, которые агент сможет выполнять безопасно;
• ночные и пиковые нагрузки, которые дорого закрывать людьми.

Лучше не спешить, если:

• цена ошибки высокая — медицина, финансовые операции, юридические консультации;
• документация фрагментарна: RAG на плохой базе даёт уверенно неверные ответы;
• обращения сильно эмоциональные или уникальные — там человек всё равно быстрее;
• вы работаете с персональными данными и не решили вопрос, куда они уходят при вызове внешней модели.

Как разворачивать без боли

1. Соберите топ-20 обращений за последние месяцы и посчитайте их долю. Автоматизируйте сначала их.
2. Запустите агента в режиме «черновик ответа для оператора»: модель предлагает, человек подтверждает. Так вы измерите качество без риска для клиента.
3. Настройте эскалацию по тону, сумме и числу неудачных попыток — до перевода в полностью автономный режим.
4. Логируйте все ответы, где не нашлось источника в базе. Это ваш список дыр в документации.
5. Считайте не только зарплаты, но и токены, поддержку базы знаний и время инженеров на интеграцию.

* RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из вашей базы знаний и отвечает, опираясь на них, а не только на то, что «помнит» из обучения.