Еженедельный отчёт по LLM-платформе: что смотреть CTO

Почему обычный дашборд не помогает

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

Проблема не в данных, а в форме. Когда LLM-платформа работает через несколько моделей и маршрутов, число метрик быстро растет. Через пять минут просмотра человек уже сравнивает линии, а не принимает решения. Такой экран полезен дежурному инженеру, но не для еженедельного чтения CTO.

У CTO обычно есть 10 минут, а не час. За это время он должен понять, стала ли платформа дороже, медленнее или рискованнее для продакшена. Если отчет не дает ясного ответа, его откладывают. Потом команда живет по ощущениям: "кажется, все нормально" или "вроде стало хуже". Для разговора о бюджете, SLA и приоритетах этого мало.

Хороший еженедельный отчет должен приводить к одному из трех действий:

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

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

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

Простой пример: задержка выросла на 12%. Сам по себе этот график мало что дает. Но если неделя к неделе трафик не изменился, доля дорогой модели выросла, а резервный провайдер включался дважды, картина уже ясна. CTO видит не "аномалию на графике", а конкретную проблему, цену этой проблемы и следующий шаг.

Что оставить в одном еженедельном срезе

Еженедельный отчет по LLM-платформе должен помещаться на один экран или на одну страницу для каждой платформы. Если данных больше, CTO начинает листать графики и теряет суть. Нужен срез, который отвечает на простой вопрос: неделя прошла нормально или что-то требует решения уже сейчас.

Сверху дайте короткую сводку. Достаточно нескольких строк с общим объемом, расходами, задержкой, ошибками и одним-двумя заметными сдвигами. Ниже оставляйте детали только по отклонениям. Если все в пределах нормы, не нужно раскрывать десять графиков по каждой модели, маршруту и команде.

Удобно держать отчет в четырех блоках: качество, надежность, стоимость и изменения. Сначала CTO видит, стало ли хуже то, что получает пользователь. Затем - были ли сбои, таймауты, рост ретраев и переключения на резервный маршрут. После этого - сколько потратили за неделю и почему сумма изменилась. В конце - что именно поменялось: релиз, новая модель, другой провайдер, правка промпта или обновление правил маршрутизации.

Такой порядок читается быстро. Например, расходы выросли на 18%, а задержка почти не изменилась. Значит, причина часто лежит не в трафике, а в смене маршрута или модели, и это стоит показать сразу в блоке изменений.

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

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

Какие метрики брать каждую неделю

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

Базовый набор выглядит так:

• сколько запросов прошло за неделю и сколько приложений реально отправляли трафик
• какая доля запросов завершилась успешно и почему остальные не дошли до ответа
• какой P50 и P95 по основным маршрутам
• сколько ушло денег в рублях и токенах, и сколько стоит средний запрос
• как распределился трафик по моделям и провайдерам, и что происходит с качеством на контрольном наборе

Важно читать эти метрики вместе, а не по отдельности. Расходы могут не измениться, но P95 уйдет вверх из-за того, что часть трафика переехала на более медленную модель. Или success rate останется высоким, но качество просядет: ответы формально приходят, а бизнес-задачу решают хуже.

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

Если трафик идет через единый шлюз, собирать такой срез заметно проще. Например, в RU LLM в одном контуре видны маршруты, провайдеры, биллинг и данные по запросам, поэтому легче понять, какая модель съедает бюджет, где растут таймауты и как ведут себя маршруты с размещением в РФ.

Какие события важнее графиков

График редко объясняет, почему цифра сдвинулась. CTO быстрее принимает решение, когда видит несколько событий недели: что поменялось в маршрутизации, кто дал сбой, где вырос риск и какой новый сценарий начал потреблять заметный трафик.

Для еженедельного отчета обычно хватает 4-6 таких строк. Каждая строка должна отвечать на один вопрос: это меняет стоимость, задержку, качество или регуляторный риск?

Удобный формат простой:

• что случилось
• когда началось и сколько длилось
• кого это затронуло
• что сделала команда
• нужно ли решение от CTO

Первое событие, которое почти всегда важнее красивого графика, - смена маршрута на другую модель. Если команда перевела трафик с одной модели на другую, в отчете нужна причина в одну фразу. Например: рост задержки, просадка качества на конкретном сценарии, лимиты у провайдера или попытка снизить цену запроса. Сразу добавьте итог: стало быстрее на 18%, дороже на 6% или жалоб не прибавилось.

