KI-alapmodell váltása minőségromlás nélkül: Evals, Canary és Rollback

Egy új AI-alapmodell gyakran jobb válaszokat, alacsonyabb költségeket vagy gyorsabb válaszidőket ígér. Egy éles weboldali chatbot esetében a váltás mégsem egy tetszőleges szoftvercsomag cseréje. Már egy új modellverzió is eltérően súlyozhatja az utasításokat, részletesebben fogalmazhatja meg a válaszokat, másként hozhat létre strukturált adatokat, vagy eltérő sorrendben hívhat meg eszközöket. A migráció ezért csak akkor sikeres, ha a chatbot legalább olyan megbízhatóan látja el konkrét feladatait, mint korábban – és ha a csapat problémák esetén perceken belül vissza tud állni a korábbi verzióra.

A szolgáltatók rendszeresen kivezetnek modelleket. A OpenAI dokumentációja a kivezetésekről tartalmazza a leállítási dátumokat és az ajánlott helyettesítő modelleket; az Anthropic pedig a saját modell-életciklusában megkülönbözteti az „Active”, „Legacy”, „Deprecated” és „Retired” státuszokat. Az ilyen határidők adják a migráció apropóját, de nem jelentik a minőség bizonyítékát. Ezt csak egy olyan tesztelési és bevezetési eljárás biztosítja, amely illeszkedik a saját chatbothoz.

Mi változik valójában az alapmodell váltásakor?

Ezt a folyamatot egyértelműen el kell különíteni az embedding modell migrációjától. Az embedding váltásakor a dokumentumokat újra kell vektorizálni, és biztosítani kell a keresési indexek kompatibilitását. Az alapmodell váltásakor a keresési index általában változatlan marad; az a modell változik, amely a rendszerutasításból, a beszélgetésből, a megtalált forrásokból és az eszközök eredményeiből előállítja a választ. Ezért a válaszadási viselkedést, a forráshűséget, a formátumot, az eszközhasználatot, a biztonságot, a késleltetést és a költségeket kell tesztelni.

Még egy általános Shadow Mode teszt a weboldalon való indítás előtt is csak a feladat egy részét oldja meg. A Shadow Traffic ugyanazokkal a bemenetekkel láthat el két modellt anélkül, hogy az új választ kiadná. Az itt leírt alapmodell-váltás továbbmegy: előre meghatároz egy elfogadási mátrixot, a valódi forgalom egy kis részét a jelölthöz irányítja, figyeli a felhasználói és rendszerjelzéseket, és tesztelt visszalépési tervet tart készenlétben.

A teszt előtt: határozzon meg egyértelmű migrációs megállapodást

Az összehasonlítások értéktelenek, ha eközben több dolog is változik. Ezért az első körben tartsa konstansként a rendszer-promptot, a keresési konfigurációt, az eszközsémákat, a hőmérsékletet, a maximális kimeneti hosszat és a biztonsági szabályokat, és dokumentálja az elkerülhetetlen paraméterváltozásokat, például a nem támogatott mintavételi opciókat. Dokumentálja a korábbi modellt bázisként, az új modellt pedig jelöltként. Lehetőség szerint használjon explicit modellverziókat egy változó alias helyett. Egy alias később egy másik pillanatképre mutathat, ami megváltoztatja a feltételezetten reprodukálható összehasonlítást.

A migrációs megállapodás tartalmazza azokat a felhasználói csoportokat és funkciókat is, amelyek egyelőre ki vannak zárva. Egy GYIK chatbot például korán átkerülhet a Canary szakaszba, míg a megrendelések írási hozzáférései, a szerződéses információk vagy a különösen érzékeny ügyfélszolgálati esetek hosszabb ideig a bázismodellen maradnak. Így a kockázatot az üzleti hatás, és nem csak a technikai komplexitás alapján korlátozzuk.

A tesztkészletnek a valós forgalmat kell tükröznie

Egy Golden Set nem tartalmazhat csak tiszta, standard kérdéseket. Gyűjtsön anonimizált vagy szintetikusan reprodukált eseteket a legfontosabb szándékokból (intents): egyértelmű kérdések, kétértelmű megfogalmazások, pontosító kérdések, hiányzó dokumentumok, ellentmondásos források, eszközhibák és olyan bemenetek, amelyeket emberi kezelőnek kell átadni. Ossza fel az eseteket nyelv, eszköz, ügyféltípus és kockázati osztály szerint. Ezáltal látható marad, ha egy jó összpontszám kis, de üzletileg kritikus részcsoportokat takar el.

