Przewodniki

Wybór spośród kandydatów

oloproof select wybiera spośród kilku wersji systemu najlepszą, która spełnia każde wymaganie, i osobno mówi, czy naprawdę wyprzedza następną. Używaj go, gdy masz na przykład trzech agentów, dwa prompty lub cztery ustawienia wyszukiwania i jeden zestaw wymagań.

Dlaczego nie wybrać najlepszych liczb

Wybór najtańszego kandydata, którego liczby przekraczają progi, ma dwa problemy. Zmierzone 91% przy progu 90% to jeden punkt powyżej, w szumie tysiąca przypadków. A gdy patrzysz na kilku kandydatów, ten, który przekroczył próg dzięki szczęściu, jest tym, którego wybierasz. Dlatego każdy kandydat musi najpierw sam ustalić każdą regułę, na surowszym poziomie ufności, bo ogląda się kilku: przy trzech kandydatach i polityce 95% każdy jest rozstrzygany na poziomie 98.33% (1 - 0.05/3). Szeregowani są tylko kandydaci, którzy przechodzą każdą regułę, a tańszy nigdy nie może wymienić reguły bezpieczeństwa na swój koszt.

Deklarowanie wyboru

Napisz plik wyboru obok projektu i rozstrzygnij go według release.yaml projektu:

select:
  candidates:
    agent_a: run_01JC8Q2X7D
    agent_b: agent_b.yaml
    agent_c: agent_c.yaml
  objective:
    metric: cost_per_task
    direction: minimize

Kandydat to zapisany identyfikator przebiegu albo plik projektu, który oloproof select najpierw uruchamia. Przebieg, który można użyć ponownie, nie kosztuje nic nowego. Polityka może zawierać tylko reguły przebiegu, a wczesne zatrzymanie musi być wyłączone.

oloproof select select.yaml
oloproof select select.yaml --save

--save zapisuje też wybór dla lokalnego workbencha, w Candidates.

Czytanie odpowiedzi

Są trzy wyniki:

Kandydat zostaje wybrany, a jego przewaga nad drugim jest ustalona: sparowane porównanie obu na celu daje PASS.
Kandydat zostaje wybrany, a jego przewaga nie jest ustalona: drugi byłby na tych dowodach równie uzasadnionym wyborem.
Żaden kandydat się nie kwalifikuje: reguły każdego kandydata są wypisane z odpowiedziami, więc widać, czego brakuje.

Polecenie kończy się kodem 0, gdy kandydat zostaje wybrany, i 3, gdy żaden się nie kwalifikuje.

Przykład krok po kroku

Trzej agenci muszą osiągnąć wskaźnik sukcesu co najmniej 90% i wskaźnik naruszeń co najwyżej 1%; celem jest najniższy koszt na zadanie.

Agent	Sukces	Naruszenia	Koszt na zadanie
A	94%	0.5%	$18
B	91%	0.1%	$12
C	96%	2%	$30

Każdy jest rozstrzygany na poziomie 98.33%. Przy 1,000 przypadków żaden agent się nie kwalifikuje: wskaźnik naruszeń A nie jest jeszcze wykazany poniżej 1%, 91% B jest zbyt blisko 90%, by je ustalić, a C przekracza pułap naruszeń. Odpowiedź brzmi „żaden kandydat się nie kwalifikuje”, wraz z tym, czego brakuje każdemu. Przy 3,000 przypadków A ustala obie reguły i zostaje wybrany. B jest tańszy, ale jego sukces wciąż nie jest ustalony, więc nigdy nie jest szeregowany: wybór B na podstawie liczb wydałby wymaganie, którego nikt nie wykazał.

oloproof select select.yaml --save zachowuje wybór dla workbencha. oloproof push --selection ID wysyła go do hostowanego workspace’u razem z uruchomieniem każdego kandydata, przez politykę egress projektu; ID to nazwa folderu w .oloproof/bundles/ albo digest wyboru. Zanim workspace zachowa wybór, dokonuje go ponownie z uruchomień, które ma, według polityki, według której te uruchomienia rozstrzygnięto, i zachowuje go tylko wtedy, gdy wynik jest taki sam: wybór, którego wynik lub zdania zmieniono, który wskazuje uruchomienie, którego projekt nie ma, albo którego silnik nie dokonuje z tych uruchomień, zostaje odrzucony i nic nie jest zapisywane. Rozstrzygnij więc uruchomienia kandydatów według polityki wyboru, zanim je wyślesz. Strona Candidates projektu go wymienia, a jego strona pokazuje go dokładnie tak jak lokalny workbench.

Owner lub Admin może zrobić z niego stronę dowodów na stronie wyboru: wynik, poziom oraz dla każdego kandydata nazwę, id uruchomienia i reguły na skorygowanym poziomie, z etykietą "Reported by the developer", nigdy treść przypadku.

Dalej