Az egyetlen modell csapdája
Minden nagy MI-szolgáltató azt szeretné, ha elhinné, hogy zászlóshajó modellje a helyes válasz bármely kérdésre. Ez a hit neki üzletileg kényelmes, Önnek műszakilag hamis.
Egy modell, amely ragyog a hosszú környezetű jogi következtetésben, nem a megfelelő tízszavas képaláírás előállítására. Egy csúcsminőségű látással bíró modell túlméretezett — és valószínűleg túl drága — egy kötegelt feladathoz, amely szerkezetes JSON-t formáz át. Egy modell, amelynek ára áteresztőképességre van hangolva, a lehető legrosszabb választás lehet, amikor két másodperc alatt kell válasz.
Ha egyetlen modellre épít, nem a legjobb eszközt választja. A legjobb elérhető eszközt választja egy mesterséges megkötésen belül. Idővel ez a megkötés halmozódik: túlfizet az egyszerű feladatokért, alulteljesít az összetetteknél, és amikor annál a szolgáltatónál kiesés vagy áremelés van, az egész terméke megáll.
Képességek, nem nevek
A hasznos elvonatkoztatás nem az, hogy „melyik modell", hanem hogy „milyen képességekre van szüksége ennek a kérésnek". Ennek a kérdésnek pontos válasza van.
Egy csatolt képernyőképpel érkező beszélgetési üzenetnek látásra van szüksége. Egy külső API-t hívó munkafolyamat-lépésnek eszközökre. Egy kódasszisztensnek, amely a saját kimenetét ellenőrzi, kódfuttatásra. Egy éjszakai összefoglaló csővezeték, amelynek nem kell gyorsnak lennie, használhat kötegelt árazást; egy terméken belüli asszisztens, amelyre valaki vár, nem.
Ha előbb sorolja fel a képességkövetelményeket, a modellválasztás szűrési és rendezési feladattá válik. Adott követelt készlettel — mondjuk szöveg, látás és szerkezetes kimenet — megtalálja mindazokat a modelleket, amelyek mindhármat támogatják, majd minőség és ár szerint rendezi őket a jelenlegi kéréskörnyezethez. Ez a rendezés kérésről kérésre változhat aszerint, hogy az illető mit csinál, és hogyan áll a forrásaival.
Pontosan ezt teszi a ToRun irányítási csővezetéke. A mód (Beszélgetés, Kód, Kép, Kutatás és mások) képességkészletre képződik le. A készlet leszűri a modellkatalógust. Az ár és minőség szerinti rangsor választja a győztest. Az eredmény az, hogy a DeepSeeket használhatja nagy mennyiségű szerkezetes kinyerésre, a Claude-ot vagy GPT-4 osztályú modelleket árnyalt következtetésre, a Google Geminit hosszú környezetű dokumentummunkára és szakosodott képmodellt generálásra — mindezt ugyanarról a termékfelületről, anélkül hogy elosztó logikát írna.
A tartalék nem kellemes ráadás
A szolgáltatói kiesések nem ritka szélső esetek. Az egész iparágban havonta többször előfordulnak. Ha a terméke egyetlen szolgáltatótól függ, és annak API-ja romlik, a terméke romlik vele.
A tartalékos lánc üzemeltetési minimum: ha az elsődleges modell átmeneti hibát ad vissza egy kérésre, a platform megismétli a következő legjobb alkalmas modellen. Ez feltételezi, hogy az irányítási réteg már tudja, mely modellek alkalmasak — és pontosan ezt adja a képesség szerinti irányítás.
A tartaléknak van egy kevésbé nyilvánvaló haszna is: kiszámíthatóan tartja a számlázási viselkedést. Ha az első választás modellje ideiglenesen használati korlát fölött van, a következő alkalmas modellre kanyarodás tartományon belül tartja a költséget anélkül, hogy hibát mutatna.
A gyakorlati következtetés
Amikor MI-platformokat mérlegel, tegyen fel két kérdést: hogyan választ modellt minden kéréshez, és mi történik, ha az a modell nem elérhető vagy túl drágává válik?
Ha bármelyikre az a válasz, hogy „mindig az X modellt veszi", az építészeti szag. A ma elérhető modellek nem a legjobb modellek lesznek fél év múlva. Új szolgáltatók jelennek meg. Az árak elmozdulnak. A képességhatárok változnak. Az az építészet, amely a modellválasztást irányítási feladatnak tekinti — nem beállítási döntésnek —, jobban öregszik, idővel kevesebbe kerül, és nyomás alatt elegánsabban romlik.
Egy modell kiindulópont. Az irányítási réteg az igazi alapzat.