Lad os være ærlige. Multi-model er blevet et kinderegg i mange AI-roadmaps: en router her, en cascade der, måske et lille Mixture-of-Agents. Ny forskning peger nu på, at konstruktionen hviler på en antagelse, der ikke holder. Et stort studie af 67 frontmodeller fra 21 leverandører introducerer begrebet co-failure ceiling og hævder, at teams undervurderer den samlede fejlrate op til 2,25 gange, når de kun ser på parvis fejlkorrelation. Det rammer direkte ned i indkøb, drift og governance.
Pointen er brutal i sin enkelhed: Det, der begrænser gevinsten ved orkestration, er ikke hvor sjældent modeller fejler parvist på samme prompt, men andelen af prompts hvor alle modeller i puljen fejler samtidig. Det loft kan hverken en smart router, en flittig cascade eller et ivrigt agent-ensemble forcere.
Hvad fandt studiet
Studiet er publiceret på arXiv og evaluerer 67 sprogmodeller på en fælles prompt-pulje for at måle, hvor ofte fejl optræder samtidigt. VentureBeat opsummerer hovedkonklusionen og kobler den til kendte arkitekturmønstre i store virksomheder. Begge kilder bekræfter definitionen af co-failure ceiling som andelen af prompts, hvor alle valgte modeller svarer forkert på samme tid.
Én sætning stikker ud: undervurderingen af fejlrate op til 2,25 gange, når beslutninger designes efter lav parvis fejlkorrelation. VentureBeat nævner tallet eksplicit. Det bør dobbelttjekkes direkte i papirets figurer, før nogen skriver det ind i en SLA, men vinklen står selv uden eksakt faktor.
Metoden i korte træk
Forskerne placerede modeller fra 21 leverandører på samme bane: identiske prompts, sammenlignelige scoringskriterier, fokus på fælles fejl. I stedet for kun at kigge efter uenighed parvist, måles hvor ofte alle valgte modeller er forkerte samtidig. Den rate er systemets loft.
VentureBeat refererer også et interview med medforfatter Josef Chen om, hvordan naive majority-vote på tværs af modeller med forskellig kvalitet kan give negativ nettogevinst: svagere modeller kan reelt outvote den stærkeste. Det lyder kontraintuitivt, men passer til observationen om fælles svagheder.
Hvad betyder co-failure ceiling
En lavpraktisk intuition: Forestil dig tre modeller. Hvis 18 procent af jeres prompts er steder, hvor alle tre fejler samtidig, så er 82 procent den øvre grænse for præcision for enhver router, cascade eller afstemning med netop de tre. Uanset hvor klog routing er. I de 18 procent er der intet korrekt svar i puljen.
Parvis fejlkorrelation kan være lav (A fejler sjældent på det samme som B). Fint. Men hvis der findes en klasse af prompts, hvor alle fejler (fx delt domæneblindhed, samme træningsbias), snyder den lave parvise korrelation øjet. Loftet flytter sig ikke.
Hvorfor populære designs snubler
Routers, cascades og Mixture-of-Agents lyder fornuftige: routere sender simple ting til billige modeller, svære til dyrere; cascades prøver billigt først og eskalerer; MoA samler svar. Problemet er antagelsen om, at fejlmønstrene ikke kollapser samtidigt.
Når de gør det, rammer man loftet. Routere kan ikke vælge en rigtig model, når ingen i puljen kan svare rigtigt. Cascades eskalerer – men ind i den samme blinde vinkel. Og i MoA kan svagere modeller trække medianen ned. Enkelt – og dyrt.
Skjulte omkostninger i driften
Orkestration har en skyggepris. Hver ekstra modelforbindelse øger median-latency. Hver ekstra leverandør giver nye fejlpunkter, nøgler, kvoter og audit-krav. Vedligehold vokser trinvist: flere health checks, genforsøg, dashboards, alarmer og pager-nætter.
Governance følger med. Hvem bærer ansvaret, når et ensemble fejler i en reguleret proces? Den stærke model, der blev outvoted? Routeren, der traf beslutningen? Eller dataansvarlige, der ikke fangede co-failure i valideringen? Imens tikker regningen: ekstra CPU, flere netværkshop, højere tokenforbrug – uden kvalitetsløft, hvis loftet står stille.
Den praktiske test før I bygger
Brug studiets matematik som en gratis test, før nogen skriver Terraform-moduler til en router. I har sandsynligvis allerede en prompt-log. Saml et repræsentativt udsnit. Marker binært per prompt, om svaret er korrekt eller ej, for hver kandidatmodel i puljen. I komplekse domæner kan korrekthed defineres som passing af en suite af assertions frem for menneskelig bedømmelse. Vær konsistent.
Beregn co-failure-raten for puljen: Hvor ofte fejler alle kandidater samtidigt? Udvid puljen med én ekstra model og se, om loftet falder meningsfuldt – ikke kun statistisk støj. Hvis ikke, er der ingen pointe i at bygge en router til dette sæt. Loftet bestemmer.
Forslag til eksperimentdesign
Start med en single-model baseline. Mål præcision, latency og totalomkostning per 1000 forespørgsler. Vælg to til tre alternative modeller i samme kvalitetsbånd. Kør alle modeller mod samme, versionerede eval-pulje på mindst et par tusind prompts per use case. Beregn:
- Co-failure-rate for puljen
- Marginalt fald i co-failure når en model tilføjes eller fjernes
- Skjulte omkostninger: ekstra median- og p95-latency, model-API-fejlrate, genforsøg
- Netto gevinst: kvalitetsløft minus skyggeomkostning
Sæt tærskler på forhånd. Eksempel: kræv mindst 20 procent relativ reduktion i co-failure og højst 10 procent stigning i median-latency – ellers droppes orkestration. Tærsklerne er jeres, men skriv dem ned før testen, ikke efter.
Single premium eller ensemble
Det nøgterne valg er ofte en stærkere enkeltmodel frem for at orkestrere flere middelgode. VentureBeat citerer Chen for rådet om kun at kombinere modeller inden for samme kvalitetsbånd. Det matcher intuitionen om at undgå, at svagere medlemmer stemmer de stærke ned.
Der kan være et lyspunkt for MoA, når kvaliteten matches, og der opnås reel diversitet. Samme model i Self-MoA hjælper sjældent, hvis målet er at hæve absolut nøjagtighed. Diversitet uden kvalitet er dyr pynt.
Compliance og falsk robusthed
Fornemmelsen af robusthed er farlig i regulerede processer. Hvis flere modeller siger det samme, er det ikke automatisk korrekt – det kan være fælles blind vinkel. Uden dokumenteret validering, versionerede eval-sæt og audit-log for beslutningskæden står man svagt, når tilsyn spørger, hvorfor en fejlagtig afgørelse blev truffet.
Kravet er enkelt at formulere, men tungt i praksis: fuld audit med hvilken model blev kaldt, i hvilken rækkefølge, med hvilken temperatur, hvilke retriever-kilder – og hvor fejlen opstod. Kan fejl ikke reproduceres på en single baseline, opstår langvarig leverandør-pegen.
Åbne spørgsmål og begrænsninger
Der er huller, som kræver ædruelighed: Hvilke prompttyper og domæner indgik i studiet? Hvor meget flytter few-shot eksempler eller skarpere kontekstualisering ved co-failure? Hvor hurtigt forældes en eval-pulje, når modeller opdateres bag facaden?
Og den famøse 2,25x: VentureBeat nævner tallet, men uden fuld tabelkontekst i den åbne dækning. Det bør ses i papirets originale resultatafsnit, ikke kun i en sekundær artikel. Det ændrer ikke logikken i loftet – men det styrer, hvor aggressivt man bør handle lokalt.
Konkrete råd til engineering
Teams bør have tre ting før orkestration: en versionsstyret eval-pipeline, en co-failure-måling pr. use case, og en A/B-procedure med rigtige brugere eller realistiske workloads. Tilføj en modstandsprøve: design prompts, der stress-tester kendte svagheder (lang kontekst, regneopgaver, policy-efterlevelse). Se om loftet flytter sig.
- Målepunkter: co-failure-rate, p50/p95-latency, success-rate pr. domæneklasse, tokens pr. beslutning, leverandør-fejlrate
- Validering: daglig sampling, ugentlig regressionskørsel, månedlig genbalancering af eval-pulje
- A/B: single stærk model vs. orkestreret pulje, samme workloads, foruddefinerede stop-kriterier
- Governance: audit-log med versionerede prompts, model-ID, temperatur, top-p, citations/kilder
SLA og kontrakter
Konsekvensen for leverandørvalg er klar: Kræv testkreditter eller sandkasseadgang til at køre jeres eval-pulje før køb. Sæt SLA op omkring kvalitet på jeres benchmarks – ikke kun oppetid og latency. Bed om gennemsigtighed i modelversioner, ændringslog og udfasningsplan.
Ansvar for fejl i ensemblesituationer bør ikke forsvinde mellem kontraktlinjer. Specificer, at leverandørens målinger skal kunne reproduceres på jeres eval-sæt.
Tre illustrative scenarier
Kundesupport-assistent: Tre modeller kombineres til produktspørgsmål. Routeren vælger billig model ved en FAQ-lignende prompt, men fejlen opstår i en gråzone mellem produkt A og A Pro. Alle tre har set samme marketingsprog i træningen og misforstår skellet. Co-failure slår igennem. Eskalering hjælper ikke.
Kodegenerator: En stærk generalist og to specialister afstemmer forslag. En tricky SQL-CTE med implicit kolonnenavn falder i samme hul for alle tre, fordi træningsdata mangler edge-cases. Majority vote vælger et sikkert, men forkert mønster. En enkelt premium-model med bedre langkæde-evner kunne have klaret det.
Finansiel rapportgenerator: Ensemblet sammenfatter kvartalsdata fra flere kilder. Et regnskabsprincip skifter og kræver ny fortolkning af deferred revenue. Alle modeller fortolker forkert, fordi eval-sættet er for gammelt. Co-failure viser sig som en pæn, men forkert note. Compliance vil kende dokumentationen – ikke hensigten.
Hvad det gør ved roadmaps
Praktisk skifte: Mindre fokus på arkitekturprojekter, mere på evaldata, målemetoder og valideringskvalitet. Flyt budgetter fra generiske orkestrationslag til enten en bedre enkeltmodel eller til en stærkere eval- og monitoreringspipeline. Det er mindre prangende – og mere effektivt.
Kør korte, skarpe eksperimenter over uger, ikke kvartaler, før nogen foreslår enterprise-wide routere. Mål loftet tidligt, ikke efter at CI/CD er fyldt med toggles.
Konklusion uden glasur
Co-failure ceiling er et hårdt loft over multi-model. Hvis loftet ikke falder, når der tilføjes modeller i jeres egen eval, er orkestration oftest dyr kompleksitet forklædt som strategi. Kør co-failure-testen på jeres prompts. Indfør kontinuerlig validering og audit-log, så fejl kan findes og ejes. Revider orkestration først, når beviset står – ikke før.
Kilder og note om metode
Kilder: arXiv paper When Does Combining Language Models Help – A Co-Failure Ceiling on Routing, Voting, and Mixture-of-Agents Across 67 Frontier Models (primær metode og definition), VentureBeat Enterprises using multiple AI models are underestimating failure rates by 2.25x (opsummering, interviewcitat og driftsimplikationer). Hvor tal for 2,25x optræder, er de refereret fra VentureBeat og bør verificeres direkte i papirets resultatafsnit før kontraktbrug.
Usikkerheder: Det er ikke fuldt belyst hvilke domæner og prompttyper der dominerede eval-puljen, eller hvor meget prompt-engineering og kontekstualisering kan skubbe ved co-failure i praksis. Effekt over tid, når modeller versioneres, kræver løbende re-evaluering. Ingen af disse forbehold rokker ved loftets idé, men de bestemmer, hvor aggressivt man bør handle lokalt.
