Kihagyás

Hogyan építsünk modell-routert a harnessbe (LangChain, 2026-10-01)

Szerzők: Sydney Runkle és Eugene Yurtsev (LangChain) Megjelenés: 2026-10-01 Eredeti cím: „How to Build a Model Router in the Harness” Forrás: https://www.langchain.com/blog/how-to-build-a-model-router-in-the-harness Archív példány: https://archive.codenewsletter.ai/2105704739585565066 Kód: https://github.com/langchain-ai/open-swe (agent/middleware/model_selection.py) Típus: technikai blog-bejegyzés, nem peer-reviewed tanulmány Terjedelem: 2 297 szó

Bevezetés és a központi állítás

A frontier modellek drágák, és ez agent-méretben már nem fenntartható. A cikk állítása szerint viszont a legtöbb feladat nem igényel frontier-szintű intelligenciát. A szerzők a LangChain belső kódoló agentjén, az Open SWE-n mérték meg, mennyit ér az, ha a modellválasztás nem globális, hanem feladatonkénti: a medián költség 64 százalékkal csökkent, mérhető minőségromlás nélkül.

A második, elvi állítás ennél is fontosabb: a routing döntés helye a harness, nem egy általános gateway. Az érvelés egyszerű. A jó modellválasztáshoz ugyanaz a domain- és feladatkontextus kell, amit a harness már úgyis összeállít (a prompt, az eszközök, a szakterületi tudás). Egy generic gateway ezzel nem rendelkezik, ezért ott a döntés szükségképpen vak.

A legfontosabb pontok:

  • Modell-harness-feladat illeszkedés: a jó agent nem a legerősebb modellt használja mindenhol, hanem feladatonként a megfelelőt. A szerzők ezt nevezik model-harness-task fit-nek
  • A medián költség 64 százalékkal csökkent (0,94 dollár a 2,61 dollárral szemben), a minőség mérhetően nem változott
  • Az átlag 42 százalékkal, a p90 37 százalékkal esett, tehát a megtakarítás nem néhány olcsó kiugró eset eredménye
  • A kérések 90 százaléka nem igényelte a legerősebb modellt: 56 százalék a középső, 34 százalék a gyors, és csak 10 százalék a csúcs-szintre ment
  • A szintek között 30-szoros költségszórás van: a medián szál 0,097 dollár a gyors, 1,50 dollár a középső és 2,88 dollár a csúcs-szinten
  • A router a szál első emberi üzenetén fut, egyszer dönt, és a modellt az egész szálra rögzíti
  • A klasszifikátor a Jev nevű döntési modellre került át, amitől a besorolás közel 50-szer gyorsabb lett
  • Az ellenkező irányú kontroll megbukott: amikor a felét kizárólag a gyors modellre irányították, a mérnökök egy nap alatt jelezték a minőségromlást, és a tesztet leállították

Összegzés

A cikk egy négylépéses recept, és a sorrend a lényeg része. Először meg kell érteni a feladatokat a saját trace-ekből, mert enélkül a szintek találomra születnek. Másodszor meg kell érteni a modelleket a költség-intelligencia görbén, hogy a szintek valós alternatívák legyenek. Harmadszor a routert a harnessbe kell építeni, mert a döntéshez szükséges kontextus ott van. Negyedszer mérni kell a kimenetet, mert a router értéke csak akkor valódi, ha a minőség nem romlik.

A cikk legerősebb része nem a megtakarítás, hanem a kudarc dokumentálása. A szerzők lefuttatták az ellenkező irányú kísérletet is (mi történik, ha minden a gyors modellre megy), és egy nap alatt leállították, mert a mérnökök azonnal jelezték, hogy a kimenet minősége tönkreteszi a munkájukat. Ez a kontroll nélkül hiányzott volna, és a „64 százalék olcsóbb” eredmény félrevezető lenne.

A harmadik tanulság a mérés kétarcúsága. Az offline eval a biztonságos út, de a kódoló agentnél nem működik jól: a PR minőségét és review-elhetőségét nehéz offline pontozni. Az élő A/B teszt valósághű, de a felhasználókat egy esetleg nem optimális routernek teszi ki. A szerzők ezért mindkettőt használták, és két jelzést követtek: a mergelt PR-ok arányát (erős jel) és a felhasználói visszajelzést (ritka, de ott derültek ki a routing-hibák).

