Egy friss tanulmány 67 nagy teljesítményű nyelvi modellt vizsgált 21 szolgáltatótól, köztük GPT-5.5, Claude Opus 4.8 és Gemini 3.1 Pro modelleket. A szerzők azt találták, hogy a többmodelles orchestration (modell-orchestration) egyik alapfeltevése matematikailag hibás: nem elég a páronként alacsony hibakorreláció, mert létezik egy all-wrong mérőszám — a „co-failure rate” vagy közös hibatető — amely a rendszer legfelső korlátját jelenti. Ennek következményeként komplex útválasztó (router), kaskád vagy többi modellből szintetizáló Mixture-of-Agents (MoA) megoldások sokszor nem hoznak tényleges javulást az üzemeltetési költségek és késleltetés növekedése mellett.
Milyen orchestration-architektúrákat vizsgálnak és mi a rejtett költségük
A tanulmány három általános szerkezetet ír le:
- Model routers: forgalomirányítók, amelyek drágább modellekhez küldenek bonyolultabb lekéréseket és olcsóbbakhoz az egyszerűeket.
- Cascades: minden kérést először egy olcsóbb modellhez küldenek, és csak ha az alacsony biztonsággal válaszol, emelik a folyamatot egy prémium modellhez.
- Mixture-of-Agents (MoA): több modellt ugyanazzal a prompttal lekérdeznek, majd aggregált választ állítanak elő.
Ezek a megoldások „árnyékárat” visznek be: megnövelt késleltetés, karbantartási és kormányzási (governance) költségek, valamint több API-szállítóval járó komplexitás. A csapatok rendszerint páronkénti hibakorrelációra támaszkodnak a modellek kiválasztásakor: ha két modell más-más típusú hibákat követ el, az alacsony korreláció reményében kombinálva lefedi egymás vakfoltjait.
Miért csődöt mondhat ez a logika
A szerzők rámutatnak, hogy a páronkénti korreláció nem mutatja meg azt a prompt-egységet (common-mode atom), amelyen az összes piacvezető modell egyszerre hibázik. Például a kutatás MATH-500 feladatsorán a statisztikai páronkénti korrelációkra alapozott előrejelzés szerint a teljes modellcsomag egyszerre csak 2,3%-ban hibázna, miközben a valós, mért co-failure arány 5,2% volt. A szabványos korrelációs metrikák tehát a valós hibaarányt hozzávetőleg 2,25-szörösen alábecsülik.
Josef Chen, a tanulmány szerzője azt mondta a VentureBeatnek: „Naive majority voting across unequal models had negative mean gain (minus 10 points on our hard mix): diverse-but-weaker members outvote the strong one.” A gyakorlati következtetés: csak hasonló minőségi sávba tartozó modelleket érdemes kombinálni; ha ez nem megoldható, a csapatoknak inkább egyetlen, legjobb modellt kell választaniuk.
A co-failure-t kiváltó tényezők és a formátum hatása
A kutatás kimutatta, hogy a feladat formátuma erősen befolyásolja a közös hibák kiterjedését. Amikor a GPQA adatbázisból vett posztgraduális szintű tudományos kérdéseket többszörös választási formátumból szabad szöveges (free-response) formátumba alakították, az „all-wrong tail” 12,7%-ra nőtt. Ez azt jelzi, hogy az open-ended, generatív feladatoknál a co-failure kifejezetten nagy lehet.
A kutatók két típust különböztetnek meg:
- Ceiling-bound környezetek (például nyitott végű matematika): a co-failure magas, a feladat túl nehéz, minden modell egyszerre hibázik, és az orchestration nem segít.
- Realizability-bound környezetek (például posztgraduális tudományos kérdések): a co-failure közel nulla, vagyis legalább egy modell általában ismeri a helyes választ, de a modellek finoman eltérnek, így egy útválasztó nem tud megbízhatóan kiválasztani a helyes választ hiányzó orákulum nélkül.
Ingyenes, matematikai elővizsgálat: Clopper–Pearson bound
A tanulmány praktikus eszközt kínál: a Clopper–Pearson határ segítségével ingyen (előzetes lekérések nélkül) kis mintán kiszámítható a rendszer tényleges, garanciális maximiális pontossága. A példa szerint ha öt ügynököt 50 mintakérdésen tesztelnek, és az összes modell egyszerre két kérdésen hibázik, könnyű azt gondolni, hogy a rendszer 96%-os pontosságot ér el. A Clopper–Pearson formula azonban a statisztikai bizonytalanságot figyelembe véve azt mutathatja, hogy a valós co-failure arány akár 12% is lehet.
Gyakorlati lépések: vállalati környezetben érdemes egy elkülönített, visszatartott (held-out) adatkészletet létrehozni — például egy fintech cég vehet 200 összetett ügyfélszolgálati jegyet az előző negyedévből, és emberi megoldásokat írhat benchmarknak. A mérés integrálása egyszerű: a fejlesztőcsapat a már meglévő eval logokból számolja a közös hibákat, és ez a CI részeként újraszámolható, amikor a modellcsomag vagy a terhelés változik.
Mire érdemes költeni: egy modell vagy ensemble?
A kutatás egyértelmű javaslata, hogy olyan feladatoknál, amelyeket objektíven ellenőrizni lehet (például futó SQL-lekérdezés, pontos számlaszám kinyerése egy PDF-ből, vagy szigorú JSON-séma szerinti formázás), általában jobb egyetlen, legjobb piaci modellt fizetni, mint több olcsóbbat összekötni komplex útválasztással. A kivétel az, ha van egy nagyon erős, lekérés-szintű routing jel (query-level routing signal), vagy ha a csapat képes ugyanazon kvalitású modelleket párosítani.
MoA-architektúrák esetén a Self-MoA (ugyanannak a prémium modellnek többszöri lekérdezése és aggregálása) gyengébb lehet, ha a csomagban több, minőségében egyező, alacsony páronkénti korrelációjú modell áll rendelkezésre: ilyenkor a sokszínű, de jól párosított ensemble jobb teljesítményt ad.
Következtetések és mérnöki tanácsok
A szerzők szerint a co-failure ceiling az, ami valóban korlátozza a multi-model megközelítéseket: a piac vezető modelljei gyakran egyetértenek, és gyakran ugyanazokon a nehéz promptokon buknak el. A mérés költségmentes, tehát minden csapat képes követni a saját co-failure rátáját az új modellgenerációk megjelenésével, és a metrika alapján dönteni az orchestration-ről. Végső soron a vevők érdemi karja a hibamódok heterogenitása és a piaci churn — nem pusztán a modellek számának növelése.
