A klasszikus szoftver, ha hibás, hibaüzenetet ad. Az LLM, ha hibás, magabiztosan ad rossz választ. Ezt csak observability-vel találod meg.
Miért nem elég a Datadog?
A klasszikus szoftver-observability három pilléren áll: logok, metrikák, trace-ek. Erre épült az APM-iparág (Datadog, New Relic, Dynatrace), és a kérdések is mindig ugyanazok: „hol lassú?", „hol hibázik?", „hol szakad meg a request?".
LLM-alapú rendszerekben ezek a pillérek megmaradnak — de nem elegek. Mert az LLM:
- nem dob exception-t, ha rossz a válasz,
- nem ad HTTP 500-at, ha hallucinál,
- nem írja a logba, hogy „bizonytalan voltam",
- és időnként jól, időnként rosszul válaszol ugyanarra a promptra.
A klasszikus monitoring szépen látja, hogy a request lefutott 1,8 másodperc alatt, 200 OK-val, 4500 tokenért. Csak épp azt nem látja, hogy a válasz értelmetlen volt, hallucináció, vagy elveszett a kontextus.
Ehhez kell az LLM observability — egy új réteg a klasszikus három pillér fölött, ami a válasz minőségét és a modell viselkedését is méri. Ez a cikk arról szól, mit érdemes mérni, milyen eszközökkel, és milyen stratégiai döntéseket kell végiggondolni egy production LLM-rendszer observability-jénél.
Az LLM observability öt dimenziója
A klasszikus három pillért (logs, metrics, traces) ötre kell kibővíteni:
Az utolsó kettő a valódi újdonság — és ez az, ami a legtöbb csapatnál egyszerűen hiányzik.
Tracing: minden LLM-hívás látszik
Az „LLM call tree"
Egy modern AI-rendszer egyetlen user request alatt akár 20-50 LLM- vagy tool-hívást is megejt. Valahogy így:
User: "Foglalj egy asztalt holnap estére 4 főre"
↓ (Trace ID: abc123)
├─ [LLM] Query understanding (gpt-4o-mini, 320ms, 145 tokens)
├─ [Tool] check_user_history (DB, 25ms)
├─ [LLM] Plan generation (gpt-4o, 850ms, 1200 tokens)
├─ [Tool] search_availability (API, 180ms)
├─ [LLM] Reply generation (gpt-4o, 1,2s, 800 tokens)
└─ [Tool] send_confirmation (SMS, 95ms)
Total: 2,67s, 2145 tokens, $0,034
Ha csak a végső választ logolod, fogalmad sincs, hol romlott el valami. Ha minden lépést trace-elsz, konkrétan látod: a search_availability 5 másodpercig várt egy lassú API-ra, azért lett 7 másodperces az egész válaszidő — nem a modell volt lassú.
OpenTelemetry + LLM-specifikus attribútumok
A jó gyakorlat: OpenTelemetry szabványt használsz, LLM-specifikus attribútumokkal. Így a tracing nem egy egyedi, házi formátum, hanem bármely vendor tooljával olvasható.
import { trace, SpanStatusCode } from "@opentelemetry/api";
const tracer = trace.getTracer("ai-agent");
async function callLLM(messages: Message[], model: string) {
return tracer.startActiveSpan("llm.completion", async (span) => {
span.setAttributes({
"llm.vendor": "openai",
"llm.model": model,
"llm.input.messages_count": messages.length,
"llm.input.tokens": countTokens(messages),
"llm.request.temperature": 0.2,
"llm.request.max_tokens": 2000,
});
try {
const response = await openai.chat.completions.create({ /* ... */ });
span.setAttributes({
"llm.output.tokens": response.usage.completion_tokens,
"llm.output.total_tokens": response.usage.total_tokens,
"llm.output.finish_reason": response.choices[0].finish_reason,
"llm.cost.usd": calculateCost(model, response.usage),
});
span.setStatus({ code: SpanStatusCode.OK });
return response;
} catch (e) {
span.recordException(e);
span.setStatus({ code: SpanStatusCode.ERROR, message: e.message });
throw e;
} finally {
span.end();
}
});
}
A 2024–25-ben formálódott OpenTelemetry GenAI semantic conventions szabványos attribútumneveket ad. Érdemes követni, mert a vendor tooling erre épül — és így nem ragadsz be egy proprietary formátumba.
A 12 KPI, amit folyamatosan mérni kell
Nem kell mindet egyszerre bevezetni — de hosszú távon ezek azok a számok, amik visszajeleznek, hogy a rendszer él vagy haldoklik.
Teljesítmény-KPI-k
1. Latency (P50, P95, P99) — per LLM-call és per end-to-end user request. A P95–P50 közti szakadék mutatja meg, „van-e nagyon rossz pillanat".
2. Time to First Token (TTFT) — streaming esetén kritikus. 600 ms alatt „azonnali" érzés, 1,5 másodperc felett már „lassú".
3. Tokens per second (TPS) — a generálás sebessége a TTFT után. 50+ TPS már kényelmes olvasási élmény.
Költség-KPI-k
4. Cost per user request — átlag és P95, heti trenddel. Csendben szokott emelkedni.
5. Cost per business outcome — például „cost per successful booking", „cost per qualified lead". Sokkal informatívabb, mint a per-token cost: ez az, amit a CFO megért.
6. Token usage breakdown — input vs. output, cached vs. uncached (prompt caching!), modell szerint (mennyi megy gpt-4o-ra vs. gpt-4o-mini-re).
Minőségi KPI-k
7. Faithfulness (RAG esetén) — a válasz csak a kontextusra támaszkodik, vagy „kitalál"? LLM-as-a-judge méri.
8. Hallucination rate — hány válaszban van nem alátámasztott állítás? Citation-validációval mérhető.
9. Schema/format compliance — a strukturált output milyen arányban valid? Cél: 99% felett.
10. Tool call success rate — a tool-hívások hány %-a sikeres? A hibák feloszthatóak: rossz paraméter (LLM hibája) vs. valós error (tool hibája).
Felhasználói KPI-k
11. User feedback rate ( / ) — hány %-ban ad a user explicit feedbacket? Az alacsony rate (1–3%) nem rossz — a leszavazás viszont aranybánya, mert azok pontosan azok a pillanatok, amikor valami fájt a usernek.
12. Task completion rate — hány session végződik sikeresen (foglalás, vásárlás, megoldott kérdés)? Ez a végső üzleti KPI; minden más csak proxy.
Eszközválasztás: build, buy vagy hibrid?
Nem kell scratch-ből építeni — a piac telített, és van mindenkinek való.
A stratégiai vonalak:
- Buy (SaaS, pl. LangSmith): gyors indulás, kevés DevOps. Ára van, de időt vásárolsz.
- Self-host open source (Langfuse, Phoenix): adatszuverenitás és költségkontroll. Cserébe valakinek karban kell tartani.
- Build on OTel: ha már van observability stacked, és csak az LLM-réteget toldod hozzá. Akkor ér meg, ha a csapatnak van OTel-tapasztalata.
A legrosszabb döntés a „majd később megcsináljuk". Hat hónap múlva már 100 000 trace fog hiányozni, és utólag senki nem fogja tudni rekonstruálni, miért romlott el a Q1-es ügyfélélmény.
Online vs. offline evaluation
Két dolog, amit gyakran összekevernek:
Offline eval fejlesztés közben fut. Fix dataset (50–500 kérdés-válasz pár), CI/CD-ben pörög, regressziót detektál. A kérdés: „az új prompt jobb-e, mint a régi?"
Online eval production-ben fut. Élő forgalmon, real-time, sampling-alapon (minden hívást túl drága lenne). Drift-et detektál. A kérdés: „az élő válaszok minősége tartja-e magát?"
A kettő nem helyettesíti egymást — kiegészítik. Az offline eval a deploy előtti regressziót fogja meg, az online eval a deploy utáni driftet (új user behavior, új edge case-ek, vendor csendes modell-frissítései).
LLM-as-a-judge production-ben
// 1% sampling rate — produkcióból
if (Math.random() < 0.01) {
const judgeScore = await tracer.startActiveSpan(
"llm.eval.judge",
async () => {
return await llm.generate({
model: "gpt-4o-mini", // olcsóbb judge
messages: [{
role: "system",
content: `Értékeld a választ 1-5 skálán:
- relevance
- faithfulness (csak a forrásra támaszkodik?)
- completeness
JSON-ban válaszolj.`
}, {
role: "user",
content: JSON.stringify({ query, context, response })
}],
response_format: { type: "json_object" }
});
}
);
await metrics.recordEvalScore(traceId, judgeScore);
}
Vigyázat: az LLM-as-a-judge sem tökéletes — körülbelül 80–90% korrelációt ér el emberi értékeléssel. Vannak biasai, és önmagát kicsit elnézi. Időről időre kalibráld emberi reviewerek mintáján, mielőtt ground truthnak hinnéd.
Debugging — amikor valami szétesik
Három forgatókönyv a production gyakorlatból:
„Hirtelen rossz lett a minőség"
Lehet csendes modell-update a vendor oldalán (az OpenAI gyakran így frissít). Lehet új user behavior (új prompt-mintázat, amire nem készültél). És lehet RAG corpus drift is — új dokumentumok kerültek be, amik elnyomják a régieket a top-K találatból.
Debugging útvonal: trace-ek áttekintése a romlás időszakából → diff a régi (jó) és új (rossz) válaszok között → eval suite újrafuttatása (még átmegy?) → vendor changelog ellenőrzése.
„Egy bizonyos user vagy kérdés mindig elhasal"
Edge case, ami nem volt az eval suite-ban. Lehet egyedi prompt injection vagy szokatlan input — ritkán permission/context-leak.
Debugging útvonal: reprodukció ugyanazzal a session ID-val → full trace áttekintése (melyik lépés hibázott?) → prompt és context újrajátszása offline környezetben → eval suite bővítése ezzel a case-szel, hogy ne ismétlődjön.
„Költség elszállt"
Új user behavior nagyobb token-igénnyel; sikertelen retry-loop (a hibás kérés többször indul újra); új feature, ami nagyobb kontextust használ; vagy egyszerűen lecsökkent a cache hit-rate.
Debugging útvonal: top-1% legdrágább trace áttekintése → token-trend per endpoint → retry-counter (van-e infinite loop?) → cache hit-rate mérése.
Stratégiai döntések — mit válassz?
Mit logoljunk?
Mindent logolni drága és privacy-érzékeny. Semmit logolni vakvágány. A gyakorlatban beváló receptura:
- Mindig logold a metaadatot: trace ID, user ID, latency, cost, model.
- Sampling-szerűen (1–10%): full prompt + response.
- Soha ne logold nyersen: PII, kártyaszám, jelszó — előbb redactold.
Hol tároljuk?
- Hot storage (utolsó 30 nap): gyors lekérdezésre, debughoz.
- Cold storage (1 év): audit, compliance, retrospektív elemzés.
- Discard egy év fölött: GDPR és költség.
A Langfuse és a Phoenix támogatja a tiered storage-et out-of-the-box — ezt felesleges magadnak megírni.
Ki látja?
- Engineering: teljes hozzáférés tracinghez, debugginghez.
- Product: aggregált KPI-k, user feedback.
- Compliance: audit log, PII-leak detekció.
- Customer support: csak az adott user sessionjei.
A role-based access nem szépészeti kérdés. Az AI-trace-ek gyakran tartalmaznak szenzitív tartalmat (a user mit kérdezett) — egy átláthatatlan engineering tool végül GDPR-incidens lesz.
Mikor szóljon az alert?
Klasszikus alerting: error rate, latency. Az LLM-specifikus alertek viszont mást néznek:
A roadmap — hogyan építsd fel fokozatosan?
Nem kell a teljes stack-et day 1-en bevezetni. A reális menetrend:
Hónap 1: tracing alap
- LLM-observability vendor választása vagy Langfuse self-host
- Minden LLM/tool-hívás trace-elése (OTel)
- Basic dashboard: latency, cost, error rate
Hónap 2: evaluation alap
- Offline eval suite (50–100 kérdés)
- CI/CD integráció — minden prompt-change-nél futás
- Online sampling-alapú LLM-as-a-judge
Hónap 3: user feedback + KPI-k
- Visszajelző gomb minden válasznál
- Task completion KPI-k definíciója
- Cost per business outcome riport
Hónap 4–6: alerting + drift detekció
- A kritikus KPI-kra alerting
- Heti review-ülés a top-1% legrosszabb sessionökkel
- Heti eval-eredmény trend
Hónap 6+: continuous improvement
- A „failed" sessionök kategorizálása
- Eval suite bővítése valós hibákból
- A/B testing infrastruktúra (prompt-verziók, modell-verziók)
A leggyakoribb hibák — amiket érdemes elkerülni
„Majd később observability." A logok utólag nem visszakereshetőek. Day 1-től kell — pont mint a tesztek.
Csak technikai KPI-k. A 200 ms-os latency szuper, ha közben a válasz rossz. A minőségi metrikákat is mérd, különben szépen csillogó dashboardod lesz, miközben a usereid elmenekülnek.
Túl sok PII a logokban. Egy GDPR-audit kínos, ha a logokban 100 000 ügyfél tranzakciója van pucéran. Redactold az inputot és az outputot, mielőtt logolod.
LLM-as-a-judge naivan. A judge maga is hibázhat. Kalibráld emberi mintán, ne tekintsd ground truthnak — különben az „eval score" csak egy szép, megnyugtató, de hazug szám lesz.
Nincs user feedback. A hüvelykujj fel/le a legolcsóbb és legjobb signal. Egy gomb. Ne hagyd ki.
Alert fatigue. Túl sok alert → senki nem reagál. Prioritás és noise reduction kell, különben az on-call mérnök egy hét után némítja az egészet.
Összefoglalás: 7 takeaway
-
A klasszikus observability nem elég — az LLM nem dob hibát, ha rossz választ ad. Külön réteg kell.
-
Öt dimenzió: logs, metrics, traces + evaluations + user feedback. Az utolsó kettő az újdonság.
-
OpenTelemetry + GenAI conventions — szabványkövető tracing, ami minden tool-lal kompatibilis.
-
Tizenkét KPI négy csoportban: teljesítmény, költség, minőség, felhasználói. Ne csak a latency-t mérd.
-
Offline + online eval együtt: CI/CD-ben regresszió-tesztelés, production-ben drift-detekció.
-
Vendorválasztás: Langfuse (self-host), LangSmith (LangChain), Datadog (ha már ott vagy). Ne építs nulláról.
-
Az első naptól kell — utólag már nem lehet rekonstruálni. Minden késleltetett observability-döntés több munka, nem kevesebb.
A jó LLM-observability láthatóvá teszi a láthatatlant: a hallucinációt, a kontextus-vesztést, a költség-elszállást, a minőség-driftet. Anélkül vakon repülsz — és csak akkor tudod meg, hogy gond van, amikor egy ügyfél megpanaszolja.
Egy érett AI-csapat többet költ observability-re, mint magára az LLM-hívásokra. Megéri. Mert egy nem-mért rendszer fokozatosan romlik, anélkül hogy észrevennéd — és a felépítés után a romlás visszafordítása többszöröse annak, amibe az observability került volna.
Szeretnéd látni, hogyan néz ki az AIMY-ban az LLM observability stack? Vedd fel velünk a kapcsolatot — megmutatjuk az élő dashboardot és a tracing-mintákat.