LLM Observabilita 2026: Langfuse vs LangSmith vs Helicone — Praktické porovnanie pre produkčných AI agentov

Aktualizované: 16. júna 2026

LLM observabilita znamená kontinuálne sledovanie, logovanie a analýzu volaní jazykových modelov v produkčných aplikáciách: od jednotlivých promptov a tool callov až po náklady, latenciu a kvalitu výstupov. V roku 2026 sú tri dominantné platformy Langfuse, LangSmith a Helicone, a každá má iný profil silných stránok. Langfuse je open-source-first s plne self-hostovateľnou verziou, LangSmith je tesne previazaný s LangChain/LangGraph ekosystémom a Helicone je proxy-based platforma s minimálnou inštrumentáciou. V tomto článku ich porovnám na reálnych workloadoch, na ktorých som ich sám pustil.

• Langfuse v3 ponúka najlepší pomer funkcií k cene, je open-source pod MIT licenciou a podporuje self-hosting cez Docker Compose alebo Kubernetes Helm chart.
• LangSmith je nenahraditeľný, ak používate LangChain alebo LangGraph: automatické tracing bez konfigurácie a hlboká integrácia s evaluation datasetmi.
• Helicone funguje ako HTTP proxy pred OpenAI/Anthropic API, takže ho nasadíte zmenou base URL. Najmenšie nároky na zmenu kódu zo všetkých troch.
• Pre AI agentov s tool callingom je rozhodujúce hierarchické zobrazenie spanov. Langfuse a LangSmith ho zvládajú výborne, Helicone má rovnejší model.
• Self-hosting je realisticky možný len pri Langfuse (komunitná aj enterprise edícia) a Helicone (komunitná edícia). LangSmith je čisto cloudová služba.
• Náklady na 1 milión spanov mesačne sú približne 49 USD pri Langfuse Cloud, 49 USD pri LangSmith Plus a 200 USD pri Helicone Pro. Porovnanie je však netriviálne, lebo definícia "spanu" sa líši.

Prečo potrebujete LLM observabilitu v produkcii

Keď nasadíte AI agenta do produkcie, čoskoro zistíte, že klasické APM nástroje typu Datadog alebo New Relic nestačia. LLM volania majú svoje špecifiká: každý request má iný počet input/output tokenov, latencia rastie lineárne s dĺžkou výstupu, kvalita odpovede nie je binárna a tool calling vytvára hlboké stromy podvolaní. Bez špecializovanej observability platformy sa debugging redukuje na čítanie logov a tipovanie, prečo agent v jednom z piatich behov dal nezmyselný výstup.

V praxi som sa stretol s tromi opakujúcimi sa problémami, ktoré sa bez observability nedajú rozumne riešiť. Prvý je silent regression: zmeníte prompt a 8 % používateľov dostane horšiu odpoveď, ale priemerná latencia a chybovosť zostanú rovnaké. Druhý je cost creep: jeden enterprise zákazník začne posielať 200-tisíc tokenov v jednom prompte (lebo si pridal nový file do kontextu), a faktúra od OpenAI vyskočí o 40 %. Tretí je tool loop: agent v 2 % prípadov skončí v cykle, kde 12-krát volá ten istý nástroj. Honestly, všetky tri problémy sa odhalia jediným pohľadom na trace, ale len ak ich naozaj máte.

Téma sa prirodzene prelína s testovaním a evaluáciou LLM aplikácií: observabilita rieši "čo sa stalo v produkcii", evaluácia rieši "je to dobré". Najlepšie platformy dnes obe funkcie spájajú. Z produkčných traces si urobíte dataset a pustíte naň evaluator.

Rýchle porovnanie: Langfuse vs LangSmith vs Helicone

Skôr než zájdem do detailov, zhrniem najdôležitejšie rozdiely v tabuľke. Cenotvorba sa týka stavu k 1. júnu 2026 a vychádza z verejných pricing stránok. Pre presné kvóty si pricing overte priamo.

