Vælg en model ud fra dokumentation

Definér beslutningen

En modelsammenligning kræver et konkret anvendelsesformål. En model, der forklarer en lille funktion godt, håndterer måske ikke en stor repositoryændring lige så godt. En billigere model kan opfylde kvalitetskravet for rutinemæssige transformationer. En vanskelig undersøgelse kan kræve større ræsonnementsevne.

Beskriv først opgaven og begrænsningerne. Medtag tilladte data, nødvendige værktøjer, svartid og højeste acceptable omkostning. Nogle begrænsninger er ufravigelige. Lad ikke en høj score på et andet område udligne en begrænsning for databehandling.

Brug repræsentative opgaver

Lav et lille evalueringssæt ud fra arbejde, teamet faktisk udfører. Fjern følsomme data, medmindre evalueringsmiljøet er godkendt til dem. Medtag enkle opgaver, svære opgaver og opgaver, hvor det korrekte svar er at bede om manglende oplysninger.

For en fiktiv rapporteringstjeneste kan du bruge en kendt datofejl, en lille filterfunktion og en forklaring af en rettighedsregel. Forbered det forventede resultat, før du kører sammenligningen. Medtag en negativ test, der afviser den kendte fejl.

Hold nogle opgaver adskilt fra udviklingen af prompten. Hvis du gentagne gange tilpasser prompten til alle eksempler, kan den endelige score overvurdere den generelle ydeevne. Et særskilt sæt hjælper med at vise, om den forbedrede prompt virker ud over de eksempler, den blev udviklet med.

Gør sammenligningen rimelig

Registrér den præcise modelversion, prompt, tilføjede kontekst, værktøjer og rettigheder. Brug tilsvarende udgangspunkter. Hvis én model får et helt repository og en anden får én fil, sammenligner resultatet både arbejdsgange og modeller.

Sammenligninger af arbejdsgange kan være nyttige. Beskriv dem korrekt. Et agentprodukt omfatter mere end en model. Udvælgelse af kontekst, værktøjer, kørselsgrænser og håndtering af fejl kan påvirke resultatet.

Gentag kørsler, når variation i output har betydning. Registrér fejlslagne forsøg i stedet for kun at rapportere det bedste resultat. Brug skriftlige vurderingskriterier og flere reviewere til subjektive kriterier, hvor det er praktisk.

Vurdér kvalitet før hastighed

Kontrollér først de ufravigelige acceptkriterier. Opfylder ændringen kravet? Bevarer den adgangskontrollerne? Består de relevante tests? Kan en reviewer forstå diffen?

Sammenlign derefter arbejdsindsats, gennemløbstid og omkostninger for acceptable resultater. Medtag gentagne forsøg og menneskeligt review. Et billigt svar, der kræver gentagne rettelser, kan blive dyrt for den samlede opgave.

Offentlige benchmarks kan hjælpe med at finde kandidater. De bruger bestemte opgavesæt og scoringsmetoder. Betragt ikke en benchmarkscore som en direkte måling af teamets produktivitet.

Registrér beslutningen og betingelserne for en ny vurdering

Resultatet kan være en snæver anbefaling. For eksempel: »Brug denne model til små testtilføjelser i dette repository med de eksisterende reviewkrav.« Du behøver ikke én model til alle opgaver.

Angiv, hvad der vil kræve en ny evaluering. Det kan være en ændret modelversion, en anden værktøjskonfiguration, en ny datakategori eller et vedvarende fejlmønster. Behold en alternativ løsning til opgaver, der overstiger den valgte models evner.

Evaluering skal reducere usikkerhed om en virkelig beslutning. Undgå en permanent modelkonkurrence, der kræver større indsats end det arbejde, den støtter.