LLM-havainnointi 2026: Langfuse, LangSmith ja Helicone tuotannon jäljityksessä

Päivitetty: 28.7.2026

LLM-havainnointi tarkoittaa tuotannossa ajettavien kielimallikutsujen jäljittämistä, kustannusten mittaamista ja laadun arviointia yhtenäisen työkalupinon kautta. Vuonna 2026 kolme kärkinimeä ovat Langfuse (avoin lähdekoodi, itse-isännöitävä oletus), LangSmith (paras LangChain- ja LangGraph-tiimeille) ja Helicone (nopein käyttöönotto proxyn kautta). Olen kolmen viime vuoden aikana pyörittänyt kaikkia näitä tuotannossa, ja arkkitehtuurivalinta (proxy vs. SDK-spanit vs. natiivit callback-hookit) vaikuttaa käytettävyyteen enemmän kuin mikään yksittäinen ominaisuus. Rehellisesti sanottuna, tässä oppaassa käyn läpi vertailun, konkreettiset asennusnäytteet ja päätöskehyksen, jonka olisin toivonut itselläni olleen ensimmäistä pinoa valitessa.

• Langfuse on vuonna 2026 avoimen lähdekoodin oletus: MIT-lisensoitu, ClickHouse + PostgreSQL -taustainen ja natiivi OpenTelemetry-ingest.
• LangSmith voittaa monivaiheisten agenttien visualisoinnissa, mutta on maksullinen SaaS ja hinnoiteltu per trace. Se voi nousta jopa 5–10 %:iin LLM-API-kuluista.
• Helicone toimii proxyna: vaihdat vain base_url:n ja saat kustannuslokin viidessä minuutissa. Hintana ~20–50 ms lisälatenssi per kutsu.
• Kustannusseuranta vaatii aina token-tagien tallentamisen (user_id, feature, model), muuten showback ja anomaliahälytykset eivät toimi.
• Itse-isännöinti on välttämätön, kun promptit sisältävät henkilötietoja tai liikesalaisuuksia; Langfuse ja Helicone OSS ovat tähän parhaat.
• OpenTelemetry (OpenLLMetry / OpenInference -konventiot) yhdistää LLM-jäljitykset olemassa oleviin APM-pinoihin (Datadog, Grafana, Jaeger).

Mitä LLM-havainnointi käytännössä tarkoittaa?

LLM-havainnointi (englanniksi LLM observability) on käytäntö, jossa jokaisesta kielimallikutsusta tallennetaan strukturoitu telemetria (prompt, vastaus, token-määrät, latenssi, kustannus ja kutsupuun rakenne), ja tätä dataa käytetään sekä operatiivisiin hälytyksiin että laadun arviointiin. Perinteinen APM-työkalu näkee vain HTTP-tason: POST /v1/chat/completions, statuskoodi 200, kesto 3 200 ms. Se ei kerro, että malli hallusinoi asiakkaan tilauksen tai että agentti jäi silmukkaan kuudessa peräkkäisessä työkalukutsussa.

Käytännön havainnointi jakautuu neljään pilariin: metriikat (aggregoidut signaalit, esim. p99-latenssi mallikohtaisesti), jäljitykset (spanipuu, joka näyttää missä sub-kutsu hidasti), lokit (raakadata prompt- ja vastausteksteistä) ja evaluaatiot (LLM-tuomarit tai regex-tarkistukset, jotka arvioivat laadun). Ilman evaluaatiokerrosta seurantasi kertoo ainoastaan, että jokin ajettiin. Se ei kerro, oliko tulos oikea.

Oman kokemukseni mukaan ensimmäinen dashboard, jonka jokainen tiimi tarvitsee, sisältää neljä graafia: pyyntömäärä mallikohtaisesti, p50/p95/p99-latenssi TTFT:llä (time to first token), kustannus per käyttäjäsessio ja virheiden osuus mallikohtaisesti. Kaikki muu (evaluaatiot, prompt-versiointi, A/B-testit) on tämän päälle rakennettavaa infrastruktuuria.

Vertailutaulukko: Langfuse vs. LangSmith vs. Helicone

