Prípad proti magickej orchestrácii
Graf, ktorý vyzeral inteligentne
Diagram orchestrácie bol krásny tak, ako bývajú krásne nebezpečné diagramy. Zaoblené políčka, pôvabné šípky, plánovač, výskumník, overovateľ, vykonávateľ nástrojov, pamäťová vrstva, uzol na schvaľovanie človekom a záverečná odpoveď. Ukážka sa pohybovala s divadelnou sebadôverou. Používateľ požiadal o analýzu, plánovač rozložil úlohu, zavolali sa nástroje, objavili sa priebežné poznámky a záverečná odpoveď prišla s pokojom systému, ktorý nikdy nezažil produkčnú prevádzku.
Potom prišli prvé skutočné výnimky. Nástroj vrátil čiastkové údaje. Plánovač to skúsil znova s iným dopytom a stratil pôvodný dôvod. Overovateľ kontroloval štýl, ale nie konflikt zdrojov. Pamäť priniesla starý predpoklad, pretože vyzeral relevantne. Krok schvaľovania človekom schválil záverečný text bez toho, aby videl zlyhanú vetvu. Záznam existoval, ale čítať ho bolo ako prezerať si kufor zabalený výborom počas požiarneho cvičenia. Graf nezlyhal dramaticky. Skryl tvar zodpovednosti.
Toto je argument proti magickej orchestrácii. Nie proti orchestrácii ako takej. Komplexné AI systémy potrebujú koordináciu. Potrebujú volať nástroje, smerovať úlohy, spravovať kontext, pýtať sa ľudí, zotavovať sa z chýb, deliť prácu a spájať dôkazy. Argument smeruje proti štýlu orchestrácie, ktorý považuje dômyselný graf alebo agentovú slučku za náhradu explicitného stavu, zmlúv, vlastníctva, limitov a záznamov. Mágia pôsobí v ukážke dojmom, pretože skrýva mechanizmus. Inžinierstvo je užitočné v produkcii, pretože mechanizmus odhaľuje natoľko, aby sa dal opraviť.
AI orchestrácia je miesto, kde sa pravdepodobnosť stretáva s pracovným postupom. Toto spojenie neodpúšťa. Model si môže zvoliť plán. Nástroj môže vrátiť výsledok. Politika môže povoliť akciu. Opakovaný pokus môže zmeniť kontext. Človek môže schváliť. Nadväzujúci systém môže konať. Ak tieto prechody nie sú pomenované, ohraničené a zaznamenané, organizácia získa systém, ktorý vyzerá inteligentne, ale jeho správanie sa ťažko reprodukuje a ešte ťažšie riadi. Nie je autonómny. Je len vyhýbavý s lepším brandingom.
Orchestrácia nie je inteligentný prach
Slovo orchestrácia môže spôsobiť, že obyčajné inžinierstvo znie novookúzlene. Postupnosť sa stane reťazou. Podmienka sa stane smerovačom. Volanie funkcie sa stane nástrojom. Cyklus while sa stane agentom. Fronta sa stane pamäťou, ak je osvetlenie správne. Časť tohto slovníka je užitočná, pretože AI systémy skutočne prinášajú nové problémy s koordináciou. Časť z neho je balenie. Balenie nie je zlé. Stáva sa drahým, keď tímy zabudnú, čo je vo vnútri škatule.
Vo svojom jadre je orchestrácia riadenie stavu, rozhodnutí, zdrojov a prechodov. Aká je úloha. Aký je aktuálny stav. Ktoré vstupy sú povolené. Ktorý nástroj možno zavolať. Aký tvar výstupu sa očakáva. Čo sa stane pri zlyhaní. Ktoré opakované pokusy sú povolené. Ktoré akcie vyžadujú schválenie. Aké dôkazy sa musia uchovávať. Ktorý krok možno prehrať. Ktorý krok je nezvratný. Tieto otázky existovali pred generatívnou AI. Modely ich robia dôležitejšími, nie zastaranými.
Magické orchestrovanie sa týmto otázkam vyhýba tým, že nechá model alebo framework odvodiť príliš veľa počas behu. Plánovač rozhodne o rozklade. Model si vyberie nástroje. Výstup nástroja sa stane kontextom. Ďalší krok ho interpretuje. Pamäť pridá históriu. Overovač prikývne. Objaví sa konečná odpoveď. Toto môže fungovať pri nenáročných prieskumných úlohách. Je to krehké, keď pracovný postup zasahuje do záznamov, peňazí, bezpečnosti, súladu s predpismi, záväzkov voči zákazníkom, infraštruktúry alebo iných systémov, ktoré neoceňujú improvizačné divadlo.
Disciplinovaný návrh orchestrovania neodstraňuje flexibilitu. Umiestňuje flexibilitu do koľají. Model môže navrhnuť plán, ale výstup plánovača má schému. Systém môže volať nástroje, ale nástroje majú rozsahy a rozpočty. Pracovný postup sa môže opakovať, ale dôvody opakovania sú klasifikované. Pamäť môže pomôcť, ale autoritatívny stav žije inde. Človek môže schváliť, ale schválenie vidí relevantné vetvy a dôkazy. Flexibilita prežije. Záhada nesmie riadiť.
Problém skrytého stavu
Najčastejším zlyhaním orchestrovania je skrytý stav. Stav sa objavuje vo výzvach, poznámkových blokoch, úložiskách pamäte, výstupoch nástrojov, medzisprávach, sumarizáciách modelu, uložených výsledkoch, ľudských komentároch a vnútorných častiach frameworku. Každá vrstva obsahuje čiastočnú pravdu. Žiadna nie je trvalým záznamom. Keď sa niečo pokazí, tím sa pýta, čo systém veril v kroku sedem. Odpoveďou je koláž.
Skrytý stav robí ladenie útrpným. Model si vybral iný nástroj, pretože skoršia sumarizácia použila silnejšie sloveso. Opakovanie vynechalo obmedzenie. Položka pamäte z predchádzajúcej úlohy ovplyvnila plán. Výsledok nástroja bol skrátený. Overovač videl konečnú odpoveď, ale nie zamietnutú vetvu. Systém sa správal vierohodne a vierohodné správanie je najotravnejší druh na vyšetrovanie, pretože odmieta vyzerať rozbité, kým nepoznáte chýbajúci fakt.
Trvalý stav úlohy by mal byť explicitný. Mal by zahŕňať zámer úlohy, povolený rozsah, zdrojovú množinu, verziu plánu, volania nástrojov, výstupy nástrojov, dôvody opakovania, ľudské rozhodnutia, kontroly politík, náklady, časové limity a vykonané akcie. Nie každá nenáročná interakcia potrebuje ťažký register, ale každé orchestrovanie, ktoré môže ovplyvniť skutočnú prácu, potrebuje model stavu nad rámec prepisu. Prepis je užitočné rozprávanie. Nie je operačným systémom.
Explicitný stav tiež zlepšuje dizajn produktu. Používatelia môžu vidieť, či systém plánuje, čaká na nástroj, je blokovaný politikou, žiada o kontrolu, opakuje po prechodnej chybe alebo je pripravený vykonať zmeny. Operátori môžu pozastaviť alebo obnoviť. Vývojári môžu testovať prechody. Audítori môžu prehrávať. Systém sa stáva menej magickým a užitočnejším, čo je kompromis, ktorému niektoré ukážky odolávajú a väčšina prevádzkových tímov ho hlboko oceňuje.
Volania nástrojov nie sú nevinné
Používanie nástrojov dáva systémom AI ruky. To je užitočné a nebezpečné. Čítanie kalendára, vyhľadávanie v dokumentoch, dopyt do databázy, odoslanie e-mailu, otvorenie tiketu, zmena záznamu, nasadenie kódu alebo prevod peňazí nie sú rovnocenné akcie. Magický orchestrátor ich môže považovať za nástroje v zozname. Vážny systém ich považuje za schopnosti s rozsahmi, vedľajšími účinkami, povoleniami, rozpočtami a požiadavkami na dôkazy.
Každé volanie nástroja potrebuje zmluvu. Vstupy musia byť typované a overené. Výstupy musia byť skontrolované. Chyby musia byť klasifikované. Vedľajšie účinky musia byť deklarované. Idempotencia musí byť pochopená. Časové limity musia byť ohraničené. Opakované pokusy musia byť bezpečné. Povolenia musia byť odvodené od používateľa, úlohy a politiky, nie od nadšenia modelu. Systém by mal vedieť, či nástroj iba číta, zapisuje návrh, mení záznam, upozorňuje osobu alebo spúšťa externú povinnosť. Kladivo a bankový prevod by nemali zdieľať rovnakú atmosféru.
Výstup nástroja sa musí tiež považovať za vstup. Môže byť čiastočný, zastaraný, neoprávnený, nejednoznačný alebo nepriateľský. Výsledok vyhľadávania nie je dôkazom, kým systém nepozná zdroj, aktuálnosť a povolenie. Výsledok databázy môže vynechať riadky kvôli riadeniu prístupu. Chyba API môže vrátiť správu, ktorá by sa nemala stať inštrukciou. Nástroj môže zlyhať zdvorilo a aj tak zlyhať. Orchestrátor nesmie posielať každú odpoveď nástroja späť do modelu, akoby vrátenie textu bolo to isté ako hovoriť pravdu.
Vedľajšie účinky si zaslúžia osobitnú opatrnosť. Plán vygenerovaný modelom sa dá zahodiť. Odoslaný e-mail sa nedá vrátiť s rovnakou istotou. Zmenený záznam môže spustiť nadväzujúce systémy. Nasadenie môže ovplyvniť používateľov. Refundácia môže presunúť peniaze. Orchestrácia by mala oddeliť návrh od konania a vyžadovať explicitné brány pre nezvratné alebo závažné kroky. Ak systém dokáže robiť skutočné veci, potrebuje viac než len agentovú slučku. Potrebuje brzdy, kľúče a niekoho, kto vie, kde je rezerva.
Opakovanie pokusov je politika v prestrojení
Opakovanie pokusov vyzerá ako technické lepidlo, kým orchestrátor umelej inteligencie nezačne robiť rozhodnutia. Ak nástroj zlyhá, skús to znova. Ak je výstup modelu chybný, opýtaj sa znova. Ak overovač odmietne odpoveď, prepracuj ju. Ak sa plán zastaví, naplánuj znova. Toto môže byť rozumné. Môže to tiež zmeniť výsledok, skryť neistotu, zvýšiť náklady alebo vymazať dôkazy o tom, prečo prvá cesta zlyhala. Opakovanie pokusu nie je len druhý pokus. Je to rozhodnutie o tom, aký druh zlyhania systém smie zahladiť.
Politika opakovania by mala byť explicitná. Prechodné chyby infraštruktúry sa dajú opakovať inak ako konflikty politík. Chybný JSON sa dá opraviť inak ako chýbajúci dôkaz. Nízka dôvera môže spustiť kontrolu namiesto ďalšej vzorky. Konflikt zdrojov by sa nemal riešiť tým, že model požiadame, aby znel rozhodnejšie. Časový limit nástroja by sa nemal stať povolením použiť slabší zdroj bez označenia zmeny. Systém musí vedieť, prečo opakuje, čo sa zachováva, čo sa mení a kedy prestať.
Bez tejto disciplíny orchestrácia vytvára zdvorilé slučky. Systém sa stále snaží, pretože snaženie je v kóde lacné. Môže spáliť rozpočet, zaplniť protokoly, zmiasť používateľov a nakoniec vytvoriť odpoveď, ktorá vyzerá lepšie hlavne preto, že skoršie dôkazy nestability sú skryté. V produkcii slučka, ktorá skrýva vlastné neúspešné pokusy, nie je vytrvalosť. Je to amnézia s indikátorom priebehu.
Opakovania by mali vytvárať záznamy. Počet pokusov, dôvod, zmenené vstupy, zmenený plán, zachované dôkazy, náklady, latencia a konečné rozhodnutie. To dáva prevádzkovateľom spôsob, ako vidieť, či je pracovný postup zdravý alebo iba vytrvalý. Pomáha to tiež rozhodnúť, či opraviť kvalitu vstupov, spoľahlivosť nástrojov, formátovanie modelu, jasnosť politiky alebo očakávania používateľov. Opakovanie bez klasifikácie je pokrčenie ramien v spustiteľnej podobe.
Overovanie nie je dekoratívny uzol
Mnohé orchestračné diagramy zahŕňajú overovač. Dobre. Potom sa overovač požiada, aby skontroloval, či je odpoveď vierohodná, dobre štruktúrovaná alebo v súlade s pokynmi. Menej dobré. Overovač, ktorý číta iba konečnú odpoveď, môže prehliadnuť chyby, na ktorých záleží: slabý zdroj, zakázaný vstup, zlyhaný nástroj, konflikt zásad, nebezpečná akcia alebo plán zmenený bez schválenia. Môže vyleštiť predné dvere, zatiaľ čo kuchyňa horí.
Overovanie by malo byť viazané na zmluvy a dôsledky. Ak je úlohou extrakcia, overujte podľa rozsahov zdroja. Ak je úlohou klasifikácia, overujte povolené označenia a dôkazy. Ak je úlohou vykonanie nástroja, overujte povolenia, argumenty, vedľajšie účinky a vrátenie zmien. Ak je úlohou podpora rozhodovania, overujte zásady, aktuálnosť zdroja, neistotu a požiadavky na preskúmanie. Ak je úlohou komunikácia, overujte publikum, tvrdenia, tón a zverejnenie. Všeobecný overovač je lepší ako žiadny. Overovač špecifický pre úlohu je lepší ako divadlo.
Niektoré overovanie by malo byť deterministické. Schémy, povolené hodnoty, povolenia, rozpočty, prahy, aktuálnosť zdroja a povinné polia nepotrebujú básnický úsudok modelu. Používajte pravidlá tam, kde sú pravidlá jasné. Používajte modely tam, kde je nejednoznačnosť skutočná. Používajte ľudí tam, kde dôsledky a sporný význam vyžadujú zodpovednosť. Magická orchestrácia často žiada model, aby overoval iný model, pretože sa to zdá symetrické. Symetria je príjemná v architektonických diagramoch. Nie je automaticky kontrolou.
Overovač by mal vidieť stopu, ktorú potrebuje. Samotný konečný text zriedka stačí. Potrebuje vstupy, množinu zdrojov, výstupy nástrojov, neúspešné pokusy, transformácie, kontroly zásad a plánovanú akciu. Mal by mať tiež právomoc blokovať, požadovať viac dôkazov, postúpiť na ľudské preskúmanie alebo označiť obmedzenia. Overovač, ktorý nemôže zastaviť pracovný postup, je recenzent v maškaráde.
Pamäť by nemala napodobňovať autoritu
Pamäť agenta je užitočná, keď nesie preferencie, predchádzajúci kontext a opakované znalosti o úlohách. Je nebezpečná, keď napodobňuje autoritatívny stav. Zapamätaná preferencia nie je zásada. Predchádzajúca odpoveď nie je záznam. Zhrnutie prípadu nie je prípad. Úspešný minulý plán nie je dôkaz, že ďalšia úloha povoľuje rovnaké nástroje. Pamäť pomáha kontinuite. Nemalo by sa jej dovoliť prepašovať autoritu zo včerajška do dneška.
Pamäť potrebuje typy. Osobná preferencia, stav úlohy, organizačné zásady, dôkazy zo zdrojov, naučený vzor, uložený výsledok nástroja a historické rozhodnutie sú rôzne veci. Potrebujú rôzne rozsahy, platnosť, povolenia a zobrazenie. Ak orchestrátor jednoducho získa relevantné spomienky a pridá ich do kontextu, relevantnosť sa stane jedinou bránou. Relevantnosť nie je povolenie. Súkromná poznámka môže byť relevantná. Napriek tomu môže byť zakázaná.
Pamäť tiež potrebuje vymazanie a opravu. Nesprávny predpoklad by nemal pretrvávať, pretože bol raz užitočný. Dočasná podmienka projektu by mala vypršať. Oprava používateľa by sa mala uplatniť v definovanom rozsahu. Zmena zásad by mala zneplatniť starú pamäť. Zhrnutie vygenerované modelom by sa nemalo stať skratkou, ktorá nahrádza primárny zdroj. Systém by mal ukázať, aká pamäť ovplyvnila plán, a umožniť používateľom ju spochybniť. Inak sa pamäť stane zdvorilým strašením.
Pravidlo je jednoduché: autoritatívny stav žije v spravovaných úložiskách. Pamäť môže pomáhať pri plánovaní, ale nemala by ticho rozhodovať. Ak orchestrátor používa pamäť, zaznamenajte, ktorá pamäť, prečo bola povolená a ako ovplyvnila plán. Toto sa zdá ťažké, iba ak pamäť vykonáva závažnú prácu. Ak pamäť vykonáva závažnú prácu, ťažkosť je presne o to.
Jednoduchosť poráža mágiu častejšie, než tímy očakávajú
Nie každý AI pracovný postup potrebuje agentov. Niektoré potrebujú deterministický pipeline s jedným modelovým krokom. Niektoré potrebujú vyhľadávanie, klasifikátor a frontu na ľudskú kontrolu. Niektoré potrebujú formulár, ktorý zavolá model na návrh textu. Niektoré potrebujú dávkové vyhodnotenie. Niektoré potrebujú plánovač. Niektoré potrebujú viackrokové používanie nástrojov. Architektúra by mala nasledovať úlohu, nie aktuálne nadšenie pre diagramy s agentmi.
Nudná alternatíva často vyhráva. Pevná postupnosť sa testuje ľahšie ako otvorená slučka. Typovaná brána nástrojov je bezpečnejšia ako voľný výber nástrojov. Fronta s explicitnými stavmi sa prevádzkuje ľahšie ako rekurzívny agent. Pravidlový strážca je lacnejší ako modelový sudca, keď je pravidlo jasné. Cesta eskalácie na človeka je lepšia ako ďalší pokus, keď sú dôsledky vysoké. Toto nie sú proti-AI postoje. Sú to postoje za systém.
Existuje kompromis. Flexibilnejšia orchestrácia zvládne nejednoznačnosť a neočakávané trasy. Zároveň zvyšuje variabilitu, nároky na dôkazy, náklady a zložitosť ladenia. Explicitnejšia orchestrácia môže pôsobiť rigidne. Zároveň zlepšuje reprodukovateľnosť, vlastníctvo a zotavenie. Správny bod závisí od nejednoznačnosti úlohy, dôsledkov, objemu a tolerancie voči zlyhaniu. Magické myslenie predstiera, že flexibilný koniec dáva všetko zadarmo. Produkcia pošle faktúru neskôr, s položkami.
Užitočná dizajnová otázka je: čo by model nikdy nemal vyberať. Autorita zdroja. Používateľské oprávnenia. Rozpočtové limity. Nezvratné akcie. Povinnosti uchovávania. Právny základ. Bezpečnostné prahy. Niektoré z nich môžu modely navrhovať alebo vysvetľovať. Nemali by ich však ticho nastavovať. Model môže pomôcť orientovať sa v pracovnom postupe. Nemal by sa stať ústavou len preto, že bolo pohodlné dať všetko do kontextu.
Navrhnite orchestráciu ako prevádzkový model
Seriózna orchestrácia začína zmluvou o úlohe. Aký je cieľ. Aké dáta sú povolené. Aké výstupy sú prijateľné. Ktoré nástroje sa môžu použiť. Ktoré akcie sú zakázané. Aký rozpočet platí. Aká latencia je tolerovateľná. Aké dôkazy sa musia uchovať. Aké ľudské roly existujú. Aké stavy zlyhania sú možné. Aké cesty zotavenia existujú. Ak tím nevie odpovedať na tieto otázky, nepotrebuje magickejší graf. Potrebuje jasnejšiu úlohu.
Potom definujte prechody stavov. Naplánované, čaká na vstup, získava, nástroj čaká, nástroj zlyhal, konflikt dôkazov, blokované politikou, ľudská kontrola, schválené, aplikované, kompenzované, zrušené. Tieto stavy môžu znieť všedne, pretože sú. Umožňujú systém prevádzkovať. Umožňujú človeku vedieť, či má čakať, zasiahnuť, schváliť alebo opraviť. Umožňujú testom overiť správanie. Umožňujú incidentom začať od faktov namiesto dojmov.
Potom definujte hranice. Modely navrhujú plány. Brány vykonávajú nástroje. Pravidlá vynucujú presné obmedzenia. Overovače kontrolujú zmluvy. Ľudia rozhodujú o sporných dôsledkoch. Logy uchovávajú dôkazy. Fronty zvládajú oneskorenie. Úložisko drží trvalý stav. Každá hranica by mala byť dosť nudná na vysvetlenie. Ak model robí niekoľko z týchto vecí, pretože to bolo jednoduchšie, pomenujte riziko a rozhodnite, či je úloha dosť nízko-stávková na to, aby sa to tolerovalo. Niekedy je. Mnoho interných asistentov môže byť ľahkých. Problém je predstierať, že ľahký dizajn je základom pre automatizáciu s vysokými dôsledkami.
Napokon, zlyhanie testu. Nástroj vracia čiastkové údaje. Zdroj je v konflikte. Model generuje neplatný výstup. Pamäť je zastaraná. Používateľ nemá oprávnenie. Limit nákladov je dosiahnutý. Ľudská kontrola nie je dostupná. Sieť je pomalá. Plán sa po schválení zmení. Akcia čiastočne uspeje. Ak orchestrátor nedokáže povedať, čo sa v týchto prípadoch stane, graf je len dekoratívny. Môže to byť stále pekný graf. Umiestnite ho k rastline, nie do produkcie.
Ponaučenie
Argument proti magickej orchestrácii je argumentom za inžiniersku disciplínu. Systémy umelej inteligencie potrebujú koordináciu a modely môžu koordináciu urobiť adaptívnejšou. Ale adaptácia bez explicitného stavu, zmlúv pre nástroje, politiky opakovaní, overovania, hraníc pamäte, brán pre akcie a ciest obnovy nie je inteligencia. Je to systém, ktorý žiada budúcich operátorov, aby objavili jeho dizajn čítaním záznamov až po tom, čo sa stalo niečo drahé.
Dobrá orchestrácia je menej mystická a užitočnejšia. Pomenúva stavy. Obmedzuje nástroje. Zaznamenáva dôkazy. Oddeľuje návrh od akcie. Klasifikuje opakovania. Overuje voči zmluvám úloh. S pamäťou pracuje ako s pomocnou, nie autoritatívnou. Ľuďom poskytuje kontrolovateľné stavy namiesto nepriehľadných prepisov. Vyberá jednoduché pipelines, keď jednoduché pipelines stačia. Pridáva agentov tam, kde nejednoznačnosť ospravedlňuje prevádzkovú cenu.
Mágia skrýva mechanizmus. Vážna umelá inteligencia potrebuje mechanizmy, ktoré možno kontrolovať, pozastaviť, opraviť a zlepšiť. Cieľom nie je odstrániť úžas zo softvéru. Cieľom je udržať úžas mimo správy o incidente.