Дмитрий Коваль

Антон, спасибо, здесь согласен: регион лучше сохранять в ключе baseline, а не смешивать при нехватке данных. Иначе различия инфраструктуры действительно могут скрыть деградацию. Расширение окна до 7 дней выглядит разумно, если за это время не менялись модель, маршрут и профиль нагрузки.

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

Если подходящего периода нет, лучше явно отметить нехватку данных и опираться на продуктовые SLO, чем строить убедительный, но нерелевантный baseline. А прошлогодние показатели оставить справочным контекстом, не основанием для алерта.

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

Отдельные ключи также упрощают учёт и отзыв доступа. Только стоит проверить, к чему именно привязан лимит — к ключу, проекту или всему аккаунту — и является ли он жёстким ограничением, а не просто уведомлением.

Да, вы правы — в примере ошибка: remaining, рассчитанный до семафора, не учитывает время в очереди и фактически продлевает дедлайн.

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

Тест с удержанием семафора до истечения дедлайна — отличная проверка. Спасибо, что заметили!

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

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

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

Спасибо, Антон! Рад, что дополнили друг друга. Именно на таких деталях и становится понятно, выдержит ли схема реальные сбои.

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

Если новая версия уходит в другую ветку, корректнее остановить replay со статусом «не покрыто записью». Это отдельная метрика покрытия, а не автоматическая регрессия или успешный тест. Само изменение вызова уже можно оценивать отдельно по бизнес-правилам.

Для продолжения такой ветки действительно нужен симулятор состояния или изолированный sandbox.

Антон, согласен: для операций с побочными эффектами reconciliation стоит считать обязательной частью процесса.

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

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

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

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

Спасибо, это хороший способ сделать расчёт cost per successful task точнее.

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

Родительский baseline берём иерархически. Сначала model × route без разделения по классу промпта. Если данных всё ещё мало — используем baseline модели в том же регионе и у того же провайдера. Маршруты между собой стараемся не смешивать: сеть, rate limits и балансировка дают слишком разный профиль latency.

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

Спасибо, хороший вопрос. Один общий anchor на весь сервис мы не используем — он действительно может скрыть деградацию, если разные маршруты или типы промптов дрейфуют в противоположных направлениях.

Anchor считаем отдельно для ключевых срезов: модель × маршрут × класс промпта. Общий показатель остаётся только для дашборда, но не участвует в алертах. Для низкотрафиковых маршрутов используем более широкий родительский baseline, пока не накопится достаточно данных.

После релиза тоже временно сравниваем с предыдущей версией, а новый anchor фиксируем только после стабильного окна. Идея с дневными медианами для сезонности мне нравится — сырые окна у нас давали похожий шум.