Vlastnosť	Langfuse v3	LangSmith	Helicone
Licencia	MIT (open-source)	Proprietárna	Apache 2.0 (open-source)
Self-hosting	Áno, plne podporovaný	Nie (len cloud)	Áno, komunitná edícia
Spôsob inštrumentácie	SDK alebo OpenTelemetry	SDK (auto-trace v LangChain)	HTTP proxy (zmena base_url)
Hierarchické spany	Áno, plne podporované	Áno, natívne	Áno, ale rovnejšia štruktúra
Prompt management	Áno, s verzovaním a A/B	Áno, hub-based	Áno, jednoduchšie
Cena (1M spanov/mesiac)	~49 USD (Cloud Pro)	~49 USD (Plus plan)	~200 USD (Pro plan)
Najlepšie pre	Univerzálne použitie, self-host	LangChain/LangGraph projekty	Proxy-friendly setupy

Langfuse v3: open-source-first prístup

Langfuse v3, vydaný v marci 2026, je z mojich produkčných nasadení najuniverzálnejší nástroj. Architektúra stojí na Postgres pre metadáta, ClickHouse pre spany a Redis pre cache. Inštrumentácia sa robí buď cez ich Python/TypeScript SDK, alebo cez štandardné OpenTelemetry tracery. Ak už používate OTel v inej časti stacku, integrácia je triviálna.

Typický kód pre trasovanie agenta s tool callingom vyzerá takto:

from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context
from anthropic import Anthropic

langfuse = Langfuse(
    public_key="pk-lf-...",
    secret_key="sk-lf-...",
    host="https://cloud.langfuse.com",
)
client = Anthropic()

@observe(as_type="generation")
def call_llm(messages: list, tools: list):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=2048,
        messages=messages,
        tools=tools,
    )
    # Langfuse automaticky zaznamená usage a cost
    langfuse_context.update_current_observation(
        input=messages,
        output=response.content,
        usage_details={
            "input": response.usage.input_tokens,
            "output": response.usage.output_tokens,
        },
        model="claude-sonnet-4-6",
    )
    return response

@observe(name="research-agent")
def run_agent(query: str, user_id: str):
    langfuse_context.update_current_trace(
        user_id=user_id,
        tags=["agent", "research-v2"],
        metadata={"query_length": len(query)},
    )
    messages = [{"role": "user", "content": query}]
    for _ in range(10):  # max 10 turn limit
        resp = call_llm(messages, tools=TOOLS)
        if resp.stop_reason == "end_turn":
            return resp
        messages.extend(handle_tool_calls(resp))
    raise RuntimeError("Agent prekrocil limit iteracii")

Dekorátor @observe vytvorí span pre každé volanie funkcie a automaticky ich zoreťazí do stromu. To je užitočné práve pri agentoch, kde jeden user query spustí desiatky podvolaní. Langfuse podporuje aj manuálne trace(), span() a generation() API, ak chcete jemnejšiu kontrolu.

Veľká výhoda Langfuse v3 je natívna podpora session-level grupovaných traces. Konverzačného agenta zoskupíte podľa session_id a v UI vidíte celú konverzáciu ako jeden stream. Pri klasickom traceri musíte robiť cross-trace queries, čo nie je elegantné.

LangSmith: hlboká integrácia s LangChain ekosystémom

LangSmith je oficiálna observability platforma od tímu, ktorý stojí za LangChain a LangGraph. Ak používate tieto frameworky, dostanete tracing zadarmo. Stačí nastaviť environment premenné LANGSMITH_TRACING=true a LANGSMITH_API_KEY, a všetky reťaze, agenti aj retrievery sa začnú logovať. Pre LangGraph aplikácie je to praktickú nutnosť, lebo natívna vizualizácia stavového grafu funguje len v LangSmith UI.

Mimo LangChain ekosystému musíte použiť ich @traceable dekorátor:

from langsmith import traceable, Client
from openai import OpenAI

client = OpenAI()
ls_client = Client()

@traceable(run_type="llm", name="classify-intent")
def classify_intent(text: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4.1",
        messages=[
            {"role": "system", "content": "Klasifikuj intent pouzivatela."},
            {"role": "user", "content": text},
        ],
    )
    return response.choices[0].message.content

