Minden héten új benchmark, új leaderboard és új állítás, hogy egy modell lehagyott egy másikat. Ebből semmi sem számít éles használatban. A működő rendszer kérdése szűkebb: melyik modell ad elég gyakran helyes választ, elég gyorsan és elég olcsón a te konkrét munkaterheléseden. Itt van, hogy döntünk.
Indulj a workloadtól, ne a modelltől
A legtöbben azt a hibát követik el, hogy először modellt választanak. A helyes kiindulópont a workload. Három kérdés legtöbb esetet eldönt:
- Szinkron, felhasználó felé néző interakció (chat, search) ez, vagy aszinkron (batch feldolgozás, éjszakai ügynök)?
- Milyen hosszú a tipikus kontextus, és milyen gyakran ugrik meg?
- Mennyire kritikus a tool use - kell-e a modellnek függvényt hívni, böngészni vagy MCP szervert megbízhatóan használni?
A három kérdésre adott válasz általában egy-két valódi jelöltre szűkít.
Hol szokott mindegyik nyerni
Ezek munkamegfigyelések szállított projektekből, nem benchmark állítások.
Claude nálunk konzisztensen nyer ágens munkára - hosszú, többlépcsős tool use, érvelés zűrös kontextuson, vázlatírás, ahol számít a hangnem. Ez az alapértelmezésünk olyan helyzetekre is, ahol szeretnénk, hogy a modell őszinte legyen a bizonytalansággal kapcsolatban, ahelyett hogy magabiztosan tévedjen. Az 1M-tokenes kontextus opció számít néhány workloadnak, de gyakrabban a nyereség a hosszú, bonyolult promptok instrukciókövetésében van.
GPT a legjobb mindenes általános chat-re, képgenerálásra és olyan use case-ekre, ahol az OpenAI ökoszisztéma (assistants, files, batch) valódi produktivitásnövelő. Az érvelő modellek kiválóak nehéz one-shot problémákra, ahol a latency nem szűk keresztmetszet.
Gemini költségben nyer skálán és valóban masszív kontextusban. Ha 500 oldalas dokumentumot kell adni egy modellnek és kérdezni róla, vagy millió olcsó osztályozást futtatsz, nehéz verni.
A költség és a latency döntés, nem utógondolat
Egy tízszer drágább, kétszer okosabb modell nem mindig a helyes választás. Rendszeresen routingolunk ugyanazon a workflow-n belül különböző modellekhez - kis modell triage-ra, nagyobb a végső vázlatra, érvelő modell csak akkor, amikor a probléma valóban igényli. Ez a kaszkád az egyik legnagyobb tőkeáttételű minta éles AI munkában, és ezért ritkán a „melyik modellt használjátok” a helyes kérdés.
A latency hasonló. Egy felhasználó felé néző chat, ami 800ms alatt válaszol, élőnek érződik. Ugyanaz 4 másodpercnél törtnek érződik, függetlenül attól, milyen okos a válasz. Mindig a tényleges interakcióban teszteld a modellt, ne csak az API-n.
Lock-in és migrációs kockázat
Feltételezzük, hogy bármely modell választást 12 hónapon belül változtatni kell. Az árak esnek, új verziók jönnek, szolgáltatók kiesnek. Vékony absztrakcióval építünk a modell hívás fölött, evalokkal, amik nem szolgáltatóhoz kötöttek, és olyan promptokkal, amiket portabilitásra írunk. A költség kicsi; az opcionalitás nagy.
Hogyan segítünk
A tényleges workload alapján választunk modellt kliens rendszerekhez, megépítjük a kaszkád routingot, ahol megtérül, és portabilisen tartjuk az architektúrát, hogy a választás újragondolható legyen, ahogy a piac mozog. Ha hamarosan elkötelezed magad egy szolgáltató mellett egy nagy rendszerre, egy külső nézet általában megéri a beszélgetést - főleg a szerződés aláírása előtt.
Címkék