Alla on tiivistys ominaisuuksista, joilla kolme kärkinimeä eroavat toisistaan vuonna 2026. Numerot pohjautuvat toukokuun 2026 julkaisuihin ja omiin mittauksiini keskisuuren SaaS-tuotteen (~2 M kutsua/kk) tuotantoympäristössä.

Ominaisuus	Langfuse	LangSmith	Helicone
Arkkitehtuuri	SDK-spanit (OTel)	Framework-callbackit	HTTP-proxy
Lisenssi	MIT (avoin)	Suljettu SaaS	Apache 2.0 (OSS-versio)
Itse-isännöinti	Kyllä (Docker + K8s)	Enterprise-lisenssillä	Kyllä (Docker)
Käyttöönotto	15–30 min	5–10 min (LangChain)	< 5 min (proxy)
Latenssin lisäys	0 ms (async)	0 ms (async)	20–50 ms (proxy-hop)
Agenttijäljitys	Vahva	Vahvin (LangGraph)	Rajoitettu (vain HTTP-taso)
Prompt-hallinta	Kyllä (versioitu)	Kyllä (versioitu)	Perustaso
LLM-as-judge -evaluaatiot	Kyllä	Kyllä (kattavin)	Rajoitettu
Hinta (5 M spania/kk)	~$500 (managed)	~$1 800	~$400

Nyrkkisääntö: valitse arkkitehtuuri stackisi mukaan. Jos kaikki agenttilogiikkasi on LangGraphissa, LangSmith on nolla-frictionia. Jos käytät sekakäyttöisesti OpenAI-SDK:ta, LlamaIndexiä ja custom-koodia, Langfusen OTel-pohja normalisoi kaiken saman skeeman alle. Jos et halua koskea sovelluskoodiin lainkaan, Helicone-proxy on käytännössä ainoa vaihtoehto.

Langfuse käytännössä: itse-isännöity oletusvalinta

Langfuse v3 (julkaisu 2025 loppuvuonna, ClickHouse-yhtiö hankki projektin tammikuussa 2026) käyttää ClickHousea korkean volyymin trace- ja span-datan tallentamiseen sekä PostgreSQL:ää konfiguraatiolle (käyttäjät, projektit, promptit). Python-SDK v4 rakentuu OpenTelemetryn päälle, joten vanhat langfuse.decorators-tuonnit on korvattava from langfuse import observe, get_client -tuonneilla. Tämä on ainoa iso rikkova muutos.

Yksinkertaisin instrumentointi OpenAI-kutsulle näyttää tältä:

from langfuse import observe, get_client
from openai import OpenAI

langfuse = get_client()
client = OpenAI()

@observe(name="answer_customer_question")
def answer_question(question: str, user_id: str) -> str:
    langfuse.update_current_trace(user_id=user_id, tags=["support", "prod"])

    response = client.chat.completions.create(
        model="gpt-4.1-mini",
        messages=[
            {"role": "system", "content": "Vastaa suomeksi lyhyesti."},
            {"role": "user", "content": question},
        ],
        temperature=0.2,
    )

    langfuse.update_current_observation(
        input=question,
        output=response.choices[0].message.content,
        usage_details={
            "input_tokens": response.usage.prompt_tokens,
            "output_tokens": response.usage.completion_tokens,
        },
    )
    return response.choices[0].message.content

Kaikki OpenAI-, Anthropic- ja Google-mallit ovat mukana Langfusen sisäänrakennetussa hinnastossa, joten usage_details-kentät riittävät kustannusten laskentaan. Fine-tuunattujen tai itse-hostattujen mallien osalta määrität hinnat itse projektiasetuksissa.

Itse-isännöinti Docker Composella onnistuu kolmella tiedostolla (docker-compose.yml, .env, Caddyfile TLS-terminointiin). Toukokuusta 2026 alkaen ainoastaan full-stack-konfiguraatio on virallisesti tuettu; vanha "lite"-tila on poistettu. Tuotannossa suosittelen erillistä managed ClickHouse -klusteria (Aiven, ClickHouse Cloud), koska embedded-instanssi ei kestä yli 10 M spania/päivä ilman kunnollista tuningia. Törmäsin tähän itse viime keväänä, ja tunnin migraation sijaan päädyin viikon downtime-suunnitteluun. Tarkat vaatimukset löydät Langfusen virallisesta SDK-dokumentaatiosta.