A hivatalos Anthropic útmutatója a sikerkritériumokról és az Evals tesztekről specifikus, mérhető és az alkalmazási célra szabott kritériumokat, valamint valósághű határeseteket javasol. Az OpenAI útmutatója az Evals tesztekről szintén a megbízható alkalmazások elengedhetetlen részeként írja le a teszteket, különösen a frissítések vagy az új modellek kipróbálása során. Mivel az OpenAI ugyanezen az oldalon bejelenti a korábbi Evals platform kivezetését, a saját Golden Setet hordozható formátumban kell tárolni, és nem szabad egyetlen műszerfalhoz kötni.

Értékelési mátrix egyetlen átlagérték helyett

A következő határértékek példák, nem univerzális előírások. A korábbi éles környezeti teljesítményből és a hiba okozta kárból kiindulva határozza meg őket. A jelölt nem érhet el alacsonyabb tokenárat a forráshűség romlása árán.

Az automatikus ellenőrzések alkalmasak JSON-sémákhoz, kötelező megfogalmazásokhoz, hivatkozási célokhoz, eszköz-argumentumokhoz és determinisztikus üzleti szabályokhoz. A hangnemhez, a teljességhez és a hasznos magyarázatokhoz emellett egyértelmű értékelési rubrikára van szükség; a szakértői szúrópróbák kalibrálják az LLM-alapú értékelőt. Az eredményeket szándékonként és kockázati osztályonként kell tárolni, nem csak egyetlen pontszámként. Egy ilyen készlet alapvető felépítését mutatja be a Válaszminőség Golden Set segítségével.

Konkrét példa: Modellváltás a B2B támogatásban

Tegyük fel, hogy egy B2B szoftverszolgáltató chatbotot üzemeltet termékkérdésekre, fiókkezelésre és a támogatási jegyek előkészítésére. A csapat 240 tesztesetet hoz létre: 120 gyakori tudásalapú kérdést, 40 kétértelmű pontosító kérdést, 30 hiányzó forrással rendelkező esetet, 25 eszközszimulációt és 25 biztonsági vagy átadási esetet. Mindkét modell pontosan ugyanazokat a promptokat, dokumentumtalálatokat és szimulált eszközeredményeket kapja.

A jelölt gyorsabban és olcsóbban válaszolja meg a standard kérdéseket, de öt pontosító kérdésben elveszíti a kapcsolatot az előző üzenettel. Az összpontszám ennek ellenére jobb lenne. A szegmenselemzés azonban egyértelmű minőségromlást mutat. A csapat nem egy tetszőleges kivételt ad hozzá, hanem pontosítja a beszélgetési szabályt, kibővíti a tesztkészletet hasonló esetekkel, és újra teszteli mindkét modellt. Az éles Canary-bevezetés csak azután kezdődik meg, hogy a jelölt teljesíti az összes szigorú feltételt.

Kezdetben a megfelelő új beszélgetések két százalékát rendelik a jelölthöz. A hozzárendelés a beszélgetés indításakor például a Conversation ID hash-éből származik, és a teljes beszélgetésre fennmarad; a magasabb Canary-szintek csak az új beszélgetésekre vonatkoznak. Az írási eszközhívások és a magas kockázatú szándékok egyelőre a bázison maradnak. Egy megfelelően nagy megfigyelési ablak után tíz, 25, 50 és végül 100 százalék következik – de csak akkor, ha minden mérési pont továbbra is zöld. A szinteket és a minimális mintaméreteket előre rögzítik, hogy az időprés később ne hígítsa fel a szabályokat.

Online jelzések, amelyek valóban számítanak

A Canary szakaszban a HTTP-hibák és az átlagos késleltetés nem elegendőek. Figyelje a válasz nélküli arányt, az első válasz utáni megszakítást, az ismételt kérdéseket, a Handoff-arányt, a forráskattintásokat, a sémahibákat és az eszközmegszakításokat a bázis és a jelölt esetében külön-külön. Egy közös nyomkövetés összekapcsolja a modellverziót, a promptverziót, a keresési találatokat és az eszközlépéseket anélkül, hogy felesleges személyes adatokat tárolna. Cikkünk a chatbot megfigyelhetőségéről (observability) részletesen elmagyarázza ezt az ellenőrzési nyomot.

