LLM-observability

Wat is LLM-observability?

LLM-observability is een AI-toepassing kunnen volgen, begrijpen en uitpluizen gedurende haar hele leven. Niet enkel of ze nog draait, maar wat ze bij een bepaalde vraag gedaan heeft en of het antwoord iets waard was.

De reden dat dit een eigen naam nodig heeft, is dat een taalmodel anders stukgaat dan gewone software. Gewone software faalt met veel lawaai. Ze gooit een fout, geeft een 500 terug, of valt stil. Een taalmodel doet dat zowat nooit. Het geeft je een vlot en zelfzeker antwoord dat toevallig fout is, terwijl je monitoringscherm groen kleurt omdat de aanvraag na 900 milliseconden netjes een 200 teruggaf.

De vraag verschuift daardoor. Bij een database vraag je of ze geantwoord heeft. Bij een AI-toepassing moet je vragen of ze juist geantwoord heeft, of ze de juiste bron gebruikt heeft, of ze binnen de opdracht gebleven is, en of ze niets gedaan heeft dat ze niet mocht doen.

De drie lagen die je nodig hebt

Microsoft groepeert dit in drie mogelijkheden die samenwerken, en die opdeling is een goede manier om erover te denken, welk gereedschap je ook gebruikt.

Tracing legt vast wat er bij één aanvraag gebeurde. Welk model aangeroepen is, met welke prompt, welke tools eraan te pas kwamen, wat die tools teruggaven, en hoe de agent van de vraag naar het antwoord geraakt is. Bij een agent die acht stappen doorloopt, is dit de enige manier om te achterhalen welke stap fout liep.

Evaluatie beoordeelt de kwaliteit van de output zelf. Dit is wat een gewone monitoringopstelling niet kan, want er is geen fout om op te vangen. Je laat een reeks beoordelaars los op antwoorden en krijgt scores terug op dingen zoals of het antwoord gedekt wordt door het bronmateriaal, of het relevant is voor de vraag, en of het samenhangend is.

Monitoring is wat in productie meedraait zodra het geheel live staat. Tokenverbruik, wachttijd, foutpercentages en kwaliteitsscores doorheen de tijd, met alarmen als de output onder een drempel zakt of als er iets schadelijks doorglipt.

Het nuttige zit in hoe ze aan elkaar hangen. Monitoring vertelt je dat er iets veranderd is. Evaluatie vertelt je wat er slechter geworden is. Tracing vertelt je waarom. Laat je er één van de drie weg, dan hou je een gat over dat je op een vervelend moment ontdekt.

De standaard eronder

Er bestaat een open standaard voor, en dat telt als je liever niet vastzit aan het dashboard van één leverancier.

OpenTelemetry, hetzelfde project dat achter tracing in gewone software zit, heeft semantische conventies voor generatieve AI. Die leggen vast hoe een span eruitziet voor een modelaanroep, een embedding-aanroep of een zoekopdracht, en welke attributen erop horen. Je krijgt namen als gen_ai.operation.name voor het soort bewerking, gen_ai.provider.name voor de aanbieder, gen_ai.request.model voor het model dat aangeroepen wordt, en gen_ai.usage.input_tokens en gen_ai.usage.output_tokens voor het verbruik.

Omdat die namen afgesproken zijn, kan een trace uit het ene framework in hetzelfde gereedschap belanden als een trace uit het andere. En je tokenkost per aanvraag wordt daardoor een getal dat je kan groeperen en filteren zoals eender welke andere meting. Microsoft Foundry bouwt zijn tracing op OpenTelemetry en voert het door naar Application Insights, en het ondersteunt traces uit meerdere frameworks, waaronder LangChain, LangGraph en het Microsoft Agent Framework.

Eén kanttekening die je best kent voor je er veel op bouwt: deze conventies staan nog aangemerkt als in ontwikkeling, dus de namen van attributen kunnen nog wijzigen.

Wat je meet op een agent

Zodra je toepassing geen enkele modelaanroep meer is maar een agent, veranderen de vragen, en daarmee ook de metingen.

Bij antwoorden die op je eigen documenten steunen, kijk je naar drie dingen. Wordt het antwoord effectief gedekt door het materiaal dat opgehaald is. Heeft de zoekstap überhaupt het juiste stuk teruggebracht. En is het antwoord relevant voor de vraag die gesteld werd.

Bij een agent die acties uitvoert, kijk je naar andere dingen. Heeft hij de juiste tool aangeroepen met de juiste argumenten. Is hij binnen de opdracht gebleven, inclusief de regels en de beperkingen die erbij hoorden. Heeft hij achterhaald wat de gebruiker echt wou. Is hij tot een einde gekomen.

Er is nog een meting die mensen vergeten: de kost per geslaagd resultaat. Een agent die negen keer op tien juist antwoordt maar er vier keer zoveel tokens voor verbruikt, is niet vanzelfsprekend beter dan een agent die acht keer op tien juist antwoordt. Dat gesprek kan je niet voeren zonder de tokenattributen op je traces.

Waar moet je op letten bij LLM-observability

Prompts en antwoorden zijn data die je vanaf nu bewaart. Een volledige trace bevat wat de gebruiker typte en wat het model antwoordde, en daar kunnen makkelijk persoonsgegevens of commercieel gevoelige zaken in zitten. Beslis wat je bijhoudt, hoe lang, en wie erin mag kijken, voor je alles begint te loggen.

Evalueer niet alles in productie. Een beoordelaar op elk antwoord loslaten betekent dat je bij elke aanvraag een tweede modelaanroep betaalt. Steekproeven zijn normaal, en die volstaan zolang de steekproef echt willekeurig is en niet gewoon wat toevallig makkelijk te vangen viel.

Een beoordelaar is ook een model. Automatische scores komen meestal van een taalmodel, en dus hebben ze hun eigen vertekeningen en hun eigen foutenmarge. Behandel een score als een signaal dat er iets bekeken moet worden, en niet als een uitspraak.

Traces zonder testset verklaren enkel het verleden. Ze vertellen je wat er gebeurd is bij een aanvraag die al de deur uit is. Om te weten of een aanpassing iets verbetert, heb je een vaste set testvragen met verwachte antwoorden nodig die je kan draaien voor je uitrolt.

Bouw het voor je live gaat en niet erna. Tracing achteraf op een agent zetten die al in productie draait, betekent dat je geen nulmeting hebt, en dus ook niet kan aantonen of vorige maand beter of slechter was.