Capcana modelului unic
Orice furnizor mare de inteligență artificială vrea să crezi că modelul lui de vârf este răspunsul potrivit la orice întrebare. Această credință îi este comod comercial și îți este falsă tehnic.
Un model care strălucește la raționament juridic cu context lung nu este cel potrivit pentru a produce o legendă de zece cuvinte. Un model cu vedere de vârf este exagerat — și probabil prea scump — pentru o sarcină în loturi care reformatează JSON structurat. Un model al cărui preț este acordat pe debit poate fi cea mai proastă alegere cu putință când îți trebuie răspuns în două secunde.
Când construiești pe un singur model, nu alegi cea mai bună unealtă. Alegi cea mai bună unealtă disponibilă înăuntrul unei constrângeri artificiale. Cu timpul, această constrângere se adună: plătești prea mult pentru sarcinile simple, rămâi în urmă la cele complexe, iar când acel furnizor are un defect sau o scumpire, tot produsul tău stă.
Capabilități, nu nume
Abstracția utilă nu este „care model", ci „ce capabilități îi trebuie acestei cereri". Această întrebare are un răspuns precis.
Un mesaj de conversație cu o captură de ecran atașată are nevoie de vedere. Un pas de flux care cheamă un API din afară are nevoie de unelte. Un asistent de cod care trebuie să-și verifice propria ieșire are nevoie de executarea codului. Un lanț de rezumare de noapte care nu trebuie să fie rapid poate folosi tarifare în loturi; un asistent din interiorul produsului, pe care cineva îl așteaptă, nu.
Când enumeri întâi cerințele de capabilitate, alegerea modelului devine o sarcină de filtrare și ordonare. Având un set cerut — să zicem text, vedere și ieșire structurată — găsești toate modelele care le acceptă pe toate trei, apoi le ordonezi după calitate și preț pentru contextul curent al cererii. Această ordonare se poate schimba de la o cerere la alta după ce face persoana și cum stă cu fondurile.
Exact asta face lanțul de direcționare al ToRun. Modul (Conversație, Cod, Imagine, Cercetare și altele) se mapează pe un set de capabilități. Setul filtrează catalogul de modele. Clasarea după preț și calitate alege câștigătorul. Rezultatul este că poți folosi DeepSeek pentru extragere structurată la volum mare, Claude sau modele din clasa GPT-4 pentru raționament nuanțat, Google Gemini pentru lucru cu documente în context lung și un model de imagine specializat pentru generare — totul de pe aceeași suprafață de produs, fără să scrii logică de repartizare.
Rezerva nu este un adaos plăcut
Defectele furnizorilor nu sunt cazuri rare la margine. Se întâmplă în toată ramura de câteva ori pe lună. Dacă produsul tău depinde de un singur furnizor și API-ul lui slăbește, produsul tău slăbește odată cu el.
Un lanț de rezervă este minimul de funcționare: când modelul principal întoarce o eroare trecătoare pentru o cerere, platforma o reia pe următorul cel mai bun model apt. Asta presupune ca stratul de direcționare să știe deja ce modele sunt apte — și tocmai asta dă direcționarea după capabilități.
Rezerva are încă un folos mai puțin evident: îți ține comportarea de facturare previzibilă. Dacă modelul primei alegeri este temporar peste o limită de folosire, cotirea spre următorul model apt ține costul în interval fără să-i arate cuiva o eroare.
Concluzia practică
Când cântărești platforme de inteligență artificială, pune două întrebări: cum alege un model pentru fiecare cerere și ce se întâmplă când acel model nu este disponibil sau devine prea scump?
Dacă răspunsul la oricare este „ia mereu modelul X", acesta este un miros de arhitectură. Modelele disponibile azi nu vor fi cele mai bune modele peste șase luni. Apar furnizori noi. Prețurile se mișcă. Granițele capabilităților se schimbă. O arhitectură care tratează alegerea modelului ca pe o sarcină de direcționare — nu ca pe o decizie de configurare — îmbătrânește mai bine, costă mai puțin în timp și slăbește mai elegant sub presiune.
Un model este un punct de plecare. Un strat de direcționare este temelia adevărată.