26.5.3 Monitoring dashboard kódok

2025.10.06.
AI Biztonság Blog

Régóta túlléptünk azon a korszakon, amikor a rendszerek állapotát logfájlok végtelen görgetésével és `grep` parancsokkal próbáltuk felmérni. Egy modern AI rendszer, különösen egy Red Teaming alatt álló modell, élő, lélegző organizmus. A pulzusát, a reakcióit és a stressz-szintjét valós időben kell látnunk. A monitoring dashboard nem csupán egy szép grafikon-gyűjtemény, hanem a frontvonal, ahol az anomáliákat és a támadási kísérleteket legelőször észlelhetjük. Ez a fejezet azokat a kód-alapokat mutatja be, amelyekkel ezeket az „élő” nézeteket táplálhatod.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

A dashboard mögötti adatáramlás anatómiája

Mielőtt a kódra térnénk, értsük meg a folyamatot. Egy hatékony monitoring rendszer három fő komponensből áll, amelyek egymásra épülnek. A mi feladatunk Red Teamerként leginkább az első pont implementálása, de a többit is ismernünk kell a teljes képhez.

Monitoring architektúra vázlata

1. Adatgyűjtő (Agent) (pl. API Wrapperben) 2. Idősoros Adatbázis (pl. Prometheus, InfluxDB) 3. Vizualizációs Réteg (pl. Grafana, Kibana)

Ebben a láncban a mi fókuszunk az Adatgyűjtő (Agent) kódjára irányul. Ez az a szoftverkomponens, amely közvetlenül az AI modell interakciói mellett „ül”, és releváns metrikákat gyűjt, majd továbbítja azokat a tároló réteg felé.

Példa 1: Metrikák exportálása Prometheus számára (Python)

A Prometheus egy ipari sztenderddé vált „pull” alapú monitoring rendszer. Ez azt jelenti, hogy a mi alkalmazásunknak csak egy HTTP végpontot kell biztosítania (`/metrics`), ahonnan a Prometheus időközönként le tudja kérdezni az aktuális metrika-értékeket. A `prometheus-client` Python könyvtár ezt rendkívül egyszerűvé teszi.


from flask import Flask, Response
from prometheus_client import Counter, Gauge, generate_latest

# Alkalmazás inicializálása
app = Flask(__name__)

# Metrikák definiálása
# Counter: Olyan metrika, ami csak növekedni tud (pl. összes kérés)
JAILBREAK_ATTEMPTS = Counter('jailbreak_attempts_total', 'Sikeresnek ítélt jailbreak kísérletek száma')

# Gauge: Olyan metrika, aminek az értéke nőhet és csökkenhet is (pl. aktuális válaszidő)
RESPONSE_LATENCY = Gauge('avg_response_latency_seconds', 'Átlagos válaszidő másodpercben')

# Egy példa függvény, ami a modell válaszát dolgozza fel
def process_model_output(response, latency):
 if "jailbreak detected" in response.lower():
 JAILBREAK_ATTEMPTS.inc() # Számláló növelése eggyel
 RESPONSE_LATENCY.set(latency) # Gauge értékének beállítása

# A /metrics végpont, amit a Prometheus lekérdez
@app.route('/metrics')
def metrics():
 return Response(generate_latest(), mimetype='text/plain; version=0.0.4')

# ... a kód többi része, ami a modellt hívja és a process_model_output-ot használja
 

Példa 2: Metrikák küldése (push) egyedi API végpontra (Node.js)

Nem minden rendszer „pull” alapú. Néha nekünk kell aktívan elküldenünk a metrikákat egy központi gyűjtő API-nak. Ez a „push” modell flexibilisebb lehet, különösen szerver nélküli (serverless) vagy elosztott környezetekben. Itt egy egyszerű példa `fetch` használatával.


// A központi monitoring szolgáltatás végpontja
const METRICS_ENDPOINT = 'https://monitoring.sajat-szerver.hu/api/v1/metrics';

/**
 * Metrikákat küld a központi gyűjtőnek.
 * @param {string} modelId - A monitorozott modell azonosítója.
 * @param {object} metrics - A küldendő metrikák (pl. { latency: 0.8, tokens: 256 }).
 * @param {string[]} tags - Címkék a könnyebb szűréshez (pl. ['red-teaming', 'test-run-5']).
 */
async function pushMetrics(modelId, metrics, tags) {
 const payload = {
 timestamp: new Date().toISOString(), // Időbélyeg kritikus fontosságú
 model: modelId,
 metrics: metrics,
 tags: tags
 };

 try {
 const response = await fetch(METRICS_ENDPOINT, {
 method: 'POST',
 headers: {
 'Content-Type': 'application/json',
 'Authorization': `Bearer ${process.env.METRICS_API_KEY}` // Hitelesítés
 },
 body: JSON.stringify(payload)
 });

 if (!response.ok) {
 console.error(`Hiba a metrikák küldésekor: ${response.statusText}`);
 }
 } catch (error) {
 console.error('Hálózati hiba a metrikák küldésekor:', error);
 }
}

// Használat:
// pushMetrics('gpt-4-turbo-v2', { latency: 1.2, cost: 0.0015 }, ['pii-detection-test']);
 

Példa 3: Lekérdezési pszeudokód a vizualizációhoz (PromQL)

Az adatok gyűjtése csak a csata fele. A dashboardon megjelenő grafikonok mögött lekérdezések futnak, amelyek a nyers adatokból értelmes információt állítanak elő. A Prometheus a PromQL (Prometheus Query Language) nyelvet használja. Bár ez nem a mi alkalmazásunkban fut, a megértése segít abban, hogy milyen adatokat érdemes gyűjteni.


# Példa 1: A jailbreak kísérletek növekedési üteme az elmúlt 5 percben
# A rate() függvény kiszámolja a számláló másodpercenkénti átlagos növekedését.
rate(jailbreak_attempts_total[5m])

# Példa 2: A 95. percentilis válaszidő az elmúlt 10 perc adatai alapján
# Ez segít kiszűrni a kiugró, de ritka lassulásokat és a valós teljesítményt mutatja.
histogram_quantile(0.95, sum(rate(response_latency_seconds_bucket[10m])) by (le))

# Példa 3: Riasztás, ha 15 perc alatt több mint 5 jailbreak kísérlet történt
# Az alert menedzsment alapja, ami proaktívvá teszi a monitoringot.
increase(jailbreak_attempts_total[15m]) > 5
 

Kulcsgondolat

A monitoring dashboard kódjai jelentik a hidat a modell absztrakt viselkedése és a konkrét, mérhető, valós idejű adatok között. Egy Red Teamer számára a jól megtervezett metrikák és a vizuális megjelenítésük nem kényelmi funkció, hanem egy elsődleges felderítő eszköz. Ezek a kódrészletek nem öncélúak; céljuk, hogy a rejtett mintázatokat, a támadási vektorokat és a rendszer sebezhetőségeit láthatóvá tegyék, mielőtt azok komoly károkat okoznának.