A modern mesterséges intelligencia rendszerek viselkedésének visszaállíthatósága nem pusztán technikai kérdés: sokszor a rendszer döntéseinek későbbi megértéséhez nem az azonos eredmény újragenerálása szükséges, hanem annak megállapítása, hogy a döntés pillanatában milyen modellek, adatok, konfigurációk, és külső szolgáltatások vettek részt a számításban. Ezt a szerző „historical reconstructability” — történeti rekonstruálhatóság — fogalmával írja le, és azt állítja, hogy ez a tulajdonság futásidőben keletkezik, nem pedig utólag a megmaradt artefaktumokból következik.
A probléma lényege
Gondoljunk egy AI-támogatott döntésre, amelyet hat hónappal később vizsgálnak. Ugyanannak a rendszernek az újrafuttatása eltérő választ hozhat; a vizsgálónak azonban nem szükségképpen egy újraalkotott válasz, hanem annak megállapítása kell, hogy az eredeti végrehajtás során melyik modell-végpont, melyik szabályzat (policy), milyen visszakeresett kontextus, eszközszerződés (tool contract) és mely futásidő-konfiguráció volt érvényben. Sok AI-üzemeltető azzal foglalkozik, mit tud a rendszer ma — benchmarkok, sikerarányok, késleltetés, költség — de ez a kép nem mond semmit arról, hogy egy múltbeli végrehajtás mennyire lesz később érthető.
A rekonstruálhatóság különbözik a reprodukálhatóságtól: az előbbi arra vonatkozik, hogy meg lehessen állapítani az eredeti végrehajtás körülményeit, akár az eredmény újbóli előállítása lehetetlen vagy eltérő is legyen.
Miért nehéz rekonstruálni egy végrehajtást?
Az AI futtatókörnyezetek gyakran olyan függőségeket használnak, amelyek történeti azonosítói és kapcsolatai nem maradnak meg. Egy telepítés (deployment) rögzíti a deklarált állapotot, de a végrehajtás során további függőségek záródhatnak — például egy modell alias más végpontra mutathat, egy feature vagy adatforrás megváltozhat, a visszakeresett kontextus vagy a memória csak a kérés feldolgozásakor válik ismertté. Az ilyen, ténylegesen használt elemeket a szerző futásidő-kötésnek (runtime binding) nevezi: ezek azok a tények, hogy az adott végrehajtás mihez kötődött valójában.
A cikk szemléletes példája az E891 jelű hipotetikus végrehajtás: bár a deployment deklarálhatja az alkalmazás 8f31c2 jelű revízióját és a modell v17-et, magának a végrehajtásnak a hatóköre prompt h31-et, retrieval index r42-t, dokumentumokat d182@17 és d761@4, eszközszerződést h42, policy v8-at és végül hatást e3-at köthetett. Ezek közül több elem csak futásidőben vált ismertté, ezért a deployment állapota önmagában nem ad teljes történeti leírást.
A jelenlegi adatok veszteséges leképezése
A ma használt eszközök — verziókezelés, tranzakciós naplók, elosztott trace-ek — különböző nézeteit adják egy futásnak, de nem feltétlenül őrzik meg az egy végrehajtáshoz tartozó, anyagilag releváns konfigurációt. Egy művelet létezik és egy entitás létezik, de az, hogy a művelet ténylegesen használta-e az adott entitást, külön tény. A W3C PROV fogalomrendszere már megkülönbözteti, hogy egy activity használ egy entityt, de maga az architektúra gyakran nem követeli meg a futásidő-kötések rögzítését és tartós megőrzését.
OpenTelemetry és egyéb tracing megoldások át tudják vinni a függőségazonosítókat, de ezzel még nem biztosítanak tartós, később feloldható történeti jelentést. Azonosító kódok a nyomkövetésben ma elvesszhetnek, mikor a hivatkozott állapotok elavulnak vagy megszűnnek elérhetők lenni.
Mit kell megőrizni: kötési és feloldási integritás
A szerző szerint a rekonstruálhatóság megőrzéséhez két tulajdonságot kell biztosítani egy definiált végrehajtás-osztályra és meghatározott megőrzési időre:
- Binding integrity (kötési integritás): rögzíteni kell, hogy az adott végrehajtás ténylegesen mely függvényeket, modelleket, adatállapotokat és egyéb erőforrásokat használta.
- Resolution integrity (feloldási integritás): a rögzített identitásokat olyan módon kell tárolni, hogy később feloldhatóak legyenek a történeti állapotokra, amelyekre vonatkoznak.
A megőrzés hibakezelése: nem egyszerű telemetry-vesztés
Amikor egy külső hatás (például egy eszköz által végrehajtott művelet) elkövetésre kerül, de a használati rekord nem vált tartóssá (nem került tartós tárhelyre), akkor a külső világ és a belső történeti nyilvántartás eltér. Ilyen esetben nem arról van szó, hogy egyszerűen „elveszett egy log”: a rendszer architektúrájának meg kell határoznia, mi történik, ha a megőrzés nem sikerül. Lehet például követelmény a tartós használati rekord megléte az effektus commitálása előtt, atomikus kiírás tranzakciós outbox-szal, a végrehajtás karanténba helyezése reconciliáció céljából, vagy kompenzáló művelet indítása. Ha nincs ilyen definiált viselkedés, a történeti rekonstruálhatóság nem garantált.
A megőrzési réteg: mi hiányzik az ökoszisztémából
A létező technológiák (provenance és lineage modellek, tracing, regisztrációs rendszerek, content-addressed tárolók) építőköveket adnak, de magukban nem követelik meg azt a futásidő-kötelezettséget, amely biztosítja az egy végrehajtáshoz kapcsolódó dependency closure tartós azonosíthatóságát. A szerző Orrery nevű referencia-architektúrát javasolja: ez rögzíti a futásidőben létrejövő, anyagilag releváns kötések pillanatát és megőrzi a hozzájuk tartozó feloldható identitásokat.
AIGov Core mint részmegoldás
AIGov Core bemutat egy korlátozott megvalósítást: egy evidence ledger tárol hash-láncolt eseményeket, és egy replay engine képes egy kimentésből kormányzási döntést rekonstruálni anélkül, hogy élő állapotot kérdezne. Egy ellenőrző mechanizmus Ready, Partial vagy NotReady jelzést ad az exportnak attól függően, maradt-e feloldatlan lineage, hiányzó policy-artefaktum, verzióeltérés vagy replay-hiba. Ez megmutatja, hogy a rekonstruálhatóság tesztelhető tulajdonság, de nem oldja meg azt az esetet, amikor a futásidő-kötés sosem került rögzítésre.
Következtetés: rekonstruálhatóság mint architekturális kötelezettség
A megőrzési hiány a tényleges függések és a rendszer által tartósan megőrzött információk közötti eltérés. Ennek bezárásához a futtatókörnyezetnek kötelezettséget kell vállalnia: amikor egy végrehajtás anyagilag releváns állapotot köt meg, a rendszernek rögzítenie kell a kötést, tartós identitást kell biztosítania a függőséghez, és hozzáférést kell tartania a történeti állapothoz a meghatározott megőrzési idő alatt. A rekonstruálhatóság tehát nem csupán megfigyelhetőség vagy képesség mellékterméke; aktív architekturális tulajdonságként kell kezelni, tervezni, tesztelni és végrehajtani a futásidő során.