LangSmith käytännössä: agenttijäljitys LangGraph-tiimeille

LangSmith on LangChain Inc.:n kaupallinen SaaS ja tiiviisti sidoksissa LangChain- ja LangGraph-frameworkkeihin. Jos ajat monivaiheisia agentteja LangGraph-runnereilla, LangSmith on paras jäljityskokemus markkinoilla: jokainen node, edge ja state-transition renderöityy interaktiivisena aikajanana, ja voit uudelleensuorittaa yksittäisen spanin muokatulla promptilla suoraan käyttöliittymästä.

Instrumentointi ei vaadi käytännössä koodimuutoksia. Pelkkä ympäristömuuttuja riittää:

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=lsv2_pt_xxx
export LANGSMITH_PROJECT=support-agent-prod

Non-LangChain-kutsuille (esim. suora OpenAI-SDK) käytetään @traceable-dekoraattoria:

from langsmith import traceable
from openai import OpenAI

client = OpenAI()

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

Iso varoitus: LangSmithin hinnoittelu on per trace ja per span. Yhden agenttiajon, joka tekee 20 sub-kutsua, hinta on ~$0,001–0,002. Kuulostaa halvalta, kunnes olet 5 miljoonassa ajossa kuukaudessa. Omilla numeroillani LangSmith-lasku oli 7 % OpenAI-kuluistani, kun taas Langfuse-managed jäi 2 %:iin ja Langfuse-selfhosted alle 0,3 %:iin (pelkkiä infrakuluja). Enterprise-lisenssillä saa self-hostingin, mutta hinta liikkuu viisi- tai kuusinumeroisissa summissa vuodessa. LangSmithin virallinen jäljitysopas löytyy LangSmith-dokumentaatiosta.

Helicone käytännössä: proxy viidessä minuutissa

Helicone on radikaalisti erilainen: se on reverse proxy, joka istuu sovelluksesi ja LLM-provider-API:n välissä. Instrumentointi tarkoittaa yhtä base_url-muutosta OpenAI-clientissä:

from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {os.environ['HELICONE_API_KEY']}",
        "Helicone-User-Id": user_id,
        "Helicone-Property-Feature": "checkout-assistant",
    },
)

response = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": "Miksi tilaukseni ei toimi?"}],
)

Siinä kaikki. Kustannukset, latenssit, käyttäjä-ID ja custom properties kirjautuvat Heliconen dashboardille ilman, että sovelluskoodiin lisätään SDK:ta. Tämä on epäilemättä nopein tapa saada kustannusnäkyvyys legacy-koodiin, jota et halua tai voi refaktoroida. Törmäsin tähän itse eräässä konsultointiprojektissa, jossa asiakkaan tiimillä oli 40+ mikropalvelua, ja SDK:n lisääminen jokaiseen olisi vienyt kuukausia.

Kompromissit ovat kaksi. Ensimmäinen: proxy-hop lisää 20–50 ms latenssia per kutsu. Ei paljon suhteessa 500–5 000 ms LLM-latenssiin, mutta merkittävää jos ajat rinnakkain kymmeniä sub-kutsuja per pyyntö. Toinen: proxy näkee HTTP-tason, mutta ei sovelluksen sisäistä tilaa. Jos agenttisi tekee kaksi peräkkäistä LLM-kutsua ja niiden välissä hakee tietokannasta, Helicone kirjaa kaksi erillistä requestia — ei yhtenäistä trace-puuta, joka kertoisi kokonaisviiveen syyn.

Miten seuraat LLM-kustannuksia tuotannossa?

Kustannusseurannan minimivaatimus on tallentaa jokaisesta kutsusta neljä kenttää: input_tokens, output_tokens, model ja usd_cost. Kaikki kolme työkalua tekevät tämän automaattisesti, kun promptaat oikean SDK:n läpi. Todellinen ero näkyy siinä, miten attribuoit nämä kulut takaisin käyttäjiin, tiimeihin tai ominaisuuksiin.

