Архітектура ШІ для виробничих агентів: способи збоїв та контрольні шари

Чому прототипи зазнають невдач

Системи штучного інтелекту для виробництва рідко зазнають краху через слабкість моделей. Вони зазнають краху тому, що архітектура, яка оточує модель, ніколи не сприймала недетермінізм як обмеження проектування. Майже кожне подальше рішення формується під впливом трьох протиріч: можливостей проти контрольованості, затримки проти точності та автономії проти підзвітності.

Хороші архітектори спочатку запитують «чому», а вже потім «що». Без філософії проектування список компонентів є лише чек-листом. З нею він перетворюється на основу, яка також охоплює проблеми, з якими ще ніхто не стикався.

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

Як насправді гинуть системи ШІ

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

Галюцинації як проблема пошуку

Люди зазвичай відносять галюцинації до проблем якості моделі. З точки зору архітектури це може бути проблема з пошуком інформації, помилка у керуванні вікном контексту чи невдача у калібруванні рівня впевненості. Якщо попросити модель проаналізувати 200-сторінковий документ, коли вміщується лише 4 000 токенів, вона не зможе зрозуміти, чого бракує, тому вигадує решту. Рішення полягає у самій системі: точний пошук інформації, обмеження кількості контексту та чітке відображення невизначеностей через системні інструкції та схему вихідних даних.

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

Команди часто об’єднують у одне три різні аспекти. Дрейф моделі виникає, коли постачальник оновлює базову модель, і її поведінка змінюється, хоча з вашого боку нічого не впроваджувалося. Дрейф даних відбувається, коли змінюються вхідні дані – наприклад, коли співробітник служби підтримки, який звик до запитів до 2024 року, починає мати труднощі з запитаннями про нові продукти. Дрейф знань виникає, коли світ розвивається, а те, чого навчилася модель, стає застарілим. Кожен з цих випадків вимагає свого способу виявлення та усунення.

Помилки, які перетинають межі агентів

Системи з кількома агентами створюють ще більш складну проблему. Агент A отримує трохи неправильний результат, агент B сприймає його як істину, а агент C вживає незворотних дій на основі помилкових міркувань B. Як тільки виникає помилка, з’ясувати, де вона почалась, майже неможливо. Допомагають три заходи безпеки: агенти обмінюються показниками довіри, передача даних нижче певного рівня довіри активує захисний механізм, а кожен агент записує інформацію лише у журнал аудиту з можливістю додавання нових записів.

Забруднення контексту

Довгі розмови та велика кількість історій викликів інструментів заповнюють вікно контексту матеріалом, який погіршує продуктивність. Увага розсіюється серед все більшої кількості інформації, а ключові інструкції опиняються ближче до центру, де увага найслабша. Архітекторам потрібен цілеспрямований життєвий цикл контексту: механізми для стиснення інформації, стратегії її узагальнення та чітке розділення між робочою пам’яттю та довгостроковою пам’яттю.

Цикли повторних спроб

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

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

Агент, який читає електронні листи, обробляє документи або переглядає Інтернет, може натрапити на контент із ворожими інструкціями, спрямованими на його захоплення. Це не питання безпеки моделі. Це класична атака ін’єкції на межі між надійними та ненадійними даними. Заходи захисту є структурними: виконання в ізольованому середовищі, суворе розділення рівня інструкцій та рівня даних, а також перевірка результатів за встановленим схемою перед будь-якими подальшими діями.

Відсутність постійної оцінки

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

Платформа як сузір’я

Платформа корпоративного ШІ — це не моноліт. Це кластер систем, кожна з яких має власні обов’язки, контракти інтерфейсу та способи виникнення несправностей. Проектування має охоплювати весь життєвий цикл запиту (прийом даних, формування контексту, виклик моделі, виконання інструментів, перевірка відповіді, можливості моніторингу), при цьому слід враховувати, що будь-який рівень може зламатися.

Отримання даних — це конвеєр

