Галоўная / Артыкулы

Дзевяць архітектурных элементаў для систем штучнага інтелекту высокай якосцы.

Выучыце план архітектуры, складаючыся з дзевяць элементаў — які включае сеті з прынцыпам разгранічэння довер'я, роўні даных і механізмы прыкреплення доказаў — для стварэння систем штучнага інтелекту высокай якосцы, якія можна перапрацаваць.

20 хв чытання4681 слоў

Разлік межы дэмаверсіі і рэальнай працы, пра які ніхто не говорыць

Стварыць пратотып агента на базе ШІ за выходныя — гэта проста.

Прыўяжыце LLM да ціклу вызова інструментаў, падключыце яго да базы вектарных даных, дадзіце інтерфейс чату, і раптам у вас ёсць што-та, што выглядае вражаюча пад час дэмаверсіі. Кераванне задоволена. Інжынеры аптрымлены. Каму-то спадае на думку напісаць „Пілот у трэцьму квартале“ на дошцы зазначэнняў.

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

Агент выдаеў вярненне некорактныя сумы — таму што ніхто не паводзіў чыстую межу межы таго, што вырашае ШІ, і таго, што ўжо є фіксаванай, выконвальной логікай. Аудыт безпекі блакуе запуск — таму што даныя кліента былі таямніча перадаваны через зовнішню API для вбудоўвання. Хтось з аддзелу са адпаведнасцю запытае, чаму система даўшыя месцы выдала конкрэтны адказ — і не існуе можлівасці восстановіць логіку гэтага рашэння. Вялікі скрыпт агента стае недаступным для змян — таму што інжыніерыя запросаў, бізнес-правілы і інтеграцыя API з’едналіся ў адны файл. Рэзультаты змінююцца пасля стандартнага переіндексавання — і ніхто не можа воспамятаць, што сказаў асістэнт у пярэдні месяц.

Некамфортная рэальнасць такая:

Выбір модэлі ніколі не быў складным аспектам. Складнасць крыецца ў структуруванні системы на адной з гэтых модэляў.

Агентная система — гэта не проста тонкі шар ШІ, прыўязаны да скрыптав. По суті, гэта детерміністычная корпоратывная система, якая, як правіло, мае ядро верагатывочнага абдумавання — і яна выклікае тыя ж інжынерныя вакалентнасці, якія неабходны для платежной платформы чы сутнічных банкавскіх інфраструктур.

У гэтай серыі представлены ўсе архітектурныя елементы для стварэння такой системы. Яна структуруецца наваколо дзевяці основных рашэнняў па дизайне — дзевяці столпоў — якія кожная практычна прыменяемая агентная платформа должна правільна рэалізаваць адночасна, кারане калі адна з іх не працюе, іншыя таксама часта перестаюць працаваць.

Наш прыклад: Aurora Bank

Архітектура, прыменяваная ў абстракцыйных раслідаваннях, рэдка калі стае практычнаю. Таму ў гэтай серыі мы будзем прыкладваць кожную концэпцыю да конкрэтнага, хоць і вымышленага, сцэнарыю:

Aurora Bank — это середняя роздробная банкавая установа, якая прымоць 4 000 чалавек. Яны запускають "Aurora Assistant" — платформу, створаную для: — адпаведзення на запыткі спецялістаў пра правіла та ўмовы дзеяння, — адказвання за обробку кредытавання (збіранне дакументаў, перакананне ў правядомасці дадзеных, практычнае вырабаткаванне рашэнняў), — а таксама керування задачамі службы паслявыпускнага адказу, такімі як вярненне грошаў, выкарыстоўванне інформацыі пра рахунакі та направленне запыткаў.

