Ang “Aling modelo ang dapat nating tawagin?” ay dating itinuturing na tanong tungkol sa API. Sa dumaraming organisasyon, mas malapit na ito sa isang tanong tungkol sa procurement, performance engineering, at arkitektura.
Ang pagbabagong ito ay bunga ng isang simpleng pag-unlad: marami na ngayong modelo, na iniaalok ng maraming provider, na malaki ang pagkakaiba sa mga kalakasan, presyo, latency profile, opsyon sa deployment, at mga kondisyong kontraktuwal. Isang kapaki-pakinabang na senyales ang inanunsiyong kasunduan ng Stripe para bilhin ang OpenRouter. Saklaw ng iisang API ng OpenRouter ang mahigit 400 modelo mula sa mahigit 80 provider, na may mga pamantayan sa routing kabilang ang pagiging kumplikado ng gawain, presyo, bilis, pagiging maaasahan, latency, throughput, at mga partikular na gastos ng provider.
Ang umuusbong na tungkulin ay hindi naman kinakailangang isang bagong titulo. Maaari itong saklawin ang AI platform engineering, arkitektura, procurement, inference operations, o product engineering. Ngunit nagiging malinaw na ang responsibilidad nito: magpasya kung aling modelo ang dapat humawak sa aling gawain, sa ilalim ng anong mga limitasyon, na may anong fallback, at batay sa anong ebidensya.
Ang routing ay isang desisyong pampatakaran na nagkukunwaring imprastraktura
Ang payak na router ay nagtatanong: “Aling modelo ang pinakamura?” Ang kapaki-pakinabang na router ay nagtatanong ng mas tiyak: “Ano ang pinakamurang modelong nakatutugon sa mga kinakailangan sa kalidad, latency, pagiging maaasahan, privacy, at operasyon ng kahilingang ito?”
Nagkakaiba ang mga kinakailangang iyon ayon sa gawain. Maaaring mangailangan ang isang classifier para sa customer support ng mahuhulaang structured output at mababang latency. Maaaring bigyang-katwiran ng mahirap na coding task ang mas mabagal ngunit mas mahusay na modelo. Maaaring paboran ng high-volume summarization pipeline ang mas maliit na modelo, lalo na kung sapat ang kalidad nito matapos ang pagsusuri. Maaaring mangailangan ang isang workflow na saklaw ng regulasyon ng partikular na rehiyon, retention policy, o kasunduan sa provider anuman ang presyo ng token.
Ito ang dahilan kung bakit kabilang ang routing sa mga architecture review, hindi lamang sa application code. Higit pa sa invoice ang maaaring maapektuhan ng route. Maaari nitong maapektuhan ang data residency, exposure sa outage, observability, pagkakapare-pareho ng tugon, pag-uugali sa paggamit ng tool, at dami ng pagsusuring pantao na kakailanganin sa mga susunod na hakbang.
Ang apat na disiplina sa likod ng isang seryosong routing function
1. Procurement: ihambing ang buong serbisyo, hindi lamang ang presyong nakalagay para sa token
Madaling maihambing nang mali ang mga presyo ng modelo. Maaaring magkaiba ang singil para sa input at output token. Maaaring baguhin ng cached input, batch processing, priority service, at mga kahilingang may mahabang context ang kalkulasyon. Kaunti rin ang sinasabi ng nominal na presyo ng provider tungkol sa mga retry, rate limit, support, minimum commitment, egress, o gastos sa engineering para sa paglipat.
Dapat magpanatili ang may-ari ng routing ng imbentaryo ng mga modelo at provider na may mga field gaya ng:
- presyo para sa input, output, cached, at batch;
- mga limitasyon sa context at output;
- mga dokumentadong rate limit at naobserbahang throughput;
- mga distribusyon ng latency, hindi lamang karaniwang latency;
- availability at pag-uugali kapag nag-timeout;
- mga tuntunin sa paggamit ng datos, retention, residency, at kontrata;
- mga sinusuportahang kakayahan, kabilang ang mga tool call, structured output, vision, at streaming;
- mga opsyon sa fallback at migration.
Ang resulta ay mas malapit sa talaan ng mga materyales sa teknolohiya kaysa sa listahan ng mga pangalan ng modelo. Dapat itong repasuhin kapag nagbabago ang mga presyo, patakaran, bersyon ng modelo, o dami ng negosyo.
2. Performance engineering: sukatin ang gawain, hindi ang leaderboard
Makakatulong ang mga pangkalahatang benchmark bilang gabay, ngunit kailangan ng mga desisyon sa routing ang mga pagsusulit na partikular sa workload. Maaaring mahusay ang isang modelong gumaganap sa isang pampublikong coding benchmark, ngunit maaaring hindi ito ang pinakamahusay na pagpipilian para sa mga internal repository, kombensiyon sa pagpapangalan, tool schema, o security control ng isang organisasyon.
Bumuo ng isang kinatawang evaluation set mula sa mga totoong kahilingan, na inalisan o kinontrol ang sensitibong materyal. Lagyan ng label ang mahahalagang resulta: katumpakan sa impormasyon, wastong JSON, matagumpay na pagpili ng tool, tagumpay sa code test, pag-uugali sa pagtanggi, pangangailangan ng escalation, at katanggap-tanggap na estilo. Pagkatapos, itala ang gastos, oras bago lumabas ang unang token, kabuuang latency, timeout rate, retry rate, at haba ng completion.
Huwag agad pagsamahin ang resulta sa iisang score. Maaaring itago ng weighted score ang isang seryosong failure mode. Halimbawa, maaaring hindi angkop para sa isang automated workflow ang modelong may napakahusay na average quality ngunit madalas na gumagawa ng malformed tool call. Maaaring mas matipid sa kabuuan ang mas mabagal na modelo kung nababawasan ng mga sagot nito ang magastos na pagsusuring pantao.
Gumamit ng proseso ng champion-and-challenger: panatilihin ang kasalukuyang aprubadong route, subukan ang mga alternatibo gamit ang parehong corpus, at i-promote lamang ang challenger kapag nalampasan nito ang malinaw na mga threshold sa kalidad at operasyon. Dapat ituring ang mga pahayag na iniulat ng provider bilang mga input sa isang test plan, hindi bilang patunay na katulad ang pagganap ng isang modelo sa inyong kapaligiran.
3. Arkitektura: gawing maaaring palitan ang pagpili ng modelo
Nagiging magastos ang pagruruta kapag kumakalat sa buong application ang mga palagay na partikular sa modelo. Pinaghihiwalay ng isang matatag na disenyo ang gawain ng negosyo mula sa pagtawag sa provider.
Magtakda ng panloob na kontrata para sa mga kakayahan. Maaari nitong tukuyin na ang isang operasyong “classification” ay nagbabalik ng nakapirming schema, mga field para sa kumpiyansa o pag-iwas sa pagsagot, isang identifier ng modelo, at isang identifier ng trace. Maaaring tukuyin naman ng operasyong “draft response” ang mga limitasyon sa tono, mga kinakailangan sa pagsipi, at pinakamataas na badyet para sa latency. Pagkatapos, isinasalin ng mga adapter ng provider ang kontratang iyon sa mga indibidwal na API.
Panatilihing may bersyon ang mga prompt, schema, depinisyon ng tool, panuntunan sa kaligtasan, at mga patakaran sa pagruruta. Itala kung aling snapshot ng modelo at provider ang nagsilbi sa bawat kahilingan. Magpanatili ng sapat na impormasyon upang muling magawa ang isang desisyon nang hindi kinakailangang panatilihin ang sensitibong nilalaman ng user.
Planuhin nang sinasadya ang mga fallback. Maaaring isa pang provider, mas maliit na modelo, naka-queue na workflow, o landas para sa pagsusuri ng tao ang fallback. Hindi nito dapat tahimik na baguhin ang kahulugan ng gawain. Kung sapilitan ang structured output, dapat suportahan ng fallback ang parehong kontrata o magpasimula ito ng kontroladong pag-escalate.
4. Pamamahala: magpasya kung kailan hindi awtomatikong magruruta
May ilang kahilingang hindi dapat ipadala sa pinakamurang modelong available—o sa anumang external na modelo. Kailangan ng patakaran sa pagruruta ng mga panuntunang nagbubukod sa kumpidensiyal na datos, mga desisyong may malaking epekto, mga wikang hindi sinusuportahan, hindi pangkaraniwang habang konteksto, o mga pagkilos na nangangailangan ng hakbang ng pag-apruba ng tao.
Dapat ding pag-ibahin ng mga team ang pagiging teknikal na available ng isang modelo at ang pagiging aprubado nito para sa isang partikular na gamit. Maaaring magkaiba ang mga kinakailangan sa procurement at legal ayon sa yunit ng negosyo. Maaaring napakahusay ng isang modelo sa isang ebalwasyon ngunit hindi pa rin magamit sa isang workflow na hindi umaayon sa organisasyon ang mga tuntunin nito sa pangangasiwa ng datos.
Isang praktikal na talahanayan ng pagruruta
Maaaring maging simple at malinaw ang panimulang patakaran:
| Klase ng gawain | Pangunahing layunin | Posibleng ruta | Nagpapasimulang dahilan ng pag-escalate |
|---|---|---|---|
| Pagkuha ng datos na mataas ang dami | Balidong schema at mababang gastos bawat yunit | Maliit o katamtamang laki ng modelo na may mahigpit na beripikasyon ng output | Pagpalya ng schema o mababang kumpiyansa |
| Masalimuot na pagsusuri | Kalidad at pangangasiwa ng ebidensiya | Mas may kakayahang modelo na may mas malaking badyet para sa latency | Kulang na ebidensiya, kalabuan, o flag ng patakaran |
| Interaktibong tulong | Mabilis na inaakalang tugon | Modelong mababa ang latency, na maaaring sundan ng pagpipino | Mababang kumpiyansa o kahilingan ng user para sa mas malalim na sagot |
| Sensitibong workflow | Inaprubahang pangangasiwa ng data at pagiging nasusubaybayan sa audit | Provider na aprubado ng kontrata o kontroladong deployment | Hindi aprubadong data, aksyon, o hurisdiksyon |
Magkakaiba ang eksaktong talahanayan sa bawat organisasyon. Ang mahalaga ay dapat madaling basahin ng mga stakeholder mula sa product, seguridad, finance, at engineering ang mga panuntunan sa pag-route—hindi nakabaon sa isang conditional statement.
Ano ang ibig sabihin nito para sa mga bumubuo ng karera
Ang pinakamalalakas na kandidato para sa gawaing ito ay magsasama ng ilang uri ng kahusayan. Sapat ang kanilang pag-unawa sa machine learning upang makapag-isip tungkol sa kakayahan at paghirap ng performance; sapat sa systems engineering upang mapamahalaan ang latency, mga retry, rate limit, at mga mode ng pagkabigo; sapat sa finance upang ma-modelo ang kabuuang gastos; at sapat sa procurement at governance upang masuri ang mga pangako at limitasyon ng provider.
Magiging komportable rin silang sumulat ng mga rekord ng pagpapasya. Ipinapaliwanag ng isang kapaki-pakinabang na rekord kung bakit pinili ang isang ruta, anong ebidensya ang sumusuporta rito, anong mga panganib ang nananatili, at anong pangyayari ang dapat magpasimula ng muling pagsusuri. Mas mahalaga ito kaysa pagsasaulo ng mga pinakabagong pangalan ng modelo dahil patuloy na magbabago ang mga pangalan at presyo ng modelo.
Maaaring maipakita ng isang maikling portfolio project ang kasanayang ito nang hindi nangangailangan ng malaking production system. Pumili ng isang workload, gumawa ng redacted na evaluation set, ikonekta ang tatlong model provider o lokal na modelo sa likod ng isang karaniwang interface, at ihambing ang kalidad, bisa ng schema, mga percentile ng latency, mga rate ng pagkabigo, at tinatayang buwanang gastos sa ilang dami ng paggamit. Magdagdag ng mga panuntunan sa policy para sa sensitibong input at fallback path. Ilathala ang pamamaraan ng pagsubok at mga limitasyon nito.
Maging tiyak tungkol sa pinatutunayan ng project. Hindi nito pinatutunayang may isang modelong pinakamahusay sa lahat ng pagkakataon. Pinatutunayan nitong kaya mong gawing nasusukat na operating policy ang isang malabo at hindi tiyak na problema sa pagpili ng modelo.
Ang hudyat para sa karera
Nagiging estratehikong mahalaga ang model routing dahil ang intelligence ay hindi na isang iisang nakapirming dependency. Isa itong portfolio ng mga serbisyo na may magkakaibang trade-off at nagbabagong ekonomiya. Maaaring mabawasan ng mga team na itinuturing ang portfolio na iyon bilang mapagpapalit na imprastraktura ang mga gastos, ngunit maaari rin silang lumikha ng mga nakatagong problema sa kalidad, pagsunod sa mga patakaran, at reliability. Maaaring mapalampas naman ng mga team na itinuturing itong permanenteng commitment sa iisang modelo ang mas magagandang opsyon.
Ang umuusbong na disiplina ay nasa pagitan ng dalawang sukdulang ito: sapat na abstrakto upang makapagpalit ng provider, sapat na partikular upang mapanatili ang kalidad ng gawain, at sapat na nakabatay sa ebidensya upang mapangatwiranan ang pagpili. Iyan ang oportunidad sa karera sa model routing—hindi ang minsanang pagpili ng API, kundi ang pagbuo ng decision system na patuloy na gumagawa ng mabubuting pagpili.
Si Tom Whitfield ang responsableng human editor ng AI Career Brief, na tumatalakay sa mga kasanayan, tungkulin, at matatalinong hakbang para sa pagtatrabaho sa panahon ng AI.