@traceable(run_type="chain", name="support-agent")
def support_agent(message: str, user_id: str):
    intent = classify_intent(message)
    # dalsia logika podla intentu...
    return {"intent": intent, "user_id": user_id}

Najsilnejšia stránka LangSmith je prepojenie traces s evaluation datasetmi. Z produkčných traces si filterom vyberiete 200 prípadov, kliknutím ich exportujete do datasetu a pustíte naň evaluator (vlastný, alebo z ich knižnice). To zatvára feedback loop medzi produkciou a regresiami pri každom novom prompte. Detailne rozoberám túto myšlienku v článku o context engineering pre AI agentov.

Helicone: proxy-based observabilita bez zmeny kódu

Helicone má radikálne odlišný prístup. Namiesto SDK funguje ako transparentný HTTP proxy. Zmeníte base_url na https://oai.helicone.ai/v1 (pre OpenAI) alebo https://anthropic.helicone.ai (pre Anthropic) a pridáte autorizačnú hlavičku. Helicone request preposiela ďalej a loguje všetko, čo prejde.

from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {HELICONE_API_KEY}",
        "Helicone-User-Id": user_id,
        "Helicone-Property-Feature": "search-agent",
        "Helicone-Cache-Enabled": "true",
    },
)

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": "Kto vyhral Wimbledon 2025?"}],
)

Výhoda je zjavná. Nemusíte sa starať o SDK kompatibilitu, fungujete s ľubovoľným klientom, ktorý vie zmeniť base URL. Helicone navyše poskytuje vstavané caching, rate limiting a retry logic ako súčasť proxy vrstvy. Pri Langfuse a LangSmith musíte tieto features riešiť v aplikačnom kóde.

Nevýhoda proxy modelu je v hĺbke tracing-u. Helicone vidí HTTP volania, ale ak agent volá tool funkcie v Pythone (napr. databázový query, file read), tie sú pre Helicone neviditeľné. Trace je preto rovnejší. Vidíte sekvenciu LLM volaní, ale nie strom s tool callmi. Pre RAG aplikácie a komplexné agentic workflowy je to limit, pre jednoduché chatboty stačí. Tento problém ladí dobre s odporúčaniami z článku o budovaní Agentic RAG pipeline, kde tool-level tracing je kľúčový.

Helicone v marci 2026 pridal podporu pre session grouping cez hlavičku Helicone-Session-Id a custom properties, ktoré sa dajú filtrovať v dashboarde. To čiastočne kompenzuje absenciu hlbokých spanov, ale stále to nie je strom.

Ako trasovať agentov s tool callingom

Pre AI agentov je tracing iný problém než pre obyčajné LLM volania. Jeden user query rozbije strom typicky takto: user message → router LLM call → tool call A → DB query → LLM call s tool výsledkom → tool call B → API request → finálny LLM call. Pre debugging musíte vidieť celý strom, lebo problém je často v tool výstupe, nie v LLM.

Konkrétny príklad z môjho posledného projektu: agent, ktorý odpovedá zlú odpoveď, lebo retriever vrátil neexistujúci dokument. Bez span stromu zistíte len, že odpoveď je zlá. So stromom vidíte, že retriever bol volaný s nesprávnym query embeddingom, lebo router LLM extrahoval otázku zle. Fix je v routeri, nie v retrieveri. Pomohlo to ušetriť asi pol dňa hádania.

V praxi som sa rozhodol takto: pre agentov používam buď Langfuse alebo LangSmith, pre jednoduché RAG endpointy alebo chatboty stačí Helicone. Pravidlo je jednoduché. Ak má váš workflow viac ako 3 úrovne podvolaní, potrebujete platformu so stromovým tracingom. Ak ide o lineárnu sekvenciu LLM → response, proxy stačí.

Príklad: hierarchické spany v Langfuse pre LangGraph agenta

from langgraph.graph import StateGraph
from langfuse.callback import CallbackHandler

