Offline evaluatie vs online monitoring voor AI-agents

Definitie van offline evaluatie

Trajectaamopbouw

Een traject is een geordende lijst van stappen die de agent moet volgen wanneer deze een specifieke invoer ontvangt. Elke stap bevat:

- de gebruikersuiting of systeemgebeurtenis die de agent activeert - de gedachte of redenering die de agent zou moeten produceren (als je chain-of-thought logt) - de toolaanroep of API-aanvraag die de agent zou moeten doen - het verwachte toolantwoord of omgevingsfeedback - de definitieve agentuitvoer die aan de gebruiker of downstream-systeem moet worden getoond

Wanneer je trajecten verzamelt, begin je meestal met een kleine set van representatieve gebruikersverhalen, en breid je deze vervolgens uit door randgevallen toe te voegen die je in logbestanden hebt gezien of die je je kunt voorstellen op basis van vereistendocumenten.

Beoordelingsrubriek

Offline evaluatie vergelijkt de daadwerkelijke traject van de agent met het gouden traject met behulp van een rubriek die verschillende onafhankelijke dimensies kan bevatten:

- Exacte overeenkomst – produceert de agent dezelfde reeks toolaanroepen en -antwoorden? - Semantische gelijkenis – zijn de uitings- of uitvoervormen zinvol gelijkwaardig, zelfs als de woordkeuze verschilt? - Getrouwheid – blijft de redenering van de agent gebaseerd op de verstrekte tooluitvoer? - Taakgeslaagd – voldoet de definitieve uitvoer aan de geslaagdcriteria die voor het verhaal zijn gedefinieerd?

Elke dimensie krijgt een score tussen 0 en 1. De algehele offline-score is vaak een gewogen gemiddelde, maar je kunt elke dimensie ook als een aparte poort behandelen.

Offline-evaluatie uitvoeren in CI

Omdat de set van trajecten statisch is en de rubriek deterministisch is, kun je de evaluatie als een stap in je continue integratiepijplijn uitvoeren. De stap controleert typisch:

- de agentcode en de trajectfixtuur - installeert eventuele vereiste afhankelijkheden - voert de agent uit tegen elk traject, met vastlegging van het daadwerkelijke spoor - past de rubriek toe en schrijft een JSON-rapport - mislukt de build als elke score onder een vooraf gedefinieerde drempelwaarde daalt

Dit geeft je snelle feedback over regressies die je kunt reproduceren.

Definiëren van online monitoring

Wat u observeert in productie

Online monitoring vergelijkt niet met een vooraf geschreven script. In plaats daarvan worden live signalen van de actieve agent gestreamd en worden afwijkingen van gevestigde baselines gezocht. Typische signalen omvatten:

- distributie van de lengte of token telling van gebruikersuitingen - frequentie van elke toolaanroep - foutpercentages geretourneerd door externe API's - latentie van elke stap in de agentlus - tarief van fallback- of retry-gedrag - semantische afwijking in de finale output (gemeten met embeddingafstand tot een recente referentieset)

Omdat productieverkeer onbegrensd is, verzamelt u deze signalen over tijdvensters (bijv. vijfminuten schuivende vensters) en vergelijkt u deze met historische percentielen.

Instrumentatiepunten

Om de benodigde gegevens te krijgen, moet u de agent op een paar sleutelpunten instrumenteren:

- op het ingangspunt - vang de onbewerkte gebruikersaanvraag en een tijdstempel op - voordat elke toolaanroep wordt gedaan - log de beoogde aanroep en de argumenten - na elke toolreactie - log de succesvlag, foutcode en payloadgrootte - na het produceren van de finale output van de agent - log de uitvoertekst en eventuele veiligheidsscores - op regelmatige tussenpozen - verzend een hartslag die het geheugengebruik en de CPU-belasting bevat

Deze logboeken worden naar een observatieachtergrond (Prometheus, Loki of een aangepaste tijdsreeks) verzonden, waar u dashboards en waarschuwingen kunt maken.

Voorbeeld van een waarschuwingsregel

Een nuttige regel is om een waarschuwing te geven wanneer het percentage aanroepen naar een bepaalde externe API dat een 5xx-fout retourneert, het 99e percentiel van de afgelopen twee weken voor drie opeenvolgende vensters overschrijdt. Dit vangt een plotselinge verslechtering van een afhankelijkheid die de offline-set nooit heeft gedekt, omdat de foutmodus alleen onder echte wereldbelasting verschijnt.

Gangbare valkuilen wanneer je afhankelijk bent van slechts één laag

