På denna sida
Ett svar om en returnerad order ser redo ut att skickas: korrekt språk, vänligt och kort. I detta illustrativa fall ger en automatisk bedömning full poäng. Assistenten säger också till kunden att återbetalningen har gjorts, trots att ingen kontrollerade betalningssystemet.
Felet är inte en dålig mening. Det är en dålig definition av bra.
I en inhämtad demonstration av utvärdering bygger ett team bedömningar för en agent som skriver programvarudokumentation. Det intressanta ögonblicket är när den som kan arbetet beskriver vad kvalitet betyder och ett verktyg gör beskrivningen till kriterier. Senare väcker en låg poäng rätt tvivel: kanske måste agenten rättas, eller kanske utvärderingen.
Mallen är en teori om uppgiften. Testa teorin.
Börja med misstaget som underkänner
Team börjar ofta med sådant som är lätt att ge poäng: tydlighet, ton, struktur och fullständighet. Det är användbart, men sällan tillräckligt.
För det illustrativa återbetalningssvaret ska ”påstå aldrig att återbetalning är klar utan betalningskvitto” stå över språkkvalitet. Vid datasynkronisering väger ”mappa inte fakturaadressens e-post till kontoägarens e-post” tyngre än en välskriven förklaring av fältmappningen.
Be ämnesexperten om tre slags fall: ett uppenbart bra, ett uppenbart fel och ett där kunniga personer kan vara oense. Bevara källposterna och skälet bakom varje bedömning. Om ett fall beror på en regel som kan ändras, versionsmärk regeln med etiketten.
Första omgången kan vara liten. Den får inte vara vag.
- Uppgiftsägare
bra, dåliga och omtvistade fall
- Exakta kontroller identitet · behörighet · mål
kod upprätthåller fakta
- Semantisk mall
granska bara det som kräver tolkning
- Granskning av oenighet
rätta etiketter och kriterier
| Kontroll | Bättre ansvarig | Varför |
|---|---|---|
| Nödvändig behörighet finns | Kod och styrande poster | Faktumet är exakt och har följder |
| Mål-ID matchar källans identitet | Kod och en testpost | En modell ska inte gissa identifierare |
| Svaret besvarar kundens fråga | Mänskligt granskad mall, eventuellt modellgranskare | Betydelsen behöver tolkas |
| Tonen passar situationen | Mänskligt granskad mall, eventuellt modellgranskare | Flera former kan vara godtagbara |
Vår guide till AI i befintliga arbetsflöden ger närliggande råd om att skilja modellbedömning från kontroller: kod ska bevara originalvärden och kontrollera gränser efter ett modellval. Modellens säkerhet blir inte tillåtelse.
Poängen ärver mallens blinda fläckar
Invändningen är rimlig: ”En människa kan inte granska varje körning. Vi behöver en skalbar granskare.” Ja. Frågan är vad granskaren skalar upp.
Om mallen belönar ett välputsat svar men aldrig kontrollerar om ordern faktiskt återbetalades kommer automatiseringen att skala upp utelämnandet. Ett tal med två decimaler ser exakt ut. Det kan ändå mäta fel sak.
Google Clouds dokumentation om utvärdering av modellgranskare beskriver ett praktiskt test: förbered fall med mänskliga betyg, kör det modellbaserade måttet och jämför poängen. Poängen är inte att en människas syn är ofelbar, utan att modellen behöver en yttre standard innan dess poäng får tyngd.
Granska oenighet, inte bara genomsnittlig samstämmighet. Om granskaren godkänner ett svar som supportchefen avvisade, fråga vilket saknat kriterium som förklarar det. Om två experter är oense, spara båda etiketterna och hitta regeln de tolkar olika. Jämna inte tyst ut tvisten.
Urvalet är lika viktigt som kriteriets ord. En samling vanliga framgångar kan få granskaren att verka pålitlig och lämna svåra fall oprövade. Ta med ofullständiga poster, motstridiga instruktioner och fall där rätt svar är att stanna och fråga. Behåll en egen grupp fall som mallens författare inte anpassat sig till, så att förbättring på bekanta exempel måste bevisas också på andra. När affärsregeln ändras, uppdatera både etiketter och förväntade resultat. En fryst testuppsättning kan annars belöna gårdagens policy.
Håll resultatet kopplat till utvärderingen
En mall för en synkroniseringsagent bör följa kundens resultat. Ändrades rätt kontakt? Respekterades samtycket? Kan en misslyckad post spelas upp utan att en åtgärd med följder upprepas?
Guiden till Brevo-anslutningen förklarar varför ett lyckat API-anrop kan samexistera med ett saknat attribut. En utvärdering som bara kontrollerar att agenten anropade ändpunkten missar resultatet. En som bara granskar målsystemet kan missa en förbjuden väg som råkade sluta med rätt värde. Båda spelar roll när vägen bär risk.
Börja med en smal uppgift och några feltyper. Märk upp fallen med den som äger uppgiften. Lägg exakta kontroller i kod och använd en modellgranskare bara där språk eller omdöme verkligen kräver det. Kör samma fall efter ändringar av prompt, modell eller verktyg. Registrera vad senare fel avslöjar om mallen.
Priset är experttid i början. Vinsten är att varje senare poäng betyder något som någon kan försvara.
En dashboard kan visa en poäng. Bara mallen säger vad du räknade.
Vanliga Frågor
Vem ska definiera kriterierna för att bedöma en AI-agent?
De som kan uppgiften och dess följder bör definiera godtagbara resultat och underkännande fel. Utvecklare kan göra bedömningarna till upprepningsbara kontroller och testa om en modellgranskare stämmer med mänskliga betyg.
Bevisar en hög poäng att agenten fungerar?
Nej. Poängen mäter överensstämmelse med en mall på de fall som testades. En svag mall, skeva fall eller en dåligt kalibrerad granskare kan ge höga poäng åt ett skadligt resultat.
Vad bör kod kontrollera i stället för en modellgranskare?
Exakta behörigheter, postidentifierare, nödvändiga verktygsanrop och tillstånd i målsystemet bör kontrolleras med kod när det går. Modellgranskning passar semantiska egenskaper som exakta regler inte avgör.