A Mastra Vitest-integrációval CI-ben is tesztelhetők az AI-agentek

A Mastra új Vitest-integrációja lehetővé teszi, hogy a fejlesztők az evalokat a folyamatos integrációs folyamat részeként futtassák. Az agentek, workflow-k és scorerek tesztjei úgy jelennek meg, mint a hagyományos egységtesztek.
- A Mastra evaljai Vitesttel CI-munkafolyamatban futtathatók.
- Agentek, workflow-k és egyedi scorerek is tesztelhetők.
- A toleranciák és küszöbértékek kezelik az LLM-válaszok változatosságát.
- Az integrációhoz legalább az @mastra/[email protected] szükséges.
- A riportáló kapu- és scorer-szintű eredményeket jelenít meg.
Az evalok a CI-folyamat részei lehetnek
A Mastra szeptember 24-én bemutatott integrációjával az evalok közvetlenül a Vitestben futtathatók. Minden eval egy hagyományos egységtesztként viselkedik, a riportáló pedig a futás végén kiírja a kapukat és pontszámokat, így látható, mely tesztek teljesültek, melyek buktak el, és miért.
A fejlesztők agenteket, workflow-kat és scorereket is ellenőrizhetnek. A megoldás célja, hogy a regressziók még a telepítés előtt kiderüljenek. A Mastra példája szerint egy prompt módosítása megváltoztathatja az agent produkciós viselkedését, ezt pedig a CI-ben futó tesztek jelezhetik. A pull requestek a tesztekben meghatározott állítások alapján ellenőrizhetők.
Toleranciák az eltérő LLM-válaszokhoz
A nyelvi modellek válaszai ugyanarra a bemenetre is eltérhetnek, ezért a pontos szövegegyezésre épülő állítások könnyen hibát jelezhetnek. A Vitest-integráció toleranciákat és küszöbértékeket támogat, így a tesztek kezelni tudják ezt a változatosságot.
Két fő API áll rendelkezésre. A runEvals közvetlenül visszaadja az eredményt, amelyre a fejlesztő külön állításokat tehet a verdiktről, a kapuk teljesüléséről vagy a pontszámokról. Az expectEvals ugyanezt Vitest-állításként használja, és tesztkimenetben kapunként és scorerenként is részletes bontást jelenít meg.
A dokumentációban szereplő agentpélda egy időjárási agentet vizsgál. A teszt ellenőrzi, hogy az agent meghívja a weatherTool eszközt, nem keletkezik eszközhiba, a válaszban szerepel London, az answer relevancy scorer pedig eléri a 0,7-es küszöböt. A példákban a tesztek időkorlátja 60 másodperc, mivel a Vitest alapértelmezett, 5 másodperces korlátja túl rövid lehet a nyelvi modellekre épülő evalokhoz.
Workflow-k és egyedi scorerek tesztelése
A workflow-k mindkét API-val célként adhatók meg. A Mastra a futási pályát, vagyis a trajectoryt, a workflow-lépések végrehajtási sorrendjében rögzíti, az eszközmeghívásokat pedig a megfelelő lépések alá rendezi. A createTrajectoryAccuracyScorerCode az aktuális pályát egy elvárt pályával hasonlítja össze. Pontszáma 1,0, ha minden lépés és minden megnevezett, beágyazott eszközmeghívás a megfelelő sorrendben szerepel. Kapuként használva bármilyen eltérés meghiúsítja a tesztet.
A scorerek önmagukban nem célpontok, de saját .run() metódusukkal tesztelhetők elvárt kimenet mellett. A forrás példája egy olyan egyedi scorert mutat be, amely azt ellenőrzi, hogy a válasz tartalmaz-e Celsius- vagy Fahrenheit-fokban megadott hőmérsékletet.
Telepítés és használat
A használathoz a Mastra az @mastra/evals csomag és a Vitest telepítését írja elő. A támogatott Vitest-verzió a 3-as vagy a 4-es főverzió. A funkcióhoz legalább az @mastra/[email protected] szükséges, a támogatás a Mastra 22665-ös pull requestjében került be.
A fejlesztőnek regisztrálnia kell a MastraEvalsReporter riportálót a vitest.config.ts fájlban. A konfigurációban az evaltesztek fájlmintája, a részletes riportáló, a környezeti változók betöltése és az evalokhoz készült beállítófájl is megadható. A példakonfigurációban a fájlok párhuzamos futtatását kikapcsolják.
A mátrixteszteléshez a Vitest test.for funkciója kombinálható az expectEvals megoldással, vagy a runEvals használható egyetlen adatelemmel. Ilyenkor minden adatelem külön tesztként fut, így egy regresszió külön hibás tesztként jelenhet meg.
Mastra: Introducing Vitest Integration for Testing | Mastra Blog


