Wijzigingslogboek

oloproof 0.1.0a1 is gepubliceerd, dus het golden path begint met pip install oloproof in een schone omgeving en gaat meteen door naar oloproof init en oloproof run. Releases worden gebouwd en gepubliceerd vanuit een getagde commit in CI, via trusted publishing van PyPI, zonder opgeslagen token.

Een run of een vergelijking die vroeg stopt, legt nu elke tussenblik vast die hij deed, en de workbench speelt ze af: het altijd geldige interval dat bij elke blik smaller wordt tegenover een drempel die niet beweegt, en de blik waarop elke regel besliste. Hij tekent alleen intervallen die de engine heeft vastgelegd. Een interval met een vaste steekproef wordt nooit geanimeerd alsof het live is, want er naar blijven kijken tot het er goed uitziet, maakt de garantie ervan ongeldig.

⌘K of Ctrl+K toont elke bestemming die je kunt zien, en een geplakte run-id of vergelijkingsdigest opent die. g en dan een letter navigeert, j en k gaan door de rijen van een tabel, en ? toont alle sneltoetsen. Een case opent naast zijn run, met zijn bewijsketen en de mensen die hem gelabeld hebben. Bij verminderde beweging stopt elke animatie.

De workbench draait nu op oloproof.com, en het golden path is daar van begin tot eind geslaagd: een reviewer labelde 80 cases die de workspace had getrokken, vond 7 foute antwoorden die de judge had goedgekeurd, en de workspace besliste Geslaagd op zijn geverifieerde steekproef (91,2%, interval 74,5% tot 100,0%), waar de gepushte run alleen onvoldoende bewijs had. Toegang is op uitnodiging.

oloproof collect ontvangt OTLP/HTTP van een standaard OpenTelemetry SDK, voegt GenAI- en OpenInference-spans samen tot inhoudsgeadresseerde traces en houdt hun inhoud op je eigen machine; een push volgt je egress-beleid. oloproof traces promote maakt van een trace een testcase met zijn herkomst, en weigert duplicaten.

Je collector ondertekent elk uur een commitment op elke trace die hij verzegelde. De workspace trekt vervolgens een steekproef met zijn eigen willekeur en controleert elke getrokken trace tegen dat commitment, zodat een steekproef niet te sturen is door traces achter te houden. oloproof traces evaluate beoordeelt de steekproef op de vastgelegde outputs, de workspace beslist erover onder de evaluatie die een Owner vastzette, en een betrouwbaarheidsreeks volgt elke metriek over de steekproeven heen op de Production-pagina van het project.

Een Owner of Admin opent een wachtrij en wijst reviewers toe, die vanaf het toetsenbord labelen: pass of fail, een score op een gedeclareerde schaal, of een blinde voorkeur tussen twee runs, elk vastgelegd per account. De browser van de reviewer haalt de inhoud van cases op bij oloproof collect aan jouw kant, met een ondertekend ticket van vijf minuten, zodat de workspace die inhoud nooit bewaart.

Een run kan worden ondertekend met een runner-sleutel die een Owner registreerde, of door de beheerde worker. Een Owner zet de hele evaluatie vast (suite, evaluators, metrieken en baseline-run) en het bijbehorende gatebeleid, en de workspace beslist over elke systeemversie bij zijn eerste run van precies die evaluatie, tegenover de vastgezette run. Menselijke labels tellen alleen van onafhankelijke labelers, geteld per account.

Een PPI-interval corrigeert een judge met een willekeurige steekproef van menselijke labels, en de garantie ervan vraagt een steekproef die niemand heeft gekozen. De workspace trekt die steekproef nu nadat het bewijs van de run daar is bevroren, houdt de seed voor zichzelf en controleert het gecorrigeerde interval met zijn eigen engine. De runpagina laat zien of de workspace een interval heeft geverifieerd; een steekproef die op je eigen machine is getrokken, blijft gelabeld als te goeder trouw.

Een beleid met early_stopping: true draait cases in geseede batches en stopt een run, of een kandidaat en zijn baseline in gelijke pas, zodra elke regel heeft beslist, vastgelegd als DECIDED_EARLY met de cases die niet nodig waren. Gestopte percentages gebruiken een altijd geldig betting-interval, zodat kijken na elke batch de garantie behoudt. Het pass-percentage van een judge kan als gate dienen via een PPI-interval dat de judge combineert met een blinde willekeurige steekproef van menselijke labels, getoond naast de intervallen van alleen de judge en alleen de mensen.

Vier meldingen, elk een categorie die een lid vanuit de e-mail zelf kan uitzetten: een beheerde job is klaar of mislukt, een gepushte run of vergelijking waarvan de gate een release blokkeert, gebruik op 80% en 100% van de gratis bundel, en een nieuw lid. Een gate-e-mail citeert de opgeslagen beslissing en linkt naar de run, zonder inhoud van cases. Alleen e-mail: geen Slack, pager of webhook.

Log in met een e-mailadres en een wachtwoord, of met een provider, met geverifieerde adressen en wachtwoordherstel. Iemand kan zijn eigen account verwijderen: de gebruiker en elke workspace waarvan alleen hij lid was, verdwijnen tegelijk, en de worker wist het bewijs van die workspaces.

Een judge kan een getypeerde vraag (ja of nee, een keuze, een score op niveaus) beantwoorden met een waarschijnlijkheid voor elk antwoord, uitgelezen uit de tokenwaarschijnlijkheden van een lokaal model in één forward pass. Zijn kalibratie wordt gemeten tegen menselijke labels en vastgelegd in zijn registervermelding, en een cascade stuurt alleen de cases waarover een goedkope judge twijfelt door naar een sterkere. Een getrainde classifier kan ook een evaluator zijn, zonder sleutel en zonder netwerk.

Label de cases van een run vanuit een bestand of de terminal, en probeer een conceptjudge tegen die labels voordat je hem in gebruik neemt. Een judge rapporteert zijn bias naast zijn overeenstemming, een judge waarvan de bias een gedeclareerde marge overschrijdt, mag geen gate beslissen, en een validatie telt niet meer zodra het gemeten model verandert. Probes zonder labels controleren of een oordeel verschuift terwijl er niets wezenlijks veranderde, en paarsgewijze vergelijkingen worden in beide volgordes gesteld, zodat een antwoord dat alleen om zijn positie de voorkeur krijgt opvalt zonder dat iemand labelt.

Een trajectorie legt vast welke agent elke stap zette, en elke overdracht. Evaluators beoordelen routering (bereikte het verzoek de agent die het hoort af te handelen), toolrechten (riep een agent een tool aan die niet de zijne was) en agents die de controle heen en weer schuiven in plaats van af te ronden, en slices groeperen cases per route.

Een suite kan elke case meerdere keren meten. Replicaties worden per case samengevoegd vóór elk interval, vergelijkingen koppelen ze als fracties, en de run meldt hoeveel cases het met zichzelf oneens waren. Een systeem kan een fout als tijdelijk markeren zodat de runner hem opnieuw probeert: bij een live RAG-systeem herstelde dat 18 van de 22 ontbrekende cases en werd het interval 39% smaller.