07 - Model Selection és Routing¶

Egy production AI rendszernek nem szabad abból kiindulnia, hogy minden request a legerősebb elérhető modellhez tartozik. A különböző taskok eltérő quality, latency, cost, context size, multimodality, structured output és tool-use igénnyel rendelkeznek.

A model selection ezért architekturális döntés, nem csak egy config mező.

Miért fontos a routing?¶

Képzelj el egy alkalmazást, amely végez:

language detectiont,
document classificationt,
support-answer generationt,
nehéz debuggingot,
image understandinget,
embedding generálást.

Minden taskot ugyanarra a drága reasoning modellre küldeni működhet, de gyakran pazarló és lassabb a szükségesnél.

Jobb mentális modell:

Request
   |
Task classification
   |
   +--> simple extraction ------> small/fast model
   +--> complex reasoning ------> strong reasoning model
   +--> image task -------------> multimodal model
   +--> semantic indexing ------> embedding model

Fő kiválasztási szempontok¶

Capability¶

Meg tudja oldani a modell megbízhatóan a feladatot?

Példák:

complex code reasoning,
long-form synthesis,
extraction,
classification,
image understanding,
tool calling.

Ne optimalizáld az árat addig, amíg nincs meg a minimálisan elfogadható quality szint.

Latency¶

Egy kiváló, de 20 másodpercig válaszoló modell alkalmatlan lehet autocomplete-ra vagy interaktív UI-ra.

Különböző workloadok különböző latencyt tolerálnak:

Autocomplete        -> nagyon alacsony latency
Chat assistant      -> közepes latency
Background analysis -> magasabb latency is elfogadható

Cost¶

A costot nem csak a model price befolyásolja:

input tokenek,
output tokenek,
reasoning effort,
request volume,
retryk,
context size.

Egy tokenenként kétszer drágább modell összességében olcsóbb is lehet, ha egy callból megoldja azt, amihez az olcsóbb modell három sikertelen próbálkozást igényel.

Context size¶

Bizonyos taskok nagy dokumentumot vagy repository contextet igényelnek. Másoknak néhány száz token is elég.

A nagy context window csak akkor érték, ha a task ténylegesen használja.

Structured output és tool support¶

Ha az alkalmazás schema-constrained outputra vagy tool callokra épít, ezek támogatásának minősége ugyanolyan fontos, mint a natural-language quality.

Multimodality¶

Image, audio, screenshot vagy dokumentum input esetén olyan modell kellhet, amely közvetlenül fogadja ezeket a modalityket.

Static model selection¶

A legegyszerűbb stratégia fix modellt rendelni minden application feature-höz.

invoice extraction -> Model A
support chat       -> Model B
code analysis      -> Model C

Ez könnyen érthető és debugolható, ezért gyakran jó kiindulópont.

Dynamic routing¶

Fejlettebb rendszer requestenként választhat modellt.

Példa:

User request
   |
Router
   |
   +--> simple FAQ ----------> fast model
   +--> account investigation -> stronger model + tools
   +--> difficult debugging --> reasoning model

Routing input lehet például:

task type,
input length,
user tier,
required latency,
korábbi modell confidence-e,
risk level.

Escalation pattern¶

Hasznos minta a cheap-first + escalation.

Fast model
   |
Can solve confidently?
   |
  yes -> return
  no  -> stronger model

Ez csak akkor működik jól, ha az escalation megbízhatóan felismerhető. Önmagában az, hogy megkérdezzük a modellt, mennyire confident, általában kevés. Használj mérhető jeleket, ahol lehet:

schema failure,
missing required evidence,
deterministic validation failure,
low retrieval quality,
evaluation-backed classifier.

Fallbackok¶

A model routing resilience-t is javíthat.

Primary model unavailable
        |
Fallback compatible model

A fallbackot tesztelni kell. Két modell eltérhet például:

tool-call formatban,
output qualityben,
context limitben,
instruction followingban,
latencyben.

Evaluation nélkül ne feltételezz drop-in compatibilityt.

Példa: support platform¶

Lehetséges architecture:

Incoming request
      |
Intent classifier
      |
      +--> simple FAQ -> small model + retrieval
      |
      +--> refund request -> strong model + account tools
      |
      +--> legal escalation -> deterministic workflow + human

Figyeld meg, hogy bizonyos route-oknak egyáltalán nem kell LLM-hez vezetniük.

Mikor ne route-olj?¶

A routing komplexitást ad hozzá:

több configuration,
több test,
model-specific behaviour,
nehezebb observability,
több failure mode.

Kis rendszerben egy jól kiválasztott modell jobb lehet, mint a túl korán felépített routing infrastruktúra.

Observability¶

Legalább ezeket érdemes rögzíteni:

selected model,
selection reason,
token usage,
latency,
retryk,
validation failure-ök,
outcome/evaluation score, ahol elérhető.

Ezek nélkül a routing optimization találgatás lesz.

Developer takeaway¶

A modellt a workload alapján válaszd, ne presztízs alapján.

Kezdj egyszerűen, mérd a quality/latency/cost értékeket, és akkor vezess be routingot, amikor adatok mutatják, hogy különböző task classok különböző modellekből profitálnak.