- Alleen offline-scores verzenden – je kunt de poort passeren, maar nog steeds een agent vrijgeven die faalt bij zeldzame gebruikerszinnen of bij een toolgedrag dat alleen optreedt bij hoge concurrency.

- Alleen dashboards verzenden – je kunt een probleem pas dagen na de verandering opmerken die is samengevoegd, waardoor terugdraaien moeilijker wordt en de gebruikersimpact toeneemt.

- Productiecijfers vergelijken over een periode waarin het model, de prompt of de toollijst ook is gewijzigd – de waargenomen drift kan te wijten zijn aan de geplande upgrade in plaats van een regressie, waardoor valse alarmen ontstaan.

- Dezelfde drempelwaarde gebruiken voor offline- en online-signalen – offline-scores zijn meestal strak (je verwacht bijna-perfecte overeenkomsten) terwijl online-metrics ruisgevoelig zijn; het toepassen van een enkele cut-off kan leiden tot te veel valse positieven of gemiste detecties.

Een regressiepoort bouwen in CI

Hieronder staat een concreet voorbeeld van hoe je de poort voor een klantenserviceagent die een taalmodel, een opvragingsgereedschap en een ticketaanmaak-API gebruikt, zou kunnen structureren.

Stap | Gereedschap of Script | Uitvoer | Frequentie Code en fixtures controleren | git clone + git checkout | Schoon werkruimte | eenmaal per pijplijnrun Afhankelijkheden installeren | pip install -r requirements.txt | Geïsoleerde omgeving | eenmaal per pijplijnrun Agent uitvoeren op elke traject | python run_agent.py --trajecten data/trajecten.jsonl | JSONL-bestand met daadwerkelijke sporen | eenmaal per pijplijnrun Rubric toepassen | python score_traces.py --rubric config/rubric.yaml | Scores per dimensie en overall | eenmaal per pijplijnrun Drempels controleren | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | Slag/foutstatus | eenmaal per pijplijnrun Rapport publiceren | curl -X POST -d @report.json https://metrics.example.com/ingest | Record in tijdsreeks | eenmaal per pijplijnrun

Elke stap is bewust idempotent gehouden, zodat het opnieuw uitvoeren van de pijplijn hetzelfde resultaat oplevert. Als een stap faalt, stopt de pijplijn en wordt de merge-aanvraag geblokkeerd.

Het instellen van productiealarmen die ertoe doen

Effectieve onlinebewaking richt zich op signalen die snel veranderen als er iets misgaat, in plaats van op metrics die alleen langzaam afwijken.

Tool-foutpercentage

Meet het verhoudingsgetal van mislukte toolaanroepen tot het totale aantal toolaanroepen voor elke externe service. Een plotselinge piek geeft vaak aan dat er een storing is in de downstream-service of dat de serviceovereenkomst is gewijzigd en de agent zich daar nog niet aan heeft aangepast.

Lus-herhaalcount

Sommige agents herhalen een toolaanroep als ze een dubbelzinnige reactie ontvangen. Volg het gemiddelde aantal herhalingen per gebruikersaanvraag. Een toename kan betekenen dat het model onzekerdere uitvoer produceert of dat de tool vage fouten retourneert.

Uitvoer-embeddingverschuiving

Bereken een zin-embedding voor elke definitieve agent-uitvoer en vergelijk de afstand tot de mediaan-embedding van de laatste stabiele week. Als de 95e percentielafstand een vooraf ingestelde grens overschrijdt, activeer een onderzoek.

Veiligheidssignaalmonitor

Als u een prompt-injectiedetector of een profanityfilter op de agent-uitvoer uitvoert, log het fractie van aanvragen die zijn gemarkeerd. Gebruik de OWASP LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) om te beslissen welke patronen u moet bekijken. Een stijging van gemarkeerde aanvragen kan aangeven dat het model gevoeliger wordt voor jailbreakpogingen.

Alle deze alarmen moeten worden doorgestuurd naar een on-callrotatie met een duidelijk runbook dat beschrijft hoe de agentversie kan worden teruggedraaid, hoe een toolwrapper kan worden hotgepatcht of hoe aanvullende trajecten kunnen worden verzameld voor offline-testen. De moeten ook worden geconfigureerd om de veiligheid en efficiëntie van de agent te waarborgen.

De cirkel sluiten: monitoringbevindingen omzetten in offline tests

De echte kracht van het hebben van beide lagen wordt zichtbaar wanneer u productieobservaties gebruikt om uw testsuite te verbeteren.

Een nieuw falen vastleggen

