“Watter model moet ons gebruik?” het vroeër na ’n API-vraag geklink. In ’n groeiende aantal organisasies is dit nader aan ’n verkrygings-, prestasie-ingenieurs- en argitektuurvraag.

Daardie verandering volg op ’n eenvoudige ontwikkeling: daar is nou baie modelle, wat deur baie verskaffers aangebied word, met wesenlik verskillende sterkpunte, pryse, latensieprofiele, ontplooiingsopsies en kontraktuele voorwaardes. Stripe se aangekondigde ooreenkoms om OpenRouter oor te neem, is ’n nuttige aanduiding. OpenRouter se enkele API strek oor meer as 400 modelle van meer as 80 verskaffers, met roeteringskriteria wat taakkompleksiteit, prys, spoed, betroubaarheid, latensie, deurset en verskafferspesifieke koste insluit.

Die ontluikende rol is nie noodwendig ’n nuwe postitel nie. Dit kan oor KI-platformingenieurswese, argitektuur, verkryging, afleidingsbedrywighede of produkingenieurswese strek. Maar die verantwoordelikheid daarvan word herkenbaar: besluit watter model watter werk moet hanteer, onder watter beperkings, met watter terugvalopsie en op grond van watter bewyse.

Roetering is ’n beleidsbesluit vermom as infrastruktuur

’n Naïewe roeteerder vra: “Watter model is die goedkoopste?” ’n Nuttige roeteerder vra ’n meer spesifieke vraag: “Wat is die goedkoopste model wat aan die gehalte-, latensie-, betroubaarheids-, privaatheids- en bedryfsvereistes van hierdie versoek voldoen?”

Daardie vereistes verskil per taak. ’n Kliëntediensklassifiseerder het moontlik voorspelbare gestruktureerde uitvoer en lae latensie nodig. ’n Moeilike koderingstaak kan ’n stadiger, meer bekwame model regverdig. ’n Hoëvolume-pyplyn vir opsommings kan ’n kleiner model verkies, veral as die gehalte daarvan ná toetsing voldoende is. ’n Gereguleerde werkvloei kan ’n bepaalde streek, bewaringsbeleid of verskafferooreenkoms vereis, ongeag die tokenprys.

Dit is waarom roetering in argitektuuroorsigte hoort, nie slegs in toepassingskode nie. Die roete bepaal meer as net ’n faktuur. Dit kan dataverblyfplek, blootstelling aan onderbrekings, waarneembaarheid, konsekwentheid van antwoorde, gedrag tydens nutsmiddelgebruik en die hoeveelheid menslike hersiening wat stroomaf benodig word, beïnvloed.

Die vier dissiplines agter ’n ernstige roeteringsfunksie

1. Verkryging: vergelyk die hele diens, nie die opskrif-tokenprys nie

Modelpryse is maklik om verkeerd te vergelyk. Inset- en uitsettokens kan verskillende tariewe hê. Gekaste insette, bondelverwerking, prioriteitsdiens en versoeke met lang konteks kan die berekening verander. ’n Verskaffer se nominale prys sê ook min oor herpogings, tempolimiete, ondersteuning, minimumverpligtinge, uitgaande dataverkeer of die ingenieurskoste van omskakeling.

’n Roeteringseienaar behoort ’n inventaris van modelle en verskaffers by te hou met velde soos:

  • inset-, uitset-, gekaste en bondelpryse;
  • konteks- en uitsetlimiete;
  • gedokumenteerde tempolimiete en waargenome deurset;
  • latensieverspreidings, nie bloot gemiddelde latensie nie;
  • beskikbaarheid en tydverstreekgedrag;
  • datagebruik-, bewarings-, verblyfplek- en kontraktuele voorwaardes;
  • ondersteunde vermoëns, insluitend nutsmiddeloproepe, gestruktureerde uitvoer, visie en stroming;
  • terugval- en migrasieopsies.

Die resultaat is nader aan ’n tegnologiemateriaallys as aan ’n lys modelname. Dit behoort hersien te word wanneer pryse, beleide, modelweergawes of besigheidsvolumes verander.

