Dokumentacja
Napisz zestaw. Uczyń go bramką.
Oloproof decyduje o wydaniach na podstawie przedziałów ufności, a nie estymacji punktowych. Te strony opisują, jak zadeklarować, co mierzyć, jak zamienić decyzję w kod wyjścia i co sędzia LLM musi spełnić, zanim będzie mógł pełnić rolę bramki.
Szybki startZainstaluj silnik, utwórz szkielet projektu i uzyskaj pierwsze uruchomienie oraz decyzję bramki na własnej maszynie. Nic jej nie opuszcza, dopóki nie wykonasz push.Podstawowe pojęciaOloproof mierzy system AI tak, jak badanie mierzy cokolwiek: te same przypadki, ci sami sędziowie, te same ziarna losowości, uruchamiane przy każdej zmianie. Tym, co dodaje do zestawu testów, jest to, że każda liczba przychodzi wraz ze swoją niepewnością, a decyzja o wydaniu jest podejmowana na podstawie przedziału, a nie estymaty.Pisanie zestawuZestaw to dwa pliki i zbiór danych. oloproof init tworzy szkielet obu, a szkielet jest opatrzony komentarzami, ponieważ pierwsze przejście przez onboarding straciło cztery próby przez brakujący ciąg znaków, a nie przez brakującą funkcję.API PythonaWszystko, co robi CLI, robi też biblioteka. Warto z niej korzystać, gdy ewaluacja ma się znaleźć wewnątrz skryptu, notatnika lub zestawu testów, a nie obok pliku konfiguracyjnego.Recording what a system didA system's output is what an evaluator reads by default. Everything else it did — the prompt it built, the passages it retrieved, the tools it called, the tokens it spent — is recorded alongside the output as artifacts and usage, and every artifact is stored content-addressed with the execution that produced it.Postęp i współbieżnośćZestaw uruchamiany na działającym modelu trwa minuty, a większość z nich schodzi na czekaniu na model. Ta strona opisuje, ile wywołań Oloproof utrzymuje jednocześnie w toku, co pokazuje podczas ich wykonywania i jak sprawdzić, ile dodatkowych przypadków rozstrzygnęłoby regułę, która nie dała rozstrzygnięcia.Gating CIA gate compares measured evidence against a threshold you declared, and exits with a code your CI understands. The decision is made on the interval, not on the estimate.Uruchamianie w CIBramkowanie CI opisuje politykę wydań i znaczenie każdego kodu wyjścia. Ta strona dotyczy tego, co dzieje się wewnątrz zadania CI: jak zainstalować tam Oloproof, gdzie znajdują się dowody w trakcie działania zadania, jak odczytać wynik bez parsowania tabeli i jak porównać pull request z gałęzią, do której jest kierowany.Comparing a candidate to a baselineThe workflow the rest of this product exists for: you changed something, and you want to know whether it helped. A comparison pairs two runs case by case and reports the difference with an interval, so a two-point move is never mistaken for a win.Reguły porównańPorównywanie kandydata z punktem odniesienia pokazuje przebieg pracy. Ta strona jest dokumentacją referencyjną reguł, według których rozstrzygane jest porównanie: jakie rodzaje istnieją, o co pyta każdy z nich, w jakich jednostkach mierzony jest margines i co przesuwa przedział, z którego są odczytywane.Przypadki klastrowaneWiększość obliczeń przedziałów zakłada, że każdy przypadek jest niezależny od wszystkich pozostałych. Trzy tury jednej rozmowy takie nie są: gdy rozmowa idzie źle, zwykle idą źle wszystkie trzy. Zestaw, który traktuje je jako niezależne, raportuje przedział węższy, niż uzasadniają to dowody, a bramka może na jego podstawie przepuścić zmianę.WycinkiGlobalny odsetek może pozostawać stabilny, podczas gdy jedna część zestawu się załamuje. Wycinek to zadeklarowana część zestawu, mierzona osobno, dzięki czemu załamanie jest widoczne. Wycinkom towarzyszą dwie zasady dyscypliny, ponieważ przeglądanie wielu części zestawu to sposób, w jaki ewaluacja znajduje szum i nazywa go odkryciem.JudgesAn LLM judge is one kind of evaluator, not all of them. Oloproof has three kinds — deterministic, LLM judge, and custom — and the rules on this page are about the second, because a model's verdict is the one that needs measuring against a human's.Ewaluacja RAGOdpowiedź wspomagana wyszukiwaniem może być błędna z czterech różnych powodów: właściwy fragment nigdy nie został wyszukany, został wyszukany, ale umieszczony w rankingu zbyt nisko, znalazł się wystarczająco wysoko, a potem wypadł z kontekstu, albo dotarł do modelu, a model i tak się pomylił. Pojedyncza liczba dokładności nie potrafi ich rozróżnić. Oloproof uruchamia system RAG jako dwa widoczne dla siebie etapy, mierzy każdy z nich i ponownie wykonuje nieudane przypadki przy kontrolowanych zmianach, aby ustalić, który powód ma zastosowanie.Agenci i narzędziaOloproof nie steruje agentem. Twój agent wykonuje własną pętlę, wywołuje własne narzędzia i zapisuje to, co się wydarzyło, jako artefakt agent_trajectory/v1. Każda metryka agenta jest odczytywana z tego zapisu, więc zapis stanowi całą integrację.Klasyfikatory i regresoryModel predykcyjny ocenia się jak każdy inny system: funkcja wywoływalna zwraca predykcję dla każdego przypadku, a ewaluatory ją odczytują. Zmieniają się mianowniki. Trafność, czułość (recall) i precyzja to trzy odsetki liczone na trzech różnych zbiorach wierszy, a model może dobrze wyglądać w jednym z nich, nie odpowiadając na pytanie, które zadaje biznes.PowiadomieniaPrzebieg zakończony powodzeniem nikogo nie powiadamia. Gdy Oloproof wysyła powiadomienie, oznacza to, że coś wymaga decyzji albo zaraz przestanie działać: wydanie zablokowane przez bramkę, zakończony przebieg zarządzany, wyczerpujący się limit.BłędyRozróż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.Dokumentacja CLIKażde polecenie, które rejestruje Oloproof, wraz z opisem jego działania. Każde przyjmuje --help, które wypisuje pełny tekst, z którego pochodzą te streszczenia.