Dziennik zmian

oloproof 0.1.0a1 jest opublikowany, więc złota ścieżka zaczyna się od pip install oloproof w czystym środowisku i prowadzi prosto do oloproof init i oloproof run. Wydania są budowane i publikowane z otagowanego commita w CI, przez trusted publishing w PyPI, bez przechowywanego tokenu.

Przebieg lub porównanie, które zatrzymuje się wcześnie, zapisuje teraz każde spojrzenie, jakie wykonało, a workbench je odtwarza: przedział ważny w dowolnym momencie, zawężający się przy każdym spojrzeniu względem progu, który się nie przesuwa, oraz spojrzenie, przy którym każda reguła podjęła decyzję. Rysuje tylko przedziały zapisane przez silnik. Przedział o stałej próbie nigdy nie jest animowany tak, jakby był na żywo, bo obserwowanie go, aż wygląda dobrze, unieważnia jego gwarancję.

⌘K lub Ctrl+K wyświetla każde miejsce, które możesz zobaczyć, a wklejony identyfikator przebiegu lub digest porównania je otwiera. g, a potem litera, służy do nawigacji, j i k przesuwają po wierszach tabeli, a ? wyświetla wszystkie skróty. Przypadek otwiera się obok swojego przebiegu, z łańcuchem dowodów i osobami, które go oznaczyły. Przy ograniczonym ruchu każda animacja się zatrzymuje.

Workbench działa teraz na oloproof.com, a złota ścieżka przeszła tam od początku do końca: recenzent oznaczył 80 przypadków wylosowanych przez obszar roboczy, wykrył 7 błędnych odpowiedzi, które sędzia przepuścił, a obszar roboczy zdecydował: Zaliczone na swojej zweryfikowanej próbie (91,2%, przedział od 74,5% do 100,0%), tam gdzie sam przesłany przebieg miał niewystarczające dowody. Dostęp na zaproszenie.

oloproof collect odbiera OTLP/HTTP ze standardowego SDK OpenTelemetry, składa spany GenAI i OpenInference w ślady adresowane treścią i trzyma ich treść na Twojej maszynie; przesyłanie stosuje się do Twojej polityki egress. oloproof traces promote zamienia ślad w przypadek testowy wraz z jego pochodzeniem i odrzuca duplikaty.

Twój kolektor co godzinę podpisuje zobowiązanie obejmujące każdy ślad, który zapieczętował. Obszar roboczy losuje następnie próbkę z użyciem własnej losowości i sprawdza każdy wylosowany ślad względem zobowiązania, więc próbki nie da się dobrać przez zatajanie śladów. oloproof traces evaluate ocenia próbkę na podstawie zapisanych wyników, obszar roboczy rozstrzyga ją według ewaluacji przypiętej przez Ownera, a sekwencja ufności śledzi każdą metrykę w kolejnych próbkach na stronie Production projektu.

Owner lub Admin otwiera kolejkę i przydziela recenzentów, którzy oznaczają z klawiatury: pass lub fail, ocena na zadeklarowanej skali albo ślepa preferencja między dwoma przebiegami, każde zapisane według konta. Przeglądarka recenzenta pobiera treść przypadków z oloproof collect po Twojej stronie na podstawie podpisanego biletu ważnego pięć minut, więc obszar roboczy nigdy jej nie przechowuje.

Przebieg może zostać podpisany kluczem runnera zarejestrowanym przez Ownera albo przez zarządzany worker. Owner przypina całą ewaluację (zestaw, ewaluatory, metryki i przebieg bazowy) oraz jej politykę bramki, a obszar roboczy rozstrzyga każdą wersję systemu przy jej pierwszym przebiegu dokładnie tej ewaluacji, względem przypiętego przebiegu. Etykiety ludzkie liczą się tylko od niezależnych oznaczających, liczonych według konta.