A negyedik tanulság, hogy a router a feladathalmazhoz van kötve, nem általános. A szerzők kimondják: a kritériumok az Open SWE feladataira íródtak, ezért a router „mélyen csatolt” ehhez a feladathalmazhoz. Egy másik agent más kritériumokat igényel. Ez nem hiba, hanem a design következménye: pontosan ezért nem jó helye egy generic gateway.

1. lépés: a feladatok megértése

A kiindulás nem a modellek, hanem a saját forgalom. A szerzők az Open SWE thread-szintű adatait húzták ki a LangSmith trace-ekből, és egy hét interaktív szálát címkézték fel LLM-klasszifikátorral.

A megoszlás tanulságos: az új funkciók 22 százalékot, a hibajavítások 17 százalékot, a teszt- és no-op futások 16 százalékot tettek ki. Vagyis a kódváltoztatás dominált, de mellette jelentős volt az olyan forgalom, ami egyáltalán nem igényel komoly modellt.

A komplexitás mérésére két jelzést használtak, és mindkettő hiányos önmagában. A költség viszonylag közvetlenül követi a komplexitást, mert a nagyobb feladat több tokent eszik. Az invokációk száma árnyaltabb: magas érték jelenthet nehezebb feladatot, de jelentheti azt is, hogy a modellnek utólagos körökre volt szüksége. A feature-felderítéssel kapcsolatos szálak hosszabbak és drágábbak voltak, a tesztelési és kiadási folyamatok rövidek és olcsók.

A fontos megfigyelés: abban az időben minden szál a legdrágább frontier modellen futott, miközben a komplexitás eloszlása széles volt. Ez adta a tesztelhető hipotézist: a router a kezdeti kérésből meg tudja becsülni a feladat típusát és nehézségét, és elküldheti a megfelelő szintre.

2. lépés: a modellek megértése

A második lépés a modellválasztás megalapozása. A szerzők az Artificial Analysis Intelligence Index-et használták, ami a modelleket közös feladathalmazon pontozza, és megadja a feladatonkénti költséget, így egyetlen görbére lehet tenni az intelligenciát a költség függvényében. A Pareto-front azoknak a modelleknek a halmaza, amelyek egyszerre a legolcsóbbak és a legokosabbak.

Három szintet választottak, mindegyiket más egyensúllyal:

  • Gyors: GLM-5.3-Flash (xhigh)
  • Kiegyensúlyozott: GPT-5.6 Sol (medium)
  • Teljesítmény: GPT-6 Astra (low)

Két megjegyzésük érdemes figyelemre. A három modell különböző szolgáltatóktól érkezik, és a gyors szint nyílt modell. A GLM-5.3-Flash a Pareto-fronton ül, zárt modellek mellett, amit a szerzők úgy olvasnak: a nyílt modellek átléptek egy küszöböt. A másik, hogy a LangChain modell-agnosztikus, ezért egy jobb modell bevezetése egyetlen sor cseréje a routerben.

3. lépés: a router a harnessben

A router maga három részből áll:

  • Alapprompt: megmondja a klasszifikátornak a feladatát, azt, hogy a legkevésbé drága modellt válassza, ami valószínűleg elvégzi a munkát
  • Szintenkénti kritériumok: rövid, hétköznapi nyelvű leírás arról, milyen munka tartozik az adott szinthez
  • Klasszifikátor modell: elolvassa a kérést, és a kritériumok szerint szintet választ

A kritériumok megírásához két forrást kell összevezetni, és ezt a szerzők külön kiemelik: a saját feladat-elemzésedet és a szolgáltatók saját útmutatóit arról, mire jók a modelljeik. Egy általános benchmark csak kiindulópont.

A döntés a szál első emberi üzenetén születik meg, és a modell az egész szálra rögzül. Ez a legegyszerűbb változat, és a cikk nyíltan elismeri a korlátját: ha egy szál menet közben témát vagy komplexitást vált, ez a design nem kezeli. A megoldást a „mi következik” szekcióba sorolják.

