Alapok
Melyik modellt válasszuk? Rossz kérdés.
A modellválasztás mérési kérdés, nem hitkérdés. Hogyan építs úgy, hogy a modell cserélhető legyen, és mikor éri meg egyáltalán váltani.
Az egyik leggyakoribb kérdés, amit kapunk: „ti melyik modellel dolgoztok?”
A válasz, amit senki nem szeret hallani: attól függ, és megmérjük.
Miért nem a modell a döntő
Ha ötven vállalatnál megnézed a stacket, nagyjából ugyanazt találod. Ugyanazokat a frontier modelleket, ugyanazokat a szerkesztőket, ugyanazokat az ágenskereteket. Ha mindenki ugyanahhoz fér hozzá, akkor a hozzáférés nem versenyelőny.
Az előny ott keletkezik, hogy ki tudja beépíteni a saját folyamataiba. Ez a munka java része pedig — a folyamatfelmérés, a kivételkezelés, az integráció, a naplózás — teljesen független attól, melyik modell fut alatta.
Ezért a modellválasztás nálunk nem stratégiai döntés. Mérési döntés.
Hogyan építs cserélhetőre
Nem misztikus. Négy dolog kell hozzá.
1. A modellhívás egy helyen legyen. Egyetlen réteg, ami tudja, melyik szolgáltatóhoz megy a kérés. Az alkalmazás többi része ne tudjon róla.
2. Strukturált be- és kimenet. Sémával definiált JSON, nem szabad szöveg, amit regexszel próbálsz visszafejteni. Így a váltás nem írja át a hívó kódot.
3. Mérési készlet a saját adataitokon. Ez a lényeg. Enélkül a váltás hitkérdés: „azt mondják, jobb”. Ezzel egy fél napos munka: lefuttatod, összehasonlítod.
4. Költség- és késleltetésmérés futásonként. Enélkül nem tudsz dönteni, mert nem tudod, mit nyersz.
Ha ez a négy megvan, egy modellváltás egy konfigurációs sor és egy mérés.
De ha most kezded: válassz egyet
Ez ellentmondásnak tűnik, pedig nem az.
Cégként modellfüggetlenül építünk, mert az architekturális döntés. De ha valaki most tanul bele, annak a legrosszabb stratégia az, hogy mindenből keveset ismer.
Válassz egy ökoszisztémát, és ismerd meg mélyen: az ágenskeretét, az eszközhívását, a kontextuskezelését, a hibáit, a költségmodelljét. Ez a tudás nagyrészt átvihető lesz. Az összehasonlítás képessége viszont csak akkor alakul ki, ha van mihez viszonyítanod — vagyis az elsőt kell nagyon ismerni.
Mikor éri meg váltani
Négy eset:
Ha a mérés jobb, és a költség nem rosszabb. A triviális eset.
Ha ugyanaz a mérés, de olcsóbb. Gyakoribb, mint gondolnád, főleg részfeladatokon. Egy jól körülhatárolt osztályozási lépés nem igényel frontier modellt.
Ha a késleltetés számít. Interaktív folyamatnál a gyorsabb, valamivel gyengébb modell összességében jobb élményt ad.
Ha megfelelőségi ok van. Adatlokáció, feldolgozási megállapodás, szerződéses kikötés. Ez néha felülír minden mérési szempontot.
Amikor nem éri meg váltani: mert megjelent valami új, és izgalmas. A váltásnak is van költsége — újramérés, újrahangolás, új hibamódok.
A vegyes megoldás
A gyakorlatban a legtöbb élő rendszerünkben több modell fut egyszerre. Egy tipikus felosztás:
| Lépés | Mi fut rajta | Miért |
|---|---|---|
| Dokumentum-osztályozás | kisebb, olcsó modell | szűk feladat, sok hívás |
| Adatkinyerés | erősebb modell | itt drága a hiba |
| Séma-validáció | sima kód | nem kell ide modell |
| Végső besorolás | erősebb modell | ítéletet igényel |
| Összefoglaló szöveg | közepes modell | elég jó, olcsóbb |
Ez a felosztás nem elméleti alapon jött ki, hanem mérésből: minden lépésnél megnéztük, mit veszítünk, ha lejjebb megyünk.
Kapcsolódó: token maxing és eval.
Kérdések ehhez a témához
Ha kezdő vagyok, melyik ökoszisztémával kezdjek?
Eggyel, és azzal alaposan. Az első hónapokban a saját tanulási görbéd a szűk keresztmetszet, nem a modell képessége. Amikor egy stacket már mélyen ismersz, a másodikat hetek alatt fel lehet venni.
Megéri kisebb modellt használni részfeladatokra?
Gyakran igen, és ez a legjobban megtérülő optimalizálás. Egy jól körülhatárolt osztályozási lépésnél egy kisebb modell ugyanazt hozza töredék áron — de csak akkor váltsatok, ha a mérési készleten megnéztétek.
Ez nálatok hogy néz ki?
Ha ez a probléma ismerős, kezdjük egy folyamattal. Írjátok meg, melyik részleg viszi el a legtöbb kézi munkaórát — visszaírunk egy konkrét javaslattal.