Azokat a tudásokat is építeni kell, amelyeket nem lehet egyszerűen leírni

Sok vállalati tudásprojekt ugyanazzal a kiindulóponttal kezdődik: egy tapasztalt mérnök bejelenti, hogy hat hét múlva távozik, és tőle kérik a folyamata átadását. A legtöbbször kapott anyag egy tiszta folyamatábra a „boldog útról”, amely helyes és rendezett, de kihagyja azokat a határértékeket, észrevételeket és helyzetfüggő ítéleteket — például melyik beszállító alkatrészei hibásodnak nedves környezetben — amelyeket az évek során tett döntésekbe ágyazva sajátként kezel az illető.

Ennek következménye: hat hónappal később, amikor összeomlik egy gyártósor, a tudásbázis nem ad útmutatást. Az interjú megtörtént, a jegyzőkönyv tárolva és indexelve lett, a keresés a releváns szakaszt előhozza, de az ott leírtak nem magyarázzák meg a mögöttes szakértői ítéletet, mert azt senki sem kérte számon.

Ez a hiány ma sok vállalati MI‑program hatékonyságát korlátozza: jobb lekérdezéssegédlet és rangsorolás csak a rögzített tudást hozza elő, de nem képes visszaállítani azt a szakértelmet, amely sosem került be a gyűjteménybe.

A kimondhatatlan tudás fogalma és formái

Michael Polanyi 1966‑ban fogalmazta meg a jelenséget a The Tacit Dimension című munkájában: „Többet tudunk, mint amit el tudunk mondani.” A kompetencia sokszor olyan készségekben, észlelésben és ítéletalkotásban gyökerezik, amelyek ellenállnak a teljes, explicit leírásnak.

A vállalati környezetben a tacit (kimondatlan) tudás többnyire három formában jelenik meg:

• Elicitable knowledge (kikérhető tudás): az információ azért marad kimondatlan, mert senki nem tett fel elég pontos kérdést, vagy mert a szakértő feltételezi, hogy mindenki ugyanúgy látja a helyzetet.
• Perceptual knowledge (észlelési tudás): a képzett figyelemben rejlő készség — például amikor egy mérnök „hallja”, hogy csapágy kezd meghibásodni, vagy egy ápoló észreveszi, hogy a beteg „valamiért rosszul néz ki” még a műszerek előtti jelzés előtt.
• Collective knowledge (kollektív tudás): a csapatok szokásai, normái és közös elképzelése arról, mi számít helyes döntésnek az adott szervezeti kontextusban.

Ezen kívül a „preventive judgment” (megelőző ítélet) is külön kihívást okoz: ha egy tapasztalt operátor kifinomult módon elkerül egy hibamódot, gyakran nem keletkezik jegy, incidensjelentés vagy nyoma annak a döntésnek — a hasznos eredmény maga az esemény elmaradása.

Az automatizálás határai és a Polanyi‑paradoxon

A gépi tanulás képes lehet szabályokat megtalálni, amelyeket az emberek nehezen tudnak megfogalmazni, feltéve, hogy elég reprezentatív példát lát. Ritka, speciális szakértelem esetén azonban kevés az ilyen példa: egy vállalatnál lehet, hogy csak kevés rendkívüli esemény és egyetlen, évtizedek alatt kialakult szakértelem áll rendelkezésre.

David Autor ezt a korlátot "Polanyi’s paradox" néven írta le: sok olyan feladat, amelyet legnehezebb automatizálni, olyan szabályokon alapul, amelyeket nem tudunk megfogalmazni. A mai nagy nyelvi modellek ezt megkerülik példákból tanulva, de a megoldás gyengül példák hiányában. A finomhangolás megtanítja a modellt a vállalati szóhasználatra és dokumentumsémákra, de nem képes újjáépíteni azokat a döntéseket, amelyekről egyáltalán nem keletkezett adat.

Ugyanakkor a gazdasági környezet is változott: a legtöbb leírt bevált gyakorlat ma már széles körben elérhető a frontier modellek képzési adataiban, így a cégversenyelőny egyre inkább a helyi ítéleten múlik — azokon az eltéréseken, határértékeken, viszonyokon és gyakorlaton, amelyeket a helyi szakemberek gyűjtöttek.

