Sagen mod magisk orkestrering
Grafen, der så intelligent ud
Orkestreringsdiagrammet var smukt på den måde, som farlige diagrammer ofte er. Afrundede bokse, elegante pile, en planlægger, en forsker, en verificerer, en værktøjsudfører, et hukommelseslag, et knudepunkt for menneskelig godkendelse og et endeligt svar. Demoet bevægede sig med teatralsk selvsikkerhed. En bruger bad om en analyse, planlæggeren nedbrød opgaven, værktøjer blev kaldt, mellemliggende noter dukkede op, og det endelige svar kom med roen fra et system, der aldrig havde mødt produktionstrafik.
Så kom de første rigtige undtagelser. Et værktøj returnerede delvise data. Planlæggeren prøvede igen med en anden forespørgsel og mistede den tidligere begrundelse. Verificereren tjekkede stil, men ikke kildekonflikten. Hukommelsen bragte en gammel antagelse tilbage, fordi den så relevant ud. Et trin med menneskelig godkendelse godkendte den endelige tekst uden at se den fejlede gren. Sporet eksisterede, men at læse det føltes som at inspicere en kuffert pakket af en komité under en brandøvelse. Grafen var ikke fejlet dramatisk. Den havde skjult formen på ansvaret.
Dette er argumentet mod magisk orkestrering. Ikke mod orkestrering i sig selv. Komplekse AI-systemer har brug for koordinering. De skal kunne kalde værktøjer, dirigere opgaver, styre kontekst, spørge mennesker, komme sig efter fejl, dele arbejde op og kombinere beviser. Argumentet er mod den stil af orkestrering, der behandler en smart graf eller agent-løkke som en erstatning for eksplicit tilstand, kontrakter, ejerskab, grænser og optegnelser. Magi er imponerende i en demo, fordi den skjuler mekanismen. Ingeniørarbejde er nyttigt i produktion, fordi det blotlægger mekanismen nok til at reparere den.
AI-orkestrering er, hvor sandsynlighed møder arbejdsgang. Det kryds er ubarmhjertigt. En model kan vælge en plan. Et værktøj kan returnere et resultat. En politik kan tillade en handling. Et forsøg igen kan ændre konteksten. Et menneske kan godkende. Et downstream-system kan handle. Hvis disse overgange ikke er navngivet, afgrænset og registreret, får organisationen et intelligent-udseende system, hvis adfærd er svær at reproducere og endnu sværere at styre. Det er ikke autonomt. Det er bare undvigende med bedre branding.
Orkestrering er ikke intelligens-støv
Ordet orkestrering kan få almindeligt ingeniørarbejde til at lyde nyfortryllet. En sekvens bliver en kæde. En betingelse bliver en router. Et funktionskald bliver et værktøj. En while-løkke bliver en agent. En kø bliver hukommelse, hvis belysningen er rigtig. Noget af dette vokabular er nyttigt, fordi AI-systemer faktisk introducerer nye koordineringsproblemer. Noget af det er emballage. Emballage er ikke ondt. Det bliver dyrt, når teams glemmer, hvad der er inde i boksen.
I sin kerne er orkestrering styringen af tilstand, beslutninger, ressourcer og overgange. Hvad er opgaven. Hvad er den aktuelle tilstand. Hvilke input er tilladt. Hvilket værktøj må kaldes. Hvilken outputform forventes. Hvad sker der ved fejl. Hvilke forsøg igen er tilladt. Hvilke handlinger kræver godkendelse. Hvilke beviser skal bevares. Hvilket trin kan afspilles. Hvilket trin er irreversibelt. Disse spørgsmål eksisterede før generativ AI. Modeller gør dem vigtigere, ikke forældede.
Magisk orkestrering undgår disse spørgsmål ved at lade modellen eller rammen udlede for meget ved kørsel. Planlæggeren beslutter nedbrydningen. Modellen vælger værktøjer. Værktøjets output bliver kontekst. Næste trin fortolker det. Hukommelse tilføjer historik. En validator nikker. Det endelige svar dukker op. Dette kan fungere til eksplorative opgaver med lav risiko. Det er skrøbeligt, når arbejdsgangen berører registre, penge, sikkerhed, compliance, kundeforpligtelser, infrastruktur eller andre systemer, der ikke sætter pris på improvisationsteater.
En disciplineret orkestreringsdesign fjerner ikke fleksibilitet. Den sætter fleksibilitet inden for rammer. Modellen kan foreslå en plan, men planlæggerens output har et skema. Systemet kan kalde værktøjer, men værktøjer har scopes og budgetter. Arbejdsgangen kan prøve igen, men årsagerne til genforsøg er klassificeret. Hukommelse kan hjælpe, men autoritativ tilstand lever andre steder. Et menneske kan godkende, men godkendelse ser de relevante grene og beviser. Fleksibilitet overlever. Mysterium får ikke lov til at køre.
Problemet med skjult tilstand
Den mest almindelige orkestreringsfejl er skjult tilstand. Tilstand optræder i prompter, kladder, hukommelseslagre, værktøjsoutput, mellemliggende beskeder, modelsammenfatninger, cachelagrede resultater, menneskelige kommentarer og framework-interne detaljer. Hvert lag indeholder delvis sandhed. Intet er den varige registrering. Når noget går galt, spørger teamet, hvad systemet troede ved trin syv. Svaret er en collage.
Skjult tilstand gør fejlfinding elendig. En model valgte et andet værktøj, fordi en tidligere sammenfatning brugte et stærkere verbum. Et genforsøg udelod en begrænsning. En hukommelsespost fra en tidligere opgave påvirkede planen. Et værktøjsresultat blev afkortet. En validator så det endelige svar, men ikke den afviste gren. Systemet opførte sig plausibelt, og plausibel adfærd er den mest irriterende slags at undersøge, fordi den nægter at se ødelagt ud, indtil du kender den manglende kendsgerning.
Varig opgavetilstand bør være eksplicit. Den bør omfatte opgavens hensigt, tilladt scope, kildesæt, planversion, værktøjskald, værktøjsoutput, genforsøgsårsager, menneskelige beslutninger, politikchecks, omkostninger, timeouts og anvendte handlinger. Ikke enhver interaktion med lav risiko har brug for en tung logbog, men enhver orkestrering, der kan påvirke rigtigt arbejde, har brug for en tilstandsmodel ud over transskriptionen. Transskriptionen er nyttig fortælling. Den er ikke operativsystemet.
Eksplicit tilstand forbedrer også produktdesign. Brugere kan se, om systemet planlægger, venter på et værktøj, er blokeret af politik, beder om gennemgang, prøver igen efter en midlertidig fejl eller er klar til at anvende ændringer. Operatører kan pause eller genoptage. Udviklere kan teste overgange. Revisorer kan afspille. Systemet bliver mindre magisk og mere nyttigt, hvilket er en handel, nogle demoer modstår, og de fleste operations-teams sætter stor pris på.
Værktøjskald er ikke uskyldige
Værktøjsbrug giver AI-systemer hænder. Det er nyttigt og farligt. At læse en kalender, søge i dokumenter, forespørge en database, sende en e-mail, åbne en sag, ændre en registrering, implementere kode eller overføre penge er ikke ækvivalente handlinger. En magisk orkestrator kan behandle dem som værktøjer i en liste. Et seriøst system behandler dem som kapaciteter med scopes, sideeffekter, tilladelser, budgetter og krav til beviser.
Ethvert værktøjskald har brug for en kontrakt. Inputs skal være typede og validerede. Outputs skal kontrolleres. Fejl skal klassificeres. Sideeffekter skal erklæres. Idempotens skal forstås. Timeouts skal være afgrænsede. Gentagne forsøg skal være sikre. Tilladelser skal udledes fra brugeren, opgaven og politikken, ikke fra modellens entusiasme. Systemet skal vide, om et værktøj kun læser, skriver et udkast, ændrer en registrering, underretter en person eller udløser en ekstern forpligtelse. En hammer og en bankoverførsel skal ikke dele samme vibe.
Værktøjets output skal også behandles som input. Det kan være delvist, forældet, uautoriseret, tvetydigt eller modstridende. Et søgeresultat er ikke bevis, før systemet kender kilde, friskhed og tilladelse. Et databaseresultat kan udelade rækker på grund af adgangskontrol. En API-fejl kan returnere en besked, der ikke skal blive til en instruktion. Et værktøj kan fejle høfligt og stadig fejle. Orkestratoren må ikke fodre hvert værktøjssvar tilbage i modellen, som om det at returnere tekst var det samme som at fortælle sandheden.
Sideeffekter fortjener særlig forsigtighed. En modelgenereret plan kan smides væk. En sendt e-mail kan ikke afsendes igen med samme sikkerhed. En ændret registrering kan udløse downstream-systemer. En implementering kan påvirke brugere. En refusion kan flytte penge. Orkestrering bør adskille forslag fra handling og kræve eksplicitte porte for irreversible eller konsekvensrige trin. Hvis et system kan gøre virkelige ting, har det brug for mere end en agent-løkke. Det har brug for bremser, nøgler og nogen, der ved, hvor reserven er.
Gentagne forsøg er politik i forklædning
Gentagne forsøg ligner ingeniørlim, indtil en AI-orkestrator begynder at træffe valg. Hvis et værktøj fejler, så prøv igen. Hvis modeloutputtet er fejlformet, så spørg igen. Hvis verificatoren afviser svaret, så revider. Hvis planen går i stå, så planlæg igen. Dette kan være fornuftigt. Det kan også ændre resultatet, skjule usikkerhed, øge omkostningerne eller slette beviset for, hvorfor den første sti fejlede. Et gentaget forsøg er ikke blot et andet forsøg. Det er en beslutning om, hvilken slags fejl systemet har lov til at glatte over.
Politikken for gentagne forsøg skal være eksplicit. Midlertidige infrastrukturfejl kan forsøges igen anderledes end politikkonflikter. Fejlformet JSON kan repareres anderledes end manglende bevis. Lav tillid kan udløse gennemgang snarere end endnu en prøve. Kildekonflikt skal ikke løses ved at bede modellen om at lyde mere beslutsom. Værktøjets timeout skal ikke blive til tilladelse til at bruge en svagere kilde uden at markere ændringen. Systemet skal vide, hvorfor det forsøger igen, hvad der bevares, hvad der ændres, og hvornår det skal stoppe.
Uden den disciplin skaber orkestrering høflige løkker. Systemet bliver ved med at forsøge, fordi det at forsøge er billigt i kode. Det kan brænde budgettet af, fylde logfiler, forvirre brugere og til sidst producere et svar, der hovedsageligt ser bedre ud, fordi det tidligere bevis på ustabilitet er skjult. I produktion er en løkke, der skjuler sine egne fejlede forsøg, ikke udholdenhed. Det er hukommelsestab med en statuslinje.
Gentagne forsøg skal producere registreringer. Antal forsøg, årsag, ændrede inputs, ændret plan, bevaret bevis, omkostning, latenstid og endelig disposition. Dette giver operatører en måde at se, om en arbejdsgang er sund eller blot vedholdende. Det hjælper også med at beslutte, om man skal rette inputkvalitet, værktøjspålidelighed, modelformatering, politikklarhed eller brugerforventninger. Et gentaget forsøg uden klassificering er et skuldertræk i eksekverbar form.
Verifikation er ikke et dekorativt knudepunkt
Mange orkestreringsdiagrammer inkluderer en verifikator. Det er godt. Men så bliver verifikatoren bedt om at kontrollere, om svaret er plausibelt, velformet eller i overensstemmelse med instruktionerne. Det er mindre godt. En verifikator, der kun læser det endelige svar, kan overse de fejl, der betyder noget: en svag kilde, en forbudt input, et mislykket værktøj, en politikkonflikt, en usikker handling eller en plan, der blev ændret uden godkendelse. Den kan polere hoveddøren, mens køkkenet brænder.
Verifikation bør være knyttet til kontrakter og konsekvenser. Hvis opgaven er ekstraktion, så verificér mod kildesegmenter. Hvis opgaven er klassifikation, så verificér tilladte etiketter og dokumentation. Hvis opgaven er værktøjsudførelse, så verificér tilladelser, argumenter, sideeffekter og rollback. Hvis opgaven er beslutningsstøtte, så verificér politik, kildens aktualitet, usikkerhed og krav om gennemgang. Hvis opgaven er kommunikation, så verificér målgruppe, påstande, tone og oplysningspligt. En generisk verifikator er bedre end ingenting. En opgavespecifik verifikator er bedre end teater.
Noget verifikation bør være deterministisk. Skemaer, tilladte værdier, tilladelser, budgetter, tærskler, kildens aktualitet og obligatoriske felter har ikke brug for en models poetiske dømmekraft. Brug regler, hvor reglerne er klare. Brug modeller, hvor tvetydigheden er reel. Brug mennesker, hvor konsekvenser og omstridt betydning kræver ansvar. Magisk orkestrering beder ofte en model om at verificere en anden model, fordi det føles symmetrisk. Symmetri er behageligt i arkitekturdiagrammer. Det er ikke automatisk kontrol.
Verifikatoren skal se det spor, den har brug for. Sluttekst alene er sjældent nok. Den har brug for input, kildesæt, værktøjsoutput, mislykkede forsøg, transformationer, politikchecks og planlagte handlinger. Den skal også have autoritet til at blokere, anmode om mere dokumentation, sende videre til menneskelig gennemgang eller markere begrænsninger. En verifikator, der ikke kan stoppe arbejdsgangen, er en anmelder i fint tøj.
Hukommelse skal ikke udgive sig for autoritet
Agenthukommelse er nyttig, når den bærer præferencer, tidligere kontekst og viden om tilbagevendende opgaver. Den er farlig, når den udgiver sig for autoritativ tilstand. En husket præference er ikke politik. Et tidligere svar er ikke en registrering. Et resumé af en sag er ikke sagen. En tidligere succesfuld plan er ikke bevis på, at den næste opgave tillader de samme værktøjer. Hukommelse hjælper kontinuitet. Den skal ikke have lov til at smugle autoritet fra i går ind i i dag.
Hukommelse har brug for typer. Personlig præference, opgavetilstand, organisatorisk politik, kildedokumentation, lært mønster, cachelagret værktøjsresultat og historisk beslutning er forskellige ting. De har brug for forskellige omfang, udløb, tilladelser og visning. Hvis en orkestrator blot henter relevante minder og tilføjer dem til konteksten, bliver relevans den eneste port. Relevans er ikke tilladelse. En privat note kan være relevant. Den kan stadig være forbudt.
Hukommelse har også brug for sletning og korrektion. En forkert antagelse skal ikke blive ved med at eksistere, fordi den var nyttig én gang. En midlertidig projektbetingelse skal udløbe. En brugerkorrektion skal gælde i et defineret omfang. En politikændring skal ugyldiggøre gammel hukommelse. Et modelgenereret resumé skal ikke blive genvejen, der erstatter en primær kilde. Systemet skal vise, hvilken hukommelse der påvirkede en plan, og lade brugere udfordre den. Ellers bliver hukommelse en høflig genfærd.
Reglen er enkel: autoritativ tilstand lever i styrede lagre. Hukommelse kan hjælpe planlægning, men den skal ikke afgøre ting i stilhed. Hvis orkestratoren bruger hukommelse, så registrér, hvilken hukommelse, hvorfor den var tilladt, og hvordan den påvirkede planen. Dette føles kun tungt, hvis hukommelse udfører konsekvensbærende arbejde. Hvis hukommelse udfører konsekvensbærende arbejde, så er tyngden netop pointen.
Enkelt slår magisk oftere, end teams forventer
Ikke alle AI-workflows har brug for agenter. Nogle har brug for en deterministisk pipeline med ét modeltrin. Nogle har brug for retrieval, en klassifikator og en kø til menneskelig gennemgang. Nogle har brug for en formular, der kalder en model til udkast. Nogle har brug for batch-evaluering. Nogle har brug for en planlægger. Nogle har brug for flertrins-værktøjsbrug. Arkitekturen bør følge opgaven, ikke den aktuelle begejstring for agentformede diagrammer.
Den kedelige løsning vinder ofte. En fast sekvens er lettere at teste end en åben løkke. En typet værktøjsgateway er sikrere end frit valg af værktøj. En kø med eksplicitte tilstande er lettere at drive end en rekursiv agent. En regelbaseret vagt er billigere end en modeldommer, når reglen er klar. En menneskelig eskaleringsvej er bedre end endnu et forsøg, når konsekvensen er høj. Det er ikke anti-AI-positioner. Det er pro-system-positioner.
Der er et tradeoff. Mere fleksibel orkestrering kan håndtere tvetydighed og uventede ruter. Det øger også varians, evidensbyrde, omkostninger og kompleksitet i debugging. Mere eksplicit orkestrering kan føles rigid. Det forbedrer også reproducerbarhed, ejerskab og genopretning. Det rette punkt afhænger af opgavens tvetydighed, konsekvens, volumen og tolerance for fejl. Magisk tænkning lader som om, at den fleksible ende giver alt gratis. Produktion sender regningen senere, med linjeposter.
Et nyttigt designspørgsmål er: hvad bør aldrig vælges af modellen. Kildeautoritet. Brugerrettigheder. Budgetgrænser. Irreversible handlinger. Opbevaringspligter. Juridisk grundlag. Sikkerhedstærskler. Nogle af disse kan foreslås eller forklares af modeller. De bør ikke sættes stille og roligt af dem. En model kan hjælpe med at navigere i en workflow. Den bør ikke blive forfatningen, fordi det var bekvemt at lægge alt i konteksten.
Design orkestrering som en driftsmodel
Seriøs orkestrering begynder med opgavekontrakten. Hvad er målet. Hvilke data er tilladt. Hvilke output er acceptable. Hvilke værktøjer må bruges. Hvilke handlinger er forbudt. Hvilket budget gælder. Hvilken latenstid er acceptabel. Hvilken evidens skal bevares. Hvilke menneskelige roller findes. Hvilke fejltilstande er mulige. Hvilke genopretningsveje findes. Hvis teamet ikke kan besvare disse spørgsmål, har det ikke brug for en mere magisk graf. Det har brug for en klarere opgave.
Definer derefter tilstandsovergange. Planlagt, venter på input, henter, værktøj afventer, værktøj mislykkedes, evidenskonflikt, politik blokeret, menneskelig gennemgang, godkendt, anvendt, kompenseret, annulleret. Disse tilstande kan lyde hverdagsagtige, fordi de er det. De lader systemet blive drevet. De lader en person vide, om man skal vente, gribe ind, godkende eller reparere. De lader tests hævde adfærd. De lader hændelser starte fra fakta i stedet for fornemmelser.
Definer derefter grænser. Modeller laver udkast til planer. Gateways udfører værktøjer. Regler håndhæver skarpe begrænsninger. Verifikatorer tjekker kontrakter. Mennesker beslutter omstridte konsekvenser. Logs bevarer evidens. Køer håndterer forsinkelse. Lagring holder varig tilstand. Hver grænse bør være kedelig nok til at forklare. Hvis modellen gør flere af disse ting, fordi det var lettere, så navngiv risikoen og beslut, om opgaven er lav nok indsats til at tolerere det. Nogle gange er den det. Mange interne assistenter kan være lette. Problemet er at lade som om, at letvægtsdesign er et fundament for højkonsekvens-automatisering.
Endelig testfejl. Værktøjet returnerer delvise data. Kildekonflikter. Modellen producerer ugyldigt output. Hukommelsen er forældet. Brugeren mangler tilladelse. Omkostningsgrænsen er nået. Menneskelig gennemgang er ikke tilgængelig. Netværket er langsomt. Planen ændres efter godkendelse. Handlingen lykkes delvist. Hvis orkestratoren ikke kan fortælle dig, hvad der sker i disse tilfælde, er grafen kun dekorativ. Den kan stadig være en smuk graf. Stil den ved en plante, ikke i nærheden af produktion.
Lærdommen
Argumentet mod magisk orkestrering er et argument for ingeniørdisciplin. AI-systemer har brug for koordinering, og modeller kan gøre koordineringen mere adaptiv. Men tilpasning uden eksplicit tilstand, værktøjskontrakter, gentagelsespolitik, verifikation, hukommelsesgrænser, handlingsporte og genopretningsstier er ikke intelligens. Det er et system, der beder fremtidige operatører om at opdage dets design ved at læse spor, efter at noget dyrt er sket.
God orkestrering er mindre mystisk og mere nyttig. Den navngiver tilstande. Den begrænser værktøjer. Den registrerer beviser. Den adskiller forslag fra handling. Den klassificerer gentagelser. Den verificerer mod opgavekontrakter. Den behandler hukommelse som hjælpende, ikke autoritativ. Den giver mennesker gennemgåelige tilstande i stedet for uigennemsigtige udskrifter. Den vælger simple pipelines, når simple pipelines er tilstrækkelige. Den tilføjer agenter, hvor tvetydighed retfærdiggør den operationelle pris.
Magien skjuler mekanismen. Seriøs AI har brug for mekanismer, der kan inspiceres, sættes på pause, korrigeres og forbedres. Målet er ikke at fjerne undren fra software. Målet er at holde undren ude af hændelsesrapporten.