Agent Reliability Score показывает, почему AI agents ломаются не в модели, а в платформе. Ключ — контроль контекста и безопасные действия.
Сбой наблюдается, когда агент начинает действовать в реальном контуре. В нескольких кейсах сбой был не в модели, а в отсутствии platform-level гарантий. Чат-бот давал уверенные, но неверные ответы о политике возвратов. Поддержка придумывала несуществующие ограничения. Внутренний агент закрывал задачи на основе устаревшего контекста. Общий паттерн один: модель корректно обрабатывает входные данные, но сами данные невалидны. Без контрактов надежности платформа не контролирует ни актуальность (freshness), ни соответствие политике, ни безопасность действий.
Решение сдвигает фокус с качества модели на качество системы. Agent Reliability Score — это адаптация ML Test Score под агентные системы. Подход оценивает не «насколько умна модель», а «может ли платформа гарантировать корректное поведение». Это прагматичный сдвиг: агент — это не только inference, а цепочка действий. В одном запросе он может собрать контекст из RAG, вызвать API, применить бизнес-правила и создать side effect. Каждый шаг — потенциальная точка отказа. Trade-off очевиден: рост надежности требует ограничений, валидации и дополнительной инфраструктуры, что увеличивает latency и сложность.
На уровне реализации ключевой элемент — контракты на контекст (context integrity). Платформа должна валидировать источники данных до передачи их агенту. Это включает:
- контроль источников: схемы, формат, полнота
- метрики качества retrieval (retrieval quality) в продакшене
- контроль свежести (context freshness) через TTL и метаданные
- валидацию схем входных данных
- отслеживание зависимостей во время выполнения
Без этого RAG превращается в источник тихих ошибок. Типичный анти-паттерн: измерить качество retrieval на этапе разработки и перестать наблюдать его после релиза. Со временем данные меняются, индексы устаревают, релевантность падает — но система этого не видит.
Отдельный слой — безопасность и управление рисками. Контекст может быть отравлен (prompt injection) через документы или API. Агент не различает «данные» и «инструкции», если платформа не фильтрует вход. Аналогично с PII: объединение нескольких источников может создать полный профиль пользователя внутри одного prompt. Это уже не проблема модели — это проблема data pipeline. Платформа должна внедрять фильтрацию, детекцию аномалий и контроль утечек как обязательный этап.
Архитектурно появляется новая зона ответственности: orchestration и guardrails. Агент не должен бесконтрольно принимать решения. Платформа задаёт границы:
- лимиты на количество действий и время выполнения
- бюджет на вызовы (cost control)
- строгие зоны, где решения детерминированы
- fallback-стратегии при сбоях зависимостей
Без этих механизмов агент становится недетерминированным процессом с внешними эффектами. Ошибка уже не метрика, а инцидент.
Результат внедрения такого подхода — не рост «интеллекта» агента, а снижение неожиданных сбоев. Метрики напрямую не указаны, но эффект выражается в предсказуемости системы. Команды получают возможность видеть слабые места до продакшена. Agent Reliability Score в этом смысле — диагностический инструмент. Он не увеличивает итоговый балл автоматически, но делает пробелы явными.
Индустрия уже проходила этот этап с ML системами. Основной вывод тогда был прост: модель — это малая часть системы, остальное — инфраструктура. Агентные системы усиливают этот эффект. Без платформенных контрактов даже идеальная модель будет принимать неверные решения, потому что она опирается на неверный контекст.