Miért fontosabb a megismételhetőség, mint a demók
A második futtatás az igazság
Az első futtatás tapsot kapott. A modell megtalálta a záradékot, a műszerfal felvillant, a válasz a megfelelő dokumentumra hivatkozott, és a teremben pontosan úgy oldódott a feszültség, ahogy akkor szokott, amikor egy költségvetési tétel védhetőbbé válik. A csapat gondosan próbált. Az adatok elég tiszták voltak, a kérdések ésszerűek, a hálózat viselkedett, a szállító laptopja nem döntött úgy, hogy kis radiátorrá válik, és senki sem kérdezett rá arra az egy szélső esetre, amelyet udvariasan egy későbbi fázisba helyeztek. Jó bemutató volt. A jó bemutatók hasznosak. Lehetőséget mutatnak. Közös tárgyat adnak az embereknek a megbeszéléshez. Láthatóvá tesznek egy elvont képességet.
Aztán jött a második futtatás. Ugyanaz a használati eset, de most a múlt heti adatokkal, másik kezelővel, egy furcsa táblázatot tartalmazó forrásdokumentummal, egy olyan szabályzatfrissítéssel, amely még nem jutott el az utasításhoz, és egy vezetővel, aki azért figyelt, mert az eredmény egy valós döntést befolyásolt. A válasz továbbra is gördülékeny volt. Nem ez volt a probléma. A probléma az volt, hogy senki sem tudta megmondani, hogy ugyanaz a válasz-e ugyanazokból az okokból, vagy egy másik válasz, amely ugyanazt a hangnemet viseli. A bemutató bizonyította, hogy a rendszer képes teljesíteni. Azt nem bizonyította, hogy a szervezet képes megismételni a teljesítményt.
Itt változik meg a komoly MI-munka jellege. Egy bemutató azt kérdezi: meg tudjuk-e csinálni egyszer. Az üzemeltetés azt kérdezi: meg tudjuk-e csinálni újra, meg tudjuk-e magyarázni, miért működött, tudjuk-e, mikor nem működött, és meg tudjuk-e őrizni a bizonyítékot, amikor valaki hat hónappal később rákérdez. Az ismételhetőség nem az innováció ellentéte. Ez az innováció azon része, amely túléli a bérszámfejtéssel, a joggal, a biztonsággal, az ügyfelekkel, a polgárokkal, az ellenőrökkel, a fáradt munkatársakkal és a valós adatok csendes ellenségességével való érintkezést.
A legtöbb MI-üzemeltetési hiba nem filmszerű összeomlásként érkezik. Apró eltérésekként érkeznek, amelyeket senki sem tud reprodukálni. Egy lekérdezési eredmény megváltozik. Egy utasításfrissítés egy esetet javít, egy másikat pedig gyengít. Egy modellfrissítés elmozdítja a döntési határt. Egy forrásadatfolyam eldob egy mezőt. Egy emberi felülbírálatot az egyik rendszerben rögzítenek, a másikban nem. A szervezetnek még mindig van működő rendszere a színházi értelemben. Már nincs olyan rendszere, amely képes ugyanazt a történetet kétszer elmondani.
A bemutató elrejti az unalmas szerződést
A demo megengedheti magának, hogy szelektív legyen. Van története, kezdete, kielégítő kattintása, és általában egy mintaadatkészlete, amelyet úgy fésültek át, mint egy gyereket az iskolai fotózás előtt. Ez nem csalás. Ez kommunikáció. A baj akkor kezdődik, amikor a szervezet összetéveszti a kommunikációt egy működési szerződéssel. A demo nem határozza meg az adatforrás frissességét, a verzióhatárokat, a tartalék útvonalakat, az emberi felülvizsgálati jogokat, a hibákról szóló kommunikációt, az adatmegőrzést, vagy azt a pontos feltételt, amelynek fennállása esetén a rendszernek meg kell tagadnia a választ. Ezek a részletek gyakran épp a képernyőn kívül lapulnak, divatjamúltan néznek ki, és arra várnak, hogy később mindenkit számlázzanak.
A megismételhetőség láthatóvá teszi a szerződést. Felteszi a kérdést, hogy melyik bemenet számít bemenetnek, nem pedig a legközelebbi másolat. Felteszi a kérdést, hogy melyik szabályverzió korlátozta a választ, nem pedig azt, hogy melyik szabályzati oldal tűnt ismerősnek. Felteszi a kérdést, hogy stabil-e a lekérési sorrend, determinisztikus-e a döntetlenek kezelése, verziózottak-e a promptok, megnevezhetők-e a modellparaméterek, rögzítésre kerülnek-e az eszközhívások, visszajátszhatja-e az üzemeltető az esetet, és hogy a felülbírálat megváltoztatja-e a munkafolyamatot, vagy csupán díszíti a naplót. Ezek nem filozófiai kérdések. Ezek a megbízható munka mögött húzódó vezetékek.
A nehéz rész az, hogy a megismételhetőség eleinte lassúbbnak tűnik. Egy csapat, amely egy demót hajszol, a leggyorsabb úton haladhat át a kerten. Egy csapat, amely megismételhetőséget épít, kénytelen járólapokat lerakni, megjelölni a kapukat, és eldönteni, kié a szerszámoskamra kulcsa. Ez bürokratikusnak tűnhet azoknak, akik csak az első hetet látják. A harmadik incidensre már irgalmasnak kezd tűnni.
Az AI-rendszerek növelik az irgalom iránti igényt, mert legitim változékonyságot vezetnek be. A nyelvi modellek mintavételezhetők. A lekérés közeli jelölteket hozhat felszínre. Az emberi ítélőképesség eltérhet. A dokumentumok lehetnek kétértelműek. Egy megismételhető rendszer nem tetteti, hogy a világ minden részletében determinisztikus. Megkülönbözteti a megengedett változékonyságot a nem kezelt változékonyságtól. Azt mondja, hogy ez a mező változhat, mert a felhasználó természetes nyelven kérdez, de ez a forráskészlet nem változhat rögzített korpuszmódosítás nélkül. Ez az összefoglaló megfogalmazása eltérhet, de a jogosultsági alap nem. Ez a pontszám elmozdulhat egy modellfrissítés után, de a frissítésnek nyomon követhetőnek kell lennie.
Az azonos bemenet nem egyszerű kifejezés
Az emberek úgy mondják, hogy azonos bemenet, mintha a kifejezés magától értetődő lenne. Valódi rendszerekben ritkán az. A látható felhasználói kérdés csak az egyik része. A tényleges bemenet tartalmazhat lekérdezett dokumentumokat, rejtett utasításokat, rendszerpromptokat, eszköz-sémákat, szabályzati szabályokat, felhasználói szerepkört, időt, területi beállítást, hozzáférési jogokat, gyorsítótárazott rekordokat, funkciókapcsolókat, modellverziót, beágyazási indexet, küszöbérték-beállításokat, és a csendes feltételezést, hogy a tegnapi adattárház-frissítés sikeres volt. Az azonos bemenet meglepően zsúfolt hellyé válhat.
Ezért kezdődik a megismételhetőség a bemenet azonosságával. A rendszernek tudnia kell, hogy mely rekordok voltak elérhetők, mely rekordok kerültek kiválasztásra, a korpusz melyik verziójában történt a keresés, melyik promptsablon lett használva, melyik szabályzatkészlet volt érvényben, melyik modell futott, mely eszközök voltak engedélyezettek, és melyik emberi szerepkör fogadta el a kimenetet. Ha ez soknak hangzik, az azért van, mert a döntési út már eleve nagy volt. Az egyetlen kérdés az, hogy a szervezet beismeri-e.
A megkülönböztetés akkor a legfontosabb, amikor az eredményeket vitatják. Ha egy ügyfél megkérdezi, miért utasították el a kárigényét, egy kórház megkérdezi, miért jelent meg egy kockázati jelzés, egy bank megkérdezi, miért eszkaláltak egy ügyet, vagy egy közintézmény megkérdezi, miért kapott egy állampolgár egy bizonyos utasítást, a szervezet nem válaszolhat pusztán a látható kérdés alapján. Szüksége van a működési környezetre. Enélkül az incidensfelülvizsgálat udvarias szeánsszá válik, amelyben mindenki naplókat, emlékeket és képernyőképeket idéz meg, miközben úgy tesz, mintha ez módszer lenne.
Az input-azonosítás a csapatokat a hamis vádaskodástól is megvédi. Ha egy eredmény azért változott, mert egy forrásdokumentum módosult, az tartalmi probléma. Ha azért, mert az indexet más paraméterekkel építették újra, az lekérdezési probléma. Ha azért, mert a modellt frissítették, az telepítési probléma. Ha azért, mert a kezelő más munkafolyamatot használt, az folyamatprobléma. Mindezt modellviselkedésnek nevezni kényelmes, de téves, és ez erős kombináció a zsúfolt naptárú szervezetekben.
Az ismételhetőség nem jelenti azt, hogy mindent befagyasztunk
Létezik egy lusta ellenvetés, miszerint az ismételhetőség megöli az alkalmazkodást. Nem öli meg. A rejtélyt öli meg. Egy ismételhető művelet keretein belül továbbra is lehet modelleket fejleszteni, promptokat módosítani, szabályokat frissíteni, adatokat tisztítani, forrásokat hozzáadni, küszöbértékeket hangolni és munkafolyamatokat újra tervezni. A különbség az, hogy a változások nevesített eseményekké válnak, nem pedig időjárássá. Amikor az eredmény elmozdul, a csapat meg tudja kérdezni, melyik ellenőrzött változás okozta. Így válik a fejlesztés tanulássá, nem pedig babonává, amelyhez kiadási jegyzetet mellékelnek.
A legjobb üzemeltető csapatok a változásokat határokkal rendelkező kísérletekként kezelik. Megtartják az alap eseteket. Shadow-evaluációkat futtatnak. Összehasonlítják a régi és az új lekérdezési eredményeket. A nagy hatású példákat a bevezetés előtt ellenőrzik. Rögzítik, ki hagyta jóvá a változást, és miért. A visszaállítás feltételeit a bevezetési megbeszélés előtt határozzák meg, nem pedig akkor, amikor a támogatási csatorna már izzik. Ez nem színházi óvatosság. Így tudnak a csapatok gyorsabban haladni, amint az első rendszer számítani kezd.
Van egy erkölcsi dimenzió is, bár jobb, ha egyszerűen fogalmazunk. Ha egy rendszer hatással van a pénzre, a munkára, a gondozásra, a prioritásokra, a jogérvényesítésre vagy a hozzáférésre, az érintettek többet érdemelnek egy előadásnál. Olyan folyamatot érdemelnek, amely képes megmagyarázni önmagát. Az ismételhetőség megteremti ennek a magyarázatnak az előfeltételét. Egy eltűnő produkciót nem lehet auditálni. Csak tapsolni lehet, vagy panaszkodni.
A jó ismételhetőség ezért elválasztja a stabilat a rugalmastól. Stabilak a történések feljegyzései, a verzióazonosítók, az evaluációs készlet, a forrás-származék, a szabály gazdája, a jóváhagyási út és az elutasítási feltételek. Rugalmasak azok a technikák, amelyekkel ezeken a határokon belül fejleszteni lehet. A szakértelem abban rejlik, hogy tudjuk, melyik melyik. Sok szervezet fordítva csinálja. Befagyasztják a folyamatot, mert senki sem bízik a rendszerben, majd rejtett technikai változtatásokat engedélyeznek, mert azokat senki sem látja. Ez redőnyös kormányzás.
Az evaluációs készlet egy működő memória
Minden érett működésnek szüksége van egy kis esethalmazra, amelyet nem hajlandó elfelejteni. Nem egy szintetikus benchmarkra, amelyet azért választottak, mert jól mutat egy jelentésben, hanem egy élő értékelési készletre, amelyet azokból a kínos esetekből állítottak össze, amelyekből a csapat tanult valamit. A dokumentum, amelyben ellentmondanak a dátumok. Az ügyfélkérés, amely két szabályzatot kever. A számla, ahol a táblázatkinyerés majdnem működik. Az orvosi feljegyzés kétértelmű rövidítésekkel. A beszerzési eset, ahol a jogalap fontosabb, mint a kézenfekvő válasz. Ezek az esetek intézményi emlékezetté válnak.
Egy megismételhető rendszer futtatja ezeket az eseteket, amikor valami változik. A cél nem a régi kimenetek imádata. Néha a régi kimenet hibás volt. A cél a mozgás megértése. Javította-e az új verzió az esetet a megfelelő okból. Eltört-e egy törékeny, de fontos viselkedést. Magabiztosabbá vált-e, miközben bizonyítékot veszített. Más forrást választott-e. Ugyanazt a következtetést hozta-e gyengébb úton. Komoly munkában az út számít, mert ugyanaz a válasz rossz okból nem ugyanaz a válasz.
Itt veszítik el az irányítást sok demóvezérelt program. Mérik a felhasználói elégedettséget, a késleltetést és a széles körű pontosságot, de nem tartják közel a fájdalmas eseteket. Az eredmény egy olyan rendszer, amely összességében jobbnak tűnhet, miközben rosszabb lesz a fontos széleken. Az átlagok hasznosak. A széleken érkezik meg a panasz mellékletekkel.
Az értékelési készletnek tartalmaznia kell elutasítási eseteket is. Egy rendszer, amely mindig válaszol, nem segítőkész. Az ilyen rendszer igényes. A megismételhetőség megköveteli, hogy a rendszer következetesen elutasítson, ha hiányoznak a források, nincs felhatalmazás, túl gyenge a bizalom, a felhasználó szerepkörén kívül kérdez, vagy a feladat emberi döntést igényel. Az elutasítási viselkedés a minőség része. Egy tiszta nem gyakran értékesebb, mint egy bájos talán, amely bizonyosságnak öltözött.
Az emberi ítéletnek is megismételhetőnek kell lennie
A megismételhetőség nem csak a gépek tulajdonsága. Az emberi lépéseknek is megismételhetőknek kell lenniük. Ha az egyik értékelő vázlatként kezeli a modell kimenetét, a másik döntésként, a harmadik pedig idegesítő kollégaként, a munkafolyamat el fog sodródni, bármilyen stabil is a modell. A szervezetnek meg kell határoznia, mit jelent az értékelés. Ellenőrzi-e az ember a forrásokat, ellenőrzi-e a szabályzatot, mintavételezi-e a bizonyítékokat, jóváhagyja-e, szerkeszti-e a nyelvezetet, vagy ő a felelős a következtetésért. Minden ige más kötelezettséget teremt.
A kezelőknek olyan felületekre van szükségük, amelyek támogatják ezeket a kötelezettségeket. Ha forrásokat kell ellenőrizniük, a forrásoknak láthatóknak kell lenniük. Ha szabályzatot kell ellenőrizniük, a szabályalapnak a kimenet közelében kell lennie. Ha felül kell bírálniuk, a felülbírálati útnak normálisnak kell lennie, nem pedig egy gomb mögé rejtve, amely árulás bevallásának érződik. Ha később meg kell magyarázniuk egy döntést, a rendszernek meg kell őriznie, amit akkor láttak. Ellenkező esetben az emberi felügyelet díszítő kifejezéssé válik, amelyhez egy alkalmazotti azonosító van csatolva.
A képzés is számít, de nem az a fajta, amely arra tanítja az embereket, hogy csodálják a rendszert. A hasznos képzés megmutatja a határokat. Példákat ad az értékelőknek erős kimenetekre, gyenge kimenetekre, hiányzó bizonyítékokra, elavult forrásokra, prompt injekcióra, szabályzatütközésre és olyan esetekre, amikor a modellt nyugodt szívvel figyelmen kívül kell hagyni. Megmondja az embereknek, mely nézeteltérések várhatók. Megmondja nekik, hogy a jó felülbírálások a kontrollrendszer részét képezik. Ha minden felülbírálást az átvétel kudarcaként kezelnek, az emberek megtanulják, hogy ne vegyék észre a problémákat. Az emberek alkalmazkodóképesek, néha kényelmetlenül annyira.
Száraz vigasz van abban, ha leírjuk az eljárást. Nem azért, mert a dokumentumok varázslatosak. Nem azok, ahogyan azt bárki tudja, aki találkozott már megosztott meghajtóval. A vigasz abból származik, hogy a szervezetet választásra kényszeríti. Egy megismételhető emberi lépés azt mondja: ennek a szerepkörnek ezt az ellenőrzést kell elvégeznie, ezzel a bizonyítékkal, e határidő alatt, és ez történik, ha az ellenőrzés kudarcot vall. Hirtelen a felügyeletnek csontváza lesz.
A véletlenszerűségnek lakcíme kell
Egyes AI-rendszerek tervezetten tartalmaznak véletlenszerűséget. A mintavételezés jobb nyelvi teljesítményt hozhat. A keresés alternatívákat fedezhet fel. Az ügynökök különböző eszközutakat próbálhatnak ki. Az emberi visszajelzés idővel módosíthatja a viselkedést. Egyik sem önmagában rossz. A működési hiba az, ha a véletlenszerűség mindenhol és sehol sincs. Ha a változatosság hasznos, mondjuk meg, hol engedélyezett. Ha kockázatos, korlátozzuk. Ha előfordul, rögzítsünk annyit, amennyiből megérthető. A lakcím nélküli véletlenszerűség az, ahogyan a csapatok egy ködfúvógép hibakeresésénél kötnek ki.
Vannak gyakorlati technikák. Használjunk determinisztikus beállításokat ott, ahol a kimenet következményekkel jár, és a feladat behatárolt. Rögzítsük a verziókat és a sablonokat. Tartsunk korpusz-pillanatképeket. Naplózzuk a keresési jelölteket. Válasszuk külön a kreatív fogalmazást a döntéstámogatástól. A változó generatív szövegnél az állításokat és a forrásokat értékeljük, ne a felszíni megfogalmazást. Az ügynök-alapú munkafolyamatoknál rögzítsük az eszközterveket, az eszközeredményeket és a megtagadási utakat. A modellfrissítéseknél páros összehasonlítást futtassunk, mielőtt a forgalom átáll. Egyik sem szünteti meg a bizonytalanságot. Helyet ad neki az asztalnál, és megakadályozza, hogy a mennyezeti lapok között kóboroljon.
Az ismételhetőség az incidensek nyelvét is megváltoztatja. Ahelyett, hogy azt mondanánk, az AI rossz választ adott, a csapat azt mondhatja, hogy a válasz a 18-as korpusz-pillanatképet, a 12-es szabályzatcsomagot, a 4-es modellverziót és a 31-es promptsablont használta, az A, C és F dokumentumokat kérte le, a B dokumentumot a hozzáférési kör miatt kihagyta, és X szerepkör hozzáférési kör nélkül fogadta el. Ez a mondat kevésbé izgalmas, mint hogy a rendszer elszabadult. Ugyanakkor hasznosabb is, ami a drámai hajlamú emberek számára visszatérő csalódás.
Amikor a rendszer nem tudja előállítani ezt a mondatot, a szervezet nem AI-t üzemeltet. AI-t kísér figyelemmel. Nézi, reagál, vigasztal, és reméli, hogy a következő műszak jobban sikerül. Ez prototípusnál elfogadható lehet. Nem elfogadható olyan munkánál, amelyre az emberek számítanak.
A beszerzés hibája
Az ismételhetőséget meg is kell vásárolni, nem csak megépíteni. Sok beszerzési folyamat még mindig a legjobb bemutatót jutalmazza. Az a rendszer, amelyik gördülékenynek tűnik, gyorsan válaszol, és a vezetőségnek a modernség kellemes érzését adja, pontokat szerez. Az a rendszer, amelyik elmagyarázza az adatmegőrzést, az exportformátumot, a regressziós tesztelést, a determinisztikus keresést, a modellverzió-rögzítést, a szerepkör-alapú felülvizsgálatot és a visszaállítási szabályzatot, kevésbé izgalmasnak hangozhat. Így vásárolnak a szervezetek jövőbeli megbeszéléseket.
Jó vásárlói kérdések nyersek. Vissza tudunk játszani egy esetet. Exportálni tudjuk a bizonyítékok útját. Be tudjuk jelölni vagy meg tudjuk nevezni minden modellt és promptot, amely befolyásol egy választ. Reprodukálható-e a lekérdezés egy index-újraépítés után. Össze tudjuk-e hasonlítani a jelenlegi viselkedést egy frissítés elfogadása előtt rögzített alapszinttel. Elemezhetők-e az emberi felülbírálatok anélkül, hogy büntetnénk a hasznos ítélőképességet. El tudunk-e távozni a rekordjainkkal. El tudjuk-e mondani egy ellenőrnek, hogy mi történt, anélkül, hogy támogatási jegyet nyitnánk és gyertyát gyújtanánk.
Ezek a kérdések nem igényelnek ellenségességet a szállítókkal szemben. Felnőttséget igényelnek. Egy jó szállítónak meg kell tudnia mondani, hogy mely részek ismételhetők, mely részek valószínűségi jellegűek, mely bizonyítékok állnak rendelkezésre, melyek nem, és mit kell a vevőnek saját magának üzemeltetnie. Az a vevő, aki nem tudja feltenni ezeket a kérdéseket, előbb-utóbb élesben fogja megtudni a válaszokat, ahol a válaszok drágábbak, és fejhallgatóval érkeznek.
Ugyanez a beszerzési logika érvényes belsőleg is. A platformcsapatok ne adjanak el demót az üzemeltetésnek az ismételhetőségi szerződés nélkül. Az adatcsapatok ne adjanak át forrásokat származási adatok nélkül. A modellcsapatok ne adjanak ki fejlesztéseket alapszint-összehasonlítás nélkül. Az irányítási csapatok ne hagyják jóvá az elveket a rekordok tesztelése nélkül. Mindenki a bevezetést akarja. Az ismételhetőség annak a fegyelme, hogy törődünk a bevezetés utáni kedddel.
Az ismételhetőség kedvesség a jövőbeli csapatok iránt
Van egy emberi ok az ismételhetőségre való odafigyelésre, amely ritkán jelenik meg stratégiai prezentációkban. Kedvesebb. Kedvesebb az üzemeltetőknek, akiknek nem szabad találgatniuk, miért változott meg egy rendszer. Kedvesebb a mérnököknek, akiknek nem szabad incidenseket rekonstruálniuk irányítópult-morzsákból. Kedvesebb a vezetőknek, akiknek nyomás alatt kell döntéseket hozniuk. Kedvesebb az ügyfeleknek, polgároknak, betegeknek és kollégáknak, akik megérdemlik, hogy ne utólag rögtönzött válaszokat kapjanak. Egy ismételhető rendszer csökkenti az intézményi színlelés mennyiségét, amely a héten való átvészeléshez szükséges.
Az ismételhetőség az őszinteséget is könnyebbé teszi. Amikor a bizonyítékok rendelkezésre állnak, a csapatok meg tudják mondani, hogy a modell itt hibázott, az adat ott volt elavult, a szabályzat kétértelmű volt, az értékelőnek nem volt elegendő kontextusa, vagy a forrás hiányzott. Bizonyíték nélkül minden beismerés kockázatosnak tűnik, mert senki sem tudja, hová fog hullani a felelősség. Ezért az emberek puhítják a nyelvezetet, késleltetik a döntéseket, és létrehozzák azt a sűrű ködöt, amelyet összehangolásnak neveznek. A bizonyíték nem teszi bátorrá a szervezeteket, de csökkenti a pontosság költségét.
Mindig lesznek meglepetések. A megismételhetőség nem varázsszer a valósággal szemben. Új esetek fogják megdönteni a feltevéseket. A felhasználók furcsa kérdéseket fognak feltenni. Érkeznek majd dokumentumok olyan formázással, mintha áramszünet közben egyeztették volna. A modellek egyik irányban fejlődnek, a másikban visszaesnek. A cél nem a meglepetés megszüntetése. A cél az, hogy a meglepetés informatív legyen, ne fertőző.
Ezért fontosabb a megismételhetőség, mint a demók. A demók azt a hitet keltik, hogy egy képesség létezik. A megismételhetőség azt a képességet adja, hogy támaszkodni lehessen rá. Az első hasznos a beszélgetés elindításához. A második szükséges a munkavégzéshez. Amikor egy AI-rendszer egy intézmény részévé válik, a kérdés többé nem az, hogy le tudja-e nyűgözni a termet. A kérdés az, hogy egy hétköznapi napon, hétköznapi nyomás alatt, hétköznapi emberekkel képes-e előállítani, megőrizni és megmagyarázni a munkáját. A hétköznapi napokon mérettetnek meg a komoly rendszerek.