A klasszikus APM (Application Performance Monitoring) eszközök — New Relic, Datadog APM, Prometheus — arra lettek optimalizálva, hogy determinisztikus rendszereket figyeljenek: HTTP kérések, adatbázis-lekérdezések, CPU és memória. Tiszta sor, érthető, mérhető.
Az LLM rendszerek viszont egy másik világ. Ezek sztochasztikusak: ugyanaz a prompt két futtatás között eltérő kimenetet adhat. A hibák gyakran csendesek — a rendszer szépen válaszol, látszólag minden rendben, csak épp rossz választ ad. És ami a legidegesítőbb: a költségek tokenalapúak, nem kérésalapúak, szóval egy elszabadult retry-loop hajnali háromkor simán le tudja csapolni a havi budgetet.
Az LLM observability három rétege (legalábbis ahogy én gondolkodom róla):
- Tracing (nyomkövetés): minden LLM-hívás, eszközhívás, retrieval lépés és ágens döntés strukturált rögzítése — prompt, válasz, tokenszám, késleltetés, hibák.
- Metrics (metrikák): aggregált mérőszámok — átlagos latency, p95/p99, költség időegységenként, sikerességi arány, user feedback score.
- Evaluation (értékelés): a kimenet minőségének automatizált mérése — hallucináció-detekció, relevancia, faithfulness, custom LLM-as-judge scorer-ek.
A sorrend nem véletlen. Tracing nélkül a metrics üres zaj, és eval nélkül gyakorlatilag vakon repülsz.
A három platform áttekintése
Langfuse — nyílt forráskódú, önhosztolható
A Langfuse 2026-ra a legelterjedtebb nyílt forráskódú LLM observability platform lett, 19 000+ GitHub csillaggal és MIT licenccel. Framework-független: natív SDK-k Python és JavaScript nyelvhez, plusz integrációk 50+ keretrendszerhez (LangChain, LlamaIndex, OpenAI SDK, Anthropic SDK, CrewAI, AutoGen). OpenTelemetry-re épül, tehát elosztott trace-eket is tud kezelni mikroszolgáltatásos architektúrákban — ez kifejezetten jól jön, ha az ágenseid több service-en keresztül futnak.
Adatmodell: traces → observations → sessions. Az observations típusokkal rendelkeznek (generation, tool call, retrieval, span), és tetszőlegesen beágyazhatók. Szóval ha van egy ágensed, ami magát hívogatja újra meg újra, a fa struktúra tisztán megmarad.
LangSmith — LangChain natív platform
A LangChain csapata által fejlesztett kereskedelmi observability és evaluation suite. Ha a stack teljes egészében LangChain + LangGraph alapú, a LangSmith adja a legjobb out-of-the-box élményt: automatikus trace capture, LangGraph Studio integráció, human-in-the-loop annotation queue-k. 2026 áprilisában a LangGraph Studio már közvetlenül a Playground-ról képes ágens prompt módosításokat visszapush-olni (ezt én magam is kipróbáltam — meglepően zökkenőmentes).
Arize Phoenix — OpenTelemetry-natív, nyílt forráskódú
Az Arize AI nyílt forráskódú projektje. Fő különbség: beépített drift- és klaszter-vizualizáció, embedding-alapú anomáliadetekció. Natívan OpenInference (OpenTelemetry-alapú szemantikai konvenció) nyomkövetésre épít, így teljes mértékben vendor-neutral. Lokálisan egy paranccsal indítható fejlesztéshez, de production-ban self-hostolható, vagy az Arize AX-be pluggelhető — attól függ, mennyire kell a managed élmény.
Telepítés és első integráció
Langfuse — önhosztolt Docker Compose
A leggyorsabb út egy lokális Langfuse példányhoz:
git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d
A webes felület a http://localhost:3000 címen érhető el. Hozz létre egy projektet, majd generálj egy LANGFUSE_PUBLIC_KEY és LANGFUSE_SECRET_KEY párost. (Pro tipp: ha első nekifutásra nem indul minden service, nyugalom — Postgres és a ClickHouse tipikusan kérnek pár másodperc türelmi időt.)
Python integráció OpenAI-hoz (dekorátor-alapú, ami szerintem a legelegánsabb megközelítés):
from langfuse.decorators import observe
from langfuse.openai import openai # drop-in OpenAI wrapper
@observe()
def summarize_document(text: str) -> str:
response = openai.chat.completions.create(
model="gpt-4o-2024-11-20",
messages=[
{"role": "system", "content": "Készíts tömör összefoglalót."},
{"role": "user", "content": text},
],
temperature=0.3,
)
return response.choices[0].message.content
# Környezeti változók:
# LANGFUSE_PUBLIC_KEY=pk-lf-...
# LANGFUSE_SECRET_KEY=sk-lf-...
# LANGFUSE_HOST=http://localhost:3000
result = summarize_document("Hosszú dokumentum szövege...")
Az @observe() dekorátor automatikusan létrehoz egy trace-t, és az OpenAI wrapper minden hívást observation-ként rögzít a prompt, válasz, token-használat és költség részletekkel. Egy sor kód, kész.
LangSmith — egy környezeti változó
A LangSmith a legkevesebb setup-ot igényli, ha már LangChain-t használsz. Ez az egyik legnagyobb erőssége — sokszor tényleg csak három sor a teljes bekötés:
pip install langsmith langchain-openai langchain-core
import os
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_API_KEY"] = "lsv2_pt_..."
os.environ["LANGSMITH_PROJECT"] = "prod-rag-agent"
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
llm = ChatOpenAI(model="gpt-4o-2024-11-20", temperature=0)
prompt = ChatPromptTemplate.from_messages([
("system", "Szakértő technikai asszisztens vagy."),
("user", "{question}"),
])
chain = prompt | llm
result = chain.invoke({"question": "Mi az a RAG?"})
# A trace automatikusan megjelenik a LangSmith UI-ban
Nem LangChain hívások tracelése a @traceable dekorátorral:
from langsmith import traceable
from openai import OpenAI
client = OpenAI()
@traceable(run_type="llm", name="generate_answer")
def generate_answer(question: str, context: str) -> str:
response = client.chat.completions.create(
model="gpt-4o-2024-11-20",
messages=[
{"role": "system", "content": f"Kontextus: {context}"},
{"role": "user", "content": question},
],
)
return response.choices[0].message.content
Arize Phoenix — egy parancsos lokális indítás
pip install arize-phoenix openinference-instrumentation-openai
import phoenix as px
from openinference.instrumentation.openai import OpenAIInstrumentor
from phoenix.otel import register
# Phoenix lokális UI indítása
session = px.launch_app() # http://localhost:6006
# OpenTelemetry tracer provider regisztrálása
tracer_provider = register(
project_name="production-agent",
endpoint="http://localhost:6006/v1/traces",
)
# Automatikus OpenAI instrumentáció
OpenAIInstrumentor().instrument(tracer_provider=tracer_provider)
# Innentől minden OpenAI hívás trace-elve van
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o-2024-11-20",
messages=[{"role": "user", "content": "Írj egy haikut a Pythonról."}],
)
A Phoenix erőssége, hogy ugyanez a kód production-ban az Arize AX cloud endpoint-ra irányítható — csak az endpoint-ot és az autentikációs headert kell cserélni, a kód változatlan marad. Nekem ez a "lokálból egyenesen prodba" élmény az, ami miatt megkedveltem.
Evaluation — LLM-as-judge gyakorlatban
A tracing csak az első lépés. Valljuk be őszintén: attól, hogy látod a hívásokat, még nem tudod, hogy jók-e. A valódi érték a kimenet minőségének automatizált mérése. Példa Langfuse-szal egy RAG válasz relevanciájának scorelására:
from langfuse import Langfuse
from openai import OpenAI
langfuse = Langfuse()
openai_client = OpenAI()
JUDGE_PROMPT = """Ítéld meg a VÁLASZ relevanciáját a KÉRDÉS szempontjából.
Add vissza egy számot 0.0 és 1.0 között, ahol:
- 1.0 = tökéletesen releváns, pontosan megválaszolja a kérdést
- 0.5 = részben releváns
- 0.0 = nem releváns
KÉRDÉS: {question}
VÁLASZ: {answer}
Válasz csak a számmal:"""
def judge_relevance(trace_id: str, question: str, answer: str):
judge_response = openai_client.chat.completions.create(
model="gpt-4o-mini",
messages=[{
"role": "user",
"content": JUDGE_PROMPT.format(question=question, answer=answer),
}],
temperature=0,
)
score = float(judge_response.choices[0].message.content.strip())
langfuse.score(
trace_id=trace_id,
name="relevance",
value=score,
comment="LLM-as-judge relevance score",
)
return score
Ugyanez LangSmith-ben egy evaluator függvényként:
from langsmith.evaluation import evaluate
from langsmith.schemas import Example, Run
def relevance_evaluator(run: Run, example: Example) -> dict:
question = example.inputs["question"]
answer = run.outputs["output"]
# ... ugyanaz a judge logika ...
return {"key": "relevance", "score": score}
results = evaluate(
lambda inputs: my_rag_chain.invoke(inputs),
data="production-qa-dataset",
evaluators=[relevance_evaluator],
experiment_prefix="rag-v2-eval",
)
Apró megjegyzés tapasztalatból: temperature=0 a judge prompthoz kritikus. Különben heti összehasonlításaidnak zaj lesz a fele.
Feature-összehasonlító táblázat (2026. április)
| Funkció |
Langfuse |
LangSmith |
Arize Phoenix |
| Licenc | MIT (OSS) | Kereskedelmi | Elastic 2.0 (OSS) |
| Self-hosting | ✅ Docker / K8s | ⚠️ Enterprise only | ✅ Docker / K8s |
| Framework | Agnosztikus (50+) | LangChain-first | Agnosztikus (OpenInference) |
| OpenTelemetry | ✅ Natív | ⚠️ Részleges | ✅ Natív alap |
| Prompt management | ✅ Verziózás + Playground | ✅ Verziózás + Playground | ⚠️ Korlátozott |
| Beépített eval metrikák | ⚠️ Custom / külső | ✅ Beépített set | ✅ Ragas, Phoenix evals |
| Embedding drift detection | ❌ | ❌ | ✅ Natív |
| LangGraph integráció | ✅ Jó | ✅ Natív (Studio) | ✅ Jó |
| Árazás (Cloud) | Ingyenes → $29/hó | Ingyenes → $39/user/hó | Ingyenes (OSS) |
| Enterprise | $2499/év-től | Egyedi | Arize AX egyedi |
Production monitoring best practices 2026-ban
1. Logolj mindent — a tárolás olcsó, a hiányzó adat drága
Rögzíts minden kérést: input, output, metaadatok (user ID, session ID, request ID), timestamp, modellverzió, temperature. Ha egy éjszaka 2 óra 17 perckor egy user furcsa választ kap, a traces-eket akkor is látnod kell, amikor reggel kinyitod a laptopot. Ezt én már kétszer tanultam meg a nehezebbik úton — nem ajánlom harmadszor.
2. Állíts költségkereteket és alerteket 50/80/100%-os küszöbökkel
Egy elszabadult prompt-ciklus egyetlen éjszaka alatt több ezer dollárba kerülhet. Konfigurálj napi és havi spending alert-eket mind a provider oldalán (OpenAI usage limits), mind az observability platformon. A Langfuse és a LangSmith is tud projekt-szintű költség-alertet küldeni Slack-re vagy PagerDuty-ra.
3. Verziózd a promptokat — minden trace mutasson prompt verzióra
Amikor egy felhasználó azt mondja, "ez a válasz régen jobb volt", tudni akarod pontosan melyik prompt verzió generálta. A Langfuse Prompt Management és a LangSmith Prompt Hub is támogatja a verziózást, A/B tesztelést és a rollback-et. Higgyetek nekem, az "ez rendben volt tegnap" típusú bug-ok a legidegőrlőbbek.
4. Figyelj a csendes hibákra — latency önmagában nem elég
Az LLM rendszerek legveszélyesebb hibái csendesek: a rendszer 200 ms alatt válaszol, az error rate 0%, de a válaszok tartalma rossz. Csak automatizált eval-ek (LLM-as-judge, hallucinációs classifier, user feedback score) tudják elkapni ezeket.
5. Kövesd a token efficiency trendet
Ha az átlagos input tokenszám hétről-hétre 10%-kal nő, valaki prompt-bloat-ot termel: hosszabb system prompt, több few-shot példa, nagyobb retrieval context. Állíts be dashboardot az átlagos token/kérés metrikára, és vizsgálj ki minden 15%-nál nagyobb növekedést. (Általában egy jóindulatú PR áll mögötte, ami "csak egy példát" tett hozzá a promptoz. Ötszázszor.)
6. Mélyreható tracing többlépéses ágensekhez
Egy 8 lépéses ReAct ágens esetén, ha csak a végső outputot loggolod, nem fogod tudni megmondani, hogy a hallucináció a retrieval step-nél, az első reasoning-nél vagy a végső generálásnál történt. Használj nested span-eket minden tool-hívásra és intermediate reasoning-re.
7. Zárd be a loop-ot production és development között
A leghasznosabb minta (és amelyik tényleg megváltoztatja az életed): a production trace-ekből, ahol a user thumbs-down-ot adott, automatikusan létrejön egy eval dataset bejegyzés. Ezt CI-ben futtatja le minden prompt change, és ha a score regressziót mutat, a deploy blokkolódik.
Mikor melyiket válaszd?
Válaszd a Langfuse-t, ha…
- adatrezidenciai követelmények miatt self-hostolnod kell (EU GDPR, egészségügy, pénzügy)
- nem LangChain stack-et használsz, vagy vegyes stack van (CrewAI, LlamaIndex, direkt OpenAI SDK)
- framework-független, OpenTelemetry-alapú megoldást akarsz
- nulla licencköltséggel akarsz indulni, és csak a hosting-ért fizetsz
Válaszd a LangSmith-et, ha…
- teljes egészében LangChain + LangGraph a stack-ed
- LangGraph Studio-t használsz ágensfejlesztéshez
- human-in-the-loop annotation queue és managed eval infrastruktúra kell
- nem akarsz infrastruktúrát üzemeltetni, és a $39/user/hó belefér
Válaszd az Arize Phoenix-et, ha…
- embedding drift és klaszter-anomália detekció kritikus (pl. termelési RAG quality monitoring)
- már az Arize AX ML observability platformot használod klasszikus ML-hez
- tiszta OpenTelemetry/OpenInference stack-et akarsz, amelyet bármelyik vendor-ba pluggelhetsz
Hibrid stratégia
2026-ban a csapatok nagy része két platformot használ párhuzamosan: egy OpenTelemetry-alapú general-purpose APM-et (Datadog LLM Observability vagy Honeycomb) az infra metrikákhoz, és egy LLM-specifikus eszközt (Langfuse vagy LangSmith) a prompt/eval/dataset workflow-hoz. Az OpenTelemetry szabvány miatt ez 2026-ban már egyetlen instrumentációval megoldható. Én ezzel a hibrid felállással dolgozom — és tényleg ritka, hogy valamit ne találok meg öt perc alatt.
Gyakran ismételt kérdések (GYIK)
Mi a különbség az LLM observability és az LLM monitoring között?
A monitoring reaktív: azt mondja meg, hogy a rendszered fut-e (latency, error rate, uptime). Az observability proaktív és explanatív: a tracing, metrics és evaluation kombinációjával meg tudod magyarázni, miért viselkedik a rendszered úgy, ahogy — beleértve a csendes minőségi problémákat is. 2026-ban a production-ready AI stack mindkettőt igényli, és a vezető platformok mindkettőt egyben szállítják.
Lehet-e Langfuse-t és LangSmith-et egyszerre használni?
Igen, de ritkán van értelme. A tracing-dupla tárolás, dupla költség. Ha OpenTelemetry-alapú kódot írsz (pl. OpenInference SDK), egyszerre több backend-re is tudod küldeni ugyanazt a trace-t, de a prompt management és eval dataset-ek nem fognak szinkronban lenni. Gyakoribb minta: egy platformon állapodnak meg csapat-szinten, plusz egy infra-oldali APM (pl. Datadog) az infrastruktúra-metrikákhoz.
Mekkora overhead-et jelent az observability egy LLM hívásra?
Tipikusan 5-50 ms közötti end-to-end overhead, amit a trace aszinkron batch-ben küld egy background worker thread-en keresztül. Az LLM hívás maga általában 500-3000 ms, tehát az observability overhead-je jellemzően <2% a teljes request time-ból. Production-ban javasolt a batch mode és sampling beállítása magas QPS esetén (pl. 10% trace sampling 1000 QPS felett).
Megfelelő-e a Langfuse cloud GDPR szempontjából?
A Langfuse Cloud két régióban üzemel (EU: Frankfurt; US: Virginia), és a EU régió GDPR-kompatibilis, SOC 2 Type II tanúsítvánnyal. Ha a payload-ok érzékeny személyes adatot tartalmaznak (pl. egészségügyi, jogi), a self-hosted Langfuse a biztonságosabb választás, mivel az adat soha nem hagyja el az infrastruktúrádat. A Langfuse SDK támogatja a PII masking-et kliens oldalon is, a küldés előtt.
Hogyan mérjem egy RAG pipeline minőségét a tracing-en túl?
Három kulcs metrika production RAG-hez: (1) retrieval relevance — a top-k dokumentum mennyire releváns a kérdésre (cosine similarity threshold vagy LLM judge); (2) answer faithfulness — a generált válasz támaszkodik-e ténylegesen a retrieved contextre, vagy hallucinál; (3) answer relevance — a válasz mennyire felel meg a felhasználó szándékának. A Ragas library (Arize Phoenix-szal natívan integrált) mindhármat out-of-the-box szállítja, LLM-as-judge módban.
Összefoglalás
Az LLM observability 2026-ban már nem opcionális infrastruktúra: a production AI rendszerek elvárt alaprétege. A három vezető platform más-más erősséget hoz:
- Langfuse — a nyílt forráskódú, framework-független alapértelmezés, ha self-hosting vagy vegyes stack a követelmény.
- LangSmith — a legmélyebb LangChain + LangGraph integráció, ágens-fejlesztői workflow-kkal.
- Arize Phoenix — embedding drift detection és klasszikus ML observability együtt, OpenTelemetry-natív alappal.
Függetlenül attól, melyiket választod, a három technikai alapelv ugyanaz: tracelj mindent nested span-ekkel, verziózd a promptokat, és automatizált eval-ekkel szűrd a csendes minőségi hibákat. Ez a három szokás — nem az eszközválasztás — dönti el, hogy a production AI rendszered megbízható lesz-e vagy sem. A tool-háború csak zaj; a disciplína a valuta.
