Эксплуатация системы, основанной на большой языковой модели, не заканчивается её запуском или первоначальным повышением точности. Система может оставаться полностью доступной, одновременно молча соглашаясь с ошибочными решениями, быстро расходуя бюджет или во время сбоев переключаясь на модель, качество которой не проверялось. Поэтому пятая часть серии Running LLM systems in production посвящена повседневной эксплуатационной пригодности — уровню, который делает систему наблюдаемой, управляемой, останавливаемой и способной к восстановлению.
Наблюдайте за решением, а не только за сервисом
Традиционные метрики сервисов, такие как частота запросов и ошибок, время отклика и загрузка процессора, не показывают, принимает ли агент хорошие решения. Источник предлагает добавить специальный уровень мониторинга решений, включающий объём решений, долю автоматического исполнения, распределение составной уверенности, время работы каждого узла, случаи блокировки средствами безопасности, потребление токенов и затраты, частоту вмешательства людей и результаты скрытых оценок на выборках из производственного трафика.
Источник выделяет четыре семейства сигналов: решения, безопасность, затраты и производительность, а также качество. Если невозможно измерять всё, приоритет следует отдавать доле автоматического исполнения, блокировкам средствами безопасности, совокупным затратам на модели и доле решений системы, пересмотренных людьми.
Также рекомендуется разделить журналы на три уровня: операционные данные большого объёма, метаданные решения в пределах границ уверенности и необработанные или структурированные данные, подпадающие под шифрование и строгий контроль. Каждое решение должно иметь постоянный идентификатор decision_id, связывающий метрики, журналы, трассировки и журнал аудита, чтобы можно было расследовать отдельное решение от начала до конца.
Сделайте затраты измеримыми и ограничиваемыми
Не следует распределять вызовы моделей по разным частям кодовой базы, поскольку это затрудняет атрибуцию и контроль затрат. Вместо этого источник предлагает единый шлюз, через который проходят все вызовы и который рассчитывает количество токенов и затраты по арендатору, возможности и модели, а также применяет ограничения частоты и бюджета.
Инструменты снижения затрат располагаются в следующем порядке: не вызывать модель, когда достаточно детерминированного правила; объединять элементы в один вызов; временно кэшировать детерминированные результаты; выбирать меньшую модель для простых задач; затем сокращать контекст и ненужные инструкции. Также следует рассчитывать предполагаемое количество токенов до вызова, а не считать каждый запрос одной единицей, устанавливая общий потолок для платформы и ограничения на повторные попытки и неограниченные циклы инструментов.
Маршрутизация, откат и аварийный выключатель
На практике не существует одной модели для всех задач. Задачи с низким риском и большим объёмом можно направлять к меньшей модели, неоднозначные или чувствительные случаи — к более мощной, а для модели-судьи использовать другое семейство моделей, чтобы модели не разделяли одни и те же уязвимости. Каждая модель, присутствующая в маршруте маршрутизации или отката, должна проходить оценку, поскольку переход на альтернативную модель может изменить качество.
Во время сбоя провайдера следует использовать определённую цепочку отката с единым общим тайм-аутом, защитным интервалом, предотвращающим вызовы провайдера, о котором известно, что он неисправен, и ключами idempotency, чтобы не обработать решение дважды, если срок вызова истёк после его фактического успешного выполнения. Когда альтернатива неприемлема, решение следует передать человеку, а не скрывать ухудшение качества.
Что касается аварийного выключателя, источник предлагает реализовать его как общее эксплуатационное состояние, которое может быть глобальным либо назначаться для арендатора или возможности. Состояния включают: нормальную работу, HUMAN_ONLY для остановки автоматического исполнения при сохранении предложений для людей, и HALTED для полной остановки принятия решений. Если получить доступ к выключателю невозможно, безопасным поведением будет переход в режим проверки человеком, а не продолжение нормальной работы.
Архитектура, предотвращающая хаос
Источник связывает эксплуатационную пригодность с шестиугольной архитектурой, отделяющей доменную логику от пакетов провайдеров моделей с помощью интерфейса и адаптерных шлюзов. Это позволяет сменить провайдера без переписывания бизнес-логики и тестировать домен с использованием фиктивной модели без сети и затрат.
Базовая архитектура включает сервисы агентов без состояния, шлюз моделей, журнал аудита только для добавления записей, общее хранилище ограничений и аварийного выключателя, хранилище секретов и объектное хранилище для входных данных и чувствительных сведений. Источник также подчёркивает необходимость отдельной идентификации для каждого сервиса, минимального набора разрешений и проверки соответствия идентичности арендатора запросу на каждом переходе, особенно при использовании краткосрочных разрешений на делегирование для отложенных задач.
Почему это важно?
Практическая ценность здесь не в добавлении нового компонента, а в объединении критически важных точек управления в одном месте: шлюз, делающий замену модели возможной, одновременно измеряет затраты, применяет ограничения, управляет маршрутизацией и откатом и активирует остановку. Успех такого подхода по-прежнему зависит от фактического тестирования сценариев отказа, таких как сбой провайдера модели, активация аварийного выключателя, внезапная нагрузка и перезапуск узла во время выполняющегося решения. Без этих тестов механизмы восстановления остаются непроверенными предположениями.