Een AI-systeem levert geen waarde omdat een model één keer een goed antwoord geeft. Het levert waarde wanneer een team kan aantonen wat het systeem deed, waarom het dat deed, wat het kostte, of het resultaat aan de acceptatiecriteria voldeed en of de volgende versie daadwerkelijk beter is.
Daarom is Langfuse bij Laava geen optioneel dashboard. Het is een vaste engineeringlaag in elk AI-systeem dat we bouwen, van de eerste Proof of Pilot tot een workflow die dagelijks in de operatie draait.
We gebruiken het omdat development en operations daarmee naar hetzelfde bewijs kijken: volledige traces, exacte promptversies, evaluatiescores, latency, tokengebruik en kosten. Simpel gezegd helpt Langfuse ons sneller te ontwikkelen, continu te optimaliseren en modelbudget in te zetten waar het echte waarde oplevert.
De lus die we in elk AI-project willen
AI-ontwikkeling wordt duur wanneer iedere wijziging op intuïtie is gebaseerd. Een nieuwe prompt klinkt beter. Een groter model voelt veiliger. Meer opgehaalde context lijkt nuttig. Maar zonder meting weet niemand wat verbeterde, wat verslechterde of wat die afweging kost.
Onze lus is eenvoudig:
- Traceer de volledige workflow, niet alleen de model-call.
- Evalueer het resultaat op expliciete acceptatiecriteria.
- Vergelijk prompt-, model- en pipelinevarianten op dezelfde werklast.
- Optimaliseer context, tokens, tools, retries, latency en modelkeuze.
- Release en monitor de winnende versie in productie.
Langfuse verbindt die stappen. Daardoor worden prompt- en modelwijzigingen engineeringbeslissingen in plaats van meningen.
1. Sneller ontwikkelen en debuggen
Wanneer AI-output niet klopt, is het model maar één mogelijke oorzaak. Een document kan verkeerd zijn geparsed. Retrieval kan een verouderd beleidsdocument hebben geselecteerd. Een tool kan een timeout hebben gehad. Een validatiestap kan drie dure retries hebben veroorzaakt. Of de promptversie in productie is niet de versie die het team verwachtte.
We traceren het volledige uitvoeringspad als geneste observaties: inputverwerking, retrieval, contextopbouw, modelgeneraties, tool-calls, validaties, menselijke goedkeuringen en downstream-acties.
Per run willen we kunnen zien:
- de exacte input en opgehaalde context;
- de prompt-, model- en applicatieversie;
- iedere tool-call, vertakking en retry;
- latency per stap en tokengebruik en kosten voor iedere modelgeneratie;
- de uiteindelijke output en de bijbehorende evaluatiescores.
Dat bewijs verkort de route van “de AI deed het fout” naar een reproduceerbare oorzaak. Engineers besteden minder tijd aan het reconstrueren van een incident uit losse logs en meer tijd aan het oplossen van het onderdeel dat daadwerkelijk faalde.
2. Prompts worden beheerde operationele logica
In een productie-AI-systeem zijn prompts onderdeel van de operationele logica. Ze horen niet als anonieme tekst in een notebook te staan of als ontraceerbare copy-paste in applicatiecode.
Met Langfuse kunnen we promptversies en deploymentlabels zoals staging en production beheren en de gebruikte prompt direct koppelen aan de resulterende trace. Voor we een versie promoveren, vergelijken we die op een representatieve dataset. Na release monitoren we of het profiel voor kwaliteit, latency en kosten standhoudt op echt verkeer. Zo niet, dan weten we precies wat veranderde en kunnen we gericht terugrollen.
Daardoor wordt itereren ook teamwerk. Engineers, product owners en domeinexperts bespreken een specifieke versie en de gemeten uitkomsten, in plaats van te debatteren over welke prompt iemand zich herinnert te hebben getest.
3. Evaluatie maakt van “ziet er goed uit” een acceptatiecriterium
Observability vertelt wat er gebeurde. Evaluatie vertelt of dat goed genoeg was. Voor serieuze AI-delivery heb je beide nodig.
We definiëren evaluatiecriteria rond het werk dat het systeem uitvoert. Een documentworkflow kan correcte gestructureerde output, juiste bronverwijzingen, alle verplichte velden en veilige escalatie bij ontbrekende informatie vereisen. Een kennisagent kan worden beoordeeld op onderbouwing, relevantie en of hij binnen beleid blijft.
Afhankelijk van de taak combineren we:
- deterministische checks zoals schemavalidatie en business rules;
- menselijke beoordeling en feedback van eindgebruikers;
- modelgebaseerde evaluatie op basis van een duidelijke rubric;
- datasets en experimenten om wijzigingen vóór release te vergelijken.
We bouwen die evaluatieset vanaf het begin op en voegen moeilijke, representatieve gevallen toe zodra het systeem ze tegenkomt. Zo ontstaat een regressietest voor AI-gedrag en voorkomen we dat een optimalisatie op één plek stilletjes iets anders beschadigt.
4. Token- en kostenoptimalisatie met bewijs
Langfuse bespaart niet automatisch tokens. Het geeft ons de herleidbaarheid die nodig is om tokens te besparen zonder met kwaliteit te gokken.
Gebruiks- en kostendata op trace-niveau maken verspilling zichtbaar. Veelvoorkomende voorbeelden zijn:
- instructies of voorbeelden die in ieder request opnieuw worden meegestuurd;
- meer opgehaalde context dan de taak nodig heeft;
- stabiele context die provider prompt caching kan gebruiken;
- retry- of agentlussen die onnodige model-calls veroorzaken;
- een flagshipmodel voor een stap die een kleiner model aankan;
- output die langer is dan het bedrijfsproces vraagt.
Zodra de bron zichtbaar is, kunnen we een kortere prompt, strakkere retrieval, caching, betere stopcondities, een kleiner model of taakgerichte modelrouting testen. Met Langfuse vergelijken we de nieuwe versie vervolgens tegen dezelfde kwaliteitscriteria.
Het doel is niet de goedkoopste losse model-call. Het doel is de beste kostprijs per geaccepteerde uitkomst: het juiste kwaliteits- en risiconiveau, met zo min mogelijk latency, tokengebruik en verspilling als de workflow toestaat.
Dat onderscheid is commercieel belangrijk. Geld besparen door het systeem minder betrouwbaar te maken is geen optimalisatie. Kosten verlagen terwijl de acceptatiegraad gelijk blijft of verbetert wel.
5. Productie-AI die beheersbaar blijft
Een AI-systeem verandert na livegang. Modellen worden bijgewerkt, prompts evolueren, brondocumenten veranderen, verkeer verschuift en nieuwe edge cases verschijnen. Zonder gedeeld operationeel dossier kan de prestatie afglijden terwijl het dashboard nog steeds succesvolle API-responses toont.
Met Langfuse kunnen we runs uitsplitsen naar omgeving, release, workflow, gebruiker of klantcontext en operationele metrics koppelen aan evaluatiescores. Dat helpt regressies detecteren, incidenten onderzoeken en bepalen waar de volgende engineeringinspanning de meeste impact heeft.
Het maakt het systeem ook beter overdraagbaar. De klant is niet afhankelijk van het geheugen van één engineer om te begrijpen waarom een agent handelde. Er is een traceerbaar pad langs context, redenering, tools, validatie en actie. Dat past bij hoe wij bouwen: duidelijke grenzen, menselijke controle waar nodig en beheerbaarheid vanaf dag één.
Tracing vraagt wel om bewuste datagovernance. We bepalen welke inputs en outputs mogen worden vastgelegd, maskeren gevoelige velden waar nodig en stemmen retentie en toegang af op het project. Langfuse is open source en kan self-hosted draaien in de cloud, VPC of on-premises omgeving van een klant wanneer de data-eisen om dat niveau van controle vragen.
Waarom specifiek Langfuse
Er zijn veel manieren om een LLM-call te loggen. Wij kiezen Langfuse omdat het de volledige engineeringlus in één platform samenbrengt:
- end-to-end tracing voor LLM-calls, retrieval, tools en applicatielogica;
- promptmanagement met versies, labels en koppelingen naar echte runs;
- online en offline evaluatie met scores, datasets en experimenten;
- token-, kosten- en latencymetrics op workflow-niveau;
- een OpenTelemetry-basis die in een bredere observabilitystack past;
- open-source en self-hosted deploymentopties.
Het grootste deel van onze applicatielaag bouwen we in TypeScript en Node.js. Langfuse sluit daar via de JavaScript/TypeScript-tooling en OpenTelemetry-basis natuurlijk op aan, zodat we één trace kunnen volgen door applicatiecode, agent-orchestratie, retrieval, tools en model-calls.
Die combinatie past bij de architectuurprincipes van Laava. We zijn niet gebonden aan één model of leverancier: modelkeuze volgt de taak, op basis van kwaliteit, latency, kosten, privacy en deploymentomgeving. Langfuse geeft ons de gemeenschappelijke meetlaag over al die keuzes heen.
We beweren niet dat één tool een AI-systeem production-ready maakt. Langfuse vervangt geen goede architectuur, veilige integraties, evaluatieontwerp of engineeringoordeel. Het maakt de gevolgen van die beslissingen zichtbaar en vergelijkbaar.
Van eerste pilot naar AI-native operatie
Een Proof of Pilot hoort geen wegwerpdemo te zijn. We instrumenteren de eerste betekenisvolle workflow, bepalen de eerste acceptatiecriteria en verzamelen direct het bewijs waarmee we kunnen verbeteren. Wanneer het systeem groeit, helpt dezelfde basis de vragen beantwoorden die bepalen of het kan opschalen: Blijft de kwaliteit stabiel? Welke stap is traag? Welk model is zijn kosten waard? Waar blijft menselijke controle nodig? Wat veranderde na de laatste release?
Dat is het verschil tussen een slimme AI-feature en AI die daadwerkelijk meewerkt in de operatie.
We zijn oprecht enthousiast over Langfuse omdat het aansluit bij hoe we willen bouwen: systemen in plaats van magie, meetbare verbetering in plaats van intuïtie en degelijke engineering achter iedere nuttige agent.
Daarom gebruiken we Langfuse in elk AI-project dat we bouwen.
Werkt je AI-pilot, maar kun je nog niet uitleggen welke versie het beste presteert, wat iedere succesvolle workflow kost of waar fouten ontstaan? Dan is observability geen afwerking. Het is de volgende engineeringstap van experiment naar productie.