Генерація з підсиленням за допомогою пошуку є складнішою, ніж може здатися з назви. Система для продакшну — це не просто вбудовування документів, запит до векторів та вставка контексту. Це конвеєр із принаймні п’ятьма етапами, кожен з яких може спричинити проблеми: прийом та розділення на частини, вибір моделі для вбудовування та її версіонування, створення індексу та частота оновлення, ранжування результатів пошуку за допомогою поєднання щільних та розріджених методів, а також формування контексту з використанням порогів релевантності. Кожен етап потребує власних показників, і зміна в одному може погіршити роботу інших, залишаючись непоміченою.

Чотири рівні пам’яті агента

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

• Робоча пам’ять — це вікно контексту протягом сеансу.
• Епізодична пам’ять зберігає короткі описи минулих розмов, доступні протягом сеансу.
• Семантична пам’ять — це корпоративні знання, які є шаром RAG.

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

Змішування цих рівнів є поширеною причиною забруднення контексту та непослідовної поведінки агентів у різних сеансах.

Багатоагентні системи та передача обов’язків

У невеликих масштабах один агент вже є рішенням проблеми. Багатоагентний дизайн є складною галуззю, де проблеми виникають через надмірну координацію, необхідність збереження консистентності спільного стану, поширення помилок та виникнення поведінки, якої не проявив би жоден окремий агент.

Найбільш занедбаною складовою є протокол передачі даних — угода щодо того, що один агент передає іншому. Мінімальний набір даних включає стан завдання, показник впевненості, виконані кроки для усунення дублікатів, посилання на відповідний контекст (а не весь контекст, що призведе до переповнення пам’яті) та будь-які обмеження, виявлені під час передачі. Без формалізованої схеми агенти передають дані у вільній формі природної мови, і отримувач змушений знову інтерпретувати їхню мету, що є основною причиною відхилень та посилення помилок.

Команди також мають вирішити, як агенти будуть ділитися пам’яттю. Зберігання приватної пам’яті для кожного агента полегшує її аналіз та перевірку, але призводить до дублювання операцій з отриманням інформації та може спричинити розбіжності у стані між агентами. Спільна дошка оголошень сприяє координації, проте вимагає механізмів керування конкурентністю, версіонування та логіки інвалідації даних. Рекомендованою стандартною налаштуванням є приватна пам’ять, при якій версіоновані, чітко визначені події публікації передають результати до спільного сховища після завершення завдання.

Ограничувальні механізми — це структура

Ограничувальні механізми — це не просто функція, додана до продакшн-системи штучного інтелекту. Це структурна властивість системи. Система, яка не має рівневих ограничувальних механізмів, — це не просто система штучного інтелекту без функцій безпеки. Це інший тип системи, яка не підходить для використання в корпораціях.

Послідовні аварійні зупинки

Кожній продакшн-системі потрібно більше, ніж один перемикач вимкнення. Їй потрібна низка різних способів реагування:

• Обмеження частоти запитів уповільнює роботу, але не зупиняє її.
• Зниження рівня функціональності блокує доступ до інструментів та переходить у режим, призначений лише для надання інформації.
• Людське керування надсилає всі запити до людських агентів.
• Завершення сеансу чисто закінчує активні сеанси агентів, зберігаючи стан аудиту.
• Повна зупинка незмінно вимикає все та фіксує стан для форензичного аналізу.

Кожен з цих механізмів має бути можливим до тестування в умовах реальної роботи, адже аварійна зупинка, яку ніколи не тестували, не є справжньою аварійною зупинкою.

Найважливішим є можливість зворотного процесу

Безпека контенту привертає найбільше уваги, проте ще важливішим питанням є те, чи можна скасувати певну дію. Якщо агент надсилає неправильний електронний лист, видаляє рядок з бази даних, здійснює оплату чи впроваджує інфраструктуру, ніщо не може це скасувати. Кожен інструмент має бути оцінений за шкалою зворотності — чим складніше скасувати дію, тим вищою має бути рівень впевненості: чим більш постійною є дія, тим обов’язковіше система має переконатися у її безпеці перед тим, як продовжити без участі людини.

Шар оцінки

Багато корпоративних проєктів на папері відповідають „найкращим практикам“, але насправді не досягають жодних результатів. Квартальний перегляд 50 вибраних результатів людиною — це лише формальність, а не справжня система оцінки. Справжня система працює безперервно, автоматично та пов’язана з механізмом спостереження.

Використання моделі як судді

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

Оцінка під час процесу розгортання

