Velg en modell ut fra dokumentasjon

Definer beslutningen

En modellsammenligning trenger et konkret bruksområde. En modell som forklarer en liten funksjon godt, håndterer kanskje ikke en stor repositoryendring like godt. En rimeligere modell kan oppfylle kvalitetskravet for rutinemessige transformasjoner. En vanskelig undersøkelse kan kreve større resonneringsevne.

Skriv oppgaven og begrensningene først. Ta med tillatte data, nødvendige verktøy, responstid og høyeste akseptable kostnad. Noen begrensninger er obligatoriske. Ikke la en høy annen poengsum utligne en restriksjon på databehandling.

Bruk representative oppgaver

Bygg et lite evalueringssett fra arbeid teamet faktisk gjør. Fjern sensitive data med mindre evalueringsmiljøet er godkjent for dem. Ta med enkle oppgaver, vanskelige oppgaver og oppgaver der riktig respons er å be om manglende informasjon.

For en fiktiv rapporteringstjeneste bruker du en kjent datofeil, en liten filterfunksjon og en forklaring av en autorisasjonsregel. Forbered forventet resultat før sammenligningen kjøres. Ta med en negativ test som avviser den kjente feilen.

Hold noen oppgaver utenfor promptutviklingen. Hvis du stadig tilpasser prompten til alle eksemplene, kan den endelige poengsummen overdrive generell ytelse. Et separat sett hjelper med å vise om den forbedrede prompten fungerer utover eksemplene som ble brukt til å lage den.

Hold sammenligningen rettferdig

Registrer nøyaktig modellversjon, prompt, oppgitt kontekst, verktøy og tillatelser. Bruk tilsvarende starttilstander. Hvis én modell får et helt repository og en annen får én fil, sammenligner resultatet både arbeidsflyter og modeller.

Arbeidsflytsammenligninger kan være nyttige. Merk dem korrekt. Et agentprodukt omfatter mer enn en modell: kontekstvalg, verktøy, utførelsesgrenser og gjenopprettingsatferd kan påvirke resultatet.

Bruk gjentatte kjøringer når variasjon i resultatet betyr noe. Registrer mislykkede forsøk fremfor bare å rapportere beste resultat. Bruk skriftlige vurderingskriterier og flere reviewere der det er praktisk, for subjektive vurderinger.

Vurder kvalitet før hastighet

Kontroller først obligatoriske akseptkriterier. Oppfyller endringen kravet? Bevarer den tilgangskontroller? Består relevante tester? Kan en reviewer forstå diffen?

Sammenlign deretter innsats, forløpt tid og kostnad for akseptable resultater. Ta med nye forsøk og menneskelig review. Et billig svar som krever gjentatt retting, kan være dyrt på oppgavenivå.

Offentlige benchmarker kan hjelpe med å identifisere kandidater. De bruker bestemte oppgavesett og poengmetoder. Ikke behandle en benchmarkpoengsum som en direkte måling av teamets produktivitet.

Registrer beslutningen og når den må revurderes

Resultatet kan være en smal anbefaling. For eksempel: «Bruk denne modellen til små testtillegg i dette repositoryet med eksisterende reviewkrav.» Du trenger ikke én modell til alle oppgaver.

Angi hva som vil kreve en ny evaluering. Eksempler er ny modellversjon, endret verktøykonfigurasjon, en ny datakategori eller et vedvarende feilmønster. Behold et alternativ for oppgaver som overstiger den valgte modellens evner.

Formålet med evaluering er å redusere usikkerhet om en reell beslutning. Unngå en permanent modellkonkurranse som bruker mer innsats enn arbeidet den støtter.