Az eddig megismert tesztek manuális futtatása hasznos a fejlesztés és a hibakeresés során, de egy professzionális környezetben ez nem skálázható és nem garantálja a folyamatos minőséget. A valódi ereje az automatizált tesztelésnek akkor mutatkozik meg, amikor beépítjük a fejlesztési folyamatba. Az LLM-alapú alkalmazások sebezhetőségeinek és viselkedésbeli regresszióinak folyamatos ellenőrzése kritikus, és erre a CI/CD (Continuous Integration/Continuous Deployment) pipeline a legalkalmasabb eszköz.
A PromptFoo parancssori eszközként tökéletesen illeszkedik a legtöbb modern CI/CD rendszerbe, legyen az GitHub Actions, GitLab CI, Jenkins vagy CircleCI. A lényeg mindenhol ugyanaz: a kódbázis minden egyes változtatásakor (vagy egy meghatározott eseményre) automatikusan le kell futtatni a tesztkészletet, és meg kell akadályozni a hibás kód élesbe kerülését.
Az alapintegráció: GitHub Actions
Nézzünk egy konkrét példát GitHub Actions segítségével! A célunk, hogy minden alkalommal, amikor valaki kódot tölt fel a `main` branch-re, a PromptFoo tesztek automatikusan lefussonak. Ehhez létre kell hoznunk egy workflow fájlt a repository `.github/workflows/` könyvtárában.
A folyamat logikája egyszerű: a CI runnernek le kell töltenie a kódunkat, telepítenie kell a PromptFoo-t, majd végre kell hajtania az `eval` parancsot. A kulcs a parancs exit code-jában rejlik. Ha minden teszt sikeres, a PromptFoo `0` exit code-dal tér vissza, jelezve a sikert. Ha akár egyetlen teszt is elbukik, a visszatérési érték nem nulla lesz, ami a CI/CD pipeline számára a build sikertelenségét jelenti, és a folyamat megszakad.
# .github/workflows/promptfoo-tests.yml
name: PromptFoo LLM Tests
# A workflow futtatásának kiváltó eseménye
on:
push:
branches: [ main ] # Futtatás minden 'main' branch-re történő push esetén
pull_request:
branches: [ main ] # Futtatás minden 'main' branch-et célzó pull request esetén
jobs:
run-promptfoo-tests:
runs-on: ubuntu-latest # A futtató környezet meghatározása
steps:
- name: Kód letöltése (Checkout)
uses: actions/checkout@v4
- name: Node.js környezet beállítása
uses: actions/setup-node@v4
with:
node-version: '20' # Ajánlott Node.js verzió
- name: PromptFoo telepítése
run: npm install -g promptfoo
- name: PromptFoo tesztek futtatása
run: promptfoo eval -c promptfooconfig.yaml
Ez a konfiguráció a legegyszerűbb, de már tökéletesen működőképes alap. Amint ezt a fájlt beilleszted a repository-dba, a GitHub Actions automatikusan elkezdi futtatni a tesztjeidet a megadott eseményekre.
Titkok kezelése: A biztonságos megközelítés
Az előző példa egy fontos dolgot nem kezelt: az API kulcsokat. Sosem szabad API kulcsokat vagy más érzékeny adatot közvetlenül a kódban vagy a CI/CD konfigurációs fájlban tárolni. Erre valók a platformok által biztosított „secrets” vagy „variables” tárolók.
GitHub Actions esetében ezeket a repository `Settings > Secrets and variables > Actions` menüpontjában adhatod meg. Létrehozhatsz például egy `OPENAI_API_KEY` nevű titkot. A workflow fájlban erre már biztonságosan hivatkozhatsz.
Módosítsuk az előző példát úgy, hogy használja a titkosított API kulcsot:
# ... (a fájl eleje változatlan)
- name: PromptFoo tesztek futtatása
# Az `env` kulcsszóval környezeti változókat adhatunk át a lépésnek.
# A PromptFoo automatikusan felismeri az OPENAI_API_KEY változót.
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: promptfoo eval -c promptfooconfig.yaml
Ezzel a módszerrel a kulcsod biztonságban marad, sosem kerül bele a logokba vagy a repository előzményeibe, de a tesztfuttatás során elérhető lesz az eszköz számára.
Haladó technikák és bevált gyakorlatok
Egy egyszerű pipeline már nagy előrelépés, de a hatékonyság és a visszakövethetőség érdekében érdemes néhány további lépést beépíteni. Ezek a gyakorlatok gyorsabbá, megbízhatóbbá és informatívabbá teszik az automatizált tesztelési folyamatot.
Eredmények archiválása (Artifacts)
A CI/CD logokból kinyerni az információt, hogy pontosan melyik teszt és miért bukott el, néha nehézkes. Sokkal praktikusabb, ha a PromptFoo által generált részletes riportot (pl. JSON vagy HTML formátumban) elmentjük. Ezeket a fájlokat hívjuk „artifact”-oknak, amelyeket a workflow futás után le lehet tölteni elemzésre.
Ehhez módosítani kell a futtatási parancsot egy kimeneti fájl megadásával (`-o`), majd egy új lépéssel fel kell tölteni ezt a fájlt.
# ...
- name: PromptFoo tesztek futtatása
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# A --no-progress kapcsolóval letisztultabb logot kapunk a CI környezetben.
# Az -o kapcsolóval megadjuk a kimeneti fájlt.
run: promptfoo eval -c promptfooconfig.yaml -o results.json --no-progress
- name: Eredmények feltöltése artifactként
# Ez a lépés csak akkor fut le, ha az előző sikeres vagy sikertelen volt,
# de nem szakadt meg teljesen (always()). Így a hibás riportot is elmentjük.
if: always()
uses: actions/upload-artifact@v4
with:
name: promptfoo-results
path: results.json
Függőségek gyorsítótárazása (Caching)
Bár a `npm install -g promptfoo` parancs nem tart sokáig, nagyobb projekteknél a függőségek telepítése jelentős időt vehet igénybe. A CI/CD rendszerek általában lehetővé teszik a függőségek gyorsítótárazását (caching), így a későbbi futtatások sokkal gyorsabbak lesznek, mert nem kell mindent nulláról letölteni és telepíteni.
A `setup-node` action beépítetten támogatja a cache-elést:
# ...
- name: Node.js környezet beállítása cache-eléssel
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm' # Megadjuk a csomagkezelőt a cache-eléshez
- name: PromptFoo telepítése
# A `npm ci` gyorsabb és determinisztikusabb, mint az `install`,
# de ehhez package-lock.json fájlra van szükség. Egyszerűbb esetben
# maradhatunk az `npm install -g promptfoo`-nál, de a cache itt is segít.
run: npm install -g promptfoo
# ...
A CI/CD pipeline-ba való integrációval a PromptFoo egy reaktív, manuális tesztelőeszközből proaktív minőségbiztosítási és biztonsági kapuvá válik. Ez a lépés elengedhetetlen ahhoz, hogy az LLM-alkalmazásainkat magabiztosan fejlesszük és üzemeltessük, miközben minimalizáljuk a váratlan viselkedésből és sebezhetőségekből adódó kockázatokat. A megbízható automatizáció alapja azonban a jól megírt, releváns tesztesetek sora, amelyek fejlesztésével a következő fejezetben foglalkozunk.