Magijos kupinos orkestracijos atvejis
Grafikas, kuris atrodė protingas
Orchestracijos diagrama buvo graži taip, kaip dažnai būna gražios pavojingos diagramos. Apvalūs langeliai, grakščios rodyklės, planuotojas, tyrėjas, tikrintojas, įrankių vykdytojas, atminties sluoksnis, žmogaus patvirtinimo mazgas ir galutinis atsakymas. Demonstracija judėjo su teatrališku pasitikėjimu. Vartotojas paprašė analizės, planuotojas išskaidė užduotį, buvo iškviesti įrankiai, atsirado tarpiniai užrašai, o galutinis atsakymas atėjo su ramybe sistemos, kuri niekada nėra susidūrusi su gamybiniu srautu.
Tada atėjo pirmosios tikrosios išimtys. Įrankis grąžino dalinius duomenis. Planuotojas bandė iš naujo su kita užklausa ir prarado ankstesnę priežastį. Tikrintojas patikrino stilių, bet ne šaltinio konfliktą. Atmintis grąžino seną prielaidą, nes ji atrodė aktuali. Žmogaus patvirtinimo žingsnis patvirtino galutinį tekstą nematęs nepavykusios šakos. Pėdsakas egzistavo, bet jį skaityti buvo tarsi apžiūrėti lagaminą, kurį per gaisro pratybas pakavo komitetas. Grafikas nebuvo žlugęs dramatiškai. Jis buvo paslėpęs atsakomybės formą.
Tai argumentas prieš magiškąją orchestraciją. Ne prieš pačią orchestraciją. Sudėtingoms AI sistemoms reikia koordinavimo. Jos turi kviesti įrankius, nukreipti užduotis, valdyti kontekstą, klausti žmonių, atsigauti po gedimų, skaidyti darbą ir derinti įrodymus. Argumentas yra prieš tokį orchestracijos stilių, kuris protingą grafiką ar agento ciklą laiko pakaitais aiškiai būsenai, sutartims, nuosavybei, riboms ir įrašams. Magija įspūdinga demonstracijoje, nes ji slepia mechanizmą. Inžinerija naudinga gamyboje, nes ji atskleidžia mechanizmą pakankamai, kad jį būtų galima taisyti.
AI orchestracija yra vieta, kur tikimybė susitinka su darbo eiga. Ta sandūra neatleidžia. Modelis gali pasirinkti planą. Įrankis gali grąžinti rezultatą. Politika gali leisti veiksmą. Pakartotinis bandymas gali pakeisti kontekstą. Žmogus gali patvirtinti. Tolesnė sistema gali veikti. Jei tie perėjimai nėra įvardyti, apriboti ir užfiksuoti, organizacija gauna protingai atrodančią sistemą, kurios elgesį sunku atkartoti ir dar sunkiau valdyti. Ji nėra autonominė. Ji tiesiog išsisukinėja su geresniu įvaizdžiu.
Orchestracija nėra intelekto dulkės
Žodis orchestracija gali priversti įprastą inžineriją skambėti naujai užburtai. Seka tampa grandine. Sąlyga tampa maršrutizatoriumi. Funkcijos iškvietimas tampa įrankiu. While ciklas tampa agentu. Eilė tampa atmintimi, jei apšvietimas tinkamas. Dalis šio žodyno yra naudinga, nes AI sistemos iš tiesų įveda naujų koordinavimo problemų. Dalis jo yra pakuotė. Pakuotė nėra blogis. Ji tampa brangi, kai komandos pamiršta, kas yra dėžutės viduje.
Iš esmės orchestracija yra būsenos, sprendimų, išteklių ir perėjimų valdymas. Kokia yra užduotis. Kokia yra dabartinė būsena. Kurie įvesties duomenys leidžiami. Kuris įrankis gali būti iškviestas. Kokia išvesties forma tikimasi. Kas nutinka gedimo atveju. Kurie pakartotiniai bandymai leidžiami. Kurie veiksmai reikalauja patvirtinimo. Kokie įrodymai turi būti saugomi. Kurį žingsnį galima atkartoti. Kuris žingsnis yra negrįžtamas. Šie klausimai egzistavo iki generatyvinio AI. Modeliai juos daro svarbesnius, o ne pasenusius.
Magiška orkestruotė šių klausimų išvengia leisdama modeliui ar sistemai per daug nuspręsti vykdymo metu. Planuoklis nustato skaidymą. Modelis pasirenka įrankius. Įrankio išvestis tampa kontekstu. Kitas žingsnis jį interpretuoja. Atmintis prideda istoriją. Tikrintojas linkteli. Galutinis atsakymas atsiranda. Tai gali veikti mažos rizikos tiriamosioms užduotims. Tai trapu, kai darbo eiga liečia įrašus, pinigus, saugą, atitiktį, įsipareigojimus klientams, infrastruktūrą ar kitas sistemas, kurios nevertina improvizacinio teatro.
Drausmingas orkestruotės dizainas nepašalina lankstumo. Jis įdeda lankstumą į bėgius. Modelis gali pasiūlyti planą, bet planuoklio išvestis turi schemą. Sistema gali kviesti įrankius, bet įrankiai turi apimtis ir biudžetus. Darbo eiga gali bandyti iš naujo, bet pakartotinio bandymo priežastys yra klasifikuojamos. Atmintis gali padėti, bet autoritetinga būsena gyvena kitur. Žmogus gali patvirtinti, bet patvirtinimas mato svarbias šakas ir įrodymus. Lankstumas išlieka. Paslaptingumas negauna vairo.
Paslėptos būsenos problema
Dažniausias orkestruotės gedimas yra paslėpta būsena. Būsena atsiranda raginimuose, juodraščiuose, atminties saugyklose, įrankio išvestyse, tarpinėse žinutėse, modelio santraukose, talpykloje saugomuose rezultatuose, žmonių komentaruose ir sistemos viduje. Kiekvienas sluoksnis turi dalinę tiesą. Nė vienas nėra patvarus įrašas. Kai kas nors nutinka ne taip, komanda klausia, ką sistema manė septintame žingsnyje. Atsakymas yra koliažas.
Paslėpta būsena daro derinimą kančia. Modelis pasirinko kitą įrankį, nes ankstesnė santrauka vartojo stipresnį veiksmažodį. Pakartotinis bandymas praleido apribojimą. Atminties elementas iš ankstesnės užduoties paveikė planą. Įrankio rezultatas buvo sutrumpintas. Tikrintojas matė galutinį atsakymą, bet ne atmestą šaką. Sistema elgėsi įtikinamai, o įtikinamas elgesys yra pats erzinantis dalykas tirti, nes jis atsisako atrodyti sugedęs, kol nežinai trūkstamo fakto.
Patvari užduoties būsena turėtų būti aiški. Ji turėtų apimti užduoties tikslą, leistiną apimtį, šaltinių rinkinį, plano versiją, įrankio iškvietimus, įrankio išvestis, pakartotinio bandymo priežastis, žmonių sprendimus, politikos patikras, išlaidas, laiko ribas ir pritaikytus veiksmus. Ne kiekviena mažos rizikos sąveika reikalauja sunkaus registro, bet bet kokia orkestruotė, galinti paveikti realų darbą, reikalauja būsenos modelio, kuris viršija pokalbio įrašą. Pokalbio įrašas yra naudingas pasakojimas. Jis nėra operacinė sistema.
Aiški būsena taip pat gerina produkto dizainą. Vartotojai gali matyti, ar sistema planuoja, laukia įrankio, yra užblokuota politikos, prašo peržiūros, bando iš naujo po trumpalaikės klaidos ar yra pasirengusi pritaikyti pakeitimus. Operatoriai gali pristabdyti arba tęsti. Kūrėjai gali testuoti perėjimus. Auditoriai gali atkurti. Sistema tampa mažiau magiška ir naudingesnė, o tai yra mainai, kuriems kai kurios demonstracijos priešinasi, o dauguma operacijų komandų labai vertina.
Įrankio iškvietimai nėra nekalti
Įrankių naudojimas suteikia AI sistemoms rankas. Tai naudinga ir pavojinga. Kalendoriaus skaitymas, dokumentų paieška, duomenų bazės užklausa, el. laiško siuntimas, bilieto atidarymas, įrašo keitimas, kodo diegimas ar pinigų pervedimas nėra lygiaverčiai veiksmai. Magiška orkestruotė gali juos traktuoti kaip įrankius sąraše. Rimta sistema juos traktuoja kaip galimybes su apimtimis, šalutiniais poveikiais, leidimais, biudžetais ir įrodymų reikalavimais.
Kiekvienas įrankio iškvietimas turi turėti sutartį. Įvestys turi būti tipizuotos ir patvirtintos. Išvestys turi būti tikrinamos. Klaidos turi būti klasifikuojamos. Šalutiniai poveikiai turi būti deklaruojami. Idempotentiškumas turi būti suprastas. Laiko limitai turi būti apriboti. Pakartotiniai bandymai turi būti saugūs. Leidimai turi būti išvedami iš vartotojo, užduoties ir politikos, o ne iš modelio entuziazmo. Sistema turi žinoti, ar įrankis tik skaito, rašo juodraštį, keičia įrašą, informuoja asmenį ar sukelia išorinį įsipareigojimą. Plaktukas ir bankinis pervedimas neturėtų turėti tos pačios nuotaikos.
Įrankio išvestis taip pat turi būti traktuojama kaip įvestis. Ji gali būti dalinė, pasenusi, neautorizuota, dviprasmiška ar priešiška. Paieškos rezultatas nėra įrodymas, kol sistema nežino šaltinio, naujumo ir leidimo. Duomenų bazės rezultatas gali praleisti eilutes dėl prieigos kontrolės. API klaida gali grąžinti pranešimą, kuris neturėtų tapti instrukcija. Įrankis gali mandagiai nepavykti ir vis tiek nepavykti. Orkestratorius neturi maitinti kiekvieno įrankio atsakymo atgal į modelį taip, lyg teksto grąžinimas būtų tas pats, kas tiesos sakymas.
Šalutiniai poveikiai nusipelno ypatingo atsargumo. Modelio sugeneruotą planą galima išmesti. Išsiųsto el. laiško negalima atsiimti su tokiu pat pasitikėjimu. Pakeistas įrašas gali suaktyvinti vėlesnes sistemas. Diegimas gali paveikti vartotojus. Grąžinimas gali perkelti pinigus. Orkestravimas turėtų atskirti pasiūlymą nuo veiksmo ir reikalauti aiškių vartų negrįžtamiems ar reikšmingiems žingsniams. Jei sistema gali atlikti realius dalykus, jai reikia daugiau nei agento ciklo. Jai reikia stabdžių, raktų ir žmogaus, kuris žino, kur yra atsarginis.
Pakartotiniai bandymai yra užmaskuota politika
Pakartotiniai bandymai atrodo kaip inžineriniai klijai, kol AI orkestratorius nepradeda priimti sprendimų. Jei įrankis nepavyksta, bandykite dar kartą. Jei modelio išvestis yra netaisyklinga, klauskite dar kartą. Jei tikrintuvas atmeta atsakymą, taisykite. Jei planas stringa, planuokite iš naujo. Tai gali būti protinga. Tai taip pat gali pakeisti rezultatą, paslėpti neapibrėžtumą, padidinti išlaidas arba ištrinti įrodymus, kodėl pirmasis kelias nepavyko. Pakartotinis bandymas nėra tik antras mėginimas. Tai sprendimas, kokio tipo gedimą sistemai leidžiama užglaistyti.
Pakartotinių bandymų politika turi būti aiški. Laikinus infrastruktūros klaidas galima bandyti kitaip nei politikos konfliktus. Netaisyklingą JSON galima taisyti kitaip nei trūkstamus įrodymus. Mažas pasitikėjimas gali paskatinti peržiūrą, o ne kitą pavyzdį. Šaltinio konfliktas neturėtų būti sprendžiamas prašant modelio skambėti ryžtingiau. Įrankio laiko limitas neturėtų tapti leidimu naudoti silpnesnį šaltinį nepažymėjus pakeitimo. Sistema turi žinoti, kodėl ji bando iš naujo, kas išsaugoma, kas keičiasi ir kada sustoti.
Be tokios disciplinos orkestravimas sukuria mandagius ciklus. Sistema bando toliau, nes bandymas kode yra pigus. Ji gali sudeginti biudžetą, užpildyti žurnalus, suklaidinti vartotojus ir galiausiai pateikti atsakymą, kuris atrodo geresnis daugiausia todėl, kad ankstesni nestabilumo įrodymai yra paslėpti. Gamyboje ciklas, slepiantis savo nesėkmingus bandymus, nėra atkaklumas. Tai amnezija su progreso juosta.
Pakartotiniai bandymai turėtų kurti įrašus. Bandymų skaičius, priežastis, pakeistos įvestys, pakeistas planas, išsaugoti įrodymai, išlaidos, delsos laikas ir galutinis sprendimas. Tai suteikia operatoriams būdą pamatyti, ar darbo eiga yra sveika, ar tik atkakli. Tai taip pat padeda nuspręsti, ar taisyti įvesties kokybę, įrankio patikimumą, modelio formatavimą, politikos aiškumą ar vartotojų lūkesčius. Pakartotinis bandymas be klasifikacijos yra gūžtelėjimas pečiais vykdomąja forma.
Patikrinimas nėra dekoratyvus mazgas
Daugelyje orkestravimo diagramų yra tikrintuvas. Gerai. Tada tikrintuvo prašoma patikrinti, ar atsakymas yra tikėtinas, taisyklingai suformuluotas arba atitinka instrukcijas. Mažiau gerai. Tikrintuvas, kuris skaito tik galutinį atsakymą, gali nepastebėti svarbių klaidų: silpno šaltinio, draudžiamo įvesties duomenų, nepavykusio įrankio, politikos konflikto, nesaugaus veiksmo arba be patvirtinimo pasikeitusio plano. Jis gali nušveisti priekines duris, kol virtuvėje dega ugnis.
Tikrinimas turėtų būti susietas su sutartimis ir pasekmėmis. Jei užduotis yra duomenų išgavimas, tikrinkite pagal šaltinio fragmentus. Jei užduotis yra klasifikavimas, tikrinkite leidžiamas etiketes ir įrodymus. Jei užduotis yra įrankio vykdymas, tikrinkite leidimus, argumentus, šalutinį poveikį ir atšaukimą. Jei užduotis yra sprendimų pagalba, tikrinkite politiką, šaltinio naujumą, neapibrėžtumą ir peržiūros reikalavimus. Jei užduotis yra komunikacija, tikrinkite auditoriją, teiginius, toną ir atskleidimą. Bendrasis tikrintuvas yra geriau nei nieko. Užduočiai pritaikytas tikrintuvas yra geriau nei teatras.
Dalis tikrinimo turėtų būti deterministinė. Schemos, leidžiamos reikšmės, leidimai, biudžetai, ribos, šaltinio naujumas ir privalomi laukai nereikalauja modelio poetinio sprendimo. Naudokite taisykles ten, kur taisyklės yra aiškios. Naudokite modelius ten, kur neapibrėžtumas yra realus. Naudokite žmones ten, kur pasekmės ir ginčijama reikšmė reikalauja atsakomybės. Magiškas orkestravimas dažnai prašo modelio patikrinti kitą modelį, nes tai atrodo simetriška. Simetrija architektūros diagramose yra maloni. Tačiau ji automatiškai nereiškia kontrolės.
Tikrintuvas turėtų matyti jam reikalingą pėdsaką. Vien galutinio teksto dažnai nepakanka. Jam reikia įvesties duomenų, šaltinių rinkinio, įrankio rezultatų, nepavykusių bandymų, transformacijų, politikos patikrų ir suplanuoto veiksmo. Jis taip pat turėtų turėti įgaliojimus blokuoti, prašyti daugiau įrodymų, nukreipti žmogiškajai peržiūrai arba pažymėti apribojimus. Tikrintuvas, kuris negali sustabdyti darbo eigos, yra recenzentas puošniais drabužiais.
Atmintis neturėtų apsimesti autoritetu
Agentų atmintis yra naudinga, kai joje saugomi pageidavimai, ankstesnis kontekstas ir pasikartojančių užduočių žinios. Ji pavojinga, kai apsimeta autoritetinga būsena. Prisimintas pageidavimas nėra politika. Ankstesnis atsakymas nėra įrašas. Bylos santrauka nėra pati byla. Sėkmingas ankstesnis planas nėra įrodymas, kad kita užduotis leidžia naudoti tuos pačius įrankius. Atmintis padeda tęstinumui. Jai neturėtų būti leista įnešti vakarykščio autoriteto į šiandieną.
Atmintis turi turėti tipus. Asmeninis pageidavimas, užduoties būsena, organizacijos politika, šaltinio įrodymai, išmoktas modelis, tarpinis įrankio rezultatas ir istorinis sprendimas yra skirtingi dalykai. Jiems reikia skirtingų apimčių, galiojimo terminų, leidimų ir rodymo. Jei orkestratorius tiesiog paima aktualius prisiminimus ir įdeda juos į kontekstą, aktualumas tampa vieninteliais vartais. Aktualumas nėra leidimas. Privatus užrašas gali būti aktualus. Vis tiek jis gali būti draudžiamas.
Atmintis taip pat turi turėti ištrynimą ir taisymą. Klaidinga prielaida neturėtų išlikti vien todėl, kad kadaise buvo naudinga. Laikina projekto sąlyga turėtų pasibaigti. Vartotojo pataisa turėtų galioti apibrėžtoje apimtyje. Politikos pakeitimas turėtų panaikinti seną atmintį. Modelio sukurta santrauka neturėtų tapti spartuojuoju keliu, pakeičiančiu pirminį šaltinį. Sistema turėtų parodyti, kokia atmintis įtakojo planą, ir leisti vartotojams ją užginčyti. Priešingu atveju atmintis tampa mandagiu vaiduokliu.
Taisyklė paprasta: autoritetinga būsena gyvena valdomose saugyklose. Atmintis gali padėti planuoti, bet neturėtų tyliai nuspręsti. Jei orkestratorius naudoja atmintį, užfiksuokite, kokia tai atmintis, kodėl ji buvo leista ir kaip ji paveikė planą. Tai atrodo sunku tik tada, kai atmintis atlieka reikšmingą darbą. Jei atmintis atlieka reikšmingą darbą, sunkumas ir yra esmė.
Paprastumas pranoksta magiją dažniau, nei komandos tikisi
Ne kiekvienam AI darbo srautui reikia agentų. Kai kuriems reikia deterministinės grandinės su vienu modelio žingsniu. Kai kuriems reikia paieškos, klasifikatoriaus ir žmogiškos peržiūros eilės. Kai kuriems reikia formos, kuri iškviečia modelį juodraščiui. Kai kuriems reikia paketinio vertinimo. Kai kuriems reikia planuotojo. Kai kuriems reikia daugiažingsnio įrankių naudojimo. Architektūra turi sekti užduotį, o ne dabartinį entuziazmą agentų formos diagramoms.
Nuobodus variantas dažnai laimi. Fiksuotą seką lengviau išbandyti nei atvirą ciklą. Tipizuotas įrankių vartai yra saugesni nei laisvos formos įrankių pasirinkimas. Eilė su aiškiomis būsenomis yra lengviau valdoma nei rekursyvus agentas. Taisyklėmis pagrįsta apsauga yra pigesnė nei modelio vertintojas, kai taisyklė aiški. Žmogiško eskalavimo kelias yra geresnis nei dar vienas bandymas, kai pasekmės didelės. Tai ne pozicijos prieš AI. Tai pozicijos už sistemą.
Yra kompromisas. Lankstesnis orkestravimas gali susidoroti su neaiškumais ir netikėtais maršrutais. Jis taip pat didina variaciją, įrodymų naštą, išlaidas ir derinimo sudėtingumą. Aiškesnis orkestravimas gali atrodyti nelankstus. Jis taip pat gerina atkuriamumą, atsakomybę ir atsigavimą. Tinkamas taškas priklauso nuo užduoties neaiškumo, pasekmių, apimties ir tolerancijos nesėkmėms. Magiškas mąstymas apsimeta, kad lankstus galas viską duoda nemokamai. Gamyba sąskaitą atsiunčia vėliau, su eilutėmis.
Naudingas dizaino klausimas: ko modelis niekada neturėtų pasirinkti. Šaltinio autoritetas. Vartotojo teisės. Biudžeto ribos. Negrįžtami veiksmai. Saugojimo pareigos. Teisinis pagrindas. Saugumo slenksčiai. Kai kuriuos iš jų modeliai gali pasiūlyti arba paaiškinti. Jie neturėtų būti tyliai nustatyti modelių. Modelis gali padėti naršyti darbo srautą. Jis neturėtų tapti konstitucija vien todėl, kad buvo patogu viską įdėti į kontekstą.
Kurkite orkestravimą kaip veiklos modelį
Rimtas orkestravimas prasideda nuo užduoties sutarties. Koks tikslas. Kokie duomenys leidžiami. Kokie rezultatai priimtini. Kokie įrankiai gali būti naudojami. Kokie veiksmai draudžiami. Koks biudžetas taikomas. Kokia delsena toleruojama. Kokie įrodymai turi būti saugomi. Kokie žmogiški vaidmenys egzistuoja. Kokios nesėkmės būsenos galimos. Kokie atsigavimo keliai egzistuoja. Jei komanda negali atsakyti į šiuos klausimus, jai nereikia magiškesnio grafiko. Jai reikia aiškesnės užduoties.
Tada apibrėžkite būsenų perėjimus. Suplanuota, laukiama įvesties, gaunama, įrankis laukia, įrankis nepavyko, įrodymų konfliktas, politika užblokuota, žmogiška peržiūra, patvirtinta, pritaikyta, kompensuota, atšaukta. Šios būsenos gali skambėti kasdieniškai, nes tokios ir yra. Jos leidžia sistemą valdyti. Jos leidžia žmogui žinoti, ar laukti, įsikišti, patvirtinti ar taisyti. Jos leidžia testams patvirtinti elgesį. Jos leidžia incidentams prasidėti nuo faktų, o ne nuo nuojautų.
Tada apibrėžkite ribas. Modeliai rengia planus. Vartai vykdo įrankius. Taisyklės užtikrina aiškius apribojimus. Tikrintojai patikrina sutartis. Žmonės sprendžia ginčijamas pasekmes. Žurnalai išsaugo įrodymus. Eilės tvarko delsą. Saugykla laiko patvarią būseną. Kiekviena riba turėtų būti pakankamai nuobodi, kad ją būtų galima paaiškinti. Jei modelis daro kelis iš šių dalykų, nes taip buvo lengviau, įvardykite riziką ir nuspręskite, ar užduotis yra pakankamai mažos svarbos, kad tai būtų galima toleruoti. Kartais taip ir yra. Daugelis vidinių asistentų gali būti lengvi. Problema yra apsimesti, kad lengvas dizainas yra pagrindas didelės svarbos automatizavimui.
Finally, test failure. Tool returns partial data. Source conflicts. Model produces invalid output. Memory is stale. User lacks permission. Cost limit is reached. Human review is unavailable. Network is slow. The plan changes after approval. The action partly succeeds. If the orchestrator cannot tell you what happens in those cases, the graph is decorative. It may still be a lovely graph. Put it near a plant, not near production.
The lesson
The case against magical orchestration is a case for engineering discipline. AI systems need coordination, and models can make coordination more adaptive. But adaptation without explicit state, tool contracts, retry policy, verification, memory boundaries, action gates, and recovery paths is not intelligence. It is a system that asks future operators to discover its design by reading traces after something expensive happened.
Good orchestration is less mystical and more useful. It names states. It limits tools. It records evidence. It separates proposal from action. It classifies retries. It verifies against task contracts. It treats memory as assistive, not authoritative. It gives humans reviewable states instead of opaque transcripts. It chooses simple pipelines when simple pipelines are enough. It adds agents where ambiguity justifies the operational price.
Magic hides the mechanism. Serious AI needs mechanisms that can be inspected, paused, corrected, and improved. The goal is not to remove wonder from software. The goal is to keep wonder out of the incident report.