Абмежэння, з якімі сталкаецца Aurora, адпавядаюць тым, з якімі сталкаюцца большасць рэальных падпрыемстваў:

  1. Персональныя даны кліентаў не могуць пакінуць інфраструктуру самага банку.
  2. Кожна автаматызаваная рашэнне павінна быць пояснена регулятору за яго запыткам.
  • Аператы, які выкалываюцься з грошамі, павінны строга следаваць правілам — тут няма жадных можнасцей для імпровізацыі.
  • Асистэнт должен весты справу з больш чым 20 внутрэчных систем (SAP, Salesforce, платформы банкавання, ServiceNow і іншыя).
  • У аспекте безпекі прыймаецца, што нарушэння є немінучым, таму за замовчаннем трэбаецца строгія меры прытаманення.
  • Зберагаеце гэтыя пяць умов, калі чытаеце далей — кожны з дзевяціх прынцыпаў існуе самэлькі для рашэння такіх абмежэнняў.

    Пяць керуючых прынцыпаў

    Перш чым перейсці да самых прынцыпаў, корыстна зразумець лежачую пад імі філасофію:

    1. Спрыяйце модэлю як аднаму з элементаў сярод багато іншых, а не як самай архітэктуры. Модэлі заменяюцца кожныя калькі месцаў; ваша архітэктура павінна выстояць усе гэтая змены.
    2. Усередзіне трэба застаўляць верыятлівасцевы падход да разумовых працэсаў, але межы павінны быць дэтэрміністычныя. LLM можа свабодна думаць, але ўсі дзеянні павінны выконвацца за дапамогою фіксаванага коду.
    3. Пэўніцеся, што кожна дзеянне стварае запис. Якщо вы не можетэ павторыць рашэнне, вы не зможаце яго пазней апрацаваць.
    4. Ізаліюйце складовыя па рэгламенту довер'я, і працавайце з кожным запитам на доступ. Агенты ўстойлівы, і самэ гэта яшчэ больш рызыкавана — намерна контролюйце гэты рызык.
    5. Ствараюце структуру так, нібы ўскора будзе аудыт і нібы вам паслаюць спавящую прымэту о 3 гадзіні ночы. Раней чы пазней гэта або ўсё ж такі будзе.

    Тепер давайце па черзі розглянуць кожны з эых элементаў — што яны значаюць, чаму самэ гэтая структура ўсунутая, супаўнае з яю дыяграма, конкрэтны прыклад і наследкі яго праігноравання.

    Элемент 1 — Логічная архітэктура: чаму шасць слоёў ёсць правільным выборам

    Здесь пытанне простае: якія ўсё тое базовыя элементы системы, і якае шар несе якую адпаведальнасць?

    Платформа на агентных тэхналогіях складаецца з шасця логічных шароў.

    Чаму шасць, а не трохі чы ўжо дзевяць?

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

    Шасць выявіліся як мінімальная колькасць шароў, у кожны з якіх є адна задача, адні власнік і адна прычына для змены. Можна пераканацца ў гэтым, запытавшыся для кожнага шару: чы можа гэты шар зменіцца сам по сабе, не вымушваючы ўсі іншыя шары зменіцца разам з ям?

    1. Слой адаптавання (L1) постаўляе змяны столькі часу — новыя інтэрфейсы, новыя каналы, новыя трэбаванні да фронт-енду.
    2. Оркестрацыя (L2) змінюецца з кожным новым варыянтом выкарыстоўвання.
    3. Мышленьне (L3) змінюецца кожны раз, калі стаў доступны болей сильны модэль, таму яго трэба можна заменіць без вплыву на іншы элементы.
    4. Інтэграцыя (L4) змінюецца кожны раз, калі бізнес падключае новую систему.
    5. Даны (L5) змінююцца паступова самыя по сабе, але правіла керавання, якія іх абгрунтуюць, змінююцца ў меру развіцця регуляцый.
    6. Керавання (L6) знаходзіцца окола як перакрываючы элемент, а не як найболей ніжны слой, таму што ідэнтыфікацыя, аудыт, аналіз, правіла контролю і керавання выкладкамі трэбае працаваць у всіх іншых слоях, а не толькі ў найбазовым.

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

    Aurora на практыцы: з-за трэбаванняя суверэнітету, прызначанага ў Столбе 2, банк Aurora зрэшты мусіць заменіць зовнішній LLM на самастойна размешчаны. Паколькі логіка абдумавання існуе ў сваёй сабе шары, гэта становіцца проста змянай налашоўкаў маршрутацыі ўнутрь L3 — не патрабуецца інтеграцыяі інструментаў, і прапанунакі не трэба перапісваць.

    Якщо вы прахідзіце праз гэта: кожны новы варыянт выкарыстоўвання ператвараецца на рэдагаванне аднаго вялікага, заплутанага файла. Замена модэляў стае непрактычной. Ніхто не можа з абавесцю сказаць, дзе насправды знаходзіцца логіка аудыту.

    Вывад: шары існуюць для пазначэння тых месца, дзе дазволена змяна. Їх правильныя праектаванні означае праектаванне «шваў» системы, а не толькі ёё элементаў.

    Тэма 2 — Фізычная архітектура: чаму суверэнны развёрткі ўзможны

    Пытанне, на якое трэба адпаведзець: дзе фізычна працюе система, і што — якшто ўзагалі ёсць такое — дазволена перавозка па за межы вашай тэриторіі?

    «Суверэнны» ў гэтым контексте значыць, што моделі, даны, эмбеддынгі і следы выканання застаюцца ў мерапрыятнасці, якую вы кантролюеце, пры чым єдыным шляхам да зовнішняго свету ёст толькі адзіны, задокументаваны і фільтруемы шлюз.

    Чаму гэты варыянт існуе зараз, калі калялькі гады таму ён не быў рэалістычным?

    1. Модулі з адаптаваемым вагам выканалі разлік. Такія модулі, як Llama 3.x, Qwen 2.5 і Mistral, тепер можна запускать самостоятельна і яны даюць рэзультаты высокай якосці для класыфікацыі, выдзеявання інформацыі, стварэння апустакоў і адпаведзення на запыткі на адной основе RAG.
    2. Квантызацыя робіць іх доступнымі за цэнай. Тэхнікі 4-бітной квантызацыі дазволяюць аднаму 80GB GPU запускать модулі з 70 мільярдаў параметраў, а меншыя модулі для цього патрабуюць значна меншаг колькасці апаратуры.
    3. Інфраструктура для обробкі даных ўжо развіта. vLLM забезпечвае паўнавыконаную обробку дадзеных у пакетах і высокую шырочу сітку для прыменення ў практыцы, Ollama ідзе на лад з работай над разработкамі, а Kubernetes можа кераваць часам ўжывання так сама, як і будзь-яй іншай службай.
  • Эканамічныя аспекты падтрымліваюць такой падход. Для средней паўстановы, якая выкорыстоўвае кэшаванне і групавую обработку, дастатнекі ўзборк GPU, каб задаваць запиты у масштабе, адпоўнаму падобным да таго, які можа выконваць внутршній асистэнт.
  • Важны нюанс: выбір прыоритэта для саверэнных модэляў не значыць абсалютную заборону на внешнія модэлі. Это означае, што кожны запит, які выходзіць за межы, є добраўчым, прыкладзеным да аднаго конкрэтнага класіфікацыя дадзеных, і праходзіць через адну воратыню — ніколи не запускаецца за дапамогою тыхняе стандартных наставак. Самэ гэта ўскладнілае логіку прадстаўлення воратыні выходу як адных дверэй: адныя стражаваныя дверы кращыя, чым двадцать незакрытых вікон.

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

    Якщо вы праігнораваце гэта: стандартна настройка ў дзеяных інструментах SaaS для вкладків тыхо перадае транскрыпціі кліента трэцьям сторонам. Ваша платформа для аналізу заканчыцца зберагачэнням следаў, наполненых персональнымі даныма, на серверах за межамі краіны. Перагляд безпекі не пройдзе — і проект таксама зазнае невяспы.

    Вывад: межы системы — это рашэнне, якое вы должны прымець свядома. Якщо вы не зробіце гэта явна, стандартная настройка прадавца зробіць гэта за вас.

    Трыцяты элемент — Модэль C4: Правильна документацыя

    Запитанне: Как документаваць систему так, каб кожны аудытар бачыў самэлькі рублёў дзеяння, якія ёму патрэбны?

    Модель C4, створаная Саймонам Браунам, прадае чатыры рублёў зуму — можна яе уявіць як панорамаванне і зумаванне на карце.

    Чаму модель C4 так добра падходзіць для агентных систем?

    1. Агентныя системы за сваёй прыродай ўскладненыя. Запитанне "дзе на самай працоўцы жыве?" не мае чыстай адпаведзі. Модель C4 змушвае быць точным: працоўнік — гэта не адна клетка на дыяграме, а сукупнасць контэйнероў (среда выканання, шлюз, разныя хранілішчы), якіе адмаўляюцься месажамі. Модель C4 адкрывае гэтыя адмаўленні, замест таго каб іх хаваць.
  • Няма аднаго дыяграма, які бы падходзіў трохму разным чытачам. Регулятораў цікавіць відзор Контэксту — тое, што стосуецца дакументаў кліента. Адпаведальнага за безпеку — відзор Контейнера — той процес, які фактычна зберагае аутантыфікацыйныя данні. Інжынера цікавяць Компаненты. C4 дае кожнаму з іх свой узел зумаў, тады нікому не трэба спарчвацца пра тое, якія фігуры павінны быць на чыём дыяграме.
  • Адносленне дыяграмаў да коду падтрымлівае актуальнасць дакументацыі. Калі дыяграмы знаходзяцца ў Structurizr, Mermaid або PlantUML, зберагаюцца ў рэпазітарыі і праходзяць перагляд праз pull-request, яны зміняюцца разам з самым кодам — а не стаюць застарэлымі ў презентацыйных слайдзах, да якіх ніхто не прыкасаўся з моменту пасляпэльнай рэорганізацыі.
  • Чатверты узел зумаў є необав’язковым, а не прымусовым. Заставіце яго для невялікай часткі логіки — можа 5% — якая дыйсна настолькі складная, што патрабуе яго.
  • Aurora ў практыцы: Калі регулятор запытаеся, якія самэўчасткі можа адносіцца да персональных даных кліента, Aurora можа адпавесць за аднаго дня. Команда паказвае дыяграму контейнераў, пазначаную меткамі зон, уведзенымі ў Раздзеле 4, а таксама дыяграму элементаў для часу выканання агента — обея створеныя безпосередна з текущага стану репазітарыя, версіюваныя разам з кодам, які іх створыў.

    Без такой дисцыпліны: новыя працавнікі вынушаныя здзейсняць зворачную інжынерыю архітэктуры на базе выхіднага коду. Аудытары атрымляюць прэzentацыю з 60 слайдамі, якая ўжо 14 месца застарелая. Кожная архітэктурная незгода ператвараецца на споры пра прастакутнікі на дошцы запісаў.

    Вывад: дакументацыя выступае як інтэрфейс межа вашай архітектурай і кожным чалавекам, якія должны ў яе верыць. C4 ператварае гэты інтэрфейс у ўскладнены і можна пераглядаць элемент, а не статычны продукт.

    Чэрговы элемент — сеткаванне з нульовым доверьем: чаму саме пяць зон

    Запытанне: Калі ў чымсь з’яўляюцца проблемы — а яны нехта буду — як запобiec ўжо большым наследкам?

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

    Чаму саме пяць?

    Таму што кожныя межы прымусова павінны аддзеляць сапраўдзі разлічны рэвэль доверы — а агенты ствараюць рэвэль доверы, які традыцыйныя архітектуры проста ніколі не мусілі урахоўваць:

    1. Z1, Edge — там, дзе спачатку прыбывае недоверлівы трафік. Ён пад сталямі атакамі, таму можна прыпусціць, што ён вялікай меры заражаны.
    2. Z2, шар прыемлень — служыць безпасова кінавыкам. Яго доверлівасць ў меры.
  • Z3, зона агентаў — рызыкаваны новак. Агенты выкарыстоўваюць дадатковыя інструменты, спраўляюць з ненадзеяным кантэнтам, які прыносится з інтернету (чым ствараецца рызык уражэння праз вставку коду), і генеруюць выходны матэрыял, які ў найкращым разе мае толькі частковую доверлівасць. Адналожэнне Z3 да Z2 дазволіла б вызовам інструментаў агентаў успадкуваць той жа рэвэл доверлівасці, што і залогаваны корыстнік — што ўзначае небяпечны наследак. Наданне агентам сваёй сабственнай зоны означае, што іх аутантыфікацыйныя данні будуць выкорыстоўваны толькі для дзеяння як агента, без можлівасці ўжытку іх у іншых цылях.
  • Z4, зона дадзейнаў — там, дзе зберагаюцца найценнейшыя данні. Зона агентаў можа дасягнуць гэтых дадзейнаў толькі через центральны пункт, пры чым кожны інструмент мае адзінакавы рэвэл даступу — прымітны даступ ніколі не разрашаны.
  • Z5, адарожненне — секрэты і практыкі CI/CD ёсць ключамі да всага. Практыка развяртання ніколі не должна дзеляць сетевы простор з маршрутамі, які обробляюць жывыя запиты.
  • Менш чым пяць зон прыведзе да занікнення меж, які разлучаюць практычна разныя рэгламенты довер’я. Больш чым пяць проста даду дапамогу додатковым бар’ерам, не ствараючы новых меж довер’я. Пяць — гэта самэй тачны лік.

    Aurora ў практыцы: атакаваўшы выкарыстоўвае компрометаваную веб-стороніцу, каб увести запит і спробаваць абмануць дапаможнага агента для заглыблення ў даныя пра заробкі спецавікаў. Палітіка зоны абсалютна блакуе шлях Z3-до-HR, адколі дыямэтрыя гэтага сектара проста не включае системы кадровага аддзелу. Центр фіксуе спробу, а атакаваўшый застаецца без нічога, кроме публічных даных з вебу. Агент быў маніпульаваны; даны банку засталіся недаступныя.

    Без такой сегрэгаціі: адна толькі выцярпаная канектарская API-клуч могла б дастаць атакаваўшаму — або зловучаму агенту — безперашкодны шлях прымусова да всіх слоёў даных.

    Вывад: агенты значная мерой парадоксуюць рызык бокавага перасування ў мережы. Правільная зонавацыя ператварае атакаванага агента з прычыны нарушэння безякості ў простае зазначанне ў логах.

    Пяты пілар — Інтэграцыя типу «хаб і споукі»: правильны патэрн для агентаў

    Запытанне: як агентам можна быць падключанымі да 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. Якщо модель будзе зіпсавана, трэба перагенераваць T2 на базе T1. Не патрэбна перепрацоўка самых первічных джерелаў дадзеных.

    2. Адчысцэнне. Калі кліент выкарыстоўвае сваё права на адчысцэнне дадзеных согласна GDPR, наявнасць чыстаўкі ліній прычына-наследак дазволяе запит на адчысцэнне прайсці детерміністычна через T1, T2, T3 і T4 па ідэнтыфікатору — без неабяжной ручной перапрацоўкі.

    Правіла, якія лежачыя в основе всьога гэтага: індекс вектара ёсць кэш, а не джерела правды.

    Як гэта выглядае ў Aurora: аддзел кіравання якасцю з’явіў, што логіка разбівання дадзеных таямна выкасывала рядкі з табліцаў. Aurora за ноч часа перыядруюе два мільйоны дакументаў з T2 за дапамогою відкорэгаванага інструмента разбівання, без патрэбы перепрацоўваць жадныя выхідныя системы і без паніки з-за відсутнасці історыі. Чэрез месяц каманда можа перадзначыць і паравярzyć, як быў бы адпаведзены заданы вопыт да і пасля выправлення.

    Без рангавання: хранілышча вектароў стаюць ўсёй едынай копіяю існуючых дадзеных. Выкасыванні ў выхідных системах ніколі не прабіваюць да іншых частак. Вопыт на кшталт "Што асістэнт сказаў гэтаму кліенту ў марцы?" проста не можа быць адпаведзены.

    Вывад: проектуйце свою архітэктуру дадзеных так, каб яна падтрымвала перыядруванне, якое вам зрэшты патрабуецца, а таксама выкасыванне, якое вы юрыдычна зобав’язаны адбыць.

    Столп 7 — Дизайн на адміністрацыю: чаму надзорчык з пададміністрацыямі кращы за моналіт

    Працоўны пытанне: як вам структураваць „суспільство“ адміністрацыяў, якія складаюць вашу систему?

    Шаблон, які падтвердзіў ся ў практыцы, — это оркестрацыя-рабочы: адзін надзорчык ставить загальную мету, а група пададміністрацыяў кожны з яных виконвае вузкую, спецыялізаваную задачу.

    Чаму раздзелэнне абавясцей краща, чым стварэнне адной вялікай адміністрацыі з п’ятдесятма дадаткамі, прыўязанымі да яе?

    1. Контэкст быстра тыяецца. Калі аднаму агенту трэба выкарыстоўваць пяцьдзiesць інструментаў і абмежэнне, якое не мае чыткага канца, яго эфектыўнасць значна падыходзіць — неправы выбар інструментаў, забутыя абмежэння, пазорліванне сюжета задачы. Спецяліст, які выкарыстоўвае пяць інструментаў і мае чыткае заведамае абмежэнне, ў дзiesяць разоў надзеяный. 2. Яго можна практычна працаваць. Не існуе значычнага спосабу для тэставання вялікога мегапрампта. Але можна стварыць спецыяльны набор тэстаў для кожнага пад-агента — напрыклад, 200 тэстовых кейсаў для даследніка і 50 для пісьменніка. Гэта ператварае тэставанне регрэсіі агентаў у чыткі і павторны процес. 3. Існуе адна точка кантролю. Надзірнік стае тым месцам, дзе вы застосоўваете бюджэты (максімум 12 крокаў або 0,40 еўра за задачу), керуеце праказамі, запускаеце перадачу задачы людзям і ствараеце правілы для кожной перадачы. 4. Работа ведзецца паралельна, а часткі можна заменяць.

    Пад-агенты можаць выконвацца адночасна, і кожны з іх можа быть заменены — на болей сильны LLM, дышэўшы, або на штос цалкам детерміністычнае для адзыскання інфармацыі — без парадужэння рэшты системы.

    Варта падкресліць, што „пад-агент“ не значыць „LLM аж да самага низу“. У наладзе Aurora пад-агент для расчытку цены не мае жаднаго LLM — это детерміністычны код, адзюжаны пад вайб агента. Гэта ўскладнівае розумеўце Пілара 8.

    Аўрора ў практыцы: процес адказу на запиты на кредыт дзеліцца на доследніка (які запошчае документы з правіл), пераканальніка (які пераглядае документы), калькулятора (які вычысляе можлівасць падтрымкі за дапамою простага коду) і пісьменніка (які складае лист для кліента). Кожны з іх ацэнюецца, мае свою версію і працюе незалежна. Якщо рэйтынг тону пісьменніка падае пасля змены модэлю, трэба выправіць саме этаг спецыяліст, а не прабаваць рашыць проблему ў вялікай системе.

    Якщо прыхіліцца не да гэтага піляра: вы ў канцыку надасіте мега-агента з сямдзятамі інструментамі, які часам два разы вызывае API для вярнення грошай за прычынамі, якія ніхто не можа з’ясавіць — і всі занадта бояцца яго трогаць.

    Вывад: раздзеленне роботы — гэта не толькі праблема эфектыўнасці. У системах з агентамі гэта справжнія адказ за надзею.

    Піляр 8 — Дэтэрмінізм проты расумавання: Найважлівейшая рашытка

    Запытанне: аднакліква, дзе самэў системе вы разрашаеце верагатыбным алгорытмам AI прымаць рашэнні, а дзе паведанне застаецца прыкрепленам да коду і правілаў?

    Гэта ёсць канецна важны элемент — усе іншыя існуюць для падтрымкі або выеўнання таго рашэння, якое вы даёте тут.

    Кансэпцыя простая:

    LLM-ы пропануюць. Дэтэрміністычныя системы вырашаюць.

    Іспользуйце LLM для таго, у чым ён выдатны: класыфікацыя, выкарыстоўванне інформаціі, стварэнне проектаў, планаванне. Іспользуйце дэтэрміністычны код для таго, чаго трэбуюць правілы і адпаведныя технічныя рэшэнні: верыфікацыя, пераказ грошаў, змяна стану, выеўнання супакорэння.

    У практыцы гэта значыць тратаваць вашы рабочыя процесы як машыны станоў, дзе LLM можа выказваць свое мнэнне толькі на спецыяльных, пераказаных пунктах прынятні рашэння, а звычайны код карацецца всім іншым.

    Чаму гэты выбар пры проектаванні адзначаецца як найважлівейшы? Таму што ён вплывае на всё іншае, што выйшла пасля:

    1. Надзеямоснае працаванне — шляхі, які стосуюцца грошэй, не параджуць меса для неспакоўнага паведання. 2. Магчымасць аудыту — паколькі варыянты рашэння ўможліва перыябраць, вы можете пераказаць кожную точку, дзе была выканана оцэнка. 3. Контроль витак — вы ухіляецеся ад выкорыстання токенав у задачах, якія простая if-заява вже можа адмахнуцца безкоштовна. 4. Супаўзятас архітектуры — надзорнік з Каламена 7 ёсць там, дзе вы вводзіце гэтыя межы, хаб з Каламена 5 прыменяе іх на роўні інструментаў, зоны з Каламена 4 мясткуюць будзь-якія неудачы, а хранальнік доказаў з Каламена 9 пасля факту падтверджае, што на самай працэ ўсё-такі адбылася.

    Aurora ў практыцы — процес вярнення грошаў:

    1. LLM, у зоне аналізу: чытае электранак паўтарожніка і выдзяляе структураваныя полья — amount: €145, reason: damaged goods, sentiment: frustrated. Шырок гэтага крока ёсць верагатывістны, і гэта прыемна, адколі ён толькі запоўняе форму.
    2. Дэтэрміністычны механізм прыняцтва рашэнняў: сумы да €200 апраўдваюцца автаматычна; сумы з €200 да €1,000 праганяюць пераказы на адпаведнасць правілам; всё, што пераходзіць за €1,000, вымагае падтверджэння чалавека. LLM ніколі не мае права пераказваць грошы — ён можа толькі запропанаваць значэнне, а сам код вялікі ўладзюе тым, што з яго будзе зроблена.

    Оба крайнія варыянты ў гэтым случае ёсць небяпечныя, і самэ гэтая прычына, чаму трэба старацца застаць у сяродзіні:

    Калі вы дазволяеце LLM адначыць усё („Проста дазвольце агенту займіцца гэтым“), вы ў канечнасці отрымаеце электранаўленне, створанае на адпаведны праграмны сигнал, якое разрашае вярненне 50 000 еўра. Калі ж усё адначыцца правіламі, то система не можа нават распакаваць звычайнае электранаўленне — фактычна адвяртаючыся да стану 1995 года.

    Вывад: пэўная автаномія LLM — це толькі трюк для дэманстрацый; абсалютная ж стрыктнасць на базе правіл — ўжо минуласць. У прыменных системах неабходна ўсведамленая, задокументаваная карта, якая чытна паказвае, дзе самэ прыменяецца кожны режым — і правільнае стварэнне такой карты ёсць найважлівейшым рашэнням у проектаванні цялай системы.

    Тэма 9 — Звязок з доказамі/Цитаты: Чаму гэта захіщае ад аудыту

    Пытанне: як зробіць кожны выхад західным — нават чераз месцы чы ўсе гады, для аудытара, які актыўна шукае недакладнасці?

    Кожныя фактычныя тверджэнні павінны быць праўязаныя да ўсходніх доказаў, а весь ляміт прыняцьня рашэння павінен застацца незмянным пасля занесення:

    Чаму гэта вытрымае аудыт? Таму што гэта дае вам тры гарантіі адразу:

    1. Абаранэнне галюцинацый. Якшто няма цітаты, то няма публікацыі. Калі наэтапе стварэння адпаведзя нельга прыўязаць правільны джерэл, выходны результат атрымвае пазначку або ўскасывается. Гэта ператварае «проста даверайце модэлю» на выконвальная, механічная правілу.

    2. Пэўная можлівасць перагляду всіх дадзенняў. Якшо хтось запытае: «Чаму система адпавяла так 3 марца?», вы можете воссоздаць абоўшчыну прабегу — первісны запит, выкарыстоўваныя фрагменты, версію запиту, версію модэлю, створаны адпаведзь і ўсія цитаты. Уместо фразы «Мы сачуваемся», вы практычна паказваеце фактычныя записі.

    3. Яснасць прычыны бягучага стану. Калі адпаведзь выявляецца некоректным, вы можаце адразу выявіць тип памылкі: чы гэта была памылка у пошуку (было выкарыстоўвана некоректнае доказацтва) чы памылка ў логічных выводах (было выкарыстоўвана правильнае доказацтва, але яго некоректна інтэрпретавалі)? Для ўсунення гэтых проблем трэба абоўшчынна разныя способы, і без чынных доказаў немагчыма ўжо адзін ад другога ўжо розлічыць іх.

    Аўрора ў практыцы: Асистэнт адпавядае на запит пра умовы штрафаў, цітаючы credit_policy_v12.pdf, сторана 14, sha256:9f2c…. Пазней, калі выйдзе версія 13 політыкі, гэтае паслявейшае адпаведзенне як і раней точна відбівае тое, што было правдзівам у момент яго дачы, таму што цитаваныя доказы фіксуюцца за дапамою хэша, а не запрашваюцца занову дынамічна. Адпаведальны за салідарнасць можа яго затвердзіць, таму што весь ланцуг можна переглядзець зноў, ён є відчутным да парадуксавання і правильна часаваны.

    Якшто праігнораваць гэта, то: вашы ўзелькі захоплення пад час інцыдэту або аудыту стануць «модель так сказала». Вы втрачаеце можлівасць адзеліць проблему з яснасцю дадзеных ад неудачы ў логічных выводах. Регуляторы называць такія системы чорнымі ящыкамі — а чорныя ящыкі закрываюцца.

    Вывад: якшо система не можа цітацыя, яе не публікуюць.

    Як перацююць дзевяць календароў

    Этыя дзевяць элементаў — гэта не спіс аднародных пытанняў; яны ствараюць адну цэлісную структуру з ядром:

    Як толькі аднаго з календароў не стане, рэшта пачынае руйнавацца. Якщо адняць шар центру і спраг (5), детермінізм (8) больш не можа быць застосаваны на рэвэлі вызваў інструментаў. Якщо адняць рангаванне дадзеных (6), у звязку паказаў (9) не застаецца нічога надзейнага для апісання. Якщо адняць дакументацыю C4 (3), вы втрачаеце можлівасць нават паспяшна апісаць засталую архітектуру пад час аудыты. Яны працуюць толькі як сэт — або ўсе дзевяць элементаў працуюць, або вся структура руйнуецца.

    Што будзе ў гэтай серыі

    Кожны наступны выпуск будзе аб’ёмным аналізам: ведаючы прынцып, супакоўваючы дыяграма, прыклад з сцэнарыю банку Aurora Bank, конкрэтныя тэхналогічныя выборы, распашчаныя анти-шаблоны, якіх трэба утрымляцца, і практычны чарткі для стварэння.

    Заключныя мысці

    Да 2026 году наявнасць супэльнага моделі больш не ўжо являецца прызнакам выдатнасці — кантэкст API ўможліва атрымаць кожнаму.

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

    Дзевяць столпаў. Дзевяць рашэнняў. Патрэбна ўсё яны правільна, адночасова.

    Далей — Частка 1: Логічная архітэктура, дзе шасцяшаровая структура будуець стварацца шар за шарам, контракт между кожной парай шароў будзе чыста апісаны, а анти-шаблоны, якія ператвараюць код базы агентаў у некерованы хаос, будуць дакладна аналізаваны.