Девять архитектурных элементов для систем искусственного интеллекта производственного уровня.
Изучите план архитектуры, состоящий из девяти элементов — включающий сети с принципом нулевого доверия, уровни данных и механизмы связывания доказательств — для создания систем искусственного интеллекта с возможностью аудита и предназначенных для крупных предприятий.
Пробел между демо-версией и продакшном, о котором никто не говорит
Создать прототип ИИ-агента за выходные — дело легкое.
Подключите большую языковую модель к циклу вызова инструментов, соедините её с хранилищем векторов, добавьте интерфейс чата — и вот у вас уже что-то, что выглядит впечатляюще на демо-версии. Руководство в восторге, инженеры полны энтузиазма. Кто-то пишет на доске «пилотный проект в 3-м квартале».
Но как только система запускается в реальных условиях, наступает реальность. Почти каждая организация сталкивается с одинаковыми проблемами, в той или иной последовательности:
Агент осуществляет возврат средств неверной суммы — потому что никто не провёл чёткого разграничения между тем, что решает ИИ, и тем, что является фиксированной, исполняемой логикой. Аудит безопасности блокирует запуск — потому что данные клиентов тайно передавались через внешний API для встраивания. Кто-то из отдела соблюдения правил спрашивает, почему система дала определённый ответ месяцы назад — и нет возможности воссоздать логику принятия решения. Огромный скрипт агента становится недоступным для изменений — потому что техники формулировки запросов, бизнес-правила и интеграция с API переплетены в одном файле. Результаты меняются после обычной переиндексации — и никто не может воспроизвести то, что говорил ассистент в прошлом месяце.
Неприятная реальность заключается в следующем:
Выбор модели никогда не был сложной частью. Сложность заключается в структурировании системы вокруг этой модели.
Агентская система — это не просто тонкий слой ИИ, добавленный к скриптам. По сути это детерминистическая корпоративная система, в которой случайно присутствует ядро вероятностного рассуждения, и она требует той же инженерной дисциплины, что и платформа для обработки платежей или инфраструктура основного банковского обслуживания.
В этой серии представлен полный архитектурный план по созданию такой системы. Он основан на девяти ключевых решениях по проектированию — девяти основополагающих принципах, — которые каждая производственная агентская платформа должна соблюдать одновременно, поскольку при сбое в одном из них обычно сбиваются и остальные.
Наш пример: банк Aurora
Архитектура, описанная в абстрактных формулировках, редко находит практическое применение. Поэтому в этой серии мы будем основывать каждую концепцию на конкретном, пусть даже вымышленном, сценарии:
Bank Aurora — это средний розничный банк, насчитывающий 4 000 сотрудников. Он внедряет «Aurora Assistant» — платформу на основе агентов, предназначенную для: — ответа сотрудникам на вопросы, связанные с правилами и требованиями регулятора, — поддержки процесса выдачи кредитов (поиск документов, проверка данных, составление решений), — а также управления задачами обслуживания клиентов, такими как возврат средств, поиск информации о счетах и направление заявок.
Ограничения, с которыми сталкивается Bank Aurora, полностью соответствуют тем, с которыми сталкиваются большинство реальных предприятий:
- Личные данные клиентов не могут покидать собственную инфраструктуру банка.
- Любое автоматизированное решение должно быть объяснимым для регулятора по его запросу.
Помните об этих пяти ограничениях во время чтения — каждый из девяти принципов был создан именно для решения подобных ограничений.
Пять руководящих принципов
Прежде чем перейти к самим принципам, полезно ознакомиться с лежащей в их основе философией:
- Рассматривайте модель как один из многих компонентов, а не как саму архитектуру. Модели заменяются каждые несколько месяцев; ваша архитектура должна выдерживать такие изменения.
- Внутри системы следует сохранять вероятностный подход к принятию решений, но границы действий должны быть детерминированными. ГЛМ может свободно мыслить, однако все действия должны выполняться через фиксированный код.
- Убедитесь, что каждое действие создаёт запись. Если невозможно повторить принятое решение, его нельзя будет защитить позже.
- Изолируйте компоненты в зависимости от уровня доверия и контролируйте каждый запрос на доступ. Агенты обладают способностями, и именно поэтому они представляют риск — сознательно сдерживайте этот риск.
- Разрабатывайте систему так, будто скоро состоится аудит и будто вам позвонят в 3 часа ночи. Рано или поздно оба этих сценария произойдут.
Теперь рассмотрим по очереди каждый из основных принципов — что они означают, почему именно такая структура является правильной, сопутствующую диаграмму, конкретный пример и последствия их игнорирования.
Принцип 1 — Логическая архитектура: почему шесть слоёв — это правильно
Вопрос здесь прост в формулировке: каковы основные составляющие системы и какой слой несет какую ответственность?
Платформа с агентами делится на шесть логических слоев.
Почему именно шесть, а не три или девять?
Традиционная трехуровневая модель — представление, логика, данные — упускает из виду именно те элементы, которые делают систему с агентами уникальной: оркестрацию, выбор модели, интеграцию инструментов и границы доверия. С другой стороны, разделение на девять отдельных компонентов часто приводит к разрыву функциональности, которая на самом деле должна оставаться целой.
Оказывается, шесть — это минимальное количество слоев, при котором у каждого есть одна задача, один ответственный и одна причина для изменений. Можно это проверить, задав вопрос по каждому слою: может ли этот слой измениться самостоятельно, не заставляя при этом меняться все остальные слои?
- Слой опыта (L1) постоянно меняется — появляются новые интерфейсы, каналы и требования к фронт-энду.
- Оркестрация (L2) изменяется с каждым новым случаем использования, который вы добавляете.
- Мышление (L3) меняется каждый раз, когда появляется более совершенная модель, поэтому она должна быть заменяемой без вмешательства в другие компоненты.
- Интеграция (L4) изменяется каждый раз, когда бизнес подключает новую систему.
- Данные (L5) медленно меняются сами по себе, но правила управления ими меняются по мере развития регулирования.
- Управление (L6) находится отдельно в качестве общего элемента, а не нижнего слоя, поскольку вопросы идентификации, аудита, оценки, ограничений и контроля затрат должны влиять на все остальные слои, а не ограничиваться только основой стека.
Полезной моделью для понимания является кухня ресторана: она разделена на зоны — гриль, обжарка, выпечка — так что каждый повар может специализироваться, а шеф-повар может заменить одну из зон без необходимости полной реконструкции всей кухни.
Aurora на практике: из-за требования к суверенитету, описанного во Втором столпе, банку Aurora в конечном итоге необходимо заменить внешний LLM на самостоятельно размещаемый. Поскольку процесс рассуждений изолирован в своем слое, это сводится к простой замене настроек маршрутизации внутри уровня L3 — не требуется интеграция никаких инструментов, и промпты не нужно переписывать.
Если пропустить этот шаг: каждый новый случай использования превращается в правку одного объемного, запутанного файла. Замена моделей становится нецелесообразной. Никто не может с уверенностью сказать, где на самом деле расположена логика аудита.
Вывод: слои существуют для обозначения мест, где допускаются изменения. Их правильная разработка означает проектирование «швов» системы, а не только её компонентов.
Второй принцип — физическая архитектура: почему возможно автономное развертывание
Вопрос, на который нужно ответить: где физически работает система и что — если вообще что-то — допускается к выходу за пределы вашей собственной зоны?
Под «автономным» в этом контексте подразумевается, что модели, данные, эмбеддинги и следы выполнения остаются внутри инфраструктуры, находящейся под вашим контролем, причем единственным путём во внешний мир служит один зарегистрированный и фильтрующий шлюз.
Почему сейчас существует такой вариант, если несколько лет назад он казался нереалистичным?
- Модели с открытой архитектурой сократили разрыв с закрытыми моделями. Теперь такие модели, как Llama 3.x, Qwen 2.5 и Mistral, можно разместить на собственном сервере, при этом они обеспечивают качество результатов, сопоставимое с профессиональными решениями, для классификации, извлечения информации, составления кратких изложений и ответов на вопросы с использованием технологии RAG.
- Квантизация делает их доступными по цене. Технологии 4-битной квантизации позволяют одной GPU объемом 80 ГБ обслуживать модели с 70 миллиардами параметров, а для более мелких моделей требуется гораздо меньше оборудования.
- Инфраструктура для обработки запросов уже сформирована. vLLM обеспечивает непрерывную обработку запросов пакетами и высокую производительность для промышленного использования, Ollama идеально подходит для разработки, а Kubernetes может координировать работу таких моделей так же, как и любых других сервисов.
Важная нюанс: выбор подхода, при котором в первую очередь учитывается суверенитет данных, не означает полного запрета на использование внешних моделей. Это означает, что любой запрос, выходящий за пределы системы, осуществляется по желанию, ограничивается конкретной категорией данных и направляется через единственный шлюз — он никогда не запускается автоматически по умолчанию. Именно поэтому шлюз выхода изображается как одни двери: одна охраняемая дверь лучше, чем двадцать незапертых окон.
Аврора на практике: всё конфиденциальное — включая данные документов клиентов, трассы выполнения операций агентами и персональные данные — остаётся внутри системы. Единственный тип трафика, разрешённый к выходу, — это анонимизированные запросы по рыночным тарифам, причём даже они проходят через шлюз, который фиксирует каждый переданный байт.
Если вы этого не сделаете: стандартная настройка некоторых инструментов SaaS автоматически отправляет записи разговоров клиентов третьему поставщику. В результате ваша платформа для мониторинга хранит данные с персональной информацией на серверах за пределами страны. Проверка безопасности проваливается, и вместе с ней проваливается и проект.
Вывод: границы системы — это решение, которое вы должны принимать осознанно. Если вы этого не сделаете явно, стандартная конфигурация поставщика сделает это за вас.
Элемент 3 — Модель C4: правильная документация
Вопрос: Как документировать систему так, чтобы каждая аудитория видела именно тот уровень деталей, который ей нужен?
Модель C4, разработанная Саймоном Брауном, предоставляет четыре уровня масштабирования — можно представить себе это как панорамирование и увеличение масштаба на карте.
Почему модель C4 так хорошо подходит для агентных систем?
- Агентные системы по своей природе сложны для понимания. Вопрос «где на самом деле находится агент?» не имеет однозначного ответа. Модель C4 заставляет быть точным: агент — это не просто отдельный блок на диаграмме, а совокупность контейнеров (среда выполнения, шлюз, различные хранилища), которые обмениваются сообщениями. Модель C4 выявляет эти обмены вместо того, чтобы скрывать их.
Aurora на практике: Когда регулирующий орган запрашивает, какие именно компоненты могут иметь доступ к персональным данным клиентов, Aurora может дать ответ уже к концу дня. Команда показывает диаграмму контейнеров с пометками зон, введенными в Разделе 4, а также диаграмму компонентов для среды выполнения агента — обе создаются непосредственно на основе текущего состояния репозитория и хранятся вместе с кодом, из которого они были сгенерированы.
Без такой дисциплины: новые сотрудники вынуждены разбираться в архитектуре, анализируя исходный код. Аудиторам предоставляют презентацию из 60 слайдов, устаревшую на 14 месяцев. Каждое разногласие по поводу архитектуры превращается в споры о фигурах на доске.
Вывод: документация выступает в качестве интерфейса между вашей архитектурой и всеми людьми, которым необходимо ей доверять. C4 превращает этот интерфейс в что-то версионируемое и подлежащее ревизии, вместо статического объекта.
Четвертый принцип — сети с нулевым доверием: почему именно пять зон
Вопрос: Как ограничить ущерб, если что-то подвергается взлому — а это рано или поздно произойдет?
Подход с нулевым доверием означает отсутствие какого-либо подразумеваемого доверия нигде: каждый запрос проходит аутентификацию (с помощью mTLS и идентификаторов рабочих нагрузок), авторизацию через проверку политик и шифрование, даже для трафика, который никогда не покидает собственную сеть. Для агентной платформы правильная сегментация включает пять зон:
Почему ровно пять?
Поскольку каждая граница должна разделять по-настоящему разный уровень доверия — а агенты вводят уровень доверия, с которым традиционные архитектуры просто никогда не сталкивались:
- Z1, периферия — сюда сначала поступает недоверенный трафик. Она находится под постоянной атакой, поэтому предполагается, что она уже скомпрометирована.
- Z2, слой приложений — обслуживает конечных пользователей напрямую. Находится в состоянии частичного доверия.
Менее пяти зон приведут к снижению четкости границ, разделяющих действительно разные уровни доверия. Более пяти зон лишь создадут дополнительные барьеры, не вводя никаких новых границ доверия. Ровно пять — это идеальное количество.
Aurora на практике: злоумышленник вводит команду через скомпрометированную веб-страницу, пытаясь обмануть исследовательского подагента, чтобы тот загрузил данные о зарплатах сотрудников. Политика зоны полностью блокирует путь от Z3 к системам HR, поскольку область действия этого сегмента просто не включает системы HR. Хаб фиксирует попытку, и злоумышленник уходит с информацией только из открытых веб-источников. Агент был манипулирован; данные банка остались нетронутыми.
Без такой сегментации: один утекший ключ API-коннектора позволит злоумышленнику или злонамеренному агенту получить прямой, без препятствий доступ ко всему уровню данных.
Вывод: агенты значительно увеличивают риск бокового перемещения в сети. Правильное зонирование превращает скомпрометированного агента из повода для сенсаций в простой зарегистрированный событие.
Пилот 5 — Интеграция по принципу «центр и спицы»: оптимальная модель для агентов
Вопрос: как агентам можно подключаться к более чем 20 корпоративным системам, не превращая слой интеграции в неконтролируемую «спагетти-систему»?
Ответ — единый центр интеграции, окруженный сертифицированными спицами.
Почему это особенно важно для агентов? Посмотрите на цифры. Прямое подключение всех систем дает 10 систем в сочетании с 8 агентами, то есть 80 отдельных интеграций. Если же всё направлять через центр, потребуется лишь 10 спиц плюс 8 подключений к агентам — всего 18 связей.
Каждая прямая точка-точка связи — это место, где учетные данные закодированы в коде, логи игнорируются, а поведение системы тихо отклоняется от остальной части. Умножьте это на 80 соединений, и у вас получится 80 мест, в которые аудитор не может полностью заглянуть. Агенты усугубляют ситуацию, а не улучшают её, поскольку каждый новый агент стремится получить доступ ко всему.
Централизация через хаб позволяет контролировать четыре важных аспекта:
1. Посредничество в аутентификации — хаб хранит реальные учетные данные Salesforce, в то время как агенты имеют только ограниченный и возможный к отзыву токен хаба. Отозвав один токен, вы блокируете только одного агента, и ничего больше. 2. Перевод схемы — слово «клиент» может означать три разных понятия в зависимости от того, речь идет о SAP, CRM или службе поддержки. Хаб урегулирует это единожды, вместо того чтобы заставлять восемь отдельных кодовых баз агентов делать это самостоятельно. 3. Надежность — ограничение скорости и механизмы защиты в хабе предотвращают, чтобы один нестабильный агент вызвал цепную реакцию повторных попыток среди всего количества агентов. 4. Единая точка аудита — единый стандартизированный формат логов, одно место для ответа на вопрос «какой агент изменял какую запись, когда и в каких пределах?»
Дополнительным преимуществом является то, что серверы инструментов в стиле MCP позволяют превращать отдельные компоненты в стандартизированные, подключаемые элементы вместо одноразового кода для интеграции.
Как это работает в Aurora: запуск ServiceNow как системы №21 означает создание одного такого компонента. Начиная с следующего дня каждый агент может использовать его в рамках той же системы аутентификации, тех же ограничений на количество запросов и той же системы отслеживания действий, что и 20 других систем. Если бы пришлось реализовывать интеграцию поочередно, это потребовало бы восьми отдельных проектов по интеграции и восьми отдельных передач данных учетных данных.
Без такого подхода: у каждого агента остается собственная копия пароля Salesforce. Невозможно отследить, какой агент изменил конкретную запись клиента. Для добавления нового инструмента требуется целый квартал работы инженеров.
Вывод: хаб выполняет для инструментов ту же функцию, что и руководитель — для агентов: является единственной полностью оснащенной точкой входа.
Элемент 6 — Архитектура данных: почему необходимы отдельные уровни
Вопрос: как следует структурировать данные, чтобы можно было воспроизводить ответы, удалять записи по требованию и сохранять контроль над всей системой?
Ответ — пять уровней, расположенных в виде конвейера:
T0 — Исходные системы. Это системы хранения первоначальных данных. Они не принадлежат вам и меняются по собственному графику без предупреждения. T1 — Чистая зона сохранения данных. Копии всех данных в том виде, в котором они поступают. Это основная точка для воссоздания данных; их нельзя редактировать или удалять, за исключением случаев, предусмотренных четкой политикой хранения. T2 — Очищенные данные. Данные, отфильтрованные, дедуплицированные, разделенные на части, маркированные по критериям персональной информации и дополненные идентификаторами происхождения. T3 — Слой обслуживания. Векторные индексы, графы знаний, семантические кэши — все это объекты, которые можно воссоздать из T2 по мере необходимости. T4 — Данные, сгенерированные агентами. Журналы разговоров, «память» системы, трейсы и полученные результаты. Этот уровень предназначен только для дополнения данных, планируется редко заранее и часто содержит самую конфиденциальную информацию во всей системе.
Почему именно пять уровней?
Если это напоминает знакомую архитектуру медальонов — бронза, серебро, золото, — это сделано намеренно; уровни T1–T3 соответствуют именно этой устоявшейся схеме. В контексте агентов добавляются два уровня по краям: четкое разделение на входных данных (T0, поскольку необходимо четко определить контракты обработки) и уровень для результатов работы агентов (T4, поскольку продукты деятельности агентов также являются данными, требующими собственных правил хранения, защиты конфиденциальности и аудита).
Структурирование данных по уровням превращает две иначе сложные проблемы в рутинную работу:
1. Воспроизводимость. Вместо того чтобы ситуация «мы изменили стратегию разбиения на части, и теперь ответы отличаются» превращалась в кризис, достаточно за одну ночь пересоздать T3 на основе T2. Если модель повреждена, её можно воссоздать из T1. Не требуется повторно сканировать исходные источники данных.
2. Удаление. Когда клиент воспользуется своим правом на удаление согласно GDPR, наличие чёткой цепочки связей позволяет запросу на удаление детерминированно проходить через T1, T2, T3 и T4 по идентификатору — без необходимости вручную разбираться в структуре данных.
Основное правило, лежащее в основе всего этого: индекс векторов — это кэш, а не источник истины.
Как это происходит в Aurora: отдел тестирования обнаружил, что логика разбиения данных незаметно удаляла строки таблиц. Aurora за одну ночь восстановила два миллиона документов из T2 с использованием исправленного инструмента разбиения, без необходимости повторной обработки каких-либо источниковых систем и без опасений по поводу потери исторических данных. Через месяц команда смогла воссоздать и сравнить способы ответа на определенный вопрос до и после устранения ошибки.
Без разделения на уровни: хранилище векторов становится единственной копией данных. Удаления в исходном источнике никогда не передаются дальше. На вопрос вроде «Что сказал ассистент этому клиенту в марте?» просто невозможно ответить.
Вывод: проектируйте архитектуру данных с учетом необходимости последующей перестройки и удалений, которые вы обязаны выполнить по закону.
Столп 7 — Дизайн на основе агентов: почему система с руководителем и подагентами лучше монолита
Вопрос заключается в следующем: как следует структурировать «общество» агентов, составляющих вашу систему?
Паттерн, проверенный на практике, — это оркестратор-работник: один руководитель определяет общую цель, а набор подагентов выполняют узкие, специализированные задачи.
Почему разделение обязанностей лучше, чем создание одного огромного агента с пятьюдесятью дополнительными инструментами?
1. Контекст быстро теряет четкость. Когда одному агенту приходится использовать пятьдесят инструментов и выполнять задачу без четких критериев завершения, его эффективность снижается — происходят неверный выбор инструментов, забывание о ограничениях, потеря нити выполнения задачи. Специалист, обладающий пятью инструментами и четко определенными задачами, гораздо надежнее. 2. Это можно проверить на практике. Нет осмысленного способа проведения модульных тестов для огромных многострочных запросов. Однако можно создать отдельный набор тестов для каждого подагента — например, 200 тестовых случаев для исследователя и 50 для писателя. Это превращает тестирование на предмет регрессии во что-то реальное и повторяемое. 3> Появляется единая точка контроля. Руководитель становится местом, где можно устанавливать бюджеты (максимум 12 шагов или 0,40 евро за задачу), управлять попытками повторного выполнения, инициировать вмешательство человека и обеспечивать контроль на каждом этапе передачи задач. 4. Работа выполняется параллельно, а компоненты можно заменять.
Подагенты могут работать одновременно, и любой из них можно заменить — более мощным LLM, дешевле стоящим вариантом или полностью детерминированным механизмом поиска — без нарушения работы остальной части системы.
Стоит подчеркнуть, что «подагент» не означает «LLM на самом низком уровне». В архитектуре Aurora подагент, отвечающий за расчёт стоимости, вообще не содержит LLM — это детерминированный код, обёрнутый в интерфейс в стиле агента. Это предвосхищает принципы, изложенные в Пилларе 8.
Аврора на практике: процесс оказания кредитной помощи делится на роль исследователя (получение документов политики), проверяющего (верификация документов), калькулятора (расчёт платежеспособности с использованием простого кода) и автора (составление письма для клиента). Каждая из этих ролей оценивается, имеет свою версию и находится в независимом управлении. Если качество текста, написанного автором, снижается после замены модели, исправляется именно этот специалист, а не вся сложная система целиком.
Если пропустить этот элемент: в итоге получится мега-агент с семьюдесятью инструментами, который время от времени вызывает API возврата средств дважды по причинам, которые невозможно определить, и все боятся что-либо менять в нём.
Вывод: разделение работы связано не только с повышением эффективности. В системах агентов это и есть основа надёжности.
Элемент 8 — Детерминизм против рассуждений: самое важное решение
Вопрос: в какой именно части системы вы позволяете вероятностным алгоритмам ИИ принимать решения, а где поведение определяется кодом и правилами?
Это ключевой принцип — все остальные существуют для поддержки или обеспечения выполнения ответа, который вы здесь дадите.
Руководящий принцип прост:
LLM предлагают варианты. Детерминистические системы принимают решения.
Используйте LLM там, где они демонстрируют наилучшие результаты: для классификации, извлечения информации, составления текстов, планирования. Используйте детерминистический код там, где требуются нормативные правила и надежная инженерия: для проверки данных, перевода средств, изменения состояния системы, обеспечения соответствия правилам.
На практике это означает рассмотрение ваших рабочих процессов как машин состояний, при которых LLM участвует в принятии решений только в определенных, перечисленных точках, а обычный код обрабатывает всё остальное.
Почему это считается самым важным дизайнерским решением? Потому что оно определяет всё остальное, что следует за ним:
1. Надежность — пути, связанные с деньгами, не должны предполагать непредвиденного поведения.
2. Возможность аудита — поскольку точки принятия решений перечисляемы, можно указать каждую точку, где было применено суждение.
3. Контроль затрат — вы избегаете траты токенов на задачи, которые уже могут быть решены бесплатно с помощью простого оператора if.
4. Согласованность архитектуры — именно в модуле-надзирателе из Части 7 вводится эта граница, хаб из Части 5 обеспечивает её соблюдение на уровне инструментов, зоны из Части 4 содержат все возможные сбои, а хранилище доказательств из Части 9 позволяет после события установить, что на самом деле произошло.
Aurora в практике — процесс возврата средств:
- LLM в зоне обработки логики: читает электронное письмо клиента и извлекает структурированные поля —
amount: €145,reason: damaged goods,sentiment: frustrated. Этот шаг носит вероятностный характер, что является приемлемым, поскольку он лишь заполняет форму. - Детерминистический механизм принятия решений: суммы до €200 утверждаются автоматически; суммы от €200 до €1,000 проходят проверку на основе правил; суммы выше €1,000 требуют подтверждения человеком. LLM никогда не имеет полномочий на перевод средств — он может только предложить сумму, а решение о том, что с ней делать, принимается исключительно кодом.
Оба крайних варианта здесь опасны, именно поэтому необходимо придерживаться среднего пути:
Позволение большой языковой модели решать всё («просто пусть агент с этим разбирается») приводит к тому, что по электронной почте с вставленным запросом пользователь получает разрешение на возврат 50 000 евро. Когда всё решают правила, система не может даже распарсить обычное письмо — фактически это возврат к уровню 1995 года.
Вывод: полная автономия большой языковой модели — это лишь трюк для демонстраций; полная жесткость, основанная на правилах, уже устарела. В производственных системах необходима тщательно спланированная и задокументированная структура, определяющая, где применяется каждый режим — и правильное создание такой структуры является самым важным решением при проектировании всей системы.
Принцип 9 — Связывание с доказательствами/цитирование: почему это обеспечивает защиту при аудите
Вопрос: как сделать каждый результат защищаемым — спустя месяцы или даже годы, для аудитора, активно ищущего ошибки?
Каждое фактическое утверждение должно быть связано с источником доказательств, а весь ход принятия решений должен оставаться неизменным после записи:
Почему это выдерживает проверку? Потому что оно обеспечивает три гарантии одновременно:
1. Фильтрация галлюцинаций. Если нет цитаты, значит, нет публикации. Когда на этапе генерации ответа невозможно указать действительный источник, результат помечается или подавляется. Это превращает принцип «просто доверяйте модели» в обязательное, механически реализуемое правило.
2. Полная возможность воспроизведения. Если кто-то спросит: «Почему система отреагировала именно так 3 марта?», вы можете воссоздать точную последовательность событий — первоначальный вопрос, извлеченные фрагменты, версию запроса, версию модели, сгенерированный ответ и ссылки на него. Вместо фразы «мы считаем» вы предоставляете реальные записи.
3. Чёткость определения корневой причины. Когда результат оказывается неверным, вы можете сразу определить тип ошибки: была ли это ошибка при извлечении информации (были взяты неверные доказательства) или ошибка в логических рассуждениях (были взяты верные доказательства, но они были неправильно интерпретированы)? Для устранения этих проблем требуются совершенно разные решения, и без точных доказательств невозможно отличить одну от другой.
Аврора на практике: ассистент отвечает на вопрос о условиях штрафов, ссылаясь на credit_policy_v12.pdf, страница 14, sha256:9f2c…. Позже, когда выходит версия политики 13, прежний ответ по-прежнему отражает именно ту информацию, которая была актуальна в момент его дачи, поскольку цитируемые данные фиксируются с помощью хэша, а не загружаются заново динамически. Специалист по соответствию может одобрить его, так как вся цепочка действий можно воспроизвести, она защищена от изменений и имеет корректные временные метки.
Если пропустить это, то: вашей единственной защитой во время инцидента или аудита станет фраза «так сказала модель». Вы теряете возможность отличить проблему качества данных от сбоя в логике рассуждений. Регуляторы назовут такую систему «черным ящиком» — а черные ящики закрывают.
Вывод: если система не может сослаться на источник, ее не публикуют.
Как взаимосвязаны девять основ
Эти девять элементов — это не просто список отдельных аспектов; они образуют единую целостную структуру с ядром:
Если убрать хотя бы одну из основ, остальные начинают разрушаться. Если исключить слой центрального узла и радиусов (5), детерминизм (8) больше невозможно обеспечить на уровне вызова инструментов. Если убрать сортировку данных (6), у механизма связывания доказательств (9) не остается ничего надежного для ссылки. Если исключить документацию C4 (3), теряется возможность объяснить оставшуюся архитектуру во время аудита. Они работают только как единый комплекс — либо все девять элементов соблюдаются, либо вся структура рушится.
Что будет в этой серии
Каждая следующая часть станет полным углубленным исследованием: руководящий принцип, сопровождающая диаграмма, конкретный пример из сценария банка Aurora, выборы технологий, распространенные антипаттерны, которых следует избегать, и практический чек-лист для разработки.
К 2026 году наличие мощной модели больше не является преимуществом — ключ API можно получить любой.
Именно архитектура отличает те системы, которые сохраняют работоспособность в долгосрочной перспективе. Команды, которым удастся внедрить агентные системы в регулируемые, высокорискованные среды, будут теми, кто понял истинную сущность задачи: создание детерминированной корпоративной системы, в которой случайно присутствует механизм вероятностного вывода.
Девять основополагающих принципов. Девять решений. Необходимо сделать все их правильно одновременно.
Далее — Часть 1: Логическая архитектура, где будет пошагово строиться шестислойная структура, четко определяться контракты между каждой парой слоев, а также подробно рассматриваться антипаттерны, превращающие кодовые базы агентов в неконтролируемый беспорядок.