Hasonlítsa össze továbbá a sikeresen megoldott esetenkénti költségeket is, nem csak az egymillió tokenenkénti költséget. Egy olcsóbb modell, amely gyakrabban vált ki visszakérdezést vagy emberi utómunkát, üzemeltetési szempontból drágább lehet. Ezzel szemben a késleltetés kismértékű növekedése elfogadható lehet, ha egy fontos kockázati osztályban bizonyíthatóan pontosabb válaszokat hoz.

A Rollback egy funkció, nem egy dokumentum

A visszalépési utat az első Canary szakasz előtt technikailag tesztelni kell. A modell-ID és a hozzá tartozó paraméterek a verziózott konfigurációhoz vagy egy ellenőrzött Feature Flag-hez tartoznak. Amíg a szolgáltató még támogatja a korábbi verziót, az a Canary során tartalék célpontként elérhető marad; a leállítási dátum előtt egy támogatott tartalék célpontra is szükség van. A meglévő beszélgetéseknek vagy konzisztensen az eredeti modelljükön kell maradniuk, vagy egy kifejezetten tesztelt szabály szerint kell váltaniuk.

Határozzon meg szigorú visszaállítási feltételeket: például egy sémahibát egy írási műveletnél, egy biztonságilag releváns szándék romlását, a hibaarány jelentős ugrását vagy a késleltetési keret túllépését. Ilyen jelzés esetén az átállás automatikusan vagy egy egyértelműen kijelölt ügyelet révén történik. Ezt követően a naplók, a jelölt verziója és az érintett minta megmarad, hogy az ok kielemezhető legyen. Egy előkészített folyamat lényegesen megbízhatóbb, mint egy rögtönzött kódtelepítés. Kiegészítésként egy teljes Incident Response Playbook is segít.

Ellenőrző lista az engedélyezéshez

• Rögzítse a leállítási dátumot, a helyettesítő modellt és az érintett végpontokat a hivatalos szolgáltatói dokumentációból.
• Rögzítse a bázist és a jelöltet változatlan prompt-, keresési és eszköz-konfigurációval.
• Ossza fel a Golden Setet szándék, nyelv és kockázati osztály szerint; egészítse ki határesetekkel és valós hibaképekkel.
• Határozzon meg szigorú mérési pontokat a forráshűségre, a strukturált kimenetekre, az eszközökre, a biztonságra és a Handoffra vonatkozóan.
• Mérje meg a késleltetést, a hibaarányt, a tokeneket és a megoldott esetenkénti költségeket.
• Tartsa stabilan a Canary-hozzárendelést a teljes beszélgetésekre vonatkozóan, és az érzékeny funkciókat kezdetben zárja ki.
• Dokumentálja a szinteket, a minimális mintaméretet, a megfigyelési időtartamot és a megszakítási határokat a bevezetés előtt.
• Tesztelje technikailag a rollback folyamatot, jelölje ki a felelősöket, és tartson elérhetővé egy szolgáltató által támogatott tartalék célpontot.
• A 100 százalék elérése után figyelje tovább a rendszert, és bővítse a Golden Setet az újonnan felfedezett éles esetekkel.

Összegzés: A modell neve csak a kezdet

Az ellenőrzött alapmodell-váltás ötvözi a termékminőséget és az üzemeltetési biztonságot. A hivatalos életciklus-útmutatók adják a határidőt, az Evals tesztek biztosítják az alkalmasság bizonyítékát, a Canary-forgalom korlátozza az ismeretlen hibák hatását, a tesztelt rollback pedig lerövidíti a reakcióidőt. Aki ezt a négy építőkövet ismételhető folyamatként alakítja ki, az kihasználhatja az új modellek előnyeit anélkül, hogy a weboldali chatbotját kísérletté tenné minden felhasználó számára.

Szeretné strukturáltan megtervezni weboldali chatbotjának modellverzióját, minőségi mérési pontjait és bevezetését? A ChatReact segít a tudásbázis, a válaszadási viselkedés és az átadások kialakításában úgy, hogy a változtatások mérhetők és kontrollálhatók maradjanak.