A klasszifikátor technikai evolúciója önmagában is tanulságos. Az első verzió egy strukturált kimenetű LLM volt, a kéréssel promptolva. A mostani verzió a Jev nevű döntési modellen fut, amitől a besorolás közel 50-szer gyorsabb lett. A cikk megjegyzi azt is, hogy ez a döntés azért illik természetesen a harness middleware-rétegébe, mert ott a modellcsere az agent többi részének változtatása nélkül megy.

A szerzők a routingot kontextus-mérnökségnek nevezik, a klasszikus feature engineering analógiájára: el kell dönteni, milyen információt lásson a router, hogy a döntése jó legyen az adott domainben.

4. lépés: az eredmények követése

A router értéke az alacsonyabb költség, de csak akkor, ha a minőség nem esik. Ehhez két dolgot kell eltalálni egyszerre: a választott modellnek el kell tudnia végezni a feladatot, és a lehető legolcsóbbnak kell lennie, ami még képes rá.

Két mérési út létezik, és mindkettőnek megvan a maga ára:

  • Offline eval: a routert fix adathalmazon futtatod, így a verziók biztonságosan és ismételhetően összehasonlíthatók. A buktató az adathalmaz: hasonlítania kell a valós forgalomra, és arra kell pontozni, ami a felhasználóknak fontos.
  • Élő A/B teszt: a szálakat a router és egy egymodelles alapvonal között osztod szét, és egy minden szálon mérhető sikerességi mutatón hasonlítod össze. Az élő forgalom természeténél fogva reprezentatív, cserébe a felhasználók egy esetleg nem optimális routert kapnak.

A szerzők két kimeneti jelzést vezettek be. Az Open SWE mostantól rögzíti minden megnyitott PR-t és azt is, hogy mergelték vagy lezárták, és a szálankénti mergelt PR lett a fő sikerességi metrika. Emellett fel-le hüvelykujj értékelést is bevezettek, hogy a PR-t nem eredményező szálakat is pontozni lehessen; minden értékelés a thread LangSmith trace-ére kerül.

A tapasztalatuk szerint a mergelt PR-ok erősebb jel, a visszajelzés ritka, mert a szálaknak csak kis része kap értékelést. Viszont pontosan a visszajelzés volt az, ahol a routing-hibák felszínre kerültek.

Az A/B teszt eredményei

Az első teszt 973 szálon futott: a fele a routeren ment, a fele mindig a legerősebb modellen.

A minőség nem változott mérhetően. A routerezett szálak 29,2 százaléka végződött mergelt PR-ban, a kontrollnál 27,3 százalék (p = 0,49). A PR-nyitási arány is lapos volt (38,9 a 39,6 százalékkal szemben, p = 0,82).

A költség viszont nagyot esett. A medián routerezett szál 0,94 dollárba került a kontroll 2,61 dollárjával szemben, ez 64 százalék csökkenés. Az átlag 42, a p90 37 százalékkal esett.

A legtöbb kérés nem igényelte a legerősebb modellt. A routerezett szálak 56 százaléka a kiegyensúlyozott, 34 százaléka a gyors, és csak 10 százaléka a teljesítmény-szintre ment. A szintek közötti költség-létra meredek: a medián szál 0,097 dollár a gyors, 1,50 dollár a kiegyensúlyozott és 2,88 dollár a teljesítmény-szinten, ez 30-szoros szórás.

A felhasználói visszajelzés ugyanabba az irányba mutatott. Amikor egy egyszerű kérés a GPT-6 Astrán futott, a mérnökök közvetlenül jelezték a túlköltekezést: „elég drága ezért a kérdésért”, illetve „ezt a kérést nem a teljesítmény-modellre kellett volna irányítani”.

A szerzők maguk is hozzáteszik a helyes önkorrekciót: az eredmény nem meglepő, hiszen a kontroll a legdrágább modelljük volt. A tanulság viszont általános, mert sok agent túlrotálja a minőséget, és közben túlköltekezik, különösen ha a feladathalmaza sokszínű.

