Az Elastic módszere külön ellenőrzi az LLM-ek által összevont cikkeket

A gördülékeny szöveg elfedheti a hibákat

Az Elastic támogatási csapata régóta szerette volna összevonni az azonos problémákról szóló, ismétlődő tudásbázis-cikkeket. A vállalat tudásbázisa több száz mérnök diagnosztikai tapasztalatát gyűjti össze, ezért a duplikátumok rontják a használhatóságát.

Előfordulhat, hogy két, egymástól 18 hónap különbséggel készült cikk ugyanazt a hibát tárgyalja, de az egyik jobb magyarázatot ad a kiváltó okra, míg a másik tartalmazza a ténylegesen működő parancsot. A keresőben előrébb megjelenő oldal így csak részleges választ adhat.

Az Elastic szerint a probléma négy éve ismert, az összevonások mégis ritkán készültek el. A megfelelő munka során minden technikai állítást össze kell vetni, meg kell őrizni a részleteket, majd egységes cikket kell írni. Ez nagy léptékben túl időigényes.

A vállalat kipróbálta a kézenfekvő LLM-es megoldást is. Két cikkből a modell körülbelül tíz perc alatt rendezett, könnyen olvasható változatot készített, az eredmény azonban hibákat rejthetett. Egy előfeltétel kimaradhatott, a 8.12+ verziókövetelmény 8.x formára változhatott, egy konfigurációs megjegyzés eltűnhetett, sőt egy olyan paraméter is bekerülhetett egy parancsba, amely soha nem létezett.

Két külön feladat, két ellenőrzési lépés

Az Elastic megközelítésének alapelve, hogy a létrehozás és az ellenőrzés külön feladat, ezért ezeket nem ugyanazon a modellen végrehajtott egyetlen lépésre bízzák. Az összevonó első passz elkészíti az egységes cikket, miközben a kódblokkokat, parancsokat, konfigurációs részleteket, URL-eket és verziószámokat változtatás nélkül kell átvinnie. A próza átírható, a technikai tartalom nem.

A második passz új környezetben fut, és nem tekinti hitelesnek az összevont cikket. Mindkét forráscikket külön vizsgálja, az anyagokat pedig atomikus állításokra bontja. Ilyen állítás lehet például, hogy egy tünet egy adott okra utal, egy beállítást újraindítás előtt kell alkalmazni, egy viselkedés egy bizonyos verzióban megváltozott, vagy egy kerülőmegoldás nem használható egy adott telepítési típusnál.

Az ellenőrző ezután minden állításnál azt vizsgálja, hogy az szerepel-e az összevont cikkben. Az állapot lehet jelen, részleges vagy hiányzó. Külön jelzi azt is, ha a két forrás ellentmond egymásnak.

A cél a kihagyások láthatóvá tétele

Az Elastic szerint a módszer azért működőképesebb, mert a „hű maradt-e az összevonás?” kérdés túl általános az AI számára. Az olyan kérdések viszont, mint hogy „az összevont cikk továbbra is kimondja-e, hogy ehhez a beállításhoz újraindítás szükséges?”, egyértelműbben ellenőrizhetők.

Az atomikus bontás különösen a kihagyásokat teszi láthatóvá. Egy új, hibás parancs feltűnhet, egy eltávolított előfeltétel viszont önmagában láthatatlan marad. Ha minden forrásállítást előre felsorolnak, mindegyikről külön döntésnek kell születnie.

A folyamat két eredményt ad: lefedettségi táblát, amely minden állítás állapotát tartalmazza, és konfliktusnaplót, amely a források közötti ellentmondásokat, valamint azok feloldását rögzíti. A humán ellenőr így nem egy késznek tűnő szöveget olvas újra teljes egészében, hanem a hiányzó állításokat és a konfliktusokat bírálja el.

Az Elastic leírása szerint a gyakorlatban a séma három modellhívásból és két táblából áll. Az első hívás összevonja a cikkeket, a további ellenőrzés pedig külön-külön auditálja az eredményt mindkét forrás alapján. A vállalat hangsúlyozza, hogy az összevonó modell saját beszámolója a konfliktusokról és a kihagyásokról csak jelzés, nem garancia. A felhasználói tudásbázisoknál ez azt jelentheti, hogy a véglegesítés előtt célzottabban lehet kiszűrni az eltűnő technikai részleteket és a hallucinált tartalmakat.