A modell, ami nem szöveget ír, hanem dönt

Az egyik ügyfelemnél tavaly építettünk egy megoldást, ami a bejövő ügyfélleveleket szétosztotta a megfelelő csapatnak. A feladat egyszerűnek hangzott. Jön egy levél, el kell dönteni, hogy a számlázáshoz vagy a műszaki csapathoz tartozik, és hogy sürgős-e. Két információ, semmi több.

Amit építettünk, az viszont egyáltalán nem volt egyszerű. Elküldtük a levelet egy nagy nyelvi modellnek, megkértük, hogy gondolja végig, döntse el a csapatot, becsülje meg a sürgősséget, és mindezt adja vissza egy jól formázott adatszerkezetben. A modell írt egy fél oldalt, amiből aztán kibogarásztuk azt a két adatot, ami kellett. Néha elrontotta a formátumot, olyankor újra kellett kérdezni. Előfordult az is, hogy magabiztosan rossz csapathoz küldte a levelet, és ezen nem látszott semmi, mert ugyanolyan határozott mondatban közölte, mint a helyes döntéseket.

Működött, csak nagyon drága és nagyon lassú módja volt annak, hogy két apró kérdésre választ kapjunk. Egy egész esszét fizettünk meg azért, hogy a végén egy kategóriát és egy számot használjunk belőle.

Szeptemberben megjelent egy modell, ami pont ezt a helyzetet célozza meg. Jev a neve, a TypeSafe AI nevű cég készítette, és az alapítója az a Diogo Almeida, aki korábban az OpenAI-nál dolgozott azokon a módszereken, amikből később a ChatGPT lett. A cég egy új modellosztályt hirdetett meg System One modellek néven, és a Jev ennek az első darabja.

Mit csinál másképp

A megszokott nyelvi modell úgy működik, hogy szöveget kap és szöveget ír vissza, szóról szóra haladva. Ha adatot akarsz tőle, akkor megkéred, hogy a szöveg formája egy adatszerkezet legyen, és reménykedsz, hogy nem ront el benne semmit. A Jev nem így dolgozik. Kap egy állapotot, vagyis azt az adatot, amiről szó van, és kap hozzá előre definiált kérdéseket. Válaszul nem mondatot ad, hanem magát a döntést, valószínűséggel együtt.

Három fajta kérdést lehet feltenni neki. Az egyik a választás, amikor megadod a lehetséges opciókat, és a modell megmondja, melyik az, mennyire biztos benne, és mennyi esélyt ad a többinek. Van egy pontozás is, amikor egy rendezett skálán kell elhelyeznie valamit. A harmadik fajta az eldöntendő kérdés, amire nem igennel vagy nemmel felel, hanem egy valószínűséggel.

Az előbbi ügyfélszolgálati példánál ez azt jelenti, hogy a kérdés a csapatra vonatkozóan visszaad egy ilyen eredményt. Számlázás kilencvenegy százalék, műszaki hat százalék, egyéb három százalék. A sürgősségre pedig kilencvenhat százalékot. Ezzel a két számmal a saját programod dolgozik tovább, és a döntési szabály a te kezedben marad, nem a modell fogalmazza meg minden egyes alkalommal újra.

Innen jön a legfontosabb különbség. A formátum nem tud elromlani, mert a modell eleve csak a megadott lehetőségek közül választhat. Az a hibafajta, amivel a fejlesztők évek óta küzdenek, vagyis hogy a válasz elvileg adatszerkezet, gyakorlatilag meg egy félig elrontott szöveg, itt nem létezik.

A sebesség nem apróság

A gyártó saját mérése szerint egy ilyen döntés hetven és ötszáz ezredmásodperc között áll elő, szemben a nyelvi modellek több másodperces válaszidejével. Ez negyven és kétszáz közötti szorzót jelent, és a költségnél is hasonló nagyságrendű az eltérés.