A második teszt az ellenkező kontroll volt: a szálak fele a routeren, fele mindig a gyors modellen. Ezt a tesztet egy napon belül leállították, még mielőtt statisztikailag értelmes eredmény születhetett volna. A mérnökök azonnal jelezték a problémát, és a kimenet alacsony minősége zavarta a munkájukat.

Mi következik

A szerzők ezt a routert proof of conceptnek nevezik, amely alapot ad egy optimálisabb routerhez:

  • Benchmarkolás DeepSWE-n vagy más kódolási benchmarkon, hogy a routing döntéseket kontrollált alapvonalon lehessen értékelni, ne csak éles A/B teszten
  • Subagentek modellválasztása. Jelenleg a subagentek a routertől függetlenül választanak modellt; a routing kiterjesztése rájuk, különösen a hosszan futó feladatokon, tovább csökkentheti a költséget
  • Menet közbeni újrairányítás. Ha egy új üzenet eléggé különbözik a korábbiaktól (mondjuk egy kérdés hibajavítássá alakul), a modellcsere megérheti. Az ára a prompt cache: a modellváltás eldobja, és az új modell teljes áron olvassa újra a szálat. Aszinkron agenteknél ez gyakran elhanyagolható, mert a cache a humán körök között úgyis lejár, ha rövid a TTL
  • A kritériumok finomítása több jelzéssel, például a trace-ekből kinyert felhasználói hangulattal: azok a szálak, ahol a felhasználó frusztrált, jelezhetik, hogy erősebb modell kellett volna

A szerzők kezdő receptje

A cikk záró receptje négy pontban, a szerzők megfogalmazása szerint:

  1. A feladatok megértése. A trace-ek tartalmazzák a valódi rekordot arról, mit kérnek az agenttől; a LangSmith Insights segít megtalálni a mintázatokat, hogy a szintek kiválasztása előtt látható legyen a feladat-mix
  2. A modellek megértése. Néhány modell kiválasztása a költség-intelligencia görbén, modern benchmarkok alapján
  3. A router beépítése a harnessbe. A routing kezelése kontextus-mérnökségként: annak eldöntése, milyen információt lásson a router, hogy a döntés jó legyen a saját domainben
  4. A feladat kimenetének követése. A sikeresség mérése a routing bevezetése előtt: evalek, online értékelők vagy felhasználói visszajelzés a trace-eken. Ha az eval-adathalmaz építése túl drága, élő A/B teszt is működik

A szerzők hozzáteszik: a feladathoz illő modell folyamatosan változik, ahogy új modellek, köztük nyílt súlyúak is, a frontra kerülnek. Mivel a LangChain modell-agnosztikus, ezeknek a nyereségeknek a begyűjtése egy szint cseréje, nem az agent újraépítése.

A gyakorlati fogódzó, amit kínálnak: egy újonnan kiadott model routing middleware, aminek megadod az alappromptot, a modell-szinteket és a kritériumokat, ő pedig minden szál elején választ modellt.

Forrás

Kapcsolódó külső források

  • Open SWE, a nyílt forráskódú kódoló agent, a mérés tárgya: https://github.com/langchain-ai/open-swe
  • A router implementációja: agent/middleware/model_selection.py az Open SWE repóban
  • LangSmith, trace-logolás és observability (nem követeli meg a LangChain-t)
  • LangSmith Custom Apps, a saját trace-elemző felület, amit a feladat-felméréshez és az eredmény-követéshez használtak
  • LangSmith Insights, LLM-alapú csoportosítás a trace-eken
  • Artificial Analysis Intelligence Index, a költség-intelligencia görbe adatforrása
  • Jev (TypeSafe AI), a klasszifikátort futtató döntési modell; a LangChain külön posztot szentelt neki („Building a Harness with Jev”)
  • GPT-5.6 Sol, GPT-6 Astra, GLM-5.3-Flash, a három választott modell
  • DeepSWE, a tervezett következő benchmark
  • Anthropic modellválasztási útmutatója, amit a cikk a „kevesebb is elég lehet” állítás alátámasztására idéz

