Proti čarobni orkestraciji
Graf, ki je bil videti inteligenten
Diagram orkestracije je bil lep na način, kot so nevarni diagrami pogosto lepi. Zaobljeni okvirji, elegantne puščice, načrtovalec, raziskovalec, preverjevalec, izvajalec orodij, pomnilniška plast, vozlišče za odobritev človeka in končni odgovor. Predstavitev se je odvijala z gledališko samozavestjo. Uporabnik je zaprosil za analizo, načrtovalec je razčlenil nalogo, orodja so bila poklicana, pojavile so se vmesne opombe, končni odgovor pa je prišel z mirnostjo sistema, ki še nikoli ni videl produkcijskega prometa.
Potem so prišli prvi pravi izjemni dogodki. Orodje je vrnilo delne podatke. Načrtovalec je poskusil znova z drugim poizvedovanjem in izgubil prejšnji razlog. Preverjevalec je preveril slog, ne pa tudi spora glede vira. Pomnilnik je priklical staro predpostavko, ker se je zdela pomembna. Korak odobritve človeka je odobril končno besedilo, ne da bi videl neuspelo vejo. Sled je obstajala, a branje je bilo podobno pregledovanju kovčka, ki ga je med požarno vajo pakiral odbor. Graf ni spektakularno odpovedal. Skril je obliko odgovornosti.
To je argument proti čarobni orkestraciji. Ne proti orkestraciji sami. Kompleksni sistemi umetne inteligence potrebujejo usklajevanje. Morajo klicati orodja, usmerjati naloge, upravljati kontekst, spraševati ljudi, se opomoči od napak, deliti delo in združevati dokaze. Argument je proti slogu orkestracije, ki pameten graf ali zanko agenta obravnava kot nadomestek za izrecno stanje, pogodbe, lastništvo, omejitve in zapise. Čarobnost je v predstavitvi impresivna, ker skriva mehanizem. Inženirstvo je v produkciji uporabno, ker mehanizem dovolj razkrije, da ga je mogoče popraviti.
Orkestracija umetne inteligence je prostor, kjer se verjetnost sreča s potekom dela. To stičišče ne odpušča. Model lahko izbere načrt. Orodje lahko vrne rezultat. Politika lahko dovoli dejanje. Ponovni poskus lahko spremeni kontekst. Človek lahko odobri. Nadaljnji sistem lahko ukrepa. Če ti prehodi niso poimenovani, omejeni in zabeleženi, organizacija dobi sistem, ki je videti inteligenten, a je njegovo vedenje težko ponoviti in še težje upravljati. Ni avtonomen. Je le izmikajoč se z boljšo blagovno znamko.
Orkestracija ni čarobni prah inteligence
Beseda orkestracija lahko običajno inženirstvo naredi videti na novo začarano. Zaporedje postane veriga. Pogoj postane usmerjevalnik. Klic funkcije postane orodje. Zanka while postane agent. Čakalna vrsta postane pomnilnik, če je osvetlitev prava. Del tega besedišča je uporabnega, ker sistemi umetne inteligence res uvajajo nove težave pri usklajevanju. Del je le embalaža. Embalaža ni zla. Postane draga, ko ekipe pozabijo, kaj je v škatli.
V svojem jedru je orkestracija upravljanje stanja, odločitev, virov in prehodov. Kaj je naloga. Kakšno je trenutno stanje. Kateri vnosi so dovoljeni. Katero orodje je lahko poklicano. Kakšna oblika izhoda je pričakovana. Kaj se zgodi ob napaki. Kateri ponovni poskusi so dovoljeni. Katera dejanja zahtevajo odobritev. Katere dokaze je treba hraniti. Kateri korak je mogoče ponoviti. Kateri korak je nepovraten. Ta vprašanja so obstajala že pred generativno umetno inteligenco. Modeli jih delajo pomembnejša, ne zastarela.
Čarobna orkestracija se tem vprašanjem izogne tako, da modelu ali ogrodju pusti, da med izvajanjem sklepa preveč stvari sam. Načrtovalec določi razčlenitev. Model izbere orodja. Izhod orodja postane kontekst. Naslednji korak ga interpretira. Pomnilnik doda zgodovino. Preverjevalec prikima. Končni odgovor se pojavi. To lahko deluje pri raziskovalnih nalogah z nizkim tveganjem. Je pa krhko, ko potek dela sega do zapisov, denarja, varnosti, skladnosti, obljub strankam, infrastrukture ali drugih sistemov, ki ne cenijo improvizacijskega gledališča.
Disciplinirana zasnova orkestracije ne odstranjuje prilagodljivosti. Postavi jo v okvirje. Model lahko predlaga načrt, vendar ima izhod načrtovalca shemo. Sistem lahko kliče orodja, vendar imajo orodja obseg in proračune. Potek dela lahko poskusi znova, vendar so razlogi za ponovni poskus razvrščeni. Pomnilnik lahko pomaga, vendar avtoritativno stanje živi drugje. Človek lahko odobri, vendar odobritev vidi ustrezne veje in dokaze. Prilagodljivost preživi. Skrivnostnost ne sme prevzeti krmila.
Problem skritega stanja
Najpogostejša napaka orkestracije je skrito stanje. Stanje se pojavlja v pozivih, beležkah, pomnilniških shrambah, izhodih orodij, vmesnih sporočilih, povzetkih modela, predpomnjenih rezultatih, komentarjih ljudi in notranjosti ogrodij. Vsaka plast vsebuje delno resnico. Nobena ni trajen zapis. Ko gre kaj narobe, se ekipa vpraša, kaj je sistem verjel v sedmem koraku. Odgovor je kolaž.
Skrito stanje naredi razhroščevanje mučno. Model je izbral drugo orodje, ker je zgodnejši povzetek uporabil močnejši glagol. Ponovni poskus je izpustil omejitev. Pomnilniški element iz prejšnje naloge je vplival na načrt. Rezultat orodja je bil okrnjen. Preverjevalec je videl končni odgovor, ne pa zavrnjene veje. Sistem se je obnašal verjetno, verjetno obnašanje pa je najbolj nadležna vrsta za preiskavo, ker noče izgledati pokvarjen, dokler ne izveš manjkajočega dejstva.
Trajno stanje naloge mora biti izrecno. Vključevati mora namen naloge, dovoljeni obseg, nabor virov, različico načrta, klice orodij, izhode orodij, razloge za ponovne poskuse, odločitve ljudi, preverjanja politik, stroške, časovne omejitve in izvedena dejanja. Vsaka interakcija z nizkim tveganjem ne potrebuje težke knjige stanja, vendar vsaka orkestracija, ki lahko vpliva na resnično delo, potrebuje model stanja, ki presega prepis. Prepis je uporabna pripoved. Ni operacijski sistem.
Izrecno stanje izboljša tudi oblikovanje izdelka. Uporabniki lahko vidijo, ali sistem načrtuje, čaka na orodje, ga blokira politika, prosi za pregled, poskuša znova po prehodni napaki ali je pripravljen izvesti spremembe. Operaterji lahko začasno ustavijo ali nadaljujejo. Razvijalci lahko preizkusijo prehode. Revizorji lahko predvajajo. Sistem postane manj čaroben in bolj uporaben, kar je kompromis, ki se mu nekateri predstavitveni posnetki upirajo, večina operativnih ekip pa ga globoko ceni.
Klici orodij niso nedolžni
Uporaba orodij daje sistemom umetne inteligence roke. To je uporabno in nevarno. Branje koledarja, iskanje po dokumentih, poizvedovanje v podatkovni bazi, pošiljanje e-pošte, odpiranje zahtevka, spreminjanje zapisa, uvajanje kode ali prenos denarja niso enakovredna dejanja. Čarobni orkestrator jih lahko obravnava kot orodja na seznamu. Resen sistem jih obravnava kot zmogljivosti z obsegi, stranskimi učinki, dovoljenji, proračuni in zahtevami po dokazih.
Vsak klic orodja potrebuje pogodbo. Vhodi morajo biti tipizirani in preverjeni. Izhode je treba preveriti. Napake je treba razvrstiti. Stranske učinke je treba prijaviti. Idempotentnost je treba razumeti. Časovne omejitve morajo biti določene. Ponovni poskusi morajo biti varni. Dovoljenja morajo izhajati iz uporabnika, naloge in pravilnika, ne iz navdušenja modela. Sistem bi moral vedeti, ali orodje samo bere, piše osnutek, spreminja zapis, obvešča osebo ali sproži zunanjo obveznost. Kladivo in bančna nakazila ne bi smela imeti enakega pridiha.
Izhod orodja je treba obravnavati tudi kot vhod. Lahko je delen, zastarel, nepooblaščen, dvoumen ali sovražen. Rezultat iskanja ni dokaz, dokler sistem ne pozna vira, svežine in dovoljenja. Rezultat podatkovne zbirke lahko izpusti vrstice zaradi nadzora dostopa. Napaka API-ja lahko vrne sporočilo, ki ne bi smelo postati navodilo. Orodje lahko vljudno odpove in še vedno odpove. Orkestrator ne sme vsakega odziva orodja vračati nazaj v model, kot da bi bilo vračanje besedila enako pripovedovanju resnice.
Stranski učinki si zaslužijo posebno previdnost. Načrt, ki ga ustvari model, lahko zavržemo. Poslanega e-poštnega sporočila ni mogoče preklicati z enako gotovostjo. Spremenjen zapis lahko sproži nadaljnje sisteme. Uvedba lahko vpliva na uporabnike. Povračilo lahko premakne denar. Orkestracija bi morala ločiti predlog od dejanja in zahtevati izrecna vrata za nepovratne ali pomembne korake. Če sistem lahko naredi resnične stvari, potrebuje več kot samo zanko agenta. Potrebuje zavore, ključe in nekoga, ki ve, kje je rezervni.
Ponovni poskusi so prikriti pravilnik
Ponovni poskusi so videti kot inženirsko lepilo, dokler orkestrator z umetno inteligenco ne začne sprejemati odločitev. Če orodje odpove, poskusi znova. Če je izhod modela nepravilen, vprašaj znova. Če preverjevalnik zavrne odgovor, ga popravi. Če se načrt ustavi, ga načrtuj znova. To je lahko smiselno. Lahko pa tudi spremeni izid, skrije negotovost, poveča stroške ali izbriše dokaze o tem, zakaj je prva pot odpovedala. Ponovni poskus ni zgolj drugi poskus. Je odločitev o tem, kakšno vrsto napake sistem sme prikriti.
Pravilnik o ponovnih poskusih mora biti izrecen. Začasne infrastrukturne napake je mogoče ponoviti drugače kot konflikte pravilnikov. Nepravilen JSON je mogoče popraviti drugače kot manjkajoče dokaze. Nizka samozavest lahko sproži pregled namesto drugega vzorca. Konflikta virov ne bi smeli reševati tako, da model prosimo, naj zveni bolj odločno. Časovna omejitev orodja ne bi smela postati dovoljenje za uporabo šibkejšega vira brez označbe spremembe. Sistem mora vedeti, zakaj ponavlja, kaj se ohrani, kaj se spremeni in kdaj prenehati.
Brez te discipline orkestracija ustvarja vljudne zanke. Sistem vztraja, ker je poskušanje v kodi poceni. Lahko porabi proračun, napolni dnevnike, zmede uporabnike in na koncu ustvari odgovor, ki je videti boljši predvsem zato, ker so prejšnji dokazi o nestabilnosti skriti. V produkciji zanka, ki skriva lastne neuspele poskuse, ni vztrajnost. Je amnezija z vrstico napredka.
Ponovni poskusi bi morali ustvarjati zapise. Število poskusov, razlog, spremenjeni vhodi, spremenjeni načrt, ohranjeni dokazi, stroški, zakasnitev in končna razrešitev. To operaterjem omogoča, da vidijo, ali je delovni proces zdrav ali zgolj vztrajen. Prav tako pomaga pri odločanju, ali izboljšati kakovost vhodov, zanesljivost orodij, oblikovanje modela, jasnost pravilnikov ali pričakovanja uporabnikov. Ponovni poskus brez razvrstitve je skomigni z rameni v izvedljivi obliki.
Preverjanje ni okrasno vozlišče
Mnogi orkestracijski diagrami vključujejo preverjevalnik. To je dobro. Nato pa preverjevalnik dobi nalogo, da preveri, ali je odgovor verjeten, dobro oblikovan ali skladen z navodili. To pa je manj dobro. Preverjevalnik, ki bere samo končni odgovor, lahko spregleda napake, ki so pomembne: šibek vir, nedovoljen vnos, neuspelo orodje, navzkrižje politik, nevarno dejanje ali načrt, spremenjen brez odobritve. Lahko polepša vhodna vrata, medtem ko kuhinja gori.
Preverjanje bi moralo biti povezano s pogodbami in posledicami. Če je naloga izluščanje, preverjaj glede na izvorne odlomke. Če je naloga klasifikacija, preverjaj dovoljene oznake in dokaze. Če je naloga izvajanje orodij, preverjaj dovoljenja, argumente, stranske učinke in povrnitev. Če je naloga podpora pri odločanju, preverjaj politiko, svežino virov, negotovost in zahteve po pregledu. Če je naloga komunikacija, preverjaj občinstvo, trditve, ton in razkritja. Splošen preverjevalnik je boljši kot nič. Preverjevalnik, prilagojen nalogi, je boljši kot gledališče.
Del preverjanja bi moral biti determinističen. Sheme, dovoljene vrednosti, dovoljenja, proračuni, pragovi, svežina virov in obvezna polja ne potrebujejo pesniške presoje modela. Uporabi pravila tam, kjer so pravila jasna. Uporabi modele tam, kjer je dvoumnost resnična. Uporabi ljudi tam, kjer posledice in sporna vsebina zahtevajo odgovornost. Magična orkestracija pogosto zahteva, da model preverja drug model, ker se to zdi simetrično. Simetrija je prijetna v arhitekturnih diagramih. Ni pa samodejno nadzor.
Preverjevalnik bi moral videti sled, ki jo potrebuje. Samo končno besedilo redko zadostuje. Potrebuje vnose, nabor virov, izhode orodij, neuspele poskuse, transformacije, preverjanja politik in načrtovana dejanja. Prav tako bi moral imeti pooblastilo, da blokira, zahteva več dokazov, preusmeri na človeški pregled ali označi omejitve. Preverjevalnik, ki ne more ustaviti poteka dela, je recenzent v lepih oblačilih.
Spomin ne sme prevzemati vloge avtoritete
Spomin agenta je uporaben, kadar nosi preference, prejšnji kontekst in znanje o ponavljajočih se nalogah. Nevaren pa je, kadar prevzema vlogo avtoritativnega stanja. Zapomnjena preferenca ni politika. Prejšnji odgovor ni zapis. Povzetek primera ni primer. Uspešen pretekli načrt ni dokaz, da naslednja naloga dovoljuje ista orodja. Spomin pomaga pri kontinuiteti. Ne bi smel smeti pretihotapljati avtoritete iz včerajšnjega dne v današnjega.
Spomin potrebuje vrste. Osebna preferenca, stanje naloge, organizacijska politika, dokazi iz virov, naučeni vzorec, predpomnjen rezultat orodja in zgodovinska odločitev so različne stvari. Potrebujejo različne obsege, roke veljavnosti, dovoljenja in prikaz. Če orkestrator preprosto poišče pomembne spomine in jih doda v kontekst, postane pomembnost edina vrata. Pomembnost ni dovoljenje. Zasebni zapisek je lahko pomemben. Kljub temu je lahko prepovedan.
Spomin potrebuje tudi izbris in popravek. Napačna predpostavka ne bi smela vztrajati samo zato, ker je bila enkrat uporabna. Začasni projektni pogoj bi moral poteči. Popravek uporabnika bi se moral uporabljati v določenem obsegu. Sprememba politike bi morala razveljaviti star spomin. Povzetek, ki ga ustvari model, ne bi smel postati bližnjica, ki nadomesti primarni vir. Sistem bi moral prikazati, kateri spomin je vplival na načrt, in uporabnikom omogočiti, da ga izpodbijajo. V nasprotnem primeru spomin postane vljudno strašenje.
Pravilo je preprosto: avtoritativno stanje živi v urejenih shrambah. Spomin lahko pomaga pri načrtovanju, vendar ne bi smel tiho odločati. Če orkestrator uporablja spomin, zabeleži, kateri spomin, zakaj je bil dovoljen in kako je vplival na načrt. To se zdi težko samo, če spomin opravlja pomembno delo. Če spomin opravlja pomembno delo, je teža ravno bistvo.
Preprosto pogosteje premaga magično, kot ekipe pričakujejo
Vsak AI potek dela ne potrebuje agentov. Nekateri potrebujejo deterministično cevovod z enim korakom modela. Nekateri potrebujejo pridobivanje, klasifikator in čakalno vrsto za človeški pregled. Nekateri potrebujejo obrazec, ki pokliče model za osnutek. Nekateri potrebujejo paketno vrednotenje. Nekateri potrebujejo načrtovalca. Nekateri potrebujejo uporabo orodij v več korakih. Arhitektura naj sledi nalogi, ne trenutnemu navdušenju nad diagrami v obliki agentov.
Dolgočasna alternativa pogosto zmaga. Fiksno zaporedje je lažje preizkusiti kot odprto zanko. Tipiziran prehod orodij je varnejši od proste izbire orodij. Čakalna vrsta z jasnimi stanji je lažje upravljati kot rekurzivni agent. Pravilno zasnovana zaščita je cenejša od modela kot sodnika, kadar je pravilo jasno. Pot za eskalacijo k človeku je boljša od ponovnega poskusa, kadar so posledice velike. To niso stališča proti AI. To so stališča za sistem.
Obstaja kompromis. Bolj prilagodljiva orkestracija lahko obvlada dvoumnost in nepričakovane poti. Prav tako poveča variabilnost, dokazno breme, stroške in zapletenost razhroščevanja. Bolj izrecna orkestracija se lahko zdi toga. Prav tako izboljša ponovljivost, odgovornost in obnovitev. Prava točka je odvisna od dvoumnosti naloge, posledic, obsega in tolerance do napak. Čarobno razmišljanje se pretvarja, da prilagodljivi konec daje vse zastonj. Produkcija račun pošlje pozneje, s postavkami.
Uporabno oblikovalsko vprašanje je: česa model nikoli ne sme izbrati. Avtoriteta vira. Uporabniška dovoljenja. Omejitve proračuna. Nepovratna dejanja. Obveznosti hrambe. Pravna podlaga. Varnostni pragovi. Nekatere od teh lahko modeli predlagajo ali pojasnijo. Ne smejo jih tiho določati. Model lahko pomaga pri navigaciji poteka dela. Ne sme postati ustava, ker je bilo priročno dati vse v kontekst.
Oblikujte orkestracijo kot operativni model
Resna orkestracija se začne s pogodbo o nalogi. Kaj je cilj. Kateri podatki so dovoljeni. Kateri izhodi so sprejemljivi. Katera orodja se lahko uporabijo. Katera dejanja so prepovedana. Kateri proračun velja. Kakšna zakasnitev je sprejemljiva. Katere dokaze je treba hraniti. Katere človeške vloge obstajajo. Katera stanja napak so možna. Katere poti za obnovitev obstajajo. Če ekipa ne more odgovoriti na ta vprašanja, ne potrebuje bolj čarobnega grafa. Potrebuje jasnejšo nalogo.
Nato določite prehode stanj. Načrtovano, čakanje na vnos, pridobivanje, orodje v teku, orodje ni uspelo, nasprotje dokazov, politika blokirana, človeški pregled, odobreno, uporabljeno, kompenzirano, preklicano. Ta stanja se morda zdijo vsakdanja, ker so. Sistemu omogočajo upravljanje. Osebi omogočajo vedeti, ali naj počaka, posreduje, odobri ali popravi. Testom omogočajo preverjanje vedenja. Incidentom omogočajo začetek iz dejstev namesto iz občutkov.
Nato določite meje. Modeli pripravijo osnutke načrtov. Prehodi izvajajo orodja. Pravila uveljavljajo jasne omejitve. Preverjevalniki preverjajo pogodbe. Ljudje odločajo o spornih posledicah. Dnevniki ohranjajo dokaze. Čakalne vrste obravnavajo zamude. Shramba hrani trajno stanje. Vsaka meja mora biti dovolj dolgočasna za razlago. Če model opravlja več teh nalog, ker je bilo lažje, poimenujte tveganje in se odločite, ali je naloga dovolj nizkega tveganja, da jo lahko prenesete. Včasih je. Številni notranji pomočniki so lahko lahki. Težava je pretvarjanje, da je lahka zasnova temelj za avtomatizacijo z visokimi posledicami.
Končno, napaka pri testu. Orodje vrne delne podatke. Viri so v nasprotju. Model ustvari neveljaven izpis. Pomnilnik je zastarel. Uporabnik nima dovoljenja. Dosežena je omejitev stroškov. Človeški pregled ni na voljo. Omrežje je počasno. Načrt se po odobritvi spremeni. Dejanje delno uspe. Če vam orkestrator ne more povedati, kaj se zgodi v teh primerih, je graf dekorativen. Še vedno je lahko lep graf. Postavite ga k rastlini, ne blizu produkcije.
Nauk
Argument proti magični orkestraciji je argument za inženirsko disciplino. Sistemi umetne inteligence potrebujejo usklajevanje, modeli pa lahko usklajevanje naredijo bolj prilagodljivo. Toda prilagajanje brez izrecnega stanja, pogodb o orodjih, politike ponovnih poskusov, preverjanja, meja pomnilnika, vrat dejanj in poti za obnovitev ni inteligenca. Je sistem, ki od prihodnjih operaterjev zahteva, da njegovo zasnovo odkrijejo z branjem sledi po tem, ko se je zgodilo nekaj dragega.
Dobra orkestracija je manj mistična in bolj uporabna. Poimenuje stanja. Omejuje orodja. Beleži dokaze. Ločuje predlog od dejanja. Razvršča ponovne poskuse. Preverja skladnost s pogodbami o nalogah. Pomnilnik obravnava kot pomoč, ne kot avtoriteto. Ljudem daje stanja, ki jih je mogoče pregledati, namesto nepreglednih prepisov. Izbere preproste cevovode, kadar so preprosti cevovodi dovolj. Doda agente, kjer dvoumnost upravičuje operativno ceno.
Magija skriva mehanizem. Resna umetna inteligenca potrebuje mehanizme, ki jih je mogoče pregledati, začasno ustaviti, popraviti in izboljšati. Cilj ni odstraniti čudež iz programske opreme. Cilj je obdržati čudež stran od poročila o incidentu.