Önmagában egy gyorsasági adat nem szokott érdekelni, mert a cégeknél a valódi bottleneck szinte sosem a modell sebessége. Itt viszont az a különbség, hogy a gyorsaság megváltoztatja, milyen feladatokra gondolunk egyáltalán. Ha egy döntés fél másodpercbe és érzékelhetetlen összegbe kerül, akkor olyan helyeken is megéri megkérdezni, ahol eddig fel se merült. Egy beszélgetés közben futó ellenőrzés, egy valós idejű szűrés, egy olyan lépés, ami minden egyes kattintásnál lefut. Ezek a mai árazás mellett egyszerűen nem fértek bele.

Van egy ennél érdekesebb következménye is. Mivel az összes kérdés egyszerre, párhuzamosan fut le ugyanarra az állapotra, nem éri meg spórolni a kérdésekkel. Eddig az volt a bevett módszer, hogy előbb megkérdezzük, milyen ügyről van szó, megvárjuk a választ, és csak utána tesszük fel a rákövetkező kérdést. Itt ehelyett feltehető mind a tíz kérdés egyszerre, és a végén egyszerűen figyelmen kívül hagyjuk azokat a válaszokat, amikre nem volt szükség. A hosszú, egymásra váró láncok eltűnnek.

A bizonytalanság, amit eddig kidobtunk

Ez az a rész, amit a legtöbb cégnél azonnal használni lehetne, és amiről a legkevesebbet beszélnek.

Egy hagyományos nyelvi modell megmondja, hogy a levél a számlázáshoz tartozik, és kész. Ugyanígy hangzik akkor is, amikor teljesen egyértelmű az ügy, és akkor is, amikor alig tudja eldönteni. A bizonytalanság elveszik valahol a válasz megfogalmazása közben, pedig pont az lenne a legértékesebb információ.

A Jev viszont megtartja. Ha a program azt kapja vissza, hogy a besorolás kilencvenhét százalékig biztos, akkor nyugodtan mehet automatikusan. Amikor viszont harmincnyolc százalék jön vissza úgy, hogy egy másik lehetőség harmincöt, akkor a levél emberhez való, mert érdemben nincs eldöntve. A kettő között pedig lehet egy sáv, ahol a rendszer megcsinálja a munkát, de rákérdez, mielőtt véglegesíti.

Amikor arról esik szó, miért maradt kézi egy folyamat, szinte mindig ugyanaz az indok jön elő. Nem az zavarja a cégeket, hogy a gép néha téved, hanem hogy nem látszik, mikor téved. Egy hetven százalékos találati arány önmagában használhatatlan, mert nem tudni, melyik harminc százalék a rossz. Ugyanaz a hetven százalék viszont teljesen más ügy akkor, ha a rendszer előre szól, hogy ezt az ötven esetet biztosra veszi, ezt a húszat pedig nem. Az elsőt gép intézi, a másodikat ember. Innentől nem minőségi kérdés, hanem munkaszervezés.

A küszöböt persze a tét határozza meg. Egy levél mappába rendezése és egy pénzvisszatérítés kiutalása nagyon különböző bátorságot kíván.

Miért lelkesedtek be ennyire az emberek

A megjelenés utáni héten elképesztő mennyiségű dolog készült el vele, és ennek a java nem is üzleti alkalmazás volt. Valaki írt egy böngészőkiegészítőt, ami görgetés közben pontozza a közösségi hírfolyamot és elhomályosítja a gépi maszlagot. Készült olyan is, ami a videók szponzorált szakaszait ugorja át anélkül, hogy bárki előre feltérképezte volna a videót. A készítők maguk Doomot játszattak vele másodpercenként tíz döntéssel, és Wikipédia oldalak között versenyeztették, ahol több száz link közül kellett választania.

A komolyabb felhasználások ugyanabba az irányba mutatnak. Több csapat a drága gondolkodó modellek elé tette be olcsó szűrőként, hogy csak akkor induljon el a nehéz gépezet, amikor tényleg szükség van rá. Mások a saját nyelvi modelljük kimenetét ellenőriztetik vele, vagyis a generatív modell marad kreatív, a Jev meg osztályoz. A kedvencem az az ötlet, hogy beszélgetéseket engednek át rajta, és az eredményt sima adatbázis oszlopként tárolják, így aztán hagyományos lekérdezéssel megkereshető, kinél magas a vásárlási szándék és ki készül felmondani.