Przedział PPI koryguje sędziego losową próbką ludzkich etykiet, a jego gwarancja wymaga próbki, której nikt nie wybrał. Obszar roboczy losuje teraz tę próbkę po zamrożeniu u siebie dowodów przebiegu, zachowuje ziarno dla siebie i sprawdza skorygowany przedział własnym silnikiem. Strona przebiegu podaje, czy obszar roboczy zweryfikował przedział; próbka wylosowana na Twojej własnej maszynie pozostaje oznaczona jako złożona w dobrej wierze.

Polityka z early_stopping: true uruchamia przypadki w partiach z ziarnem i zatrzymuje przebieg, albo kandydata i jego punkt odniesienia równocześnie, gdy tylko każda reguła podejmie decyzję, co zapisuje jako DECIDED_EARLY wraz z przypadkami, których nie potrzebowała. Zatrzymane wskaźniki używają przedziału zakładowego ważnego w dowolnym momencie, więc spojrzenie po każdej partii zachowuje gwarancję. Odsetek zaliczeń sędziego może być bramkowany przedziałem PPI, który łączy sędziego ze ślepą losową próbką ludzkich etykiet, pokazanym obok przedziałów samego sędziego i samych ludzi.

Cztery powiadomienia, każde w kategorii, którą członek może wyłączyć z poziomu samego e-maila: zarządzane zadanie zakończyło się lub nie powiodło, przesłany przebieg lub porównanie, którego bramka blokuje wydanie, wykorzystanie na poziomie 80% i 100% darmowego limitu oraz dołączenie członka. E-mail o bramce przytacza zapisaną decyzję i prowadzi do przebiegu, bez treści przypadków. Tylko e-mail: bez Slacka, pagera i webhooka.

Logowanie adresem e-mail i hasłem, a także przez dostawcę, ze zweryfikowanymi adresami i resetowaniem hasła. Osoba może usunąć własne konto: użytkownik i każdy obszar roboczy, do którego należał tylko on, znikają od razu, a worker usuwa dowody tych obszarów roboczych.

Sędzia może odpowiedzieć na pytanie określonego typu (tak lub nie, wybór, ocena względem poziomów) z prawdopodobieństwem dla każdej odpowiedzi, odczytanym z prawdopodobieństw tokenów lokalnego modelu w jednym przebiegu w przód. Jego kalibracja jest mierzona względem ludzkich etykiet i zapisywana w jego wpisie w rejestrze, a kaskada przekazuje mocniejszemu sędziemu tylko te przypadki, co do których tani sędzia nie ma pewności. Ewaluatorem może być też wytrenowany klasyfikator, bez klucza i bez sieci.

Oznacz przypadki przebiegu z pliku lub w terminalu i wypróbuj szkic sędziego na tych etykietach, zanim go przyjmiesz. Sędzia podaje swoje obciążenie obok zgodności, sędzia, którego obciążenie przekracza zadeklarowany margines, nie może pełnić roli bramki, a walidacja przestaje się liczyć, gdy zmieni się zmierzony model. Sondy bez etykiet sprawdzają, czy werdykt się zmienia, gdy nic istotnego się nie zmieniło, a porównania parami są zadawane w obu kolejnościach, więc odpowiedź preferowana tylko ze względu na swoją pozycję wychodzi na jaw bez niczyjego oznaczania.

Trajektoria zapisuje, który agent wykonał każdy krok, oraz każde przekazanie. Ewaluatory oceniają routing (czy żądanie trafiło do agenta, który powinien je obsłużyć), uprawnienia do narzędzi (czy któryś agent wywołał narzędzie, które nie było jego) oraz agentów przekazujących sobie kontrolę tam i z powrotem zamiast zakończyć, a slice'y grupują przypadki według trasy.

Zestaw może mierzyć każdy przypadek kilka razy. Powtórzenia są agregowane dla każdego przypadku przed obliczeniem jakiegokolwiek przedziału, porównania łączą je w pary jako ułamki, a przebieg podaje, ile przypadków nie zgadzało się samych ze sobą. System może oznaczyć błąd jako przejściowy, aby runner ponowił próbę: w działającym systemie RAG odzyskało to 18 z 22 brakujących przypadków i zawęziło przedział o 39%.