Оцінка не повинна бути випадковим додатковим завданням. Оновлення моделей, зміни запитів, оновлення корпусу даних та зміни схеми інструментів мають запускати автоматизовану систему оцінки, а зростання негативних показників ключових метрик має блокувати випуск продукту. Це означає наявність мінімальних порогових значень для кожної метрики, які вважаються частиною умов контракту на послугу. Мікросервіс, який не пройшов тестування на одиниці, не випускається, так само як і система ШІ, яка не пройшла оцінку.

Оперативність спостереження у випадку відкритого простору станів

Спостереження за системою ШІ відрізняється від спостереження за мікросервісом однією основною різницею: простір станів у неї не має меж. Мікросервіс або правильно обробляє запит, або ні. Відповідь ШІ знаходиться на певному рівні постійної шкали якості, і те, чи вона є хорошою, може залежати від критеріїв, які можна виміряти лише за допомогою ще одного запиту до моделі. Це вимагає зовсім іншого підходу до забезпечення оперативності спостереження.

Для кожного запиту до LLM мінімальний корисний запис включає:

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

Найважливішими є ідентифікатори версій. Без них прив’язка зниження якості до конкретної зміни є припущенням.

Три сигнали зміщення

Виявлення зміщення означає спостереження за трьома сигналами одночасно. У випадку зміщення розподілу вхідних даних питання полягає у тому, чи відрізняються надходжені запити статистично від того, на чому налаштована система, що може бути виявлено за допомогою відстані в просторі ембеддингів, наприклад косинусної схожості зі зразковим корпусом, ще до погіршення якості. У випадку зміщення якості вихідних даних питання полягає у тому, чи знижуються оцінки якості, що вимагає постійної оцінки, а не періодичних перевірок. У випадку зміщення поведінки моделі питання полягає у тому, чи таємно змінив постачальник модель, тому необхідно регулярно виконувати оцінку за допомогою детерміністичного золотого набору критеріїв для кожної моделі, з попередженнями, коли різниця перевищує певний поріг.

Вартість — це архітектура

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

Маршрутизація до найдешевшої придатної моделі

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

Семантичне кешування

Звичайне кешування погано підходить для додатків на основі ШІ, оскільки запити з ідентичним значенням рідко збігаються як рядки. Семантичне кешування індексує відповіді за їхньою близькістю у просторі ембеддингів, а не за точним текстом, досягаючи показників відтворення від 30 до 60 відсотків при великих обсягах роботи, залишаючись при цьому непомітним для рівня додатку. Для цього потрібен швидкий приблизний індекс найближчих сусідів, поріг схожості, нижче якого гарантовано відсутність знахідки, та політика TTL, що відповідає швидкості старіння знань.

Бюджети токенів

У реальних умовах приблизно 60–80 відсотків витрат на токени зазвичай походять від системних запитів, схем інструментів та отриманого контексту, а не від повідомлень користувачів чи відповідей моделі. Тому управління бюджетом має здійснюватися на етапі проектування: динамічно скорочуйте системні запити, щоб включатися лише ті частини, які стосуються типу запиту; завантажуйте схеми інструментів по мірі потреби, щоб використовуватися лише ті, які обрав планувальник; розташовуйте дані в контекстному вікні так, щоб найбільш значущі фрагменти залишалися в основному контексті, а менш значущі з’являлися у вигляді стиснутих резюме.

Нульова довіра для агентів

Концепція нульової довіри була розроблена для людських користувачів та статичних сервісів. Її застосування до агентів означає розширення цієї концепції для охоплення динамічних наборів можливостей, різного рівня впевненості та можливості діяти від імені користувачів без прямої згоди на кожну дію.

Ідентичність кожного агента

Кожен агент у робочому процесі потребує власної криптографічної ідентичності, яка відрізняється від користувача, на якого він працює, та від інших агентів. Облікові дані мають бути прив’язані до сеансу та закінчувати свою дію після його завершення. Вони також мають бути обмежені за можливостями, тобто облікові дані мають кодувати те, що може робити агент, а не лише те, хто він є. Крім того, кожне видання та скасування облікових даних має бути зафіксовано у незмінному вигляді. Це дозволяє запису аудиту відповідати на запитання про те, який агент, під якими обліковими даними, виконав певну дію для конкретного користувача та коли, що є критично важливим під час розслідування інцидентів.