Второе событие - сбой у провайдера дольше вашего внутреннего порога. Не "были краткие проблемы", а точная запись: провайдер не отвечал 27 минут при допустимом пороге 10 минут, часть трафика ушла на резервный маршрут, расходы выросли на столько-то. Для CTO это важнее средней недельной задержки, потому что такой сбой бьет по надежности и договоренностям с бизнесом.

Третье - запуск нового сценария с нормальным объемом. Часто именно он незаметно меняет весь профиль нагрузки. В понедельник команда включила LLM-проверку обращений в саппорте, а к пятнице этот поток уже съел 22% токенов. Это отдельная строка, даже если метрики качества пока ровные.

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

Случаи с персональными данными, аудитом и маскированием PII всегда выносите отдельно. Даже маленький инцидент CTO должен видеть без поиска по логам: какой запрос попал в разбор, сработало ли маскирование, сохранился ли аудит-трейл, нужны ли действия по 152-ФЗ. Если компания работает через RU LLM, сюда же стоит добавить, затронул ли случай data residency или маршруты, которые обслуживаются внутри РФ.

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

Как собрать отчет за 30 минут

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

Сначала зафиксируйте дату среза и границы отчета. Укажите, за какую неделю вы смотрите данные, какие системы входят в сводку и что вы исключили. Это спасает от путаницы. Например, не смешивайте прод и stage, а также не сводите в один итог рабочий трафик через единый шлюз и отдельные эксперименты команды.

Дальше возьмите один и тот же набор из 6-8 метрик за две недели: текущую и прошлую. Формат лучше простой: название метрики, значение за эту неделю, значение за прошлую, разница в процентах или в абсолюте. Этого хватает. Как только рядом появляются пять графиков по дням, отчет снова превращается в ленту, а не в рабочий документ.

Пороги отклонений задайте заранее, еще до просмотра чисел. Иначе команда начнет спорить по каждому движению. Для одной платформы это может быть рост стоимости на 10%, для другой - увеличение P95 задержки на 15% или скачок ошибок на 0,3 п.п. В сам отчет попадают только строки, где порог превышен. Остальные остаются фоном.

После цифр добавьте 3-5 событий, которые объясняют сдвиг. Одной строки на событие достаточно: что произошло, когда и какой был эффект. Обычно это смена маршрута, сбой у провайдера, новый крупный клиент, изменение промпта или отключенный cache в эксперименте. Короткая причина экономит больше времени, чем длинный комментарий под графиком.

В конце нужны не "наблюдения", а три решения на неделю. У каждого решения должен быть владелец и срок. Например: вернуть старый маршрут для дорогого сценария - владелец ML Lead, срок до среды. Или: проверить рост задержки в одном регионе - владелец SRE, срок до пятницы.

Если такой отчет не помещается на один экран или одну страницу, режьте детали. Хороший еженедельный отчет читают за пять минут, а не изучают как расследование.

Пример отчета для обычной недели

У банка есть LLM-помощник для операторов контакт-центра. Он подсказывает ответ, вытягивает детали из истории клиента и предлагает следующий шаг. CTO нужен не общий график, а короткая записка: что изменилось, где появился лишний компромисс и какое решение принять сегодня.

В понедельник банк открыл новую очередь обращений, и трафик вырос на 28% по сравнению с прошлой неделей. Пиковая нагрузка пришлась на середину дня, но SLA по времени ответа почти не просел: P95 вырос с 3,4 до 3,8 секунды. Ошибок маршрута и таймаутов не прибавилось, значит запас по мощности пока есть.

По деньгам неделя выглядит лучше. Один маршрут перевели на более дешевую модель, и средняя стоимость 1000 запросов в этой ветке снизилась на 16%. Проблема в другом: доля ручных правок оператором выросла с 12% до 19%. Экономия есть, но оператор стал чаще переписывать подсказку, а это уже скрытая цена.

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

Такой отчет можно уместить в пять строк:

• Трафик: +28% неделя к неделе после запуска новой очереди.
• Задержка: P95 3,8 секунды против 3,4, SLA держится.
• Стоимость: минус 16% на дешевом маршруте.
• Качество: ручные правки выросли с 12% до 19%.
• Действие команды: 32% сложных запросов вернули на прежнюю модель.

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

Отдельно стоит проверить промпт на дешевом маршруте. Часть правок может идти не из-за самой модели, а из-за слишком общего ответа или слабой инструкции по тону и структуре. Если компания работает через RU LLM, такой срез проще собрать в одном месте: видны стоимость, задержка, маршрут, переключения и история изменений.

Где CTO легко делает неверный вывод

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

