FAPO er Cisco AIs nye open source‑ramme for fuldautomatisk promptoptimering i flertrins LLM‑pipelines. Værktøjet samler et optimeringsloop med Claude Code som dirigent og introducerer fejlattribution på trin‑niveau, så en fejl ikke kun måles, men lokaliseres i den del af kæden, hvor den faktisk opstod. Derefter foreslås og testes ændringer i tre lag: først prompt, dernæst parametre og til sidst selve kædestrukturen. Koden er frigivet under Apache 2.0, og der er også støtte for Codex som agent til orkestrering.
Timingen er logisk. Mange teams oplever, at små formuleringer i en prompt kan rykke nøjagtighed med tocifrede procenter. Cisco peger selv på omkring 20 procent. Det nye her er forsøget på at gøre det arbejde reproducerbart på tværs af hele kæden, ikke kun i et enkelt trin.
Hvorfor det betyder noget nu
Prompt‑engineering i praksis er en kæde: parsere, retrievere, værktøjskald, reasonere og til sidst en evaluator. Når noget fejler, ender fejlsøgningen ofte som manuelt gennemsyn af mellemoutputs. I lille skala er det tåleligt; i skala bliver det dyrt. Et par ord flyttes i systemprompten og hjælper ét sted, men bryder et andet. Her kan en automatiseret sløjfe med trin‑specifik diagnosticering skære timer væk og fjerne meget gætteri.
MarkTechPost gengiver Ciscos vurdering: små ordvalg kan give omkring 20 procents forskel i nøjagtighed, og løsninger, der virker på få eksempler, falder fra hinanden, når datasættet vokser. Pointen her er ikke kun målingen, men at FAPO prøver at importere disciplinen fra klassisk softwaretest til LLM‑arbejde: versioner, budgetter, holdouts og en lukket sløjfe, der stopper, når målet er nået eller budgettet er brugt.
Hvad FAPO faktisk gør teknisk
Rammen organiserer arbejdet i et fast loop med seks trin: Evaluate, Attribute, Propose, Review, Compare, Accept. Først køres kæden mod validationsættet, mens systemet opsamler per‑case scores og mellemtrin. Dernæst klassificerer det fejltyper. Bagefter foreslår en agent en variant, der adresserer den dominerende fejlklasse. Et uafhængigt review‑agent tjekker for dataslør og scope. Så sammenlignes resultatet med bedste hidtil, og kun reelle forbedringer accepteres. Sløjfen gentages, til mål eller budget er nået.
Eskalering sker i tre niveauer. Laveste omkostning er promptredigeringer. Hvis det ikke rækker, justeres parametre som temperatur eller retrieval_k. Først hvis fejlklasserne peger på strukturelle problemer, ændres selve kæden, fx ved at indsætte en refleksionsnode eller skifte til et ReAct‑mønster. Rækkefølgen er simpel: udtøm billige ændringer før dyre.
Fejlattribution på trin‑niveau i praksis
En variant accepteres kun, hvis den vinder på validatoren og slår den nuværende bedste; ellers rulles den tilbage. Mange har forsøgt noget lignende i scripts. Forskellen her er, at det er samlet og designet til kæder frem for enkeltprompter.
Hephaestus‑motoren og arkitekturen
Under hjelmen ligger en kerne kaldet hephaestus, beskrevet som domæne‑agnostisk. Den udfører evaluering, driver kæden og scorer outputs. FAPO organiserer arbejdet i tenants, som hver rummer prompts, datasæt, kædedefinition, scorere og konfiguration. Tenants holdes adskilt, så parallelle optimeringer ikke forurener hinanden — praktisk for at køre flere opgaver side om side.
Kæder defineres som LangGraph state graphs. Ifølge kilden understøttes tre providers: OpenAI, Baseten og SageMaker. For at komme i gang kræves et parret input‑output‑datasæt, en indledende kæde, mindst én scorerfunktion og adgang til en LLM‑udbyder. Noget kan scaffolderes af agenten fra en opgavebeskrivelse, men kvaliteten af den første scorer sætter loftet for beslutningerne i automatikken.
Claude Code og Codex som agenter
Orkestreringen ligger hos Claude Code, og der er støtte for Codex som alternativ. Agentvalget påvirker både pålidelighed og omkostning. En stærkere agent kan foreslå bedre varianter pr. iteration, men koster typisk mere pr. kald og kan tage større skridt, der kræver mere review. En billigere agent kan kræve flere runder. Rammen gør det målbart og udskifteligt.
Agenten udfører to roller, der normalt ligger hos mennesker: den skriver forslag til ændringer og læser dem kritisk i et separat reviewtræk. Separationen reducerer åbenlyse lækager, men eliminerer dem ikke. Blindvinkler kan gå igen i begge roller.
Open source og de indbyggede guardrails
FAPO er frigivet under Apache 2.0. MarkTechPost peger på tre værn mod overfitting: kun at inspicere validationsplittet under iteration, immutable variantfiler og en uafhængig reviewer på hvert forslag. Fornuftige valg — men governance bliver ikke automatisk. Sensitive data, PII og auditkrav kræver procedurer uden for agentløkken.
Endelig evaluering sker mod et holdout, der først røres til sidst. Det er efter bogen. Spørgsmålet er, om disciplinen holder, når deadlines presser. Rammen kan låse nogle døre, men ikke alle.
Ydelseskrav og hvad der er dokumenteret
Cisco‑rapporterede resultater siger, at FAPO slog GEPA i 15 ud af 18 model‑benchmark‑sammenligninger med en gennemsnitlig gevinst på 14,1 procentpoint. På HoVer og IFBench, hvor FAPO eskalerede helt til kædeændringer, vandt værktøjet alle seks par med gennemsnitligt +33,8 procentpoint. AIME nævnes som GEPAs eneste sejr, inden for samplingstøj. Tallene er markante — og interne — og bør efterprøves uafhængigt.
Der mangler stadig detaljer for fuld reproducerbarhed: præcise modelnavne og størrelser, temperaturer og max_tokens, stikprøvestørrelser, random seeds, compute‑budget pr. iteration og om testholdout forblev urørt. Uden de oplysninger kan man kun konkludere, at fremgangsmåden ser lovende ud, og at pipeline‑eskalation kan betale sig, når fejlattribution peger i den retning.
Praktiske konsekvenser for teams
Integration kan passe ind i eksisterende CI for prompts. Definér et datasæt med klare succeskriterier, beskriv kæden i LangGraph, skriv en scorer, der afspejler forretningens mål, og giv FAPO et fast budget. Varianter bør versioneres side om side med kode, og regressionstests kan køre som job. Det er en forlængelse af eval‑pipelines og A\/B‑tests, ikke et helt nyt paradigme.
Der er dog tradeoffs. Hver iteration kører hele kæden på mange eksempler. Det koster tokens, tid og opsyn. Driften bliver mere kompleks med tenants, variantfiler og agent‑review, som nogen skal eje. Og scorerens kvalitet styrer retningen: en svag scorer kan godkende kosmetiske forbedringer — ofte værre end ingen forbedring.
Begrænsninger og risici
Overfitting er den oplagte risiko. Når samme klasse af modeller både foreslår og evaluerer, kan forbedringer kun gælde under samme evaluator. Det kan give falske positive på validationsplittet. Et robust holdout og gerne en menneskelig stikprøvegennemgang er nødvendigt i følsomme anvendelser.
Fejlattribution under støj er en anden udfordring. Ikke‑deterministiske mellemtrin kan få samme case til at opføre sig forskelligt på tværs af runs. Hvor sikkert bliver attributten så? MarkTechPost beskriver regler kombineret med LLM‑analyse, men ikke fejlratens størrelse. Forkerte attributioner kan tvinge unødig eskalation og spilde budget.
Konkurrence og kontekst
Der eksperimenteres bredt med automatiseret optimering. VentureBeat beskriver Arbor fra Renmin University og Microsoft Research, hvor et træ af hypoteser og læring fra fejl erstatter lineære gæt. I deres rapporterede forsøg gav Arbor over 2,5 gange verificerede gevinster mod standard kodeagenter på samme compute‑budget. Det er en anden tilgang end FAPO, men adresserer samme smertepunkt: at gøre forbedringer kumulative og verificerbare.
FAPOs særkende er pipeline‑bevidsthed og trin‑specifik attribution med kontrolleret eskalation fra prompt til struktur. Det er ikke bare flere prompts hurtigere, men at ændre det rigtige først. Om det i praksis slår alternativer på pris pr. gevinst, kræver side‑om‑side tests på samme budget. De data er ikke offentliggjort.
Hvad man konkret kan gøre nu
For CTO’er og AI‑ingeniører, der vil prøve idéen: vælg én pipeline med konkret forretningsværdi, saml et repræsentativt datasæt med klare labels, skriv en scorer der straffer de fejl, der koster mest, og definér kæden i LangGraph. Sæt token‑budget og iterationer som faste grænser. Log mellemtrin. Hold testholdouten isoleret. Mål ikke kun nøjagtighed, men også pris pr. forbedringspoint, latens og varians på tværs af seeds.
Review og sporbarhed bør være faste krav. Immutable variantfiler hjælper, men føj changelogs til PRs, så optimeringer gennemgår samme kvalitetssikring som kode. Hvor problemstillingen er følsom, bør en menneskelig reviewer godkende større kædeændringer, især når agenten selv foreslår dem.
Huller i rapporteringen man bør få svar på
Oplagte spørgsmål til Cisco: Hvilke modelversioner og konfigurationer indgik i de 15 ud af 18 sammenligninger og i HoVer\/IFBench? Hvor stort var compute‑budgettet pr. iteration, og hvordan fordeltes det mellem evaluate og propose\/review? Hvor stor var stikprøven, og blev signifikans testet? Og hvordan håndteres PII og audits i praksis, ud over agent‑reviewet? Svarene afgør, om værktøjet kan rulles ud i regulerede domæner uden ekstra indpakning.
Indtil da bør tal og gevinster læses som lovende, ikke som facit. Det er ikke en kritik, men almindelig ingeniørpraksis.
Afsluttende perspektiv
Hvis en pipeline‑bevidst optimeringssløjfe som FAPO holder i uafhængige tests, kan den flytte promptarbejde fra håndværk til en proces, der kan auditeres, genskabes og versioneres. Man får styr på, hvor tiden går, og kan dokumentere hvorfor en ændring virker — ikke kun at den virkede i tirsdags.
Der er åbne spørgsmål om omkostninger, evaluator‑bias og attribution under støj. Retningen er dog klar: færre heroiske, manuelt finjusterede prompts; flere målbare loops, der kan køre natten over og levere forbedringer, man tør tage i produktion.