Ezért az elicitation (kikérdezés) nem csupán egy offboarding‑feladat, hanem architekturális kérdés: ismételhető folyamatra van szükség a kimondható tudás felszínre hozására, azokra a tudásdarabokra, amelyeket helyben demonstrálni kell, és arra a szerény, de fontos különbségtételre, hogy melyik melyik.

Egy protokoll a kikérdezéshez

A központi tervezési kérdés egyszerű: milyen követő kérdés ösztönzi a szakértőt arra, hogy kimondja a hiányzó ítéletet? Az interjú minősége határozza meg a tudásbázis felső korlátját; az index határozza meg, mennyi idő alatt jut oda valaki.

A szakértői magyarázatok jellemzően négy helyen válnak homályossá. Egy hatékony interjúprotokoll célzott kérdéseket tesz fel mindegyikre:

• Thresholds (küszöbök): mely szám, mérés vagy feltétel váltja ki a beavatkozást?
• Exceptions (kivételek): mikor nem alkalmazható a dokumentált eljárás?
• Evidence (bizonyíték): mit figyelt meg a szakértő, mielőtt döntést hozott?
• Escalation (escalálás): kiket vonunk be, és mikor?

Ezek a kérdések feltárják azokat az üzemeltetési részleteket, amelyek gyakran hiányoznak a runbookokból. A nyelvi modellnek ebben a folyamatban szűk szerepe lehet: a következő kérdés javaslata, amely egy általános állítást használható szabállyá konvertál. Például egy első, vázlatos válasz így hangozhat:

„Áttekintjük a nagy kockázatú use case‑eket bevezetés előtt. Ha a kockázat jelentősnek tűnik, escalálunk a governance councilhez.”

Ez az állítás kereshető és tárolható, de egy új kolléga ezzel még nem tud dönteni: mit jelent a „jelentősnek tűnik”? Egy célzott követő kérdés után a szakértő konkrétabban fogalmazhat:

„Escalation a councilhez szükséges, ha a use case foglalkoztatási, hitelképességi vagy egészségügyi döntéseket érint, vagy ha a modell kimenete ügyfélhez jut emberi felülvizsgálat nélkül. A belső, személyes adatot nem érintő eszközöket kihagyjuk. Ha nem tudunk név szerint felelős tulajdonost azonosítani, a review nem indul el, függetlenül a kockázati szinttől.”

A második válasz némi plusz időt vesz igénybe, viszont tartalmaz döntési szabályt, kivételt, visszatérő hibamintát és blokkoló feltételt — tehát valódi iránymutatást ad. A protokollnak őrködő szabályokra is szüksége van: korlátozni kell a követő kérdések számát (a túl hosszú kikérdezés kimeríti a szakértőt és egyre inkább „egyetértő zajt” hoz létre), a modell feladatát a kérdések generálására kell szűkíteni, és külön kell választani a válaszok összegzését és validálását. Minden szakértői állításnak meg kell őriznie a forrását és kontextusát; a pontosságot függetlenül kell ellenőrizni.

Az írásomban említett nyílt forráskódú eszközt, az ExpertTrace‑t, e protokoll köré építem.

A négy‑rétegű (négy‑plane) tudásarchitektúra

A kikérdezés csak egy eleme egy szélesebb tudásrendszernek. Egy tacit‑tudatosságú architektúra négy réteget különböztet meg: capture (rögzítés), representation (reprezentáció), serving (kiszolgálás) és transmission (átadás). Mindegyik réteg más‑más hiányosságra ad választ.

• Capture plane: strukturált interjúk, incidensrekonstrukciók, döntési naplók és megfigyelés gyűjtenek többet, mint a csiszolt eljárásokat. Rögzíteni kell a kiváltó eseményt, a bizonyítékot, a kivételt és az escalációs útvonalat, amíg a szakértő még el tudja magyarázni a körülményeket. Az észlelési készséget demonstráció és gyakorlás felé kell irányítani, nem prózába préselni.