Розділення інструкцій від даних

Найважливішою елементарною складовою безпеки в агентному ШІ є розділення інструкцій та даних на окремі рівні. Ненадійні джерела ніколи не повинні забруднювати системні запити. Конкретно: зовнішні дані проходять через шар очищення перед тим, як потрапити до контексту; отриманий вміст отримує позначку довіри, а моделі наказують розглядати текст із низьким рівнем довіри як матеріал для аналізу, а не як команди. Це схоже на параметризовані SQL-запити: та сама принцип, різна реалізація.

Управління, вбудоване з самого початку

Управління ШІ — це не просто пункт для позначки відповідності стандартам. Це постійна операційна дисципліна, яка потребує архітектурної підтримки. Організація не може керувати системою, яку не може спостерігати, не може проводити аудит системи, яка не фіксує дані, та не може забезпечувати дотримання правил у системі, яка не була створена для цього. Управління має бути вбудоване, а не додане пізніше.

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

Політики, які знаходяться у прозових документах, неможливо керувати у масштабному форматі. Необхідна політика у вигляді коду: правила, які можуть читатися машиною, зберігатися під контролем версій, перевірятися та оцінюватися шлюзом ШІ під час виконання. Open Policy Agent із своєю мовою Rego є зрілим варіантом. Він може кодувати правила на кшталт „жодних рішень, спрямованих до клієнтів у ЄС, які були б прийняті цією моделлю, якщо тільки результат не містить позначки про людську перевірку“ або „цей агент не може використовувати інструмент оплати для даних, класифікованих як PII“. Оцінка на шлюзі створює єдину точку застосування правил та повний журнал аудиту, що замінює розрізнені, несуворо дотримувані та незастосовувані політики, характерні для корпоративних систем ШІ наразі.

Право на пояснення

Такі нормативи, як Закон ЄС про ШІ, разом із системами управління ризиками в компаніях, все більше вимагають, щоб рішення, прийняті за допомогою ШІ, були пояснюваними для тих людей, на кого вони впливають. Це вимога до архітектури, а не питання щодо можливостей моделі. Навіть модель, яка не може пояснити власні міркування, може брати участь у системі з поясненнями, якщо архітектура фіксує інформацію, яку отримала модель, які інструменти вона використовувала, які опції розглядала та наскільки вона була впевнена у результаті. Історія аудиту має бути спроектована так, щоб відповісти на запит про пояснення під час самого аудиту, а не відновлюватися пізніше з наявних журналів подій.

Архітектура — це продукт

Система ШІ, готова до використання, визначається не якістю її мовної моделі, а рівнем складності архітектури, яка її оточує. Модель є компонентом — потужним, цінним та важкозамінним, проте все одно лише компонентом.

Архітектура ШІ — це мистецтво створення систем, які залишаються надійними, керованими та покращуваними у місці зустрічі недетермінізму ШІ та детермінованих правил корпоративного програмного забезпечення. Кожен шар відповідає на одне запитання:

• Як уникнути поганих результатів? За допомогою захисних механізмів.
• Як помітити погіршення якості? За допомогою оцінок та можливостей спостереження.
• Як координувати кілька компонентів ШІ? За допомогою топології багатьох агентів та протоколів передачі даних.
• Як запобігти стрімкому зростанню витрат? За допомогою бюджетів на токени та маршрутизації моделей.

Як ми переконуємося, що відбуваються лише авторизовані дії? За допомогою принципу нульової довіри та прав доступу до інструментів.

Як ми задовольняємо вимоги регуляторів та аудиторів? Завдяки архітектурі управління.

Усі, хто тільки починає працювати в цій галузі, повинні зрозуміти, що архітектура ШІ — це не просто галузь архітектури програмного забезпечення. Це окрема дисципліна з власними основами та моделями мислення, яка розглядає невизначеність як основну обмеження у проектуванні, а не як окремий виняток. Проектуйте з урахуванням варіацій, а не очікуваного результату. Звертайте увагу на розподіл, а не на середнє значення. Система, яка ефективно справляється з найгіршими 5 відсотками ситуацій, заслуговує на право обслуговувати решту 95 відсотків у продакшені.