A lelkesedésnek szerintem egyszerű oka van. Az elmúlt években szinte minden AI feladatot ugyanabba a formába kényszerítettünk. Üzenetet küldünk a modellnek, az meg szöveget ír vissza, mi pedig kiszedjük belőle, ami kell. Ez akkor is így ment, amikor egy kategória, egy pontszám vagy egy igen-nem valószínűség lett volna az egész igény. Rengeteg éles kód fut ma a világban, ami legenerál egy választ, szétszedi, aztán az egészből egyetlen elágazást hoz. Most kiderült, hogy erre a részre külön eszköz is lehet.

Hol nem ez a jó válasz

Fontos, hogy ez a modell nem helyettesíti a nyelvi modelleket, és nem is akarja. Nem ír szöveget, nem fogalmaz, nem magyaráz, nem kódol és nem gondolkodik végig hosszú problémákat. Amit csinál, az egyetlen dolog, döntést hoz egy körben, megadott lehetőségek közül.

Ebből következik, hogy ha a feladat lényege maga a szöveg, akkor rossz helyen keresgélsz. Ügyfélválasz megfogalmazása, összefoglaló írása, jelentés elkészítése, szerződés elemzése és megmagyarázása. Ezek mind maradnak a nagy modelleknél. A Jev inkább a mögöttük futó apró ítéletekre való, amikből ma egy rendszerben több száz van.

A másik korlát, hogy előre meg kell fogalmazni a kérdést és a lehetséges válaszokat. Ez fegyelmet kíván, és pont ezért hasznos. Ügyfélszolgálati folyamatok átnézésekor rendszeresen az derül ki, hogy maguk a munkatársak sem egyformán sorolják be a bejövő megkereséseket, mert egyes kategóriák jelentése átfedi egymást. Amíg ez így van, a gép sem tud jó munkát végezni, hiszen nem létezik helyes válasz. A tipizált kérdés kikényszeríti, hogy ezt előbb tisztázzátok, és ez a munka akkor is megtérül, ha a végén semmilyen modellt nem használtok.

Óvatosságra int az is, hogy a modell friss. A megbízhatóságáról ma főleg a készítő saját mérései és a közösség első hetének élményei szólnak, független, hosszabb távú tapasztalat még alig van. Egy éles, pénzt mozgató folyamatot nem erre építenék hónapokig tartó saját mérés nélkül.

Mit kezdjen ezzel egy cég most

A gyakorlati haszon szerintem nem abban van, hogy mindenki rohanjon lecserélni valamit. Sokkal inkább abban, hogy érdemes végignézni, hol használtok ma nagy modellt apró ítéletekre. Bejövő levelek szétosztása, hibajegyek rangsorolása, ajánlatkérések előszűrése, dokumentumok besorolása, tartalmak moderálása. Ahol napi több ezer ilyen döntés fut le, ott a költség és a válaszidő is érezhetően változik.

A másik irány az, amit a bizonytalanságnál írtam. Ha van olyan folyamatotok, ami azért maradt kézi, mert az automatizálás túl kockázatosnak tűnt, akkor érdemes újra elővenni. A kérdés ugyanis megváltozik. Eddig azt kellett eldönteni, hogy a gépre bízzátok-e az egészet. Mostantól inkább az, hogy melyik az a rész, amit a gép biztosra vesz, és mekkora az a maradék, ami emberhez kerül.

Az elmúlt két évben a legtöbb helyen ugyanazt láttam. A cégek megvették a legerősebb modellt, ráengedték mindenre, aztán csodálkoztak a számlán és a lassúságon. Ami most kezd kirajzolódni, az egy józanabb felállás, ahol a nehéz gondolkodás marad a drága modellnél, a sok apró döntés pedig olcsó, gyors és mérhető eszközre kerül. Az ilyen szétválasztás nem hangzik izgalmasan, viszont pont ettől lesz egy AI megoldásból olyan rendszer, ami éles üzemben is kibírja a hétköznapokat.