• Representation plane: meg kell őrizni azokat a megkülönböztetéseket, amelyek hitelessé teszik az anyagot. Egy megfelelőségi szabályzat, egy „háborús történet” és egy tesztetlen hipotézis ne váljanak felcserélhető darabokká. Azt is rögzíteni kell mint alapvető tulajdonságokat: a forrást, a bizonyosságot és a validitási kontextust (üzem, időszak, eszközök, körülmények). A tudásgráfot kiterjesztjük a dokumentumokon túl a személyekre és az eseményekre is.

• Serving plane: ez határozza meg, hogyan jut el a tudás a felhasználókhoz. A válaszoknak hivatkozniuk kell a megtalált bizonyítékra és meg kell mutatniuk a forrást. Ha a gyűjtemény nem tud válaszolni, a rendszernek világosan jeleznie kell, és az adott tapasztalattal rendelkező személyhez kell irányítania a kérdést: „Kérdezd Joe‑t; ő újraépítette ezt a sort 2023‑ban” sokkal hasznosabb, mint egy magabiztos, de gyenge bizonyítékokra támaszkodó érvelés.

• Transmission plane: ez segíti elő, hogy a szakértelem miként mozogjon emberről emberre árnyékmunka, oktatás és gyakorlatközösségek révén. A platformnak észlelnie kell, mikor koncentrálódik tudás egy kis számú személynél és mikor nő a kiesés kockázata, majd elkészíteni a rögzítés és a mentorálás lépéseit még azelőtt, hogy valaki felmondana.

A tudásréteg értékelése

A visszakeresés pontossága és a válaszok hűsége megmutatja, mennyire szolgálja jól a rendszer a meglévő gyűjteményt, de nem azt, hogy a gyűjtemény ténylegesen tartalmazza‑e a szervezet működéséhez szükséges tudást. Ehhez külön értékelési hurkot kell bevezetni, amely a rögzítés prioritásaihoz és a transzfereredményekhez kötődik.

Az értékelés lépései a szerző által felvázolt módszer szerint:

• Incident replay: válasszunk ki 20–30 lezárt incidenst, távolítsuk el a megoldásokat, és adjuk meg a felnyitó tényeket a rendszernek. Kérjük meg azokat a mérnököket, akik megoldották az eseteket, hogy osztályozzák a rendszer válaszait. Hasonlítsuk össze a belső rendszer válaszait egy frontier model válaszaival, amely nem fér hozzá a cég kollekciójához: a különbség megmutatja, milyen gyakran ad csak általános, nyilvános tudáson alapuló választ a belső rendszer.

• Bus‑factor audit: teszteljünk olyan kérdéseket, amelyeket csak egy‑két alkalmazott tud megválaszolni, és vizsgáljuk, hogyan teljesít a rendszer. Egy tiszta bizonytalansági bevallás, majd hasznos irányítás egészséges; a magabiztos sablonos válaszok aláássák a bizalmat.

• Abstention calibration: mérjük, hogy a rendszer mikor válaszol, ha létezik bizonyíték, és mikor tartózkodik, ha a korpusz nem támasztja alá. Készítsünk címkézett készletet válaszolható és válaszolhatatlan kérdésekből, majd kövessük az abstention (visszautasítás) precizitását és lefedettségét a gyűjtemény növekedésével. Egy rendszer, amely soha nem mondja „nem tudom”, nincs megfelelően értékelve ezen a kritikus dimenzión.

• Transfer outcomes: mérjük, eljutott‑e a tudás azokhoz, akiknek szükségük van rá. A transzfer eredményei rövidebb tanulási időben, kevesebb megismétlődő incidensben az elicitation után és kevesebb kritikus felelősségben, amely egyetlen személytől függ. A dokumentum‑ és lekérdezésszámok aktivitást mutatnak, de nem igazolják, hogy valaki más képes lett meghozni a döntést.

Záró gondolatok

Egy erős tudásrendszer nem csak azt rögzíti, amit a szakértő mondott, hanem megőrzi a körülményeket, a bizonytalanságot és a forrást, és felismeri azt a szakértelmet, amely demonstrációt, mentorálást vagy csapatgyakorlatot igényel. Mivel minden este azok a munkatársak, akik ezeket a képességeket hordozzák, hazamennek, az architektúrát jóval azelőtt használatra kell készíteni, hogy valaki bejelentené a távozását.