„Koji model treba da pozovemo?“ nekada je zvučalo kao pitanje o API-ju. U sve većem broju organizacija, to je bliže pitanju nabavke, inženjeringa performansi i arhitekture.
Ta promena je posledica jednostavnog razvoja događaja: sada postoji mnogo modela koje nudi mnogo provajdera, a koji se suštinski razlikuju po prednostima, cenama, profilima latencije, opcijama za implementaciju i ugovornim uslovima. Najavljeni sporazum kompanije Stripe o preuzimanju OpenRoutera koristan je signal. Jedinstveni API kompanije OpenRouter obuhvata više od 400 modela više od 80 provajdera, uz kriterijume rutiranja koji uključuju složenost zadatka, cenu, brzinu, pouzdanost, latenciju, protok, kao i troškove specifične za provajdera.
Nastajuća uloga ne mora nužno biti novo radno mesto. Može obuhvatati inženjering AI platforme, arhitekturu, nabavku, operacije inferencije ili inženjering proizvoda. Ali njena odgovornost postaje prepoznatljiva: odlučiti koji model treba da obrađuje koji posao, pod kojim ograničenjima, sa kojom rezervnom opcijom i na osnovu kojih dokaza.
Rutiranje je odluka o politici prerušena u infrastrukturu
Naivan ruter pita: „Koji model je najjeftiniji?“ Koristan ruter postavlja konkretnije pitanje: „Koji je najjeftiniji model koji ispunjava zahteve ovog zahteva u pogledu kvaliteta, latencije, pouzdanosti, privatnosti i operacija?“
Ti zahtevi se razlikuju u zavisnosti od zadatka. Klasifikator za korisničku podršku možda zahteva predvidljiv strukturirani izlaz i nisku latenciju. Težak zadatak programiranja može opravdati sporiji, sposobniji model. Proces obrade sažetaka velikog obima može favorizovati manji model, naročito ako se testiranjem pokaže da je njegov kvalitet dovoljan. Regulisani proces može zahtevati određeni region, politiku zadržavanja podataka ili ugovor sa provajderom, bez obzira na cenu tokena.
Zato rutiranje pripada arhitektonskim revizijama, a ne samo kodu aplikacije. Ruta određuje više od iznosa na računu. Ona može uticati na rezidentnost podataka, izloženost prekidima rada, mogućnost posmatranja sistema, doslednost odgovora, ponašanje pri korišćenju alata i količinu ljudske provere potrebne u narednim koracima.
Četiri discipline iza ozbiljne funkcije rutiranja
1. Nabavka: uporedite celu uslugu, a ne istaknutu cenu tokena
Cene modela lako je pogrešno uporediti. Ulazni i izlazni tokeni mogu imati različite cene. Keširani ulaz, grupna obrada, prioritetna usluga i zahtevi sa dugim kontekstom mogu promeniti računicu. Nominalna cena provajdera takođe malo govori o ponovljenim pokušajima, ograničenjima brzine, podršci, minimalnim obavezama, izlaznom saobraćaju ili inženjerskom trošku prebacivanja.
Vlasnik rutiranja treba da održava inventar modela i provajdera sa poljima kao što su:
- cene ulaznih, izlaznih, keširanih i grupnih obrada;
- ograničenja konteksta i izlaza;
- dokumentovana ograničenja brzine i uočeni protok;
- distribucije latencije, a ne samo prosečna latencija;
- dostupnost i ponašanje pri isteku vremena;
- uslovi korišćenja podataka, zadržavanja, rezidentnosti i ugovorni uslovi;
- podržane mogućnosti, uključujući pozive alata, strukturirani izlaz, vizuelne mogućnosti i strimovanje;
- opcije rezervnog usmeravanja i migracije.
Rezultat je bliži spisku materijala za tehnologiju nego listi naziva modela. Treba ga preispitati kada se promene cene, politike, verzije modela ili obim poslovanja.
2. Inženjering performansi: merite zadatak, a ne rang-listu
Opšta merila mogu pomoći pri orijentaciji, ali odluke o rutiranju zahtevaju testove specifične za radno opterećenje. Model koji se dobro pokazuje na javnom merilu za programiranje možda nije najbolji izbor za interne repozitorijume organizacije, konvencije imenovanja, šeme alata ili bezbednosne kontrole.
Napravite reprezentativni skup za evaluaciju iz stvarnih zahteva, uz uklanjanje ili kontrolu osetljivog materijala. Označite ishode koji su važni: činjeničnu tačnost, validan JSON, uspešan izbor alata, uspešno prolaženje testova koda, ponašanje pri odbijanju, potrebu za eskalacijom i prihvatljiv stil. Zatim zabeležite cenu, vreme do prvog tokena, ukupnu latenciju, stopu isteka vremena, stopu ponovljenih pokušaja i dužinu odgovora.
Nemojte prerano svoditi rezultat na jednu ocenu. Ponderisana ocena može sakriti ozbiljan način otkazivanja. Na primer, model sa odličnim prosečnim kvalitetom, ali čestim neispravnim pozivima alata, može biti neprikladan za automatizovani proces. Sporiji model može biti ekonomski povoljniji ako njegovi odgovori smanjuju skupu ljudsku proveru.
Koristite proces sa prvakom i izazivačem: zadržite trenutno odobrenu rutu, testirajte alternative na istom korpusu i unapredite izazivača tek kada ispuni izričite pragove kvaliteta i operativne pragove. Tvrdnje koje navodi provajder treba tretirati kao ulazne podatke za plan testiranja, a ne kao dokaz da će se model slično ponašati u vašem okruženju.
3. Arhitektura: učinite izbor modela zamenljivim
Rutiranje postaje skupo kada se pretpostavke specifične za model provlače kroz celu aplikaciju. Otporan dizajn razdvaja poslovni zadatak od poziva provajderu.
Definišite interni ugovor o mogućnostima. On može da precizira da operacija „klasifikacije“ vraća fiksnu šemu, polja za pouzdanost ili uzdržavanje od odgovora, identifikator modela i identifikator traga. Operacija „izrade nacrta odgovora“ može da precizira ograničenja tona, zahteve u pogledu citiranja i maksimalni budžet latencije. Adapteri provajdera zatim prevode taj ugovor u pojedinačne API-je.
Vodite verzije upita, šema, definicija alata, bezbednosnih pravila i politika rutiranja. Beležite koji snimak modela i koji provajder su poslužili svaki zahtev. Sačuvajte dovoljno informacija da se odluka može ponoviti, bez nepotrebnog zadržavanja osetljivog sadržaja korisnika.
Fallback opcije osmislite namerno. Fallback može biti drugi provajder, manji model, workflow koji se stavlja u red čekanja ili putanja za ljudsku proveru. Ne sme neprimetno promeniti značenje zadatka. Ako je strukturirani izlaz obavezan, fallback mora podržavati isti ugovor ili pokrenuti kontrolisanu eskalaciju.
4. Upravljanje: odlučite kada ne treba automatski rutirati
Neke zahteve ne treba slati najjeftinijem dostupnom modelu — ili bilo kom eksternom modelu. Politika rutiranja mora da sadrži pravila za izuzimanje poverljivih podataka, odluka sa velikim uticajem, nepodržanih jezika, neuobičajeno dugog konteksta ili radnji koje zahtevaju korak ljudskog odobrenja.
Timovi takođe treba da razlikuju tehničku dostupnost modela od odobrenja za konkretnu upotrebu. Zahtevi nabavke i pravni zahtevi mogu se razlikovati po poslovnim jedinicama. Model može biti odličan u evaluaciji, a ipak neupotrebljiv za workflow čiji uslovi obrade podataka nisu usklađeni sa organizacijom.
Praktična tabela rutiranja
Početna politika može biti jednostavna i eksplicitna:
| Klasa zadatka | Primarni cilj | Moguća ruta | Okidač za eskalaciju |
|---|---|---|---|
| Ekstrakcija velikog obima | Validna šema i nizak jedinični trošak | Mali ili srednje veliki model sa strogom validacijom izlaza | Neuspeh šeme ili niska pouzdanost |
| Složena analiza | Kvalitet i rad sa dokazima | Sposobniji model sa većim budžetom latencije | Nedostatak dokaza, dvosmislenost ili oznaka politike |
| Interaktivna podrška | Brz doživljeni odgovor | Model sa niskom latencijom, kome eventualno sledi dorada | Nisko poverenje ili zahtev korisnika za dubljom analizom |
| Osetljiv tok rada | Odobreno rukovanje podacima i mogućnost revizije | Ugovorno odobren pružalac usluga ili kontrolisana implementacija | Neodobreni podaci, radnja ili jurisdikcija |
Tačna tabela će se razlikovati od organizacije do organizacije. Važno je da pravila rutiranja budu razumljiva zainteresovanim stranama iz oblasti proizvoda, bezbednosti, finansija i inženjerstva — a ne zakopana u uslovnoj naredbi.
Šta ovo znači za ljude koji grade karijeru
Najjači kandidati za ovaj posao kombinovaće nekoliko vrsta stručnosti. Razumeće dovoljno mašinskog učenja da mogu da procene sposobnosti i degradaciju; dovoljno sistemskog inženjerstva da upravljaju kašnjenjem, ponovnim pokušajima, ograničenjima brzine i režimima otkaza; dovoljno finansija da modeluju ukupne troškove; i dovoljno nabavke i upravljanja da procene obaveze i ograničenja pružalaca usluga.
Takođe će se dobro snalaziti u pisanju zapisa o odlukama. Koristan zapis objašnjava zašto je određena ruta izabrana, koji dokazi je podržavaju, koji rizici preostaju i koji događaj treba da pokrene ponovnu procenu. To je vrednije od pamćenja najnovijih naziva modela, jer će se nazivi modela i cene stalno menjati.
Kompaktan projekat za portfolio mogao bi da pokaže ovu veštinu bez potrebe za velikim produkcionim sistemom. Izaberite jedno radno opterećenje, napravite redigovani skup za evaluaciju, povežite tri pružaoca modela ili lokalna modela iza zajedničkog interfejsa i uporedite kvalitet, validnost šeme, percentile kašnjenja, stope otkaza i procenjeni mesečni trošak pri nekoliko obima. Dodajte pravila politike za osetljive ulazne podatke i rezervni put. Objavite metodologiju testiranja i ograničenja.
Budite precizni u pogledu onoga što projekat dokazuje. On ne dokazuje da je jedan model univerzalno najbolji. Dokazuje da možete da pretvorite nejasan problem izbora modela u merljivu operativnu politiku.
Karijerni signal
Rutiranje modela postaje strateški važno jer inteligencija više nije jedna fiksna zavisnost. Ona je portfolio usluga sa različitim kompromisima i promenljivom ekonomikom. Timovi koji taj portfolio tretiraju kao međusobno zamenljivu infrastrukturu mogu smanjiti troškove, ali mogu stvoriti i skrivene probleme sa kvalitetom, usklađenošću i pouzdanošću. Timovi koji ga tretiraju kao trajnu posvećenost jednom modelu mogu propustiti bolje opcije.
Ova disciplina u nastajanju nalazi se između tih krajnosti: dovoljno apstraktna da omogućava promenu pružalaca usluga, dovoljno konkretna da očuva kvalitet zadataka i dovoljno zasnovana na dokazima da opravda izbor. To je karijerna prilika u oblasti rutiranja modela — ne biranje API-ja jednom, već izgradnja sistema odlučivanja koji stalno donosi dobre izbore.
Tom Whitfield je odgovorni ljudski urednik publikacije AI Career Brief, koja se bavi veštinama, ulogama i pametnim potezima za rad u doba veštačke inteligencije.