2. Prestasie-ingenieurswese: meet die taak, nie die ranglys nie

Algemene maatstawwe kan help met oriëntering, maar roeteringsbesluite benodig werkladingspesifieke toetse. ’n Model wat goed presteer op ’n openbare koderingsmaatstaf, is moontlik nie die beste keuse vir ’n organisasie se interne bewaarplekke, naamgewingskonvensies, nutsmiddelskemas of sekuriteitskontroles nie.

Bou ’n verteenwoordigende evaluasiestel uit werklike versoeke, met sensitiewe materiaal verwyder of beheer. Merk die uitkomste wat saak maak: feitelike korrektheid, geldige JSON, suksesvolle nutsmiddelkeuse, sukses van kodetoetse, weieringsgedrag, behoefte aan eskalasie en aanvaarbare styl. Teken dan koste, tyd tot die eerste token, totale latensie, tydverstreekkoers, herpogingskoers en voltooiingslengte aan.

Moenie die resultaat te vroeg tot een telling reduseer nie. ’n Geweegde telling kan ’n ernstige foutmodus verberg. Byvoorbeeld, ’n model met uitstekende gemiddelde gehalte maar gereelde misvormde nutsmiddeloproepe kan ongeskik wees vir ’n geoutomatiseerde werkvloei. ’n Stadiger model kan ekonomies verkieslik wees as sy antwoorde duur menslike hersiening verminder.

Gebruik ’n kampioen-en-uitdaagder-proses: behou ’n tans goedgekeurde roete, toets alternatiewe teen dieselfde korpus en bevorder ’n uitdaagder slegs wanneer dit uitdruklike gehalte- en bedryfsdrempels oorskry. Bewerings wat deur verskaffers gerapporteer word, moet as insette tot ’n toetsplan behandel word, nie as bewys dat ’n model soortgelyk in jou omgewing sal presteer nie.

3. Argitektuur: maak modelkeuse vervangbaar

Roetering word duur wanneer modelspesifieke aannames deur ’n toepassing versprei raak. ’n Veerkragtige ontwerp skei die besigheidstaak van die verskafferoproep.

Definieer ’n interne vermoëskontrak. Dit kan spesifiseer dat ’n “klassifikasie”-bewerking ’n vaste skema, vertroue- of onthoudingsvelde, ’n modelidentifiseerder en ’n spooridentifiseerder terugstuur. ’n “Konsepantwoord”-bewerking kan toonbeperkings, aanhalingsvereistes en ’n maksimum vertragingsbegroting spesifiseer. Verskafferadapters vertaal dan daardie kontrak na individuele API’s.

Hou aansporings, skemas, nutsmiddeldefinisies, veiligheidsreëls en roetebeleide weergawebeheerbaar. Teken aan watter modelsnapshot en verskaffer elke versoek bedien het. Bewaar genoeg inligting om ’n besluit weer voort te bring sonder om sensitiewe gebruikerinligting onnodig te behou.

Ontwerp terugvalopsies doelbewus. ’n Terugvalopsie kan ’n ander verskaffer, ’n kleiner model, ’n werksvloei met ’n tou, of ’n menslike hersieningspad wees. Dit behoort nie stilweg die betekenis van die taak te verander nie. As gestruktureerde uitvoer verpligtend is, moet die terugvalopsie dieselfde kontrak ondersteun of ’n beheerde eskalasie aktiveer.

4. Bestuur: besluit wanneer om nie outomaties te roeteer nie

Sommige versoeke behoort nie na die goedkoopste beskikbare model gestuur te word nie—of na enige eksterne model nie. Roetebeleid benodig uitsluitingsreëls vir vertroulike data, besluite met ’n groot impak, tale wat nie ondersteun word nie, buitengewoon lang konteks, of handelinge wat ’n menslike goedkeuringstap vereis.

Spanne behoort ook te onderskei tussen ’n model wat tegnies beskikbaar is en een wat vir ’n spesifieke gebruik goedgekeur is. Verkrygings- en regsvereistes kan per sake-eenheid verskil. ’n Model kan uitstekend in ’n evaluering wees en steeds onbruikbaar wees vir ’n werksvloei waarvan die bepalings oor datahantering nie by die organisasie pas nie.