Самая частая ловушка - смотреть только на среднюю задержку. Среднее может даже улучшиться, если большая часть коротких запросов стала быстрее, но хвост P95 или P99 вырос вдвое. Для чата это особенно неприятно: 8 из 10 ответов приходят быстро, а оставшиеся 2 ломают впечатление и бьют по SLA.

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

На недельный отчет всегда смотрите с поправкой на объем. Неделю с промо-кампанией, запуском нового сценария или просто сезонным пиком нельзя честно сравнивать с тихой неделей по сырым числам. Сначала нормализуйте метрики: стоимость на запрос, ошибки на тысячу вызовов, долю медленных ответов. Только потом делайте вывод.

Еще одна ошибка - смешивать причины сбоев. Ошибка модели, сетевой таймаут и сбой бизнес-логики выглядят как один красный столбик "ошибки", но решения у них разные. Если команда работает через маршрутизацию между несколькими провайдерами, всплеск 5xx на одном маршруте не значит, что сломался промпт или просела вся платформа.

Единичный скачок тоже легко переоценить. Один плохой день без контекста - не повод срочно менять модель, лимиты или кэширование. Сначала проверьте:

• это выброс или новый уровень
• метрика вышла за заранее заданный порог или нет
• сбой затронул один маршрут или весь трафик
• проблема видна в деньгах, задержке и качестве сразу или только в одном графике

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

Быстрая проверка перед отправкой

Хороший еженедельный отчет CTO читает за две минуты и сразу понимает, стало лучше, хуже или просто шумно. Если на первой строке нет короткого вывода, отчет уже проиграл. Нужен один абзац на 3-4 предложения: что произошло за неделю, где риск, что под контролем, какое решение может понадобиться.

Перед отправкой полезно пройтись по пяти вопросам.

Есть ли сверху краткий вывод, а не россыпь цифр? Фраза вроде "расход вырос на 14% из-за сдвига трафика на более дорогую модель, задержка в норме, инцидентов нет" работает лучше, чем таблица без комментария.

У каждой метрики есть ориентир и сдвиг к прошлой неделе? "P95 задержки 2,1 с при норме до 1,8 с, неделя к неделе +11%" читается сразу. Просто "P95 2,1 с" почти бесполезно.

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

Убрали ли вы все сырое, что мешает чтению? Логи, длинные выгрузки и скриншоты графиков на полстраницы редко помогают принять решение. CTO нужен вывод. Детали можно держать в приложении или в рабочем документе команды.

Есть ли следующий шаг с именем и сроком? Если после отчета непонятно, кто и что делает, это не управленческий документ, а хроника наблюдений.

Обычно слабое место одно и то же: команда честно собирает много данных, но не закрывает вопрос "что делать дальше". Поэтому последняя строка важнее половины графиков. Например: "Переключаем 20% трафика на более дешевую модель, проверяем качество на двух сценариях, отчет по результату в пятницу, владелец Петров".

Если хотя бы на один из этих вопросов ответ "нет", отчет лучше вернуть в черновик на 15 минут. Эти 15 минут почти всегда экономят лишнюю встречу и цепочку уточнений в чате.

Что делать дальше

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

Хороший шаблон держится на простом правиле: у каждой метрики есть действие. Если средняя задержка по рабочим маршрутам выросла выше вашего порога, команда проверяет провайдера, переключает маршрут или режет тяжелый трафик. Если доля дорогих моделей растет две недели подряд, вы пересматриваете policy routing, лимиты или кэширование. Цвет на графике сам по себе ничего не решает.

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

Если у вас единый OpenAI-совместимый эндпоинт, собрать такой отчет проще. В RU LLM в одном месте уже сходятся маршрутизация, биллинг, логи запросов и аудит обработки данных внутри РФ, поэтому платформенной команде не нужно вручную склеивать несколько систем.

Через месяц устройте короткую чистку отчета. Пройдитесь по каждой строке и спросите: какое решение мы приняли по этой метрике хотя бы один раз за последние четыре недели? Если ответа нет, метрику лучше убрать.

Обычно остаются вещи такого типа:

• стоимость на 1000 запросов или на один бизнес-сценарий
• задержка по основным маршрутам, а не по всему трафику сразу
• доля ошибок у провайдеров и число переключений маршрута
• расход по командам или продуктам
• инциденты по данным, маскированию PII и аудиту

Нормальный еженедельный отчет по LLM-платформе становится короче уже ко второму месяцу. Это хороший знак. Значит, в нем остались только те цифры, после которых команда действительно что-то делает.