3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?
Интеграция AI в продукты

Встраиваем модель в продукт, а не рядом с ним

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

Или сразу: +7 (962) 368-39-51 Telegram

p95
задержка, а не среднее время ответа
SSE
потоковая выдача первого токена
cache
экономия на повторных запросах
fallback
деградация вместо отказа сервиса
Задачи

Что мешает AI-функции работать в проде

Проблемы, которые проявляются не на демо, а на второй неделе реальной эксплуатации.

Пользователь ждёт ответа слишком долго

Запрос к крупной модели занимает 5–15 секунд. Без потоковой выдачи интерфейс выглядит зависшим, и пользователи закрывают страницу, не дождавшись результата.

Стоимость растёт нелинейно

Функция стала популярной, и счёт за токены вырос в пять раз. Ограничений на объём контекста и длины ответа не было заложено, как и кэширования.

Внешний провайдер недоступен

API внешней модели отдаёт 429 или таймаут, и вся функция продукта перестаёт работать. Резервного варианта и деградации не предусмотрено.

Нет ограничений на запросы

Один пользователь может отправить сотню запросов подряд и исчерпать квоту для всех остальных. Rate limiting проектируется вместе с функцией.

Тяжёлые задачи выполняются синхронно

Обработка документа на 200 страниц блокирует веб-процесс. Пользователь получает таймаут, а задача остаётся невыполненной.

Ответы не воспроизводимы

Одинаковый запрос даёт разные результаты, и при разборе жалобы невозможно понять, что именно было отправлено в модель и с какими параметрами.

Решения

Что входит в интеграцию

Инженерная часть проекта, от которой зависит, будет ли AI-функция удобной и устойчивой.

Проектирование контракта сервиса

Определяем синхронные и асинхронные сценарии, форматы ответов и поведение при ошибках — до написания кода.

  • Разделение запросов на быстрые и длительные
  • Версионирование API и обратная совместимость
  • Единый формат ошибок с понятными кодами
  • Идемпотентность для операций, которые могут повториться

Потоковая выдача и UX

Ответ отдаётся по мере генерации, поэтому пользователь видит текст через доли секунды после отправки запроса.

  • Server-Sent Events или WebSocket для потока токенов
  • Отображение промежуточного статуса при вызове инструментов
  • Корректная обработка обрыва соединения и повтор запроса
  • Индикация стоимости или расхода лимита, где это уместно

Очереди, кэш и экономия

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

  • Очереди для пакетной обработки документов и выгрузок
  • Семантический кэш: похожие запросы получают готовый ответ
  • Ограничение длины контекста и размера ответа на уровне сервиса
  • Учёт расхода токенов по пользователю и подразделению

Надёжность и наблюдаемость

Сервис должен деградировать предсказуемо, а не отказывать целиком при проблемах у провайдера модели.

  • Ретраи с экспоненциальной задержкой и ограничением попыток
  • Резервная модель или упрощённый сценарий при недоступности основной
  • Метрики: задержка, доля ошибок, расход токенов, попадание в кэш
  • Трассировка запроса от пользователя до вызова модели
Процесс

Порядок работ

Начинаем с расчёта стоимости и требований к задержке: они определяют архитектуру сильнее, чем выбор модели.

  1. 01 1 неделя

    Требования и расчёт

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

  2. 02 2–3 недели

    Прототип сервиса

    Реализуем минимальный контракт, подключаем модель, измеряем реальные задержки и расход токенов на тестовой нагрузке.

  3. 03 2–3 недели

    Оптимизация

    Добавляем кэширование, батчинг, потоковую выдачу. Проверяем поведение под нагрузкой и при отказе провайдера.

  4. 04 2 недели

    Выпуск и эксплуатация

    Включаем функцию для пользователей постепенно, настраиваем мониторинг, алерты по стоимости и регламент обновления промптов.

Как считается стоимость одного запроса к модели

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

Управлять стоимостью можно четырьмя способами: сокращать системную инструкцию и число подаваемых фрагментов, кэшировать повторяющиеся запросы, использовать компактную модель для простых шагов и ограничивать длину ответа. На практике сочетание этих мер снижает расходы на 40–70% относительно наивной реализации без потери качества.

Почему p95 важнее среднего времени ответа

Средняя задержка в две секунды может скрывать то, что каждый двадцатый запрос выполняется двадцать секунд. Пользователи запоминают именно медленные ответы, и именно они формируют впечатление о продукте.

Поэтому мы проектируем интерфейс и сервис вокруг p95 и p99: потоковая выдача текста маскирует общее время генерации, длительные задачи уходят в фон с уведомлением о готовности, а для запросов, превысивших порог, применяется более быстрая модель. Так продукт остаётся отзывчивым даже при тяжёлых сценариях.

Деградация вместо отказа

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

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

Частые вопросы

Для типового запроса с контекстом в 2–3 тысячи токенов и ответом на 500 токенов цена на облачных моделях среднего размера составляет доли рубля. Точная величина зависит от выбранной модели, длины контекста и объёма выходного текста. Мы всегда считаем стоимость на реальном профиле нагрузки: средний запрос, тяжёлый запрос и пиковый период, — потому что бюджет определяет пик, а не среднее.

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

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

Хранить нужно метаданные: идентификатор запроса, версию промпта и модели, расход токенов, задержку и результат проверки. Полные тексты сохраняются в зависимости от политики: они полезны для разбора инцидентов и накопления примеров для улучшения, но могут содержать персональные данные. Компромисс — хранить полные тексты ограниченный срок в обезличенном виде, а долгосрочно оставлять только выборку, отобранную для анализа качества.

Разработка AI-решений: другие направления

Смежные задачи, которые обычно решаются в одном проекте с этой.

Есть продукт, в который нужно встроить AI?

Расскажите про сценарий и ожидаемую нагрузку — посчитаем стоимость одного запроса и предложим архитектуру с учётом ваших ограничений.