Käytännön tagimalli, joka toimii kaikilla kolmella:

# Langfuse-esimerkki attribuutiosta
langfuse.update_current_trace(
    user_id="u_8432",
    session_id="sess_2f9a",
    tags=["feature:document-summary", "team:support", "env:prod"],
    metadata={"tenant_id": "acme-corp", "plan": "enterprise"},
)

Näiden tagien avulla saat kolme raporttia, jotka jokainen CFO haluaa nähdä: showback (mitä kukin tiimi kulutti tässä kuussa), chargeback (mitä laskutamme asiakkaalta X) ja cache hit ratio (kuinka paljon säästimme prompt-caching-toimenpiteillä). Jos et tallenna tenant_id:tä alusta asti, joudut myöhemmin joko regeksäämään promptien sisältöä tai palauttamaan lokit ja re-taggaamaan. Kumpikaan ei ole hauskaa.

Anomaliahälytys kannattaa asettaa kahdelle signaalille: cost_per_user_p95 nousee > 3x 24 h:n baseline vs. keskiarvo, tai tokens_per_request_p99 nousee > 2x. Ensimmäinen kiinni ottaa abusaavia käyttäjiä (bottiliikenne, prompt-injection joka pakottaa mallin generoimaan suuria vastauksia), toinen kiinni ottaa retrieval-bugit, joissa RAG-pipeline liittää liian ison kontekstin. Katso lisää prompt cachingin käytännön käyttöönotosta, joka on itsessään yksi tehokkaimpia kustannusleikkureita.

OpenTelemetry ja LLM-jäljitys: miten ne kytkeytyvät?

Vuoden 2026 iso siirtymä on ollut OpenTelemetryn nousu de facto -standardiksi LLM-jäljityksessä. Kaksi konventiota kilpailee: GenAI-semanttiset konventiot OpenTelemetry-projektissa ja OpenInference (Arize-lähtöinen). Käytännössä molemmat mappautuvat samoihin attribuutteihin (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens), pienin eroin.

Miksi tämä on iso juttu? Koska voit nyt lähettää samat spanit sekä Langfuseen että Datadogiin tai Jaegeriin ilman, että instrumentointi tehdään kahdesti. Langfuse v4 SDK rekisteröi span-processorin globaaliin OTel TracerProvideriin. Jos sovelluksesi jo emittii HTTP-, DB- ja Redis-spaneita, LLM-spanit näkyvät samassa trace-puussa. Ja voit vihdoin vastata kysymykseen "kuinka paljon LLM-latenssia todella osuu käyttäjän 2,4 s:n pyyntöön verrattuna Postgres-hakuun".

# OTel Collector -konfiguraatio, joka lähettää spanit sekä Langfuseen että Datadogiin
receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp/langfuse:
    endpoint: https://cloud.langfuse.com/api/public/otel
    headers:
      Authorization: "Basic ${LANGFUSE_AUTH_B64}"
  datadog:
    api:
      key: ${DD_API_KEY}
      site: datadoghq.eu

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/langfuse, datadog]

Jos rakennat RAG-järjestelmää, joka koskettaa vektorikantaa, embed-mallia ja generointi-LLM:ää samassa pyynnössä, OTel-pohjainen instrumentointi on käytännössä ainoa tapa nähdä koko latenssibudjetti yhdessä näkymässä. Tästä syvempi katsaus löytyy tuotantovalmiin RAG-pipelinen oppaasta.

Kuinka valitset oikean työkalun tiimillesi?

Alla on päätöskehys, jota käytän itse asiakkaille konsultoidessani. Se ei anna yhtä "oikeaa" vastausta, mutta karsii vaihtoehdot 1–2:een noin 30 sekunnissa.

