Пользователь ждёт ответа слишком долго
Запрос к крупной модели занимает 5–15 секунд. Без потоковой выдачи интерфейс выглядит зависшим, и пользователи закрывают страницу, не дождавшись результата.
Выберите тему — соберём контекст
Проектируем сервис вокруг модели: контракт API, потоковая выдача ответа, очереди для тяжёлых задач, кэширование и лимиты. Считаем стоимость одного запроса и следим, чтобы она не выросла вместе с нагрузкой.
Или сразу: +7 (962) 368-39-51 Telegram
Проблемы, которые проявляются не на демо, а на второй неделе реальной эксплуатации.
Запрос к крупной модели занимает 5–15 секунд. Без потоковой выдачи интерфейс выглядит зависшим, и пользователи закрывают страницу, не дождавшись результата.
Функция стала популярной, и счёт за токены вырос в пять раз. Ограничений на объём контекста и длины ответа не было заложено, как и кэширования.
API внешней модели отдаёт 429 или таймаут, и вся функция продукта перестаёт работать. Резервного варианта и деградации не предусмотрено.
Один пользователь может отправить сотню запросов подряд и исчерпать квоту для всех остальных. Rate limiting проектируется вместе с функцией.
Обработка документа на 200 страниц блокирует веб-процесс. Пользователь получает таймаут, а задача остаётся невыполненной.
Одинаковый запрос даёт разные результаты, и при разборе жалобы невозможно понять, что именно было отправлено в модель и с какими параметрами.
Инженерная часть проекта, от которой зависит, будет ли AI-функция удобной и устойчивой.
Определяем синхронные и асинхронные сценарии, форматы ответов и поведение при ошибках — до написания кода.
Ответ отдаётся по мере генерации, поэтому пользователь видит текст через доли секунды после отправки запроса.
Тяжёлые задачи уходят в фоновую обработку, повторяющиеся запросы обслуживаются из кэша, а стоимость каждого сценария ограничена сверху.
Сервис должен деградировать предсказуемо, а не отказывать целиком при проблемах у провайдера модели.
Начинаем с расчёта стоимости и требований к задержке: они определяют архитектуру сильнее, чем выбор модели.
Фиксируем ожидаемую нагрузку, допустимую задержку и бюджет на запросы. Считаем стоимость сценария до выбора технологии.
Реализуем минимальный контракт, подключаем модель, измеряем реальные задержки и расход токенов на тестовой нагрузке.
Добавляем кэширование, батчинг, потоковую выдачу. Проверяем поведение под нагрузкой и при отказе провайдера.
Включаем функцию для пользователей постепенно, настраиваем мониторинг, алерты по стоимости и регламент обновления промптов.
Стоимость складывается из входных и выходных токенов, причём выходные обычно дороже в несколько раз. В расчёт входит не только запрос пользователя: системная инструкция, найденные фрагменты документов, история диалога — всё это тоже токены, и на длинных диалогах именно контекст определяет счёт.
Управлять стоимостью можно четырьмя способами: сокращать системную инструкцию и число подаваемых фрагментов, кэшировать повторяющиеся запросы, использовать компактную модель для простых шагов и ограничивать длину ответа. На практике сочетание этих мер снижает расходы на 40–70% относительно наивной реализации без потери качества.
Поэтому мы проектируем интерфейс и сервис вокруг p95 и p99: потоковая выдача текста маскирует общее время генерации, длительные задачи уходят в фон с уведомлением о готовности, а для запросов, превысивших порог, применяется более быстрая модель. Так продукт остаётся отзывчивым даже при тяжёлых сценариях.
Мы закладываем несколько уровней деградации: повтор запроса с задержкой, переключение на резервную модель, переход к упрощённому шаблонному ответу и, наконец, честное сообщение пользователю с предложением попробовать позже. Какой уровень включается, зависит от критичности сценария: для генерации описания товара достаточно шаблона, для юридической проверки документа лучше честно сообщить о недоступности.
Для типового запроса с контекстом в 2–3 тысячи токенов и ответом на 500 токенов цена на облачных моделях среднего размера составляет доли рубля. Точная величина зависит от выбранной модели, длины контекста и объёма выходного текста. Мы всегда считаем стоимость на реальном профиле нагрузки: средний запрос, тяжёлый запрос и пиковый период, — потому что бюджет определяет пик, а не среднее.
Да, и это нужно делать сразу. Технически устанавливаются лимиты на пользователя, на сценарий и на сутки в целом; запросы сверх лимита отклоняются с понятным сообщением. Дополнительно ограничивается длина контекста и ответа, включается кэширование повторяющихся запросов. Алерт на резкий рост расхода настраивается отдельно: обычно это признак либо аномального использования, либо ошибки в коде интеграции.
Используем комбинацию мер: повторные попытки с нарастающей задержкой, переключение на резервную модель другого провайдера и упрощённый сценарий без генерации. Критичные функции проектируем так, чтобы их отказ не блокировал основной процесс: например, автоматическая категоризация заявки при недоступности модели заменяется правилом по ключевым словам, а заявка всё равно попадает в систему.
Хранить нужно метаданные: идентификатор запроса, версию промпта и модели, расход токенов, задержку и результат проверки. Полные тексты сохраняются в зависимости от политики: они полезны для разбора инцидентов и накопления примеров для улучшения, но могут содержать персональные данные. Компромисс — хранить полные тексты ограниченный срок в обезличенном виде, а долгосрочно оставлять только выборку, отобранную для анализа качества.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Расскажите про сценарий и ожидаемую нагрузку — посчитаем стоимость одного запроса и предложим архитектуру с учётом ваших ограничений.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.