Архитектура ИИ для производственных агентов: способы сбоев и слои контроля

Почему прототипы тормозят

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

Хорошие архитекторы сначала задаются вопросом «почему», а уже потом — «что». Без философии проектирования список компонентов — это просто чек-лист. С ней он превращается в рамку, охватывающую даже те проблемы, с которыми ещё никто не сталкивался.

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

Как на самом деле погибают системы ИИ

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

Галлюцинации как проблема поиска

Люди обычно относят галлюцинации к проблемам качества модели. С точки зрения архитектуры это может быть проблема с поиском информации, ошибка в управлении окном контекста или сбой в калибровке уверенности модели. Если попросить модель проанализировать 200-страничный документ, в который помещается всего 4 000 токенов, она не сможет понять, чего ей не хватает, поэтому выдумывает оставшуюся часть. Решение заключается в самой системе: точный поиск информации, ограничение объема контекста и четкое отражение уровня неопределенности через системные указания и структуру вывода.

Три вида дрейфа

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

Ошибки, пересекающие границы между агентами

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

Загрязнение контекста

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

Циклы повторных попыток

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

Внедрение через внешний контент

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

Отсутствие непрерывной оценки

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

Платформа как созвездие

Платформа корпоративного ИИ — это не монолит. Это кластер систем, каждая из которых имеет свои обязанности, интерфейсные контракты и способы сбоев. Проектирование должно охватывать весь жизненный цикл запроса (прием данных, сбор контекста, вызов модели, выполнение инструментов, проверка ответа, возможность наблюдения) с учетом того, что любой слой может выйти из строя.

Получение данных — это конвейер

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

Четыре уровня памяти агента

Память агента следует разделить на четыре уровня:

• Рабочая память — это окно контекста в рамках одной сессии.
• Эпизодическая память хранит краткое изложение прошлых разговоров, доступных в рамках одной сессии.
• Семантическая память представляет собой корпоративные знания, что соответствует слою RAG.

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

Смешивание этих уровней является частой причиной «загрязнения контекста» и неоднозначного поведения агентов в разных сессиях.

Многоагентные системы и передача контроля

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

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

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

Структурные ограничения

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

Поэтапные аварийные остановки

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

• Ограничение скорости замедляет работу, но не останавливает её полностью.
• Снижение функциональности приводит к отключению доступа к инструментам и переходу в режим, предназначенный только для отображения информации.
• Ручное направление отправляет все запросы к операторам-человекам.
• Завершение сессии плавно прекращает активные сессии операторов, сохраняя при этом информацию для аудита.
• Полная остановка неизменно выключает всё и фиксирует состояние системы для последующего анализа.

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

Наибольшее значение имеет возможность обратного действия

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

Уровень оценки

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

Использование модели в качестве судьи

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

Оценка внутри процесса развертывания

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

Наблюдаемость при открытом пространстве состояний

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

Для каждого запроса к LLM минимальный полезный набор данных включает:

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

Идентификаторы версий имеют наибольшее значение. Без них связь между снижением качества и конкретными изменениями становится предположением.

Три сигнала отклонения

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

Стоимость — это архитектура

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

Маршрутизация к самой дешевой подходящей модели

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

Семантическое кэширование

Обычное кэширование плохо справляется с приложениями на основе больших языковых моделей, поскольку запросы с одинаковым значением редко совпадают в виде строк. Семантическое кэширование индексирует ответы по степени близости в пространстве эмбеддингов, а не по точному тексту, достигая показателей успешного поиска от 30 до 60 процентов при высокой нагрузке, оставаясь при этом незаметным для слоя приложений. Для его работы необходим индекс ближайших соседей с быстрым приблизительным поиском, порог сходства ниже которого приводит к неудачному поиску, а также политика TTL, соответствующая скорости устаревания знаний.

Бюджеты токенов

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

Политика нулевого доверия для агентов

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

Идентификация каждого агента

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

Разделение инструкций и данных

Самым важным элементом безопасности в агентных ИИ является разделение инструкций и данных на отдельные уровни. Ненадежные источники ни в коем случае не должны загрязнять системные команды. Конкретно: внешние данные проходят через слой очистки перед тем, как попасть в контекст; полученный контент получает метку доверия, а модели указывается рассматривать текст с низким уровнем доверия как материал для анализа, а не как команды. Это аналогично параметризованным SQL-запросам: тот же принцип, но другая реализация.

Управление, встроенное в архитектуру

Управление ИИ — это не просто галочка в списке соответствия стандартам. Это непрерывная операционная дисциплина, требующая архитектурной поддержки. Организация не может управлять системой, которую не может наблюдать, не может проводить аудит системы, которая не ведет журналов, и не может обеспечивать соблюдение правил системой, которая не создавалась для этого. Управление должно быть встроено в саму архитектуру, а не добавлено позже.

Политики как код

Политики, хранящиеся в прозаических документах, невозможно управлять в масштабе. Необходима политика в виде кода: правила, читаемые машинами, находящиеся под контролем версий, подлежащие тестированию и оценке ИИ-шлюзом во время выполнения. Open Policy Agent с его языком Rego представляет собой зрелый вариант. Он может кодировать такие правила, как «никаких решений, касающихся клиентов в ЕС, на основе этой модели без флага человеческого рассмотрения» или «этот агент не может использовать инструмент оплаты для данных, отнесенных к категории PII». Оценка на уровне шлюза создает единый пункт обеспечения соблюдения правил и полную запись аудита, что заменяет разрозненные, несогласованные и невыполняемые политики, характерные для корпоративных ИИ сегодня.

Право на объяснение

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

Архитектура — это продукт

Готовая к использованию система ИИ определяется не качеством её языковой модели, а степенью сложности архитектуры, окружающей эту модель. Модель является компонентом — мощным, ценным и труднозаменяемым, но всё же лишь компонентом.

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

• Как избежать плохих результатов? С помощью ограничений.
• Как заметить снижение качества? С помощью оценок и возможностей наблюдения.
• Как координировать несколько компонентов ИИ? С помощью топологии множества агентов и протоколов передачи задач.
• Как не допустить роста затрат? С помощью бюджетов на токены и маршрутизации моделей.

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

Как нам удовлетворить требования регуляторов и аудиторов? С помощью архитектуры управления.

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