1. Onko sinulla data-residency- tai compliance-vaatimus (GDPR, HIPAA, ISO 27001)? Kyllä → Langfuse self-hosted tai Helicone OSS. Ei → jatka.
2. Onko koko agenttistackisi LangChain/LangGraph-pohjainen ja LLM-kulut > $200k/vuosi? Kyllä → LangSmith on premiuminsa arvoinen. Ei → jatka.
3. Haluatko instrumentoinnin ilman koodimuutoksia? Kyllä → Helicone proxy. Ei → jatka.
4. Tarvitsetko evaluaatiotoolauksen ja prompt-versioinnin samassa työkalussa? Kyllä → Langfuse. Ei ja käytät LangChainia → LangSmith on ok. Ei ja et käytä LangChainia → Langfuse tai Helicone.

Käytännössä 70 % näkemistäni tiimeistä päätyy Langfuseen — se on avoimen lähdekoodin oletus juuri koska se kattaa evaluaatiot, prompt-hallinnan ja OTel-integraation ilman lock-inia. Loput 30 % jakautuvat aika tasan LangSmithin (agent-heavy LangChain-shopit) ja Heliconen (nopea käyttöönotto, minimaaliset koodimuutokset) välillä. Jos aiot vasta rakentaa evaluaatiokerroksesi, tutustu myös LLM-sovellusten arviointi- ja testausoppaaseen, joka menee syvemmälle DeepEvaliin ja Promptfoohon.

Usein kysytyt kysymykset

Mikä on LLM-havainnoinnin ja perinteisen APM:n ero?

Perinteinen APM (Datadog, New Relic) näkee HTTP-tason: statuskoodin, latenssin, virheprosentin. LLM-havainnointi lisää semanttisen kerroksen (prompt, vastaus, token-määrät, kustannus, kutsupuu ja laatuevaluaatiot), joka on ainoa tapa vastata kysymyksiin "hallusinoiko malli?" tai "onko RAG-konteksti relevanttia?"

Voinko käyttää useita LLM-havainnointityökaluja rinnakkain?

Kyllä, ja se on itse asiassa yleinen malli tuotannossa. Tyypillinen kombo on Helicone proxyna kustannusseurantaan + Langfuse SDK:n kautta agenttijäljitykseen ja evaluaatioihin. Kustannus ei kaksinkertaistu, koska hinnastot eivät päällekkäisty. Ainoa varoitus: älä lähetä samoja spaneja molempiin, muuten trace-datasi kaksinkertaistuu ja hälytykset menevät sekaisin.

Kuinka paljon LLM-havainnointi vaikuttaa sovelluksen latenssiin?

SDK-pohjaiset työkalut (Langfuse, LangSmith) käyttävät asynkronisia, ei-estäviä lähettäjiä, joten latenssin lisäys on 0 ms sovelluksen näkökulmasta. Proxy-pohjaiset työkalut (Helicone) lisäävät 20–50 ms per kutsu verkkohypyn takia. Kompromissi on kestävyys: jos SDK-prosessi kaatuu ennen taustalähetystä, menetät kyseiset spanit, kun taas proxy tallentaa aina.

Tarvitseeko LLM-havainnointi omaa erillistä tietokantaa?

Managed SaaS -versioissa (Langfuse Cloud, LangSmith, Helicone Cloud) ei, koska tuottaja hoitaa tallennuksen. Self-hostattaessa Langfuse vaatii sekä ClickHousen (spanit) että PostgreSQL:n (konfiguraatio), Helicone käyttää Postgresia + ClickHousea, ja LangSmith Enterprise pyörii Postgres + Redis + BlobStore -yhdistelmällä. ClickHouse on kaikissa käytännössä pakollinen, kun span-volyymi ylittää 1 M/päivä.

Onko OpenTelemetry välttämätön LLM-havainnoinnille vuonna 2026?

Ei välttämätön, mutta erittäin suositeltava. OTel-natiivi instrumentointi antaa sinulle vapauden vaihtaa työkalua ilman koodimuutoksia. Vain exporter-endpointti muuttuu. Se myös yhdistää LLM-spanit muuhun infra-telemetriaan (HTTP, DB, Redis) samaan trace-puuhun, mikä on välttämätöntä RAG- ja agenttijärjestelmien latenssidiagnoosissa. Vältä työkaluja, jotka eivät tue OTel-standardia.