Journal des modifications

oloproof 0.1.0a1 est publié : le parcours de référence commence donc par pip install oloproof dans un environnement vierge et passe directement à oloproof init et oloproof run. Les versions sont construites et publiées depuis un commit tagué dans la CI, via la publication de confiance de PyPI, sans aucun jeton stocké.

Une exécution ou une comparaison qui s’arrête tôt enregistre désormais chacun de ses examens intermédiaires, et l’atelier les rejoue : l’intervalle valide à tout instant qui se resserre à chaque examen face à un seuil qui ne bouge pas, et l’examen auquel chaque règle a tranché. Il ne trace que les intervalles que le moteur a enregistrés. Un intervalle à échantillon fixe n’est jamais animé comme s’il était en direct, car le surveiller jusqu’à ce qu’il paraisse favorable annule sa garantie.

⌘K ou Ctrl+K liste chaque destination que vous pouvez voir, et un identifiant d’exécution ou un condensé de comparaison collé l’ouvre. g suivi d’une lettre permet de naviguer, j et k parcourent les lignes d’un tableau, et ? liste tous les raccourcis. Un cas s’ouvre à côté de son exécution, avec sa chaîne de preuves et les personnes qui l’ont annoté. Toute animation s’arrête lorsque les mouvements réduits sont demandés.

L’atelier sert désormais oloproof.com, et le parcours de référence de bout en bout a réussi sur l’hôte : un relecteur a annoté 80 cas tirés par l’espace de travail, a trouvé 7 réponses fausses que le juge avait validées, et l’espace de travail a décidé Réussite sur son échantillon vérifié (91,2 %, intervalle de 74,5 % à 100,0 %) là où l’exécution poussée seule n’avait pas assez de preuves. L’accès se fait sur invitation.

oloproof collect reçoit de l’OTLP/HTTP depuis un SDK OpenTelemetry standard, assemble les spans GenAI et OpenInference en traces adressées par leur contenu et garde ce contenu sur votre machine ; un envoi suit votre politique de sortie des données. oloproof traces promote transforme une trace en cas de test avec sa provenance, et refuse les doublons.

Votre collecteur signe un engagement sur chaque trace qu’il a scellée, heure par heure. L’espace de travail tire ensuite un échantillon avec son propre aléa et vérifie chaque trace tirée par rapport à l’engagement : un échantillon ne peut donc pas être trié en retenant des traces. oloproof traces evaluate juge l’échantillon sur ses sorties enregistrées, l’espace de travail le décide selon l’évaluation qu’un Owner a fixée, et une séquence de confiance suit chaque métrique d’un échantillon à l’autre sur la page Production du projet.

Un Owner ou un Admin ouvre une file et désigne des relecteurs, qui annotent au clavier : réussite ou échec, une note sur une échelle déclarée, ou une préférence à l’aveugle entre deux exécutions, chacune enregistrée par compte. Le navigateur du relecteur récupère le contenu des cas depuis oloproof collect, de votre côté, avec un ticket signé valable cinq minutes : l’espace de travail ne le détient donc jamais.

Une exécution peut être signée par une clé de runner qu’un Owner a enregistrée, ou par le worker géré. Un Owner fixe l’évaluation entière (suite, évaluateurs, métriques et exécution de référence) et sa politique de porte, et l’espace de travail décide chaque version du système lors de sa première exécution de cette évaluation exacte, par rapport à l’exécution fixée. Les annotations humaines ne comptent que si elles viennent d’annotateurs indépendants, comptés par compte.

Un intervalle PPI corrige un juge à l’aide d’un échantillon aléatoire d’annotations humaines, et sa garantie exige un échantillon que personne n’a choisi. L’espace de travail tire désormais cet échantillon une fois les preuves de l’exécution figées chez lui, garde la graine pour lui et vérifie l’intervalle corrigé avec son propre moteur. La page de l’exécution indique si l’espace de travail a vérifié un intervalle ; un échantillon tiré sur votre propre machine reste marqué comme de bonne foi.

Une politique avec early_stopping: true exécute les cas par lots à graine fixée et arrête une exécution, ou un candidat et sa référence en parallèle, dès que chaque règle a tranché, ce qui est enregistré comme DECIDED_EARLY avec les cas dont elle n’a pas eu besoin. Les taux arrêtés utilisent un intervalle de pari valide à tout instant, si bien que regarder après chaque lot préserve sa garantie. Le taux de réussite d’un juge peut servir de porte via un intervalle PPI qui combine le juge avec un échantillon aléatoire à l’aveugle d’annotations humaines, affiché à côté des intervalles du juge seul et des humains seuls.

Quatre notifications, chacune une catégorie qu’un membre peut désactiver depuis l’e-mail lui-même : une tâche gérée terminée ou en échec, une exécution ou une comparaison poussée dont la porte bloque une publication, une utilisation à 80 % et 100 % du quota gratuit, et l’arrivée d’un membre. Un e-mail de porte cite la décision enregistrée et renvoie à l’exécution, sans aucun contenu de cas. E-mail uniquement : ni Slack, ni pager, ni webhook.

Connectez-vous avec une adresse e-mail et un mot de passe aussi bien qu’avec un fournisseur, avec des adresses vérifiées et des réinitialisations. Une personne peut supprimer son propre compte : l’utilisateur et chaque espace de travail dont il était le seul membre disparaissent d’un coup, et le worker purge les preuves de ces espaces de travail.

Un juge peut répondre à une question typée (oui ou non, un choix, une note par rapport à des niveaux) avec une probabilité pour chaque réponse, lue dans les probabilités de jetons d’un modèle local en une seule passe avant. Sa calibration est mesurée par rapport à des annotations humaines et enregistrée dans son entrée de registre, et une cascade n’envoie à un juge plus fort que les cas sur lesquels un juge bon marché hésite. Un classifieur entraîné peut aussi être un évaluateur, sans clé ni réseau.

Annotez les cas d’une exécution depuis un fichier ou le terminal, et essayez un brouillon de juge sur ces annotations avant de l’adopter. Un juge indique son biais à côté de son accord ; celui dont le biais dépasse une marge déclarée ne peut pas servir de porte, et une validation cesse de compter dès que le modèle qu’elle a mesuré change. Des sondes sans annotation vérifient si un verdict bouge alors que rien d’important n’a bougé, et les comparaisons par paires sont posées dans les deux ordres : une réponse préférée seulement pour sa position apparaît sans que personne n’ait à annoter.

Une trajectoire enregistre quel agent a effectué chaque étape, et chaque passage de relais. Des évaluateurs jugent le routage (la requête est-elle parvenue à l’agent qui devait la traiter ?), les permissions d’outils (un agent a-t-il appelé un outil qui ne lui revenait pas ?) et les agents qui se renvoient la main au lieu de terminer, et les segments regroupent les cas par route.

Une suite peut mesurer chaque cas plusieurs fois. Les réplicats sont agrégés par cas avant tout intervalle, les comparaisons les apparient sous forme de fractions, et l’exécution indique combien de cas se sont contredits eux-mêmes. Un système peut marquer un échec comme transitoire pour que le runner le relance : sur un système RAG réel, cela a récupéré 18 des 22 cas manquants et resserré l’intervalle de 39 %.