Hvad betyder Model routing?
Model routing fordeler opgaver mellem flere mulige modeller. En enkel opgave kan sendes til en mindre model, mens en anden kræver en model med andre egenskaber. Valget kan bygge på faste regler, en klassifikator eller en lært routingmekanisme.
Formålet kan være at balancere kvalitet, pris og svartid, men routing kan også håndhæve rammer som tilladt leverandør eller dataplacering. Disse rammer skal være reelle systemregler; de må ikke alene bero på en models vurdering af, hvad den selv må gøre.
Routing sker typisk før et modelkald. En cascade vurderer derimod et tidligere resultat og kan derefter sende opgaven videre. De to tilgange kan kombineres, men deres ekstra arbejde og fejlmuligheder skal med i vurderingen.
Lad bindende krav komme før optimering
Definér først, hvilke modeller der overhovedet er tilladte for opgaven. Inputformat, databehandling, kontekstbehov og værktøjsfunktioner kan begrænse valget. Derefter kan en router optimere inden for de godkendte muligheder.
En fallback må ikke omgå disse krav, blot fordi den foretrukne model er utilgængelig. Hvis ingen tilladt løsning kan gennemføre opgaven, skal systemet have en tydelig fejl- eller overdragelsesvej.
Mål routeren og hele resultatet
En router kan vælge forkert, selv om hver model fungerer godt på de opgaver, den er egnet til. Evaluér derfor både valgene og den samlede kvalitet på et fast, repræsentativt opgavesæt.
Medregn routerens egen tid og forbrug. Dokumentér regler, modelversioner og faktiske valg, så fejl kan forklares. En ændring af en model kan gøre en tidligere routingregel mindre hensigtsmæssig og kræver ny vurdering.
Et eksempel fra praksis
Forestil jer et team, der behandler produktdata. En fast regel sender simple feltnormaliseringer til en afgrænset løsning, mens vanskelige beskrivelser går til en model, der klarer opgaven bedre i testen. Begge veje bruger samme efterfølgende validering.
Piloten sammenligner routing med én fast model og tæller godkendte resultater samt samlet forbrug. Hvis routeren systematisk undervurderer opgaver med manglende oplysninger, ændres kriterierne. Besparelsen beskrives først, når den er målt for det konkrete datagrundlag.
Typiske faldgruber
- En billigere model kan blive valgt til opgaver, den ikke kan løse tilstrækkeligt.
- Fallback kan utilsigtet sende data til en ikke-godkendt tjeneste.
- Routerens eget arbejde og fejl kan blive udeladt af pris- og kvalitetsmålingen.
Det skal I afklare
- Hvilke bindende krav begrænser de tilladte modeller for hver opgavetype?
- Hvordan måles forkerte routingvalg og efterfølgende fejl?
- Er hele flowets pris, svartid og godkendte resultater sammenlignet med en enkel reference?
Spørgsmål og svar
Skal routing bruge AI?
Nej. Faste regler kan være et godt udgangspunkt, især når opgavetyper og krav er tydelige. En lært router er et muligt senere valg, som kræver sin egen evaluering.
Giver routing altid lavere omkostninger?
Nej. Ekstra klassifikation, fejl og genforsøg kan opveje gevinsten. Vurder den samlede pris pr. brugbart resultat under relevante kvalitetskrav.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- RouteLLM: Learning to Route LLMs with Preference Data ↗Forskningsmetoder til routing mellem modeller.
- FrugalGPT ↗Forskning i at kombinere modelvalg, kvalitet og omkostninger.