Fouten

Het onderscheid waarvoor deze pagina bestaat: een run die mislukte en een run die een fout gaf zijn verschillende dingen, en het ene als het andere presenteren vertelt een ontwikkelaar dat zijn wijziging slecht is terwijl in werkelijkheid het harnas omviel.

Een mislukking is een resultaat. Een fout niet.

FAIL betekent dat een gate werd geëvalueerd en dat het bewijs onder de drempel lag. Dat is een kwaliteitsresultaat over de wijziging.

RUN_ERROR betekent dat de run niet werd voltooid. Er werd geen gate geëvalueerd en er is niets over de wijziging gemeten. Het is geen beslissingstoestand, en PARTIAL of CANCELLED evenmin — ze beschrijven wat er met een run gebeurde, niet wat er over een systeem werd besloten.

Wat een onvolledige run rapporteert

Een gate over een onvolledige run eindigt met 5, niet met 1. Het bewijs ontbreekt in plaats van slecht te zijn, en de twee vragen om verschillende reacties: een falende gate vraagt je naar je wijziging te kijken, een onvolledige vraagt je naar je infrastructuur te kijken.

Cases die niet gemeten konden worden

Een case die een fout gaf, wordt begrensd, niet weggelaten. Elke metriek legt vier aantallen vast — totaal, in aanmerking komend, geobserveerd en ontbrekend — en het interval houdt rekening met de cases die het niet kon zien.

Dit doet er meer toe dan het klinkt. Een metriek die een niet-beoordeelde case als nul telt, rekent de eigen storingen van een systeem het model aan als kwaliteitsfouten, en een noemer die stilletjes krimpt wanneer een systeem begint te falen, is hoe een falend systeem een stijgende score rapporteert. Beide werden waargenomen bij een live assistent, waar 13.8% van de aanroepen HTTP 500 teruggaf.

Tijdelijke fouten

Een systeem kan declareren dat een fout tijdelijk was, en een tijdelijke fout wordt opnieuw geprobeerd in plaats van vastgelegd als kwaliteitsresultaat. Een time-out van een provider is geen bewijs over een prompt.

De declaratie is expliciet: een aanroepbaar systeem werpt TransientError met retryable=True. retryable staat standaard op False, en een TransientError zonder die vlag wordt op de case vastgelegd zoals elke andere exceptie, zodat de case ontbreekt in plaats van opnieuw geprobeerd te worden. Een HTTP-systeem en een judge-provider hebben geen declaratie nodig: een time-out, een verbroken verbinding, een 429 of een 5xx wordt voor hen opnieuw geprobeerd. Hoe dan ook wordt een aanroep hoogstens vier keer geprobeerd, met backoff, en een case die dan nog faalt, ontbreekt. Voortgang en gelijktijdigheid laat beide zien.

Configuratiefouten

Exitcode 2 betekent dat de aanroep of de configuratie fout was en dat er niets draaide. Een quotumweigering is er daar één van: het is een configuratiefout met een genoemde reden, geweigerd voordat de eerste case wordt uitgevoerd, en het is nooit een beslissingstoestand. Een commercieel feit mag niet vermomd als kwaliteitsoordeel binnenkomen.

Diagnosticeren wat wel mislukte

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

De interventie is waaronder de mislukte cases opnieuw worden gedraaid — gold-context, top-k of reranker — en het criterium zegt van welke evaluator de mislukkingen worden genomen. Een diagnose rapporteert faalfactoren met aantallen, de scenario-id's erachter en de aannames die ze deed. Ze noemt een factor, geen oorzaak: de engine beweert niet dat het ene het andere veroorzaakte, en geen scherm dat de diagnose weergeeft doet dat.

Verder lezen

• Kernbegrippen behandelt beslissingstoestanden en noemers.
• CI gaten somt elke exitcode op.
• RAG-evaluatie loopt een diagnose van begin tot eind door.