langfuse_handler = CallbackHandler(
    user_id="user-42",
    session_id="session-2026-06-16-001",
    tags=["langgraph", "support-agent"],
)

graph = build_graph()  # vas LangGraph
result = graph.invoke(
    {"messages": [{"role": "user", "content": user_query}]},
    config={"callbacks": [langfuse_handler]},
)

Tento jediný callback inštrumentuje celý LangGraph: každý node sa stane spanom, každé LLM volanie generačným spanom, a tool calls dostanú vlastné podstromy. V UI to potom vyzerá ako klasický APM flame graph, len pre AI agenta.

Sledovanie nákladov per používateľ a per feature

Cost attribution je v roku 2026 dôležitejšie než kedykoľvek predtým. Modely sa zlacňujú, ale traffic rastie rýchlejšie a zákazníci očakávajú per-seat alebo per-request billing. Bez observability platformy nemáte ako zistiť, koľko stojí jeden Enterprise customer alebo jedna feature.

Všetky tri platformy podporujú custom metadata na úrovni traces/requestov: user_id, feature_id, tenant_id, alebo ľubovoľný iný kľúč. Cost sa v každej platforme počíta automaticky z usage čísel (input/output tokeny × cena modelu) a väčšina platforiem má pre-loaded ceny modelov. Pri Anthropic Messages API nezabudnite, že cache reads majú 90 % zľavu. Overte si, že platforma rozumie poliam cache_creation_input_tokens a cache_read_input_tokens. Langfuse v3 a LangSmith ich oba podporujú, Helicone od mája 2026 tiež. K tejto téme sa hodí prečítať aj prompt caching pre LLM, kde som rozobral, ako znížiť náklady o 90 %.

Praktický tip: nastavte si cost alerty na granularite tenant_id. Najčastejší rozpočtový incident v SaaS aplikáciách nie je celkový spike, ale jeden zákazník, ktorý hocijako začne posielať gigantické prompty. Alert na "ak jeden tenant minie viac ako 100 USD za hodinu" vám ho dá vedieť skôr než finančné oddelenie.

Prompt management a verzovanie

Kým sú prompts hardcoded v kóde, ich aktualizácia vyžaduje deploy. Pri agentických aplikáciách s desiatkami promptov to nie je udržateľné. Prompt management to vyrieši: prompts uložené ako versioned artefakty mimo kódu, s podporou variantov, A/B testov a okamžitej aktualizácie.

Langfuse aj LangSmith poskytujú plnohodnotné prompt management s verzovaním, labelmi (production/staging/canary), A/B variantami a auditovateľnou históriou. Helicone má jednoduchšiu verziu: prompts so substitúciou premenných, ale bez A/B variantov.

# Langfuse - fetch produkcneho promptu s fallbackom
from langfuse import Langfuse

langfuse = Langfuse()

prompt = langfuse.get_prompt(
    "summarizer-v2",
    label="production",  # alebo "canary" pre A/B test
    fallback="Zhrn nasledujuci text v 3 vetach: {{input}}",
)

compiled = prompt.compile(input=user_text)
response = call_llm(compiled)

# linking traces s prompt verziou pre regresnu analyzu
langfuse_context.update_current_observation(
    prompt=prompt,
)

Kľúčový workflow je takýto: deployujete novú verziu promptu pod labelom canary, 5 % traffic-u smerujete na canary, sledujete metriky (latencia, cost, user feedback) a ak je všetko dobré, povýšite ju na production. Žiadny code deploy, žiadny rollback nightmare.

Self-hosting a dátová suverenita

V regulovaných odvetviach (banky, zdravotníctvo, verejný sektor) je odoslanie promptov a odpovedí do tretej strany často právne neprijateľné. Self-hosting je preto rozhodujúce kritérium.

Langfuse má najlepší self-hosting story: open-source Docker Compose pre dev, Helm chart pre Kubernetes, terraform moduly pre AWS/GCP/Azure. Enterprise edícia pridáva SSO, audit logs a RBAC, ale komunitná edícia stačí pre väčšinu use cases. Detailný návod nájdete v oficiálnej dokumentácii Langfuse.

