A teljesítménytesztek nem érvényesek éles környezetben, a GitHub kutatói szerint

A nyílt forráskódú szoftverek biztonságát ellenőrző GitHub szerint a nyelvi modellek (LLM) éles környezeti értékelése eltér a laboratóriumi teljesítménytesztekétől. A valós idejű adatok gyakran homályosak, a címkék következetlenek, és a kontextus hiányozhat, ami eltéréseket okoz a modell teljesítményében. (GitHub Blog)

A titkoskód-kereső rendszer prioritásai

A GitHub kutatói kiemelték, hogy a teljesítménytesztek hasznosak lehetnek a prototípusok összehasonlításához és az ötletek teszteléséhez, de nem tükrözik a valós használat kihívásait. Az éles környezetben ritkán előforduló hibák gyakori problémává válhatnak, és a mérőszámok javulása nem mindig fordítható le a gyakorlati viselkedésre. A titkoskód-kereső rendszere esetében a kutatók nem csupán azt vizsgálták, hogy a modell képes-e helyesen osztályozni egy sztringet.

Elsődleges céljuk a volt, hogy csökkentsék a felesleges figyelmeztetéseket, miközben elegendő biztonsági szintet tartanak fenn. A hamis pozitívok csökkentése és a preszíció javítása volt a fő cél, míg a recall, vagyis az összes valódi titok megtalálása, biztonsági korlátként szolgált. Az újítások csak akkor haladhattak tovább, ha a recall csökkenése egy előre meghatározott tartományon belül maradt.

Offline értékelés mint integrációs teszt

A modellek folyamatosan változnak, ezért az értékelés sem lehet egyszeri feladat. A GitHub csapata az offline értékelést integrációs tesztként kezelte, és minden érdemi változás – legyen a prompt módosítása, új modell bevezetése vagy a rendszer logikájának finomítása – után megismételték.

Rögzítették a prompt verzióját, a modell nevét, az adathalmaz verzióját és a rendszer konfigurációját, hogy összehasonlíthassák az eredményeket egy ismert alapvonallal. Ez lehetővé tette annak megválaszolását, hogy egy új prompt javította-e a preszíciót a recall csökkenése nélkül, vagy hogy egy modellfrissítés az egész adathalmazon segített-e.

A kutatók hangsúlyozták, hogy egyszerre csak egy fő változót vizsgáltak, hogy egyértelmű legyen az eredmények oka. Például egy prompt módosítását külön értékelték egy modellfrissítéstől, mielőtt a kettőt együtt tesztelték volna. A promptokat és az értékelési konfigurációkat kódként kezelték: verziószámozták, rögzítették a változásokat, és lehetőség szerint visszaállíthatóvá tették az előző konfigurációkat.

A tanulságok széles körben alkalmazhatók az LLM-alapú rendszerekre, beleértve a kódanalízist, a fejlesztői eszközöket, a biztonsági megoldásokat és az adatelemzést.