Wanneer een waarschuwing wordt geactiveerd, is de eerste stap het exacte aanvraag-antwoordpatroon te extraheren dat het probleem veroorzaakte. De meeste observabiliteitssystemen laten u een traceer-ID downloaden die de volgende informatie bevat:

- de oorspronkelijke gebruikersuiting - elke toolaanroep en de bijbehorende argumenten - elke toolreactie - de definitieve agentuitvoer

Sla deze trace op als een nieuwe trajectbestand.

Het verwachte gedrag labelen

Werk samen met de producteigenaar of de veiligheidsleider om te beslissen wat het correcte gedrag zou moeten zijn. Als het falen werd veroorzaakt door een bug in de tool, kunt u besluiten de toolreactie te simuleren om de gefixte versie te simuleren. Als het falen werd veroorzaakt door de redenering van het model, kunt u een keten van gedachten schrijven die leidt tot het correcte antwoord.

Toevoegen aan de offline-set

Plaats het nieuwe traject in de versiebeheerde trajectenmap. Werk de documentatie bij om de bron te noteren (bijv. "toegevoegd vanuit productie-incident INC-2024-09-12-07").

De rubric aanpassen als nodig

Soms onthult een nieuw traject een dimensie die eerder werd genegeerd. U kunt bijvoorbeeld ontdekken dat de agent soms een correct antwoord produceert, maar een overbodige verontschuldiging zin bevat die gebruikers irriteert. U kunt een "bondigheid"-dimensie toevoegen aan de rubric en deze een gewicht geven.

De poort opnieuw uitvoeren

Voer de CI-pijplijn opnieuw uit. Als het nieuwe traject de algehele score onder de drempel doet dalen, weet u dat de huidige code de poort zou zijn mislukt - wat precies is wat u wilt voorkomen voordat u deze vrijgeeft.

Het herhalen van deze cyclus creëert een feedbacklus waarin productie de testsuite leert wat te testen, en de testsuite bekende regressies voorkomt dat deze bij gebruikers terechtkomen.

Wat dit niet is

Deze discussie belooft niet dat offline evaluatie elke mogelijke bug zal opvangen voordat deze wordt vrijgegeven. Het claimt niet dat online monitoring nooit een fout zal missen of dat de twee lagen samen een 100% garantie van correctheid bieden. Het stelt niet dat het gebruik van deze methoden uw agent foutloos zal maken of dat u veiligheidsbeoordelingen, rode team-oefeningen of formele verificatie kunt overslaan. Het suggereert niet dat de beschreven signalen voldoende zijn voor regelgevingsconformiteit in domeinen met hoog risico. Het beweert niet dat de workflow het noodzakelijke menselijke toezicht zal elimineren of dat u alleen kunt vertrouwen op geautomatiseerde scores voor vrijgavebeslissingen. Het garandeert niet dat een bepaalde drempel voor elk team of elke modelarchitectuur zal werken. Het beweert niet dat de bovenstaande tabel de enige manier is om een CI-poort in te stellen of dat de vermelde waarschuwingsregels universeel optimaal zijn. Het claimt niet dat de OWASP cheat sheets alle prompt-injectiepogingen zullen voorkomen of dat ze een gedetailleerde beveiligingsbeoordeling vervangen.

Referenties

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Veelgestelde vragen

Hebben we beide nodig?

Ja, als de agent iets aanraakt waar een gebruiker of een systeem zich zorgen over maakt. Ze detecteren verschillende klassen van fouten.

Kunnen offline tests monitoring vervangen?

Nee. Uw testset kan geen invoer bevatten die u nog niet heeft bedacht.

Kan monitoring offline tests vervangen?

Nee. Monitoring vertelt u dat er iets is veranderd na het feit; een poort vertelt u dat voordat u iets vrijgeeft.

Waarop moeten we in productie een alarm instellen?

Veranderingssnelheid in foutsignalen, tool-fouttarieven en ongebruikelijke lus- of herhaalpatronen - niet alleen volume.

Hoe houden we scores vergelijkbaar over tijd?

Vastpin de rubriek en de trajecten, en registreer wijzigingen in model, prompt en tools naast de scores.

Is een van beide lagen een veiligheidscertificering?

Nee. Beide zijn engineeringsignalen. Veiligheidsbeoordeling is een afzonderlijke oefening.

Referenties

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Probeer het product: AgentGrade

2026-09-20 · alleen primaire bronnen · geen gefabriceerde verkeersmetrieken · alleen beslissingsondersteuning

Gerelateerde artikelen

- Beoordelingsrubrieken voor AgentEval die tussen stacks reizen - Verken de volledige AI micro-SaaS onderwerpmatrix →