’n Praktiese roeteringstabel

’n Aanvangsbeleid kan eenvoudig en eksplisiet wees:

TaakklasPrimêre doelwitMoontlike roeteEskalasie-aanwyser
Hoëvolume-ekstraksieGeldige skema en lae eenheidskosteKlein of middelslagmodel met streng uitvoervalideringSkemamislukking of lae vertroue
Komplekse ontledingGehalte en bewysverwerkingMeer bekwame model met ’n groter vertragingsbegrotingOntbrekende bewyse, onduidelikheid of beleidsvlag
Interaktiewe ondersteuningVinnige waargenome reaksieLae-vertragingsmodel, moontlik gevolg deur verfyningLae vertroue of gebruikersversoek om meer diepte
Sensitiewe werkvloeiGoedgekeurde datahantering en ouditbaarheidKontrakgoedgekeurde verskaffer of beheerde ontplooiingOngemagtigde data, handeling of jurisdiksie

Die presiese tabel sal van organisasie tot organisasie verskil. Die belangrike punt is dat roeteringsreëls leesbaar moet wees vir belanghebbendes in produk, sekuriteit, finansies en ingenieurswese—nie in ’n voorwaardelike stelling begrawe moet wees nie.

Wat dit beteken vir mense wat loopbane bou

Die sterkste kandidate vir hierdie werk sal verskeie soorte vlotheid kombineer. Hulle sal genoeg van masjienleer verstaan om oor vermoë en agteruitgang te redeneer; genoeg stelselingenieurswese om latensie, herpogings, tempolimiete en mislukkingsmodusse te bestuur; genoeg finansies om die totale koste te modelleer; en genoeg van verkryging en bestuur om verskafferverpligtinge en -beperkings te evalueer.

Hulle sal ook gemaklik wees daarmee om besluitrekords te skryf. ’n Nuttige rekord verduidelik waarom ’n roete gekies is, watter bewyse dit ondersteun, watter risiko’s oorbly en watter gebeurtenis ’n herevaluering moet veroorsaak. Dit is waardevoller as om die jongste modelname uit die kop te leer, omdat modelname en pryse voortdurend sal verander.

’n Kompakte portefeuljeprojek kan die vaardigheid demonstreer sonder dat ’n groot produksiestelsel nodig is. Neem een werklading, skep ’n gesuiwerde evaluasiestel, koppel drie modelverskaffers of plaaslike modelle agter ’n gemeenskaplike koppelvlak, en vergelyk gehalte, skemageldigheid, latensiepersentiele, mislukkingskoerse en geraamde maandelikse koste by verskeie volumes. Voeg beleidsreëls vir sensitiewe insette en ’n terugvalpad by. Publiseer die toetsmetodologie en beperkings.

Wees presies oor wat die projek bewys. Dit bewys nie dat een model universeel die beste is nie. Dit bewys dat jy ’n onduidelike modelkeuseprobleem in ’n meetbare bedryfsbeleid kan omskep.

Die loopbaansein

Modelroetering word strategies belangrik omdat intelligensie nie meer ’n enkele vaste afhanklikheid is nie. Dit is ’n portefeulje dienste met verskillende afwegings en veranderende ekonomie. Spanne wat daardie portefeulje as uitruilbare infrastruktuur behandel, kan koste verlaag, maar hulle kan ook verborge gehalte-, nakomings- en betroubaarheidsprobleme skep. Spanne wat dit as ’n permanente verbintenis tot een enkele model behandel, kan beter opsies misloop.

Die ontluikende dissipline lê tussen daardie uiterstes: abstrak genoeg om verskaffers te verander, spesifiek genoeg om taakgehalte te behou, en bewysgedrewe genoeg om die keuse te regverdig. Dit is die loopbaangeleentheid in modelroetering—nie om een keer ’n API te kies nie, maar om die besluitstelsel te bou wat aanhou om goeie keuses te maak.

Tom Whitfield is die verantwoordelike menslike redakteur van AI Career Brief, wat vaardighede, rolle en slim skuiwe dek vir werk in die era van KI.