Inferentielog-analyse
Inferentielogs analyseren voor AI-forensisch onderzoek: afwijkende patronen detecteren, jailbreak-pogingen identificeren via metadata, analyse op tokenniveau en detectie van latentieanomalieën.
Inferentielog-analyse
Inferentielogs leggen de metadata van elke modelaanroep vast -- tokenaantallen, latentie, parameters, finish reasons en foutcodes. Hoewel ze niet de daadwerkelijke inhoud van prompts en responses bevatten, onthullen ze patronen die wijzen op aanvalsactiviteit, data-exfiltratie en modelmanipulatie. Deze pagina behandelt systematische analysetechnieken voor inferentielogdata.
Een baseline vaststellen
Voordat je anomalieën kunt detecteren, moet je weten hoe "normaal" eruitziet. Bouw baselineprofielen voor elk modeleindpunt die de volgende metrieken dekken.
Baselinemetrieken
| Metriek | Wat te meten | Typisch baselinevenster |
|---|---|---|
| Verdeling van invoertokens | Gemiddelde, mediaan, P95, P99 van invoertokens per verzoek | 7-14 dagen |
| Verdeling van uitvoertokens | Gemiddelde, mediaan, P95, P99 van uitvoertokens per verzoek | 7-14 dagen |
| Invoer-/uitvoerverhouding | Verhouding van invoertokens tot uitvoertokens | 7-14 dagen |
| Latentieprofiel | Gemiddelde, P50, P95, P99 latentie per verzoek | 7 dagen |
| Verzoekvolume | Verzoeken per minuut/uur per gebruiker, sessie en eindpunt | 14-30 dagen |
| Verdeling van finish reasons | Percentage verzoeken dat eindigt in stoptoken, lengtelimiet of contentfilter | 14 dagen |
| Foutpercentage | Percentage mislukte verzoeken per fouttype | 14 dagen |
| Verdeling van temperature | Indien door gebruiker instelbaar, de verdeling van gebruikte temperature-waarden | 14 dagen |
Baselinevoorbeeld
# Voorbeeld van een baselineprofiel voor een klantenservicechatbot
baseline = {
"input_tokens": {"mean": 180, "median": 150, "p95": 450, "p99": 800},
"output_tokens": {"mean": 220, "median": 180, "p95": 600, "p99": 1200},
"io_ratio": {"mean": 0.82, "std": 0.35},
"latency_ms": {"mean": 850, "p50": 720, "p95": 2100, "p99": 4500},
"finish_reasons": {"stop": 0.89, "length": 0.08, "content_filter": 0.03},
"requests_per_hour_per_user": {"mean": 8, "p95": 25, "p99": 45}
}Afwijkende patronen detecteren
Patroon 1: Tokenaantal-anomalieën
Abnormale tokenaantallen zijn een van de sterkste signalen in inferentielogs.
| Anomalie | Mogelijke indicatie | Onderzoeksactie |
|---|---|---|
| Ongebruikelijk hoog aantal invoertokens | Prompt stuffing, exploitatie van contextvenster, many-shot jailbreaking | Bekijk promptinhoud op geïnjecteerde instructies |
| Ongebruikelijk hoog aantal uitvoertokens | Data-exfiltratie, model produceert inhoud buiten normale grenzen | Bekijk uitvoerinhoud op gelekte data |
| Plotselinge daling in uitvoertokens | Contentfilter blokkeert, modelweigering | Controleer finish reason en classifier-logs |
| Piek in invoer-/uitvoerverhouding | Korte invoer die zeer lange uitvoer produceert (mogelijke extractie) | Inhoudsreview met hoge prioriteit |
| Consequent uitvoer op maximale lengte | Geautomatiseerde extractie, herhaaldelijk generatielimieten raken | Controleer op geautomatiseerde toegangspatronen |
# Detecteer tokenaantal-anomalieën met behulp van z-score
import numpy as np
def detect_token_anomalies(log_entries, baseline, z_threshold=3.0):
anomalies = []
for entry in log_entries:
input_z = (entry.input_tokens - baseline["input_tokens"]["mean"]) / baseline["input_tokens"]["std"]
output_z = (entry.output_tokens - baseline["output_tokens"]["mean"]) / baseline["output_tokens"]["std"]
if abs(input_z) > z_threshold or abs(output_z) > z_threshold:
anomalies.append({
"request_id": entry.request_id,
"input_z": input_z,
"output_z": output_z,
"timestamp": entry.timestamp,
"user_id": entry.user_id
})
return anomaliesPatroon 2: Jailbreak-indicatoren in metadata
Zelfs zonder inhoud suggereren bepaalde metadatapatronen jailbreak-pogingen.
| Metadatapatroon | Jailbreak-indicator | Betrouwbaarheid |
|---|---|---|
| Meerdere verzoeken met toenemend aantal invoertokens van dezelfde gebruiker | Multi-turn contextopbouw voor geleidelijke escalatie | Gemiddeld |
| Contentfilter geactiveerd, gevolgd door geslaagd verzoek | Aanvaller verfijnt payload om filter te omzeilen | Hoog |
| Snelle opeenvolging van verzoeken met vergelijkbare lengte | Geautomatiseerd jailbreak-testen | Hoog |
| Zeer hoog aantal invoertokens met zeer laag aantal uitvoertokens | Stuffing-aanval gevolgd door modelweigering | Gemiddeld |
Verzoek met finish_reason: content_filter gevolgd door dezelfde gebruiker die invoertokens vermindert | Aanvaller heeft de triggerende inhoud geïdentificeerd en verwijdert deze | Hoog |
| Ongebruikelijke temperature- of parameterwaarden | Poging om outputwillekeur te verhogen voor jailbreak-betrouwbaarheid | Laag-gemiddeld |
Patroon 3: Exfiltratiepatronen
Data-exfiltratie via modeloutputs heeft kenmerkende metadatasignaturen.
| Patroon | Beschrijving | Detectiequery |
|---|---|---|
| Lage invoer-/hoge uitvoerverhouding | Korte prompts die lange uitvoer produceren | WHERE input_tokens < 50 AND output_tokens > 1000 |
| Sequentiële extractie | Reeks verzoeken met monotoon toenemende context | Groepeer per sessie, controleer op toenemende invoertokens |
| Hit-rate-anomalie | Piek in verzoeken met specifieke uitvoertoken-aantallen | Histogram van uitvoertokens toont ongebruikelijke clustering |
| Sessielengte-anomalie | Sessies met veel meer beurten dan typisch | WHERE turn_count > baseline.p99_turns |
Patroon 4: Latentieanomalieën
Latentiemetingen kunnen adversariële activiteit onthullen die onzichtbaar is in andere metrieken.
| Anomalie | Mogelijke oorzaak | Onderzoeksactie |
|---|---|---|
| Ongebruikelijk hoge latentie voor normale tokenaantallen | Adversariële invoer die complexere berekening veroorzaakt | Bekijk invoer op adversariële tokens of coderingen |
| Latentiepieken gecorreleerd met specifieke gebruikers | Gebruiker verstuurt computationeel dure invoer | Profileer de verzoekpatronen van de gebruiker |
| Geleidelijke latentietoename in de loop van de tijd | Modeldegradatie of toenemende contextgroottes | Controleer op uitputtingspatronen van het contextvenster |
| Piek in first-token-latentie | Ongebruikelijk complexe promptverwerking | Kan wijzen op prompt-injectie met complexe formattering |
| Consequent lage latentie met hoge uitvoer | Gecachete of voorberekende responses (mogelijke modelcompromittering) | Verifieer modelintegriteit; controleer op output-caching-bugs |
Tijdreeksanalyse
Het analyseren van inferentielogs als tijdreeksdata onthult patronen die onzichtbaar zijn in analyse op individueel verzoekniveau.
Rolling window-analyse
# Detecteer verschuivingen in modelgedrag met behulp van rolling statistics
import pandas as pd
def rolling_behavior_analysis(df, window="1h"):
rolling = df.set_index("timestamp").rolling(window)
metrics = pd.DataFrame({
"mean_output_tokens": rolling["output_tokens"].mean(),
"mean_input_tokens": rolling["input_tokens"].mean(),
"content_filter_rate": rolling["content_filter_triggered"].mean(),
"error_rate": rolling["is_error"].mean(),
"mean_latency": rolling["latency_ms"].mean()
})
# Markeer vensters waar metrieken significant afwijken van de baseline
alerts = metrics[
(metrics["content_filter_rate"] > baseline_filter_rate * 3) |
(metrics["mean_output_tokens"] > baseline_output_p95) |
(metrics["error_rate"] > baseline_error_rate * 5)
]
return alertsCorrelatieanalyse
Het kruiscorreleren van metrieken onthult patronen die analyse op één metriek mist:
| Correlatie | Signaal |
|---|---|
| Hoog aantal invoertokens + contentfilter-triggers | Prompt-injectiepogingen met safety-bypass-payloads |
| Lage latentie + hoog aantal uitvoertokens | Mogelijk gecachete of voorberekende responses (afwijkend) |
| Toenemend foutpercentage + dalend verzoekvolume | Aanvaller stuit op fouten en trekt zich terug |
| Toename in sessielengte + toename in uitvoertokens | Progressieve extractie over langdurige sessies |
Geautomatiseerde detectiequery's
SQL-gebaseerde detectie
Voor organisaties die inferentielogs in een opvraagbare database opslaan:
-- Detect potential jailbreak attempts: content filter triggers
-- followed by successful requests from the same user
SELECT
a.user_id,
a.timestamp AS blocked_at,
b.timestamp AS succeeded_at,
b.output_tokens,
EXTRACT(EPOCH FROM b.timestamp - a.timestamp) AS seconds_between
FROM inference_logs a
JOIN inference_logs b ON a.user_id = b.user_id
AND b.timestamp > a.timestamp
AND b.timestamp < a.timestamp + INTERVAL '10 minutes'
WHERE a.finish_reason = 'content_filter'
AND b.finish_reason = 'stop'
AND b.output_tokens > 500
ORDER BY a.timestamp DESC;
-- Detect potential data exfiltration: low input, high output
SELECT
user_id,
session_id,
COUNT(*) AS request_count,
AVG(input_tokens) AS avg_input,
AVG(output_tokens) AS avg_output,
AVG(output_tokens::float / NULLIF(input_tokens, 0)) AS avg_ratio
FROM inference_logs
WHERE timestamp > NOW() - INTERVAL '24 hours'
GROUP BY user_id, session_id
HAVING AVG(output_tokens::float / NULLIF(input_tokens, 0)) > 10
AND COUNT(*) > 5
ORDER BY avg_ratio DESC;Beperkingen van analyse op uitsluitend metadata
Inferentielog-analyse heeft inherente beperkingen die moeten worden erkend:
| Beperking | Impact | Mitigatie |
|---|---|---|
| Geen inhoudszichtbaarheid | Kan niet bepalen of outputs gevoelige data bevatten | Combineren met analyse van prompt-/completion-logs |
| False positives | Legitieme lange gesprekken lijken op extractie | Correleren met inhouds- en gebruikersgedragsanalyse |
| Geavanceerde aanvallers | Kunnen normale tokenverdelingen nabootsen | Meerdere detectiemethoden gelaagd toepassen |
| Modelvariabiliteit | Uitvoerlengte varieert van nature, wat ruis creëert | Gebruik per-eindpunt-baselines met voldoende historie |
Gerelateerde onderwerpen
- Prompt-log-forensics -- analyse op inhoudsniveau die metadata-analyse aanvult
- Tool call-forensics -- onderzoek van agentacties
- Severity-framework -- het scoren van incidenten ontdekt via loganalyse
Referenties
- "Anomaly Detection in Time Series Data" - IEEE (2024) - Statistical methods for time-series anomaly detection applicable to inference logs
- "OpenTelemetry Semantic Conventions for GenAI" - OpenTelemetry (2025) - Standardized metrics for AI inference monitoring
- "Detecting LLM Abuse Through API Monitoring" - arXiv:2501.xxxxx (2025) - Research on metadata-based abuse detection
Een gebruiker verstuurt 12 verzoeken in 5 minuten. De eerste 3 activeren contentfilters. De volgende 9 slagen met progressief kortere invoertokens en consequent lange uitvoertokens. Wat wijst dit patroon het meest waarschijnlijk aan?