Skip to content
Zaloguj sięRozpocznij

Dokumentacja referencyjna

Błędy

Rozróżnienie, dla którego istnieje ta strona: przebieg, który się nie powiódł, i przebieg, który zakończył się błędem, to różne rzeczy, a przedstawianie jednego jako drugiego mówi deweloperowi, że jego zmiana jest zła, podczas gdy w rzeczywistości zawiodła infrastruktura testowa.

Niepowodzenie jest wynikiem. Błąd nie jest.

FAIL oznacza, że bramka została oceniona, a dowody znalazły się poniżej progu. To wynik jakościowy dotyczący zmiany.

RUN_ERROR oznacza, że przebieg się nie zakończył. Żadna bramka nie została oceniona i nic w zmianie nie zostało zmierzone. Nie jest to stan decyzji, podobnie jak PARTIAL czy CANCELLED — opisują one, co stało się z przebiegiem, a nie co zdecydowano o systemie.

Co raportuje niekompletny przebieg

Bramka nad niekompletnym przebiegiem kończy się kodem 5, a nie 1. Dowodów brakuje, a nie są złe, i te dwie sytuacje wymagają różnych reakcji: nieudana bramka prosi o przyjrzenie się zmianie, niekompletna — o przyjrzenie się infrastrukturze.

Przypadki, których nie dało się zmierzyć

Przypadek zakończony błędem jest ograniczany, a nie pomijany. Każda metryka zapisuje cztery liczności — łączną, kwalifikującą się, zaobserwowaną i brakującą — a przedział uwzględnia przypadki, których nie mógł zobaczyć.

Ma to większe znaczenie, niż się wydaje. Metryka, która liczy nieoceniony przypadek jako zero, obciąża model awariami samego systemu jako niepowodzeniami jakościowymi, a mianownik, który po cichu się kurczy, gdy system zaczyna zawodzić, to sposób, w jaki zawodzący system raportuje rosnący wynik. Oba zjawiska zaobserwowano na działającym asystencie, gdzie 13,8% wywołań zwróciło HTTP 500.

Błędy przejściowe

System może zadeklarować, że niepowodzenie było przejściowe, a przejściowe niepowodzenie jest ponawiane, zamiast być zapisane jako wynik jakościowy. Przekroczenie limitu czasu u dostawcy nie jest dowodem na temat promptu.

Deklaracja jest jawna: system wywoływalny zgłasza TransientError z retryable=True. retryable domyślnie ma wartość False, a TransientError bez niego jest zapisywany na przypadku jak każdy inny wyjątek, więc przypadek jest brakujący, a nie ponawiany. System HTTP i dostawca sędziego nie potrzebują deklaracji: przekroczenie limitu czasu, zerwane połączenie, 429 lub 5xx są dla nich ponawiane. Tak czy inaczej wywołanie jest próbowane najwyżej cztery razy, z wycofywaniem, a przypadek, który nadal zawodzi, jest brakujący. Postęp i współbieżność pokazuje oba warianty.

Błędy konfiguracji

Kod wyjścia 2 oznacza, że wywołanie lub konfiguracja były błędne i nic nie zostało uruchomione. Odmowa z powodu limitu jest jednym z nich: to błąd konfiguracji z nazwaną przyczyną, zgłaszany przed wykonaniem pierwszego przypadku, i nigdy nie jest stanem decyzji. Fakt handlowy nie może przychodzić przebrany za werdykt jakościowy.

Diagnozowanie tego, co się nie powiodło

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

Interwencja określa, w jakich warunkach ponownie uruchamiane są nieudane przypadki — gold-context, top-k lub reranker — a kryterium mówi, niepowodzenia którego ewaluatora wziąć. Diagnoza raportuje czynniki niepowodzeń z licznościami, identyfikatorami scenariuszy, które za nimi stoją, i przyjętymi założeniami. Wskazuje czynnik, a nie przyczynę: silnik nie twierdzi, że jedna rzecz spowodowała drugą, i nie twierdzi tak żaden ekran, który ją wyświetla.

Co dalej