Helicone má tiež open-source repo s Docker Compose, ale niektoré pokročilé features (custom evaluator pipeline, advanced caching) sú len v cloude. Pre základný tracing self-host stačí.

LangSmith self-host neponúka, je to čisto SaaS produkt. Pre EU zákazníkov ponúka EU region (Frankfurt), ale dáta stále tečú cez ich infraštruktúru. Tím sľubuje on-prem v 2027, ale to je zatiaľ roadmap, nie produkt.

Ktorú platformu si vybrať podľa typu projektu

Po dvoch rokoch produkčného používania všetkých troch som si vytvoril nasledovné rozhodovacie pravidlá:

• Vyberte Langfuse, ak chcete jednu platformu, ktorá funguje v ľubovoľnom stacku (Python, TS, Go), potrebujete self-hosting alebo open-source licenciu, prípadne plánujete budovať vlastné dashboardy nad surovými dátami. Najlepší univerzálny default.
• Vyberte LangSmith, ak používate LangChain/LangGraph ako primárny framework a chcete najmenej trecie pri tracingu. Hlboká integrácia ušetrí dni inštrumentačnej práce.
• Vyberte Helicone, ak máte jednoduchú architektúru (chatbot, jednovrstvový RAG), nechcete sa hrať s SDK a oceníte vstavané caching/rate limiting. Pre lean tímy bez observability inžiniera je to najrýchlejšia cesta k základnej viditeľnosti.

Nie je zakázané ich kombinovať. Stretol som tímy, ktoré Helicone používali na cost tracking a rate limiting pred OpenAI, a paralelne Langfuse na detailný tracing agentov. Funguje to dobre, lebo proxy a SDK sú ortogonálne vrstvy.

Často kladené otázky

Je LLM observabilita to isté ako evaluácia LLM?

Nie. Observabilita zachytáva, čo sa v produkcii reálne dialo (tracing, logy, metriky). Evaluácia odpovedá na otázku, či sú výstupy správne a kvalitné. Moderné platformy ako Langfuse a LangSmith oba svety prepájajú: z produkčných traces si vytvoríte evaluation dataset a beháte naň testy.

Aký je rozdiel medzi LangSmith a Langfuse?

LangSmith je proprietárna cloud-only platforma od LangChain tímu s hlbokou integráciou do LangChain/LangGraph. Langfuse je open-source platforma s MIT licenciou, plne self-hostovateľná, framework-agnostická a založená na OpenTelemetry. Pre LangChain projekty je LangSmith pohodlnejší, pre všetko ostatné a pre regulované odvetvia je Langfuse lepšia voľba.

Môžem trasovať agentov bez akejkoľvek observability platformy?

Technicky áno, môžete logovať do Postgres/ClickHouse a postaviť si vlastné dashboardy. Realisticky je to 2 až 3 mesiace inžinierskej práce na to, čo existujúce platformy poskytujú v deň jeden. Open-source Langfuse self-hostnete za hodinu, takže ekonomicky to dáva zmysel len v špecifických prípadoch (extrémne objemy alebo veľmi nezvyčajné požiadavky).

Ako observability ovplyvňuje latenciu mojich LLM volaní?

SDK-based platformy (Langfuse, LangSmith) posielajú dáta asynchronne v background flush, takže priame ovplyvnenie latencie je pod 1 ms. Proxy-based platforma (Helicone) pridáva sieťový hop, typicky 20 až 50 ms cez verejný internet alebo 5 až 10 ms cez ich edge sieť. Pre väčšinu use cases je to akceptovateľné, pre real-time voice agentov to môže byť problém.

Ako si vybrať medzi self-hosted a cloud verziou?

Cloud vyberte, ak chcete rýchlu integráciu, automatické updaty a nemáte regulačné prekážky. Self-hosting si vyberte, ak máte compliance požiadavky (HIPAA, GDPR-strict), citlivé dáta (medical, financial), alebo extrémne objemy, kde cloud cenotvorba prestáva dávať zmysel. Pre väčšinu startupov je cloud správna voľba, pre enterprise často self-host.