Kapcsolódó belső források

  • Laya és a Jev-vita (2026-09-18): ugyanaz a Jev, a másik oldalról. A Laya szerzője szerint a TypeSafe a 2025-ös munkáját vezette be újként, és a Jev-számok harmadik féltől származnak. Itt a Jev pozitív szerepben jelenik meg: a klasszifikátor futtatója, közel 50-szeres gyorsítással. A két cikk együtt adja a Jev teljes képét
  • Hamel Husain: Your AI Product Needs Evals (2026-07-14): a háromszintű eval-rendszer, az offline eval és az élő A/B teszt trade-offja, valamint a trace-ek mint a valóság rekordja. A LangChain cikk ugyanezt a metodológiát alkalmazza egy konkrét döntésre
  • 5 design pattern for long-horizon agent harness (Google Cloud Tech, 2026-08-20): a harness-réteg mint beavatkozási pont; a stable prefix és a cache-tudatos tervezés közvetlenül kapcsolódik a menet közbeni újrairányítás cache-költségéhez
  • SoL-Pi (arXiv:2609.20519, 2026-09-17): a harness-réteg optimalizálása 44,7-49 százalékos token-csökkentéssel és körülbelül 33 százalékos költségmegtakarítással. Ugyanaz a cél (alacsonyabb költség azonos minőség mellett), más mechanizmus (kontextus-tömörítés és tool-fúzió, nem modellválasztás)
  • Claude Code context engineering: a kontextus-összeállítás mint a harness feladata, ami a routing döntés alapját adja

Hogyan kapcsolódik a saját rendszerünkhöz?

  1. A cikk a saját modell-routing gyakorlatunk elméleti megalapozása. A model-routing skill jelenleg kézi szabályokat sorol fel (vision feladatra MiniMax-M3, bizalmas adatra lokális modell, alapértelmezett DeepSeek-v4.1-flash). A cikk ugyanazt a logikát formalizálja, és hozzáadja, ami hiányzik: a szintek kritériumait a saját feladat-elemzésből és a szolgáltatói útmutatókból kell megírni, nem általános benchmarkból
  2. A „routing a harnessben, nem gatewayben” elv közvetlenül érvényes ránk. A Hermes harness, ezért a modellválasztás a harness kontextusára épülhet (a skill-tár, a memória, a feladat domainje). Ez megerősíti, hogy a modell-pinninget a cron jobokban és a skill-szintű routingot nem érdemes egy külső proxyra bízni
  3. A kritériumok feladathalmaz-specifikusak, nem általánosak. Ez a figyelmeztetés a saját rendszerünkre is áll: a podcast-feldolgozás (hosszú szöveg, egyetlen nagy írás) és a kódolási feladat (iteratív, eszközhasználat) más-más szint-térképet igényel. Egyetlen globális routing-szabály nem lesz jó mindkettőre
  4. A prompt cache költsége a menet közbeni modellváltásnál. Ez a mi kontextusunkban is él: a hosszú session-ök prefix-cache-e érték, ezért a modellváltás nem ingyenes. A cikk megoldása (csak akkor váltani, ha a cache úgyis lejárna) közvetlenül átvehető
  5. Az A/B teszt két jelzése adaptálható. A „mergelt PR” analógja nálunk a feldolgozott summary minőségi kapuja (auto-review score, output-integrity gate), a „felhasználói hüvelykujj” analógja pedig a Henky-visszajelzés. A cikk tanulsága szerint az utóbbi ritka, de pont az hozza felszínre a routing-hibákat, ezért érdemes megtartani
  6. A subagentek modellválasztása nálunk is nyitott kérdés. A cikk ezt a jövő munkájaként jelöli; nálunk a delegate_task jelenleg a szülő modelljét örökli, hacsak nincs pinnelve. A cikk érve (a hosszan futó subagenteknél nagy a megtakarítás) közvetlenül vizsgálandó
  7. A benchmark-infláció óvatossága. A cikk a Pareto-frontot az Artificial Analysis Intelligence Indexből veszi, miközben a korábbi FTF-epizódok (Seth) figyelmeztetnek, hogy a nyilvános benchmarkokra mindenki optimalizál. A helyes olvasat: a benchmark kiindulópont a szintek kiválasztásához, a döntés viszont a saját forgalmon mért eredmény legyen
Vissza a tetejére