Архитектура LLM-бота: как не упасть в продакшене

Архитектура LLM-бота поддержки в продакшене - это совсем другая задача, чем сборка прототипа за выходные. Прототип работает на 20 тестовых вопросах. Продакшн падает на 21-м - неожиданном, пограничном, нагруженном. Разбираем, где ломается типовой конвейер и как его починить до того, как это сделают пользователи.

Почему классический конвейер LLM не работает в реальности

Типовая схема выглядит так: вопрос пользователя - промпт - LLM - ответ. Выглядит просто. В реальности у неё несколько системных проблем.

• Каждый запрос стоит денег. Если слать в модель каждое «привет» и «спасибо», токены сгорают впустую. На тысяче пользователей это заметно.
• Задержка непредсказуема. LLM отвечает от 1 до 10+ секунд. Пользователь ждёт - и уходит.
• Модель галлюцинирует. На вопросах, которых не было в базе знаний, она придумывает ответ - уверенно и неверно.
• Нет управляемости. Нельзя гарантировать формат ответа, тональность, соответствие политике компании.

Всё это не значит, что LLM не нужна. Значит, что она не должна стоять первой в очереди на каждый запрос.

Гибридная архитектура: когда нужна логика, а не просто модель

Рабочая архитектура - это конвейер с несколькими слоями, где LLM подключается только там, где нужна семантика или генерация.

Слой 1 - классификация и роутинг

Первый слой определяет тип запроса: типовой FAQ, задача с транзакцией (статус заказа, возврат), свободный вопрос. Для этого не нужна LLM - хватает лёгкого классификатора или правил. Это экономит 40-60% обращений к модели.

Слой 2 - поиск по базе знаний

Для типовых вопросов используется векторный поиск: embeddings + similarity search. Если найден релевантный фрагмент с уверенностью выше порога (например, cosine similarity > 0.85) - ответ отдаётся напрямую, без LLM. Быстро, дёшево, контролируемо.

Слой 3 - LLM для генерации и сложных случаев

Только сюда попадают запросы, которые не закрыл поиск: нестандартные формулировки, составные вопросы, требующие синтеза из нескольких источников. Здесь LLM работает с контекстом из базы знаний - не генерирует из головы.

Слой 4 - постпроцессинг и валидация

Ответ LLM проверяется на соответствие шаблону, длину, наличие запрещённых фраз. Только после этого идёт к пользователю.

Как Claude помогает, но не решает все проблемы

Claude хорошо справляется с задачами синтеза и следования инструкциям. Это важно для бота поддержки: модель точнее держит системный промпт, меньше уходит в сторону от заданного стиля, корректнее отказывается отвечать на то, чего не знает.

Но даже у Claude есть ограничения в продакшне:

• Контекстное окно конечно - длинные диалоги требуют управления историей.
• API может возвращать ошибки или таймаут - нужен fallback.
• Без чёткого промпта и ограничений Claude так же может уйти в многословие.

Практика: системный промпт должен явно задавать роль, ограничения, формат ответа и что делать при неизвестном вопросе. Не «отвечай полезно», а «отвечай максимум в 3 предложениях, если не знаешь - скажи об этом и предложи связаться с оператором».

Масштабирование: стоимость, задержки и отказы в продакшне

Три метрики, которые надо считать до выхода в прод:

1. Стоимость на диалог. Считайте токены не на запрос, а на полный диалог. 5 сообщений с историей контекста - это в 3-4 раза больше токенов, чем первый вопрос.
2. P95 latency. Средняя задержка обманывает. Смотрите 95-й перцентиль: если 5% пользователей ждут 8 секунд - это проблема.
3. Error rate API. LLM API недоступен в среднем несколько часов в месяц. Без fallback-логики бот полностью встаёт.

Кэширование частых запросов снижает стоимость в разы. Семантический кэш (не точное совпадение, а похожие запросы) - ещё эффективнее. Инструменты типа GPTCache или самописные решения на Redis + embeddings решают задачу.

Паттерны отказоустойчивости для чат-ботов поддержки

Бот поддержки не может молчать. Вот минимальный набор паттернов:

• Circuit breaker. Если LLM API не отвечает N раз подряд - автоматически переключаться на статические ответы или эскалацию к оператору.
• Timeout + fallback. Лимит ожидания ответа от модели - 5-7 секунд. При превышении - вежливый дефолтный ответ, не молчание.
• Graceful degradation. Бот без LLM должен уметь закрыть хотя бы топ-20 вопросов через жёсткий FAQ. Это страховка при полном падении модели.
• Логирование каждого шага конвейера. Без этого нельзя понять, на каком слое упал ответ и почему.

От прототипа к надёжной системе: чек-лист инженера

Перед выходом в продакшн пройдитесь по списку:

1. Есть роутинг: не всё идёт в LLM.
2. Векторный поиск закрывает типовые вопросы без модели.
3. Системный промпт задаёт формат, ограничения и поведение при незнании.
4. История диалога обрезается по токенам, а не хранится целиком.
5. Настроен circuit breaker и таймаут на API.
6. Есть fallback на статику или оператора.
7. Семантический кэш для повторяющихся запросов.
8. Логирование каждого шага конвейера для диагностики сбоев.