Langfuse fylder ikke meget i hype-feeden, men den nye hands-on tutorial fra MarkTechPost gør noget sjældent: den får observability og evaluering ned i fingrene. Ikke powerpoint. Kode. Du kan køre pipeline med en rigtig OpenAI-nøgle, eller helt uden betalt model via en deterministisk mock-LLM. Det lyder beskedent, men det flytter noget i praksis for teams, der vil bygge ansvarlige LLM-tjenester uden at brænde budgettet eller tabe sporbarheden undervejs.
Vi gik opskriften igennem. Det tog mindre end en eftermiddag at få spor, prompts og eksperimenter til at lande pænt i Langfuse UI. Vi lavede et par fejl undervejs—de var nemme at lokalisere, fordi alt var traced. Det er pointen. Tutorialen får hele kæden på plads, fra første kald til første sammenlignelige måling. Kilde og kodeflow er dokumenteret hos MarkTechPost og matcher det, vi ser i værktøjet i dag.
Hvad tutorialen konkret viser
Tutorialen går målrettet frem: installér pakker i Colab med pip, sæt miljøvariabler for Langfuse-nøgler, vælg vært (EU, US eller en selvhostet URL), og tilføj valgfrit en OpenAI API-nøgle. Derfra initialiserer man klienten og verificerer auth—med et lille print, der bekræfter, om backend er OpenAI eller mock. Koden ligner meget af det, der allerede sker i små POC’er, men her bindes den til en fuld sporkæde i Langfuse UI.
Derefter: tracing af simple funktionskald via en dekorator, efterfulgt af en lille RAG-pipeline, hvor både dokumenthentning og modelkald instrumenteres. Der er også central promptstyring i Langfuse, så versionsskift bliver synlige og kontrollerbare. Dertil kommer scoring af output og datasæt-baserede eksperimenter, så iterationer bliver målt—ikke gættet. Det hele er dokumenteret i koden hos MarkTechPost, inklusiv eksempler på environment-opsætning og modelvalg.
Hvorfor det faktisk betyder noget for udvikling
Mange LLM-projekter starter i et notatark og ender i en pærevælling af ad hoc-tests. Tracing, promptversioner, scoring og datasets gør det muligt at reproducere fejl og lande forbedringer roligt. I vores egne sprints har tidsrøveren ofte været “kan du lige gentage det kald?” eller “hvilken promptversion kørte vi med i tirsdags”. Når spor, versionsnavne og output ligger ét sted, falder tempoet til ro, og kvaliteten går op.
Det overraskede os, hvor hurtigt central promptstyring gjorde en forskel. Ikke på dagen, men i uge to, da vi begyndte at sammenligne patchede varianter. Vi opdagede også en disciplin-detalje, som tutorialen ikke kan give dig: navngivning. Uden stram konvention—vi brugte noget i retning af “prompt_v1.2_patchA”—bliver loggen bare en bunke. Det er ikke et værktøjsproblem. Det er et teamproblem.
Mock‑LLM kontra rigtige nøgler
Tutorialens joker er den deterministiske mock-LLM. Den gør to ting: Du kan sætte hele observability-pipelinen op uden at betale for tokens. Og du får reproducerbarhed, der er stærkere end virkeligheden, fordi svaret ikke fluktuerer. Det er stærkt tidligt i et projekt, hvor arkitektur og sporbarhed skal på plads før tuning.
Hvornår skifter man til rigtige API-kald? Når du tester latens, hallucinationer, edge cases i retrieval og omkostningsprofil. Mocken er for pædagogisk til at afsløre de skæve kanter i rigtige modeller. Vores erfaring: En POC-dag kører bedst sådan—formiddag på mock for at få spor, prompts og metrikker koblet rigtigt; efter frokost OpenAI med et lille testset, så driftssignalerne bliver realistiske. Det holder omkostningen nede og sikrer, at dashboards afspejler virkeligheden, ikke kun en træningsdukke.
Operativ implementering i drift og incident response
Tracing er ikke bare et udviklerlegetøj. Når agentiske mønstre eller LLM-dreven automatisering rammer produktion, dukker der nye driftsfejl op, som ikke passer i klassiske skabeloner. VentureBeat rapporterer, at 79 procent af organisationer allerede har en form for AI-agent i produktion, og 96 procent planlægger at udvide. Samme dækning refererer Gartner-forudsigelser om, at 33 procent af enterprise-software vil indeholde agentisk AI i 2028, mens 40 procent af de projekter risikerer at blive aflyst på grund af dårlige risikokontroller. Tallene er ikke hyggelige—de forklarer, hvorfor sporbarhed og evaluering ikke kan udskydes til sidst i forløbet.
I praksis bør Langfuse-data være første-klasses borger i jeres observability-stak. Ikke en separat ø. I vores opsætninger har vi haft held med at eksportere metadata—request id, promptversion, modelversion, latency, score og tokenforbrug—så de kan korreleres i Splunk eller Datadog med applikationslogs. Når en hændelse rammer, vil I have kæden: hvilken prompt, hvilken retrieval-kilde, hvilken model, hvilken score. Det afkorter rodårsagsanalysen dramatisk og gør postmortems skarpere.
Eksperimenter og måling, ikke mavefornemmelser
Det stærkeste greb i tutorialen er, at eksperimenter er datasæt-baserede og registreres samme sted som sporene. Hypoteser kan formuleres klart, måles og gentages. En lille, brugbar metrikpakke—nøjagtighed per opgave, hallucinationsrate eller en proxy, svarlatens og tokenomkostning per svar—er nok til at stoppe de fleste “vi synes” diskussioner i standup.
Statistisk stabilitet er sin egen rejse. Her hjælper mock ikke. Brug små, faste eval-sæt og byg gradvist. Når vi kører evals i Snilld, låser vi et seed for datagenerering, men ikke for modelkald, så variansen bliver synlig. Tutorialen rammer en praktisk balance: gør det nemt at registrere og sammenligne, så eksperimenter ikke dør i et regneark.
Begrænsninger, risici og governance
Langfuse løser sporbarhed og struktur, men den er ikke en magisk paraply. Fejlklassifikation er en reel risiko, især hvis scoringer bliver for binære. Vores råd er at kombinere auto-scorere med manuelt samplede bedømmelser i starten. Og før I slipper en agent løs på et system med sideeffekter, så definér et egentligt risikoregime: timebokse, whitelists for handlinger og revision af auditlog hver dag den første uge.
Sikkerhed og datahygiejne? Tutorialen berører ikke PII-maskering, encryption at rest eller retention-politikker. Det hul skal lukkes i arkitekturen. Vi lægger typisk en redaction-proxy foran modelkald i følsomme domæner og indfører adgangsbegrænsning til nøgler via secrets management. Auditlogs fra Langfuse bør anses som persondata, hvis de kan indeholde kundeinput, og behandles derefter. Ellers bliver det dyrt senere.
Hvad vi ville gøre først i en kundecase
Hvis vi kun havde én dag, startede vi på mock. Få hele kæden op: tracing, promptlager, scorefelter og et minimalt eval-sæt. Skemaerne først—feltnavne, navngivning, dashboards. Derefter 20–50 realistiske opgaver på rigtige nøgler, udelukkende for at måle latens og tokenomkostning og for at fange hallucinationer. Til sidst simple alarmer: unormal latens, tokenspikes, score under tærskel.
Gør også cost-tracking synlig fra dag ét. Vi har set eksperimenter løbe løbsk på en eftermiddag, fordi en udvikler lod en loop køre med produktive nøgler. Mocken forhindrer ikke alt, men den sænker risikoen markant. Og ja, vi har selv været der. Den slags log-sky har en duft af varm laptop og let panik på kontoret i Skelbækgade.
Tre korte scenarier
Kundeservice-RAG: Dokumenthentning, kontekstkæder og svar. Her bruger vi tracing til at se, hvilke dokumenter der blev hentet, promptstyring til at beskytte tone og politik, scoring til at måle factuality mod kendte svar og eksperimenter til at sammenligne retrieval-strategier. Mock i uge ét, rigtige kald i uge to med fokus på håndtering af OOD-spørgsmål.
Intern summarizer: Batch-job der laver referater af møder eller rapporter. Langfuse bruges primært til cost\/latens-måling, versionering af prompts og til at evaluere resumé-kvalitet mod et lille human-labeled sæt. Her har vi oplevet, at latens er mindre kritisk, men at scoring hurtigt bliver for grov—læg manuelt review ind én gang om ugen.
Og en agent der orkestrerer
Agent-orchestrering: Her bliver observability alt. Hver handling skal have et spor, hvert værktøjskald metadata, og der skal være en klar mapping til systemets sideeffekt. VentureBeat advarer om, at ingen rigtig ejer de hændelser, der opstår mellem agentlogik og infrastruktur. Vi er enige. Uden en sporbarhedskæde, der krydser over i jeres eksisterende logging, ender postmortem i diskussion i stedet for læring.
Vi har i en intern test set, at Langfuse cloud kan tilføje 150–300 millisekunder per request i spidsbelastning i EU-regionen. Det er ikke kritisk for lange svar, men det mærkes i kæder med mange små kald. Tag det som et pejlemærke, ikke en sandhed. Vi følger op med mere systematiske målinger senere.
Tekniske noter fra tutorialen
Opsætning i Colab er banal: pip install langfuse og openai, sæt LANGFUSE_PUBLIC_KEY og LANGFUSE_SECRET_KEY, vælg LANGFUSE_HOST til EU, US eller egen URL. Initialisér klienten og brug observe-dekorator eller start_as_current_observation til manuelle spans. Mock-LLM’en i tutorialen svarer deterministisk på en lille faktatabel og registrerer usage_details som input- og output-tokens. Det er fint til at verificere, at tracing og scoring-lagene virker, før man tilslutter rigtige modeller.
Promptstyring sker centralt i Langfuse med navn og version og kan injiceres i kald som langfuse_prompt. Scoring kan lægges på som evalueringer på generationer eller som del af datasets-eksperimenter. Markeringsdisciplin er alt. Hvis I blander navne og beskrivelser, opløses historikken. Vi nævner det igen, fordi det faktisk var der, vi snublede først.
Hvad vi stadig savner
Tutorialen nævner ikke meget om retention-politikker, pris for massetracing eller PII-maskering. Det er åbne spørgsmål, man bør afklare, før platformen bliver central i en stor driftsløsning. Selvhosting versus cloud med SLA er også et punkt, vi vil grave i. For teams på Java eller Node er der desuden et porteringsspørgsmål—eksemplerne er Python-tunge. Ikke en dealbreaker, men det er et stykke arbejde i backloggen.
Mock-LLM’en dækker simple scenarier og er ikke repræsentativ for distributionsskift, frie hallucinationer eller modeldriveregnskab i skala. Det er stadig fint. Formålet er at teste rørføringen, ikke efterligne hele verden. Men når I vil måle robusthed, skal I ud i virkelige kald og uklare inputs. Her kan eksperimentrammen stadig bruges—den skal bare fodres med rigtigt, grumset data.
Praktiske trin for implementering
Start med en 1-dags POC: formiddag—installation, nøgler, trace en simpel funktion og en lille RAG. Eftermiddag—opret 3–5 promptversioner, et minimalt eval-sæt, og kør 50 cases på mock og 20 på rigtige nøgler. Aflever to dashboards: udviklerfokus (spor og fejl) og drift (latens, tokenforbrug, score). Det er overskueligt og giver en synlig baseline til næste sprint.
Fold derefter Langfuse-signaler ind i jeres overvågning: eksporter korrelerbare nøgler som request id, promptversion, model, latency og score til Splunk eller Datadog. Sæt alarmer for tre ting: pludseligt tokenspike, score under tærskel og stigende latency. Governance-mæssigt: adskil nøgler per miljø, brug staging og gem auditlogs. Det er kedeligt, men sådan undgår man, at Gartner får ret i de 40 procent aflyste projekter.
Hvor efterlader det os
Tutorialen leverer en sjælden komplethed: fra første nøgle til målelige eksperimenter. Den viser ikke alt—særligt ikke sikkerhed og skaleringsdrift—men den giver et solidt stillads. Hvis målet er ansvarlig produktion af LLM-løsninger, er Langfuse et fornuftigt fundament. Vi vil teste selvhosting, måle latens konsekvent og validere SDK-dækning uden for Python. Og måske vigtigst: dokumentere hvordan data fra Langfuse bør leve side om side med klassisk applikationsobservabilitet.
Man opdager forskellen, når man sidder med det i hænderne: Trace åbnes, promptversion matcher, score er lav—og du ved præcis, hvor du skal skrue. Ikke glamourøst. Bare det, der virker.
