Gadījums pret maģisko orķestrāciju
The graph that looked intelligent
The orchestration diagram was beautiful in the way dangerous diagrams often are. Rounded boxes, graceful arrows, a planner, a researcher, a verifier, a tool executor, a memory layer, a human approval node, and a final response. The demo moved with theatrical confidence. A user asked for an analysis, the planner decomposed the task, tools were called, intermediate notes appeared, and the final answer arrived with the calm of a system that had never met production traffic.
Then the first real exceptions arrived. A tool returned partial data. The planner retried with a different query and lost the earlier reason. The verifier checked style but not the source conflict. Memory brought back an old assumption because it looked relevant. A human approval step approved the final text without seeing the failed branch. The trace existed, but reading it felt like inspecting a suitcase packed by a committee during a fire drill. The graph had not failed dramatically. It had hidden the shape of responsibility.
This is the case against magical orchestration. Not against orchestration itself. Complex AI systems need coordination. They need to call tools, route tasks, manage context, ask humans, recover from failure, split work, and combine evidence. The argument is against the style of orchestration that treats a clever graph or agent loop as a substitute for explicit state, contracts, ownership, limits, and records. Magic is impressive in a demo because it hides the mechanism. Engineering is useful in production because it exposes the mechanism enough to repair it.
AI orchestration is where probability meets workflow. That junction is unforgiving. A model may choose a plan. A tool may return a result. A policy may allow an action. A retry may change context. A human may approve. A downstream system may act. If those transitions are not named, bounded, and recorded, the organisation gets an intelligent-looking system whose behaviour is difficult to reproduce and harder to govern. It is not autonomous. It is just evasive with better branding.
Orchestration is not intelligence dust
The word orchestration can make ordinary engineering sound newly enchanted. A sequence becomes a chain. A conditional becomes a router. A function call becomes a tool. A while loop becomes an agent. A queue becomes memory if the lighting is right. Some of this vocabulary is useful because AI systems do introduce new coordination problems. Some of it is packaging. Packaging is not evil. It becomes expensive when teams forget what is inside the box.
At its core, orchestration is the management of state, decisions, resources, and transitions. What is the task. What is the current state. Which inputs are allowed. Which tool may be called. Which output shape is expected. What happens on failure. Which retries are permitted. Which actions require approval. What evidence must be kept. Which step can be replayed. Which step is irreversible. These questions existed before generative AI. Models make them more important, not obsolete.
Maģiska orķestrēšana izvairās no šiem jautājumiem, ļaujot modelim vai sistēmai izdarīt pārāk daudz secinājumu izpildes laikā. Plānotājs nosaka sadalījumu. Modelis izvēlas rīkus. Rīka izvade kļūst par kontekstu. Nākamais solis to interpretē. Atmiņa pievieno vēsturi. Pārbaudītājs pamāj. Parādās galīgā atbilde. Tas var darboties zema riska izpētes uzdevumos. Tas ir trausls, ja darbplūsma skar ierakstus, naudu, drošību, atbilstību, klientu saistības, infrastruktūru vai citas sistēmas, kurām nepatīk improvizācijas teātris.
Disciplinēta orķestrēšanas dizains nenoņem elastību. Tas ievieto elastību sliedēs. Modelis var ierosināt plānu, bet plānotāja izvadei ir shēma. Sistēma var izsaukt rīkus, bet rīkiem ir darbības jomas un budžeti. Darbplūsma var mēģināt vēlreiz, bet atkārtojuma iemesli tiek klasificēti. Atmiņa var palīdzēt, bet autoritatīvais stāvoklis dzīvo citur. Cilvēks var apstiprināt, bet apstiprinājums redz attiecīgos atzarus un pierādījumus. Elastība izdzīvo. Noslēpumainība nedrīkst vadīt.
Slēptā stāvokļa problēma
Visbiežākā orķestrēšanas kļūme ir slēptais stāvoklis. Stāvoklis parādās uzvednēs, darba lapās, atmiņas krātuvēs, rīku izvadēs, starpposma ziņojumos, modeļu kopsavilkumos, kešotajos rezultātos, cilvēku komentāros un sistēmas iekšējās daļās. Katrs slānis satur daļēju patiesību. Neviens nav pastāvīgais ieraksts. Kad kaut kas noiet greizi, komanda jautā, ko sistēma uzskatīja par patiesu septītajā solī. Atbilde ir kolāža.
Slēptais stāvoklis padara atkļūdošanu nožēlojamu. Modelis izvēlējās citu rīku, jo agrākā kopsavilkumā tika lietots spēcīgāks darbības vārds. Atkārtojums izlaida ierobežojumu. Atmiņas vienums no iepriekšējā uzdevuma ietekmēja plānu. Rīka rezultāts tika saīsināts. Pārbaudītājs redzēja galīgo atbildi, bet ne noraidīto atzaru. Sistēma uzvedās ticami, un ticama uzvedība ir viskaitinošākais izmeklēšanas veids, jo tā atsakās izskatīties salauzta, līdz uzzini trūkstošo faktu.
Pastāvīgajam uzdevuma stāvoklim jābūt skaidram. Tam jāietver uzdevuma nolūks, atļautā darbības joma, avotu kopa, plāna versija, rīku izsaukumi, rīku izvades, atkārtojuma iemesli, cilvēku lēmumi, politikas pārbaudes, izmaksas, taimauti un veiktās darbības. Ne katrai zema riska mijiedarbībai ir nepieciešams smags reģistrs, bet jebkurai orķestrēšanai, kas var ietekmēt reālu darbu, ir nepieciešams stāvokļa modelis, kas pārsniedz transkriptu. Transkripts ir noderīgs stāstījums. Tas nav operētājsistēma.
Skaidrs stāvoklis arī uzlabo produkta dizainu. Lietotāji var redzēt, vai sistēma plāno, gaida rīku, ir bloķēta politikas dēļ, lūdz pārskatīšanu, mēģina vēlreiz pēc pārejošas kļūdas vai ir gatava piemērot izmaiņas. Operator var apturēt vai atsākt. Izstrādātāji var pārbaudīt pārejas. Revidenti var atskaņot. Sistēma kļūst mazāk maģiska un noderīgāka, kas ir kompromiss, kuram dažas demonstrācijas pretojas un kuru lielākā daļa operāciju komandu dziļi novērtē.
Rīku izsaukumi nav nevainīgi
Rīku izmantošana dod AI sistēmām rokas. Tas ir noderīgi un bīstami. Kalendāra lasīšana, dokumentu meklēšana, datubāzes vaicāšana, e-pasta sūtīšana, biļetes atvēršana, ieraksta mainīšana, koda izvietošana vai naudas pārskaitīšana nav līdzvērtīgas darbības. Maģisks orķestrētājs var tās uzskatīt par rīkiem sarakstā. Nopietna sistēma tās uzskata par iespējām ar darbības jomām, blakusefektiem, atļaujām, budžetiem un pierādījumu prasībām.
Katram rīka izsaukumam ir nepieciešams līgums. Ievaddatiem jābūt tipizētiem un validētiem. Izvaddati ir jāpārbauda. Kļūdas ir jāklasificē. Blakusefekti ir jādeklarē. Idempotence ir jāsaprot. Taimautiem ir jābūt ierobežotiem. Atkārtoti mēģinājumi ir jāveic droši. Atļaujas ir jāatvasina no lietotāja, uzdevuma un politikas, nevis no modeļa entuziasma. Sistēmai būtu jāzina, vai rīks tikai nolasa datus, sagatavo melnrakstu, maina ierakstu, paziņo personai vai izraisa ārēju saistību. Āmurs un bankas pārskaitījums nedrīkst dalīties ar vienu un to pašu noskaņu.
Rīka izvaddati arī ir jāuztver kā ievaddati. Tie var būt daļēji, novecojuši, neautorizēti, neskaidri vai naidīgi. Meklēšanas rezultāts nav pierādījums, kamēr sistēma nezina avotu, aktualitāti un atļauju. Datu bāzes rezultātā var trūkt rindu piekļuves kontroles dēļ. API kļūda var atgriezt ziņojumu, kam nevajadzētu kļūt par instrukciju. Rīks var pieklājīgi neizdoties un tomēr neizdoties. Orķestrētājs nedrīkst katru rīka atbildi ievadīt atpakaļ modelī tā, it kā teksta atgriešana būtu tas pats, kas patiesības stāstīšana.
Blakusefekti prasa īpašu piesardzību. Modeļa ģenerētu plānu var izmest. Nosūtītu e-pastu nevar atsaukt ar tādu pašu pārliecību. Mainīts ieraksts var iedarbināt lejupstraumes sistēmas. Izvietošana var ietekmēt lietotājus. Atmaksa var pārvietot naudu. Orķestrācijai būtu jānošķir priekšlikums no darbības un jāpieprasa skaidri vārti neatgriezeniskiem vai nozīmīgiem soļiem. Ja sistēma var paveikt reālas lietas, tai ir vajadzīgs vairāk nekā aģenta cilpa. Tai ir vajadzīgas bremzes, atslēgas un kāds, kurš zina, kur atrodas rezerves.
Atkārtoti mēģinājumi ir maskēta politika
Atkārtoti mēģinājumi izskatās pēc inženiertehniskās līmes, līdz AI orķestrētājs sāk pieņemt lēmumus. Ja rīks neizdodas, mēģini vēlreiz. Ja modeļa izvaddati ir nepareizi veidoti, jautā vēlreiz. Ja verificētājs noraida atbildi, pārskati to. Ja plāns apstājas, plāno no jauna. Tas var būt saprātīgi. Tas var arī mainīt iznākumu, slēpt nenoteiktību, palielināt izmaksas vai dzēst pierādījumus par to, kāpēc pirmais ceļš neizdevās. Atkārtots mēģinājums nav tikai otrs mēģinājums. Tas ir lēmums par to, kāda veida kļūmi sistēmai ir atļauts nogludināt.
Atkārtotu mēģinājumu politikai jābūt skaidrai. Īslaicīgas infrastruktūras kļūdas var mēģināt novērst citādi nekā politikas konfliktus. Nepareizi veidotu JSON var labot citādi nekā trūkstošus pierādījumus. Zema pārliecība var izraisīt pārskatīšanu, nevis vēl vienu paraugu. Avotu konfliktu nevajadzētu risināt, lūdzot modelim izklausīties izlēmīgākam. Rīka taimauts nedrīkst kļūt par atļauju izmantot vājāku avotu, neatzīmējot izmaiņas. Sistēmai ir jāzina, kāpēc tā mēģina vēlreiz, kas tiek saglabāts, kas mainās un kad apstāties.
Bez šīs disciplīnas orķestrācija rada pieklājīgas cilpas. Sistēma turpina mēģināt, jo mēģināšana kodā ir lēta. Tā var sadedzināt budžetu, piepildīt žurnālus, mulsināt lietotājus un galu galā sniegt atbildi, kas izskatās labāka galvenokārt tāpēc, ka agrākie nestabilitātes pierādījumi ir paslēpti. Ražošanā cilpa, kas slēpj savus neveiksmīgos mēģinājumus, nav neatlaidība. Tā ir amnēzija ar progresa joslu.
Atkārtotiem mēģinājumiem būtu jārada ieraksti. Mēģinājumu skaits, iemesls, mainītie ievaddati, mainītais plāns, saglabātie pierādījumi, izmaksas, latentums un galīgais iznākums. Tas operatoriem dod iespēju redzēt, vai darbplūsma ir veselīga vai tikai noturīga. Tas arī palīdz izlemt, vai uzlabot ievaddatu kvalitāti, rīka uzticamību, modeļa formatējumu, politikas skaidrību vai lietotāju cerības. Atkārtots mēģinājums bez klasifikācijas ir paraustīti pleci izpildāmā formā.
Verifikācija nav dekoratīvs mezgls
Daudzās orķestrācijas diagramās ir iekļauts verificētājs. Labi. Tad verificētājam tiek lūgts pārbaudīt, vai atbilde ir ticama, labi veidota vai atbilst norādēm. Mazāk labi. Verificētājs, kas lasa tikai galīgo atbildi, var palaist garām svarīgās kļūdas: vāju avotu, aizliegtu ievadi, neizdevušos rīku, politikas konfliktu, nedrošu darbību vai plānu, kas mainīts bez apstiprinājuma. Tas var nopulēt priekšējās durvis, kamēr virtuve deg.
Verifikācijai jābūt saistītai ar līgumiem un sekām. Ja uzdevums ir ekstrakcija, verificējiet pret avota fragmentiem. Ja uzdevums ir klasifikācija, verificējiet atļautās etiķetes un pierādījumus. Ja uzdevums ir rīka izpilde, verificējiet atļaujas, argumentus, blakusefektus un atgriešanu. Ja uzdevums ir lēmumu atbalsts, verificējiet politiku, avota aktualitāti, nenoteiktību un pārskatīšanas prasības. Ja uzdevums ir komunikācija, verificējiet auditoriju, apgalvojumus, toni un atklātību. Vispārīgs verificētājs ir labāks nekā nekas. Uzdevumam specifisks verificētājs ir labāks nekā teātris.
Daļai verifikācijas jābūt deterministiskai. Shēmām, atļautajām vērtībām, atļaujām, budžetiem, sliekšņiem, avota aktualitātei un obligātajiem laukiem nav nepieciešams modeļa poētisks spriedums. Izmantojiet noteikumus tur, kur noteikumi ir skaidri. Izmantojiet modeļus tur, kur neskaidrība ir reāla. Izmantojiet cilvēkus tur, kur sekas un apstrīdēta nozīme prasa atbildību. Maģiskā orķestrācija bieži lūdz vienam modelim verificēt citu modeli, jo tas šķiet simetriski. Simetrija ir patīkama arhitektūras diagrammās. Tā automātiski nav kontrole.
Verificētājam jāredz tam nepieciešamā izsekojamība. Tikai galīgais teksts reti kad ir pietiekams. Tam ir nepieciešami ievaddati, avotu kopa, rīku izvades, neizdevušies mēģinājumi, transformācijas, politikas pārbaudes un plānotā darbība. Tam arī jābūt pilnvarām bloķēt, pieprasīt vairāk pierādījumu, novirzīt cilvēku pārskatīšanai vai norādīt ierobežojumus. Verificētājs, kas nevar apturēt darbplūsmu, ir recenzents greznā tērpā.
Atmiņa nedrīkst atdarināt autoritāti
Aģenta atmiņa ir noderīga, kad tā glabā preferences, iepriekšējo kontekstu un atkārtotu uzdevumu zināšanas. Tā ir bīstama, kad tā atdarina autoritatīvu stāvokli. Atcerēta preference nav politika. Iepriekšēja atbilde nav ieraksts. Lietas kopsavilkums nav lieta. Veiksmīgs iepriekšējais plāns nav pierādījums, ka nākamais uzdevums atļauj tos pašus rīkus. Atmiņa palīdz nepārtrauktībai. Tai nedrīkst ļaut ienest vakardienas autoritāti šodienā.
Atmiņai ir vajadzīgi tipi. Personiskā preference, uzdevuma stāvoklis, organizācijas politika, avota pierādījumi, apgūts modelis, kešots rīka rezultāts un vēsturisks lēmums ir dažādas lietas. Tām ir vajadzīgas dažādas darbības jomas, derīguma termiņi, atļaujas un attēlojums. Ja orķestrētājs vienkārši izgūst atbilstošās atmiņas un pievieno tās kontekstam, atbilstība kļūst par vienīgo vārtu. Atbilstība nav atļauja. Privāta piezīme var būt atbilstoša. Tā joprojām var būt aizliegta.
Atmiņai ir vajadzīga arī dzēšana un labošana. Nepareizs pieņēmums nedrīkst palikt, jo tas reiz bija noderīgs. Pagaidu projekta nosacījumam jābeidzas. Lietotāja labojumam jādarbojas noteiktā darbības jomā. Politikas maiņai jāanulē vecā atmiņa. Modeļa ģenerēts kopsavilkums nedrīkst kļūt par saīsni, kas aizstāj primāro avotu. Sistēmai jāparāda, kāda atmiņa ietekmēja plānu, un jāļauj lietotājiem to apstrīdēt. Pretējā gadījumā atmiņa kļūst par pieklājīgu spoku.
Noteikums ir vienkāršs: autoritatīvais stāvoklis dzīvo pārvaldītās krātuvēs. Atmiņa var palīdzēt plānošanā, bet tai nevajadzētu klusībā izlemt. Ja orķestrētājs izmanto atmiņu, ierakstiet, kura atmiņa, kāpēc tā bija atļauta un kā tā ietekmēja plānu. Tas šķiet smagnēji tikai tad, ja atmiņa veic nozīmīgu darbu. Ja atmiņa veic nozīmīgu darbu, smagnējība ir tieši tas, kas vajadzīgs.
Vienkāršība pārspēj maģiju biežāk, nekā komandas sagaida
Ne katram AI darbplūsmas veidam ir vajadzīgi aģenti. Dažiem ir nepieciešams deterministisks cauruļvads ar vienu modeļa soli. Dažiem ir nepieciešama izguve, klasifikators un cilvēka pārskatīšanas rinda. Dažiem ir nepieciešama forma, kas izsauc modeli melnraksta izveidei. Dažiem ir nepieciešama partijas novērtēšana. Dažiem ir nepieciešams plānotājs. Dažiem ir nepieciešama daudzpakāpju rīku izmantošana. Arhitektūrai jāseko uzdevumam, nevis pašreizējam entuziasmam par aģentu formas diagrammām.
Garlaicīgā alternatīva bieži uzvar. Fiksēta secība ir vieglāk pārbaudāma nekā atvērta cilpa. Tipizēts rīku vārtu ceļš ir drošāks nekā brīvas formas rīku izvēle. Rinda ar skaidriem stāvokļiem ir vieglāk pārvaldāma nekā rekursīvs aģents. Uz noteikumiem balstīts sargs ir lētāks nekā modeļa vērtētājs, ja noteikums ir skaidrs. Cilvēka eskalācijas ceļš ir labāks par vēl vienu mēģinājumu, ja sekas ir lielas. Šīs nav pret-AI nostājas. Tās ir par labu sistēmai vērstas nostājas.
Pastāv kompromiss. Elastīgāka orķestrēšana var tikt galā ar neskaidrību un neparedzētiem ceļiem. Tā arī palielina mainīgumu, pierādījumu slogu, izmaksas un atkļūdošanas sarežģītību. Skaidrāka orķestrēšana var šķist stingra. Tā arī uzlabo atkārtojamību, atbildību un atkopšanos. Pareizais punkts ir atkarīgs no uzdevuma neskaidrības, sekām, apjoma un pielaides kļūmēm. Maģiskā domāšana izliekas, ka elastīgais gals visu dod bez maksas. Ražošana rēķinu atsūta vēlāk, ar rindas pozīcijām.
Noderīgs dizaina jautājums ir: ko modelim nekad nevajadzētu izvēlēties. Avota autoritāte. Lietotāja atļaujas. Budžeta ierobežojumi. Neatgriezeniskas darbības. Saglabāšanas pienākumi. Juridiskais pamats. Drošības sliekšņi. Dažus no tiem modeļi var ierosināt vai izskaidrot. Tos nevajadzētu klusi noteikt modeļiem. Modelis var palīdzēt orientēties darbplūsmā. Tam nevajadzētu kļūt par konstitūciju tikai tāpēc, ka bija ērti visu ievietot kontekstā.
Veidojiet orķestrēšanu kā darbības modeli
Nopietna orķestrēšana sākas ar uzdevuma līgumu. Kāds ir mērķis. Kādi dati ir atļauti. Kādi rezultāti ir pieņemami. Kādus rīkus drīkst izmantot. Kuras darbības ir aizliegtas. Kāds budžets attiecas. Kāda latentums ir pieļaujams. Kādi pierādījumi ir jāsaglabā. Kādas cilvēka lomas pastāv. Kādi kļūmes stāvokļi ir iespējami. Kādi atkopšanās ceļi pastāv. Ja komanda nevar atbildēt uz šiem jautājumiem, tai nav vajadzīgs maģiskāks grafiks. Tai ir nepieciešams skaidrāks uzdevums.
Pēc tam definējiet stāvokļu pārejas. Plānots, gaida ievadi, izgūst, rīks gaida, rīks neizdevās, pierādījumu konflikts, politikas bloķēts, cilvēka pārskatīšana, apstiprināts, piemērots, kompensēts, atcelts. Šie stāvokļi var šķist ikdienišķi, jo tādi tie ir. Tie ļauj sistēmu darbināt. Tie ļauj cilvēkam zināt, vai gaidīt, iejaukties, apstiprināt vai labot. Tie ļauj testiem apstiprināt uzvedību. Tie ļauj incidentiem sākties no faktiem, nevis sajūtām.
Pēc tam definējiet robežas. Modeļi izstrādā plānus. Vārtu ceļi izpilda rīkus. Noteikumi nodrošina skaidrus ierobežojumus. Pārbaudītāji pārbauda līgumus. Cilvēki izlemj par apstrīdētām sekām. Žurnāli saglabā pierādījumus. Rindas apstrādā kavēšanos. Krātuve glabā noturīgu stāvokli. Katrai robežai jābūt pietiekami garlaicīgai, lai to varētu izskaidrot. Ja modelis veic vairākas no šīm funkcijām tāpēc, ka tas bija vieglāk, nosauciet risku un izlemiet, vai uzdevums ir pietiekami zema riska, lai to pieļautu. Dažreiz tas tā ir. Daudzi iekšējie palīgi var būt viegli. Problēma ir izlikšanās, ka viegls dizains ir pamats augstu seku automatizācijai.
Beidzot testa neveiksme. Rīks atgriež daļējus datus. Avoti konfliktē. Modelis ģenerē nederīgu izvadi. Atmiņa ir novecojusi. Lietotājam nav atļaujas. Ir sasniegts izmaksu limits. Cilvēka pārskatīšana nav pieejama. Tīkls ir lēns. Plāns mainās pēc apstiprināšanas. Darbība daļēji izdodas. Ja orķestrētājs nevar pateikt, kas notiek šādos gadījumos, grafiks ir tikai dekoratīvs. Tas joprojām var būt jauks grafiks. Novietojiet to pie auga, nevis pie ražošanas.
Mācība
Iebildums pret maģisku orķestrēšanu ir arguments par labu inženierijas disciplīnai. AI sistēmām ir nepieciešama koordinācija, un modeļi var padarīt koordināciju adaptīvāku. Taču adaptācija bez skaidra stāvokļa, rīku līgumiem, atkārtotu mēģinājumu politikas, verifikācijas, atmiņas robežām, darbību vārtiem un atkopšanās ceļiem nav inteliģence. Tā ir sistēma, kas liek nākotnes operatoriem atklāt tās dizainu, lasot žurnālus pēc tam, kad ir noticis kaut kas dārgs.
Laba orķestrēšana ir mazāk mistiska un noderīgāka. Tā nosauc stāvokļus. Tā ierobežo rīkus. Tā reģistrē pierādījumus. Tā nošķir priekšlikumu no darbības. Tā klasificē atkārtotus mēģinājumus. Tā verificē atbilstību uzdevumu līgumiem. Tā izturas pret atmiņu kā palīglīdzekli, nevis autoritāti. Tā sniedz cilvēkiem pārskatāmus stāvokļus, nevis necaurredzamus atšifrējumus. Tā izvēlas vienkāršas cauruļvadus, kad vienkārši cauruļvadi ir pietiekami. Tā pievieno aģentus tur, kur neskaidrība attaisno operatīvās izmaksas.
Maģija slēpj mehānismu. Nopietnai AI ir nepieciešami mehānismi, kurus var pārbaudīt, apturēt, labot un uzlabot. Mērķis nav noņemt brīnumu no programmatūras. Mērķis ir nepieļaut brīnumu incidentu ziņojumā.