Anthropic lancerer 'claude plugin eval' til måling af plugins i CI
Anthropic har udgivet et eval‑workflow i Claude Code med kommandoen claude plugin eval. Det kører et plugin mod realistiske prompts, bedømmer svarene med definerede graders og sammenligner med en kørsel uden plugin – en no‑plugin baseline. Så kan man se, om pluginet faktisk leverer. Nyheden gælder fra Claude Code v2.1.269 og nyere, og workflowet kan køre på en mappe med plugin.json, .claude-plugin/plugin.json eller et skills‑directory plugin.
Hvert run er et rigtigt modelkald, og graderne llm og baseline bruger en judge‑model, som også faktureres. Det bliver først rigtig vigtigt, når evals flyttes til CI‑runneren, hvor ingen sidder klar til at stoppe et dyrt job.
Hvad er 'claude plugin eval' kort fortalt
Kommandoen kører et valgt plugin mod en eval‑suite af cases (hver med en prompt.md) og måler resultatet med graders. Den samme case kører to gange: med plugin lastet (with‑arm) og uden plugin (without‑arm). Forskellen – Δ – er signalet for, om pluginet bidrog. Man kan markere enkelte graders som with‑only, typisk når man blot vil se, om et bestemt tool blev valgt, uden at det tæller i den samlede score.
Versionkravet er Claude Code v2.1.269 eller højere. Workflowet er lavet til drift: teams kan lægge evals på build‑servere og få konsistente svar på, om ændringer i plugin, model eller prompts flytter kvaliteten.
Hvordan en eval‑suite er opbygget i praksis
En eval‑suite ligger under evals/ i pluginet. Hver case har sin egen undermappe med en prompt.md og en graders/‑mappe. Indholdet af prompt.md sendes til modellen som skrevet. @path‑mentions udvides ikke. Det kræver, at testdata og filreferencer er lagt eksplicit, uden at stole på dynamiske aliaser.
Frontmatter i prompt.md kan sætte max_turns (standard 10), timeout_seconds (standard 300), model, tags og allowed_tools. Det giver kontrol over samtalens længde, hvilke værktøjer modellen må bruge, og hvilken model der testes. Graders defineres i markdown med type, valgfri vægt og evt. arm, så enkelte målepunkter kan vægte højere eller udelades fra without‑armen, hvor de ikke giver mening.
Seks grader‑typer forklaret og deres pris/effekt
Der er seks grader‑typer. Fire er “billige”, fordi de kun læser transkript eller disk: regex, tool_used, tool_order og file_exists. De fanger mønstermatch i tekst, om et værktøj blev brugt, rækkefølgen af tool‑kald og om forventede filer findes. De er gode til at spotte mekaniske fejl uden ekstra modelkald.
De to sidste – llm og baseline – bruger en judge‑model og koster derfor. llm vurderer fritekst op mod kriterier formuleret i prosa. baseline sammenligner mod et referencesvar. De dækker der, hvor regex ikke rækker, men øger regning og ventetid. Valget handler om dækning versus økonomi: hvor ofte behøver man en judge for at fange reelle kvalitetsforskelle, og hvor kan billige graders klare det meste?
With‑arm vs without‑arm: Δ som den relevante metric
Hver case kører to gange: med og uden plugin. Δ = with − without. Er Δ tæt på nul, har pluginet ikke flyttet noget – og hvis en tool_used: Skill‑grader også fejler, peger det på, at modellen ikke vælger værktøjet under naturlig formulering. Det er en fejltype, som skemavalidering ikke fanger.
Grader‑typer kan markeres with‑only (fx tool_used: Skill), da without‑armen ikke kan “fyre” et ikke‑eksisterende værktøj. I dokumentationen vises et eksempel: WITH 1.00, WITHOUT 0.33, Δ +0.67 på seks runs, anslået $0.41 og 74 sekunder. Det er et dokumenteret eksempel, ikke en uafhængig benchmark; tal varierer med model, grader‑mix og antal runs.
CI‑integration og praktisk kørsels‑eksempel
Kommandoen er bygget til CI. En init kan foreslå cases og graders ved at spørge, hvordan et godt resultat ser ud – og i pipelines kan man bruge –bare <navn> til at skrive en tom skabelon i stedet. Den viste CI‑invokation inkluderer bl.a. –trust-plugin, –json results.json, –threshold 0.8, valg af både model og –judge-model, –no-publish og et loft via –max-cost-usd. Runneren kræver Claude Code og credentials som ANTHROPIC_API_KEY. Uden –trust-plugin fejler et mistænkeligt checkout med exit 1, hvilket er tilsigtet.
Rapporter skrives lokalt til evals/results/<timestamp>/report.html med per‑grader‑domme og judge‑stemmer. Hvor kontoen understøtter det, publiceres rapporten også til claude.ai, medmindre –no-publish er sat. Det stiller krav til, hvad der må uploades fra build‑miljøet. –json giver struktureret output til logs uden at ændre exit‑koder; –threshold er selve CI‑gaten, og usage‑limits kan ligne regressioner, hvis man ikke holder øje.
Omkostnings- og belastningsovervejelser
Regnestykket er: cirka cases × runs × arms agent‑kørsler plus omkring tre korte judge‑kald pr. llm/baseline‑grader pr. run. Hvert eval‑run og hver judge‑vurdering er et faktureret modelkald. Tre håndtag styrer prisen: antallet af runs, hvor mange graders der kræver judge, og valg af judge‑model.
Det er en afvejning mellem signifikans og budget. Start med få runs og flest mulige billige graders for hurtige signaler. Læg llm/baseline ovenpå enkelte nøglecases, hvor tekstlig kvalitet er afgørende. Det sænker både omkostninger og varians i tid. Modelvalg på test og judge påvirker igen latens og pris.
Hvad workflowet kan opdage (og hvad det ikke kan)
Styrken er tidlig opdagelse af skill trigger failure. Når Δ ~ 0, og tool_used: Skill viser, at værktøjet ikke blev valgt, er fejlen tydelig i spændet mellem prompt og værktøjsvalg. Derudover kan tool_order afsløre forkert sekvens, og file_exists kan fange manglende artefakter. regex er nyttig, når et bestemt udtryk skal være til stede, uden at kalde en judge.
Begrænsningerne: Det er ikke en sikkerheds‑ eller compliance‑audit. Multimodale eller stateful plugins kan kræve ekstra opsætning for at testes meningsfuldt. Og governance: publicering til claude.ai er praktisk, men det er ikke fuldt beskrevet, hvilke data der præcist uploades, eller hvilke kontroller findes ud over –no-publish. Test i et afgrænset miljø først.
Anbefalinger for teams der vil implementere dette
Start småt med 10–20 cases med høj forretningsværdi. Brug primært de billige graders. Tilføj llm/baseline på 3–5 nøglecases, hvor tekstlig kvalitet er kritisk. Sæt –max-cost-usd som loft og brug –threshold som klar gate, så commits ikke går videre, når Δ falder under jeres niveau.
Angiv allowed_tools eksplicit og hold max_turns stramt i hurtige checks. Gem rapporter som build‑artefakter, og brug –no-publish i miljøer med følsomme data. Overvej en let “sanity suite” uden judge på hver commit og en tungere nightly med judge‑graders.
Større billede og hvorfor evals bliver vigtigere
Modelpaletten bliver bredere og dygtigere, inkl. større kontekstvinduer og mere multimodalitet. Evals hjælper med at holde faste målepunkter på tværs af modelskift: præsterer pluginet bedre end en bar model, og vælger det rigtige tools under naturligt sprog?
Ulempen er fristelsen til at kalde judge‑modeller oftere, hvilket koster tid og penge. Den tekniske dokumentation giver retningslinjer, men der mangler eksterne benchmarks. Indtil de findes, må teams lave egne miniregnskaber og følge, om CI‑latens bliver en bremse.
Åbne spørgsmål og hvad journalister bør følge op på
Skalerbarhed: hvordan performer workflowet med 500 cases? Hvad sker der med kø‑tid, latens og pris, når judge‑andelen stiger? Governance ved publicering: hvilke felter sendes til claude.ai, og findes der org‑kontroller ud over –no-publish?
Multimodale plugins og eksterne credentials: hvordan orkestreres evals med eksterne systemer eller long‑running processer? Derudover mangler uafhængige cases fra virksomheder med CI‑integration, der kan dele reelle tal for omkostning, tid og fejltyper.
Konklusion
claude plugin eval giver et konkret A/B‑greb til plugin‑udvikling: realistiske prompts, seks grader‑typer, en no‑plugin baseline og en Δ, der viser, om pluginet gjorde forskellen. I CI kan –threshold og –max-cost-usd beskytte mod både kvalitetsfald og økonomiske overraskelser. Hvert judge‑kald koster, og rapport‑publicering kræver omtanke i følsomme miljøer.
Vejen frem: start småt, mål på det vigtigste, brug dommere med måde, og udvid først, når signalet er stabilt.
