Construisez sur des preuves.
Oloproof aide les équipes à évaluer des systèmes d’IA avec des tests reproductibles, des diagnostics et des preuves sur lesquelles fonder une décision.
S’exécute dans votre CI. Vos preuves restent sur votre machine.
Tester des prompts à la main ne résiste pas à la production.
Les équipes livrent des changements de modèle et de prompt chaque semaine. Vérifier quelques sorties au hasard dans un bac à sable ne vous dit presque rien de ce qui a changé, pour qui, ni si la publication est sûre.
Oloproof remplace cela par un relevé mesuré : les mêmes cas, les mêmes juges, les mêmes graines, exécutés à chaque changement.
Une modification de prompt corrige une classe d’échecs et en casse discrètement une autre. Personne ne le remarque avant un client.
Sur un système RAG en service, environ un cas observé sur neuf a changé de verdict entre deux mesures identiques.
Un banc de test en service comptait ses 13,8 % d’erreurs HTTP 500 comme des zéros, imputant les pannes au modèle. Une moyenne ne peut pas porter une décision.
Quand les équipes risques, le service juridique ou un client demandent ce que vous avez testé, des captures d’écran dans un fil de discussion ne sont pas une réponse.
Quatre choses dont toute décision de publication a besoin.
Jeux de données versionnés, graines fixées et juges déclaratifs. Chaque exécution se reproduit à l’identique, des mois plus tard.
Des écarts avec intervalles de confiance et seuils, pour qu’un mouvement de deux points ne soit jamais pris pour une victoire.
Échecs regroupés par segment, intention et chemin d’outils, chacun relié aux traces exactes qui les sous-tendent.
Une recommandation de publication accompagnée de ses preuves — exportable pour revue, audit et clients.
Chaque intervalle franchit la ligne zéro en pointillés. À ne lire que les estimations ponctuelles, le reranker aurait été livré.
Conçu pour les équipes qui doivent justifier la publication.
Définissez jeux de données, juges et seuils sous contrôle de version. Relisez les changements d’évaluation comme vous relisez du code.
Contrôles programmatiques, juges LLM, classifieurs entraînés qui notent du texte sur votre propre machine et annotations humaines dans un seul pipeline. L’accord de chaque juge avec les humains est mesuré avec un intervalle, et un juge qui n’a pas franchi son seuil ne peut pas décider d’une publication.
Faites échouer une pull request quand une métrique franchit son seuil. La porte indique quels cas ont bougé et de combien.
Chaque score renvoie aux entrées, sorties, appels d’outils, contexte récupéré et justification du juge. Rien n’est une boîte noire.
La qualité n’est jamais le seul axe. Suivez la dépense et la latence de queue à côté de la justesse, sous les mêmes seuils.
Partagez l’exécution, les diagnostics et la recommandation sans modifier la décision mesurée qu’elle contient.
Trois étapes, puis tout tourne seul.
Apportez vos propres cas sous forme de fichier JSONL. Déclarez les juges et les seuils qu’une publication doit franchir.
Une commande en local, la même commande en CI. Changements de prompt, de modèle, de récupération et d’outils reçoivent tous le même traitement.
Lisez les écarts, ouvrez les traces en échec et gardez les preuves attachées à la décision que vous avez prise.
Chaque chiffre remonte à un cas.
Les exécutions sont immuables et datées. Jeux de données, prompts, juges et configuration sont versionnés ensemble, de sorte que tout résultat peut être reproduit ou contesté.
À lire les estimations ponctuelles, le reranker apporte +12,7 points de hit@1. À les lire honnêtement, ce panel ne peut pas dire s’il aide ou s’il nuit.
Ce que ce n’est pas, pas encore.
Tout ce qui suit est vrai le jour où vous le lisez.
- 01
Il n’existe aucun déploiement hébergé auquel vous inscrire. L’accès se fait sur invitation.
- 02
Il n’y a pas de tarifs. L’unité est un cas évalué ; les tarifs ne sont pas fixés.
- 03
Il n’y a aucun audit de sécurité, aucun rapport SOC 2 et aucun DPA. Il n’y a aucun client ni aucune étude de cas, donc aucun n’est cité.
- 04
Les notifications passent uniquement par e-mail : ni Slack, ni pager, ni webhook. Il n’y a pas de document de rapport. Une exécution se lit dans l’atelier ou s’exporte sous forme de lot.
- 05
L’évaluation en production n’est pas construite : les traces sont reçues sur votre propre machine, et rien ne note encore le trafic de production.
- 06
Il a été exécuté de bout en bout contre exactement un système tiers en service. Ce sont les preuves ci-dessus, et il s’agit d’un seul système.
Mesurez avant de livrer.
Apportez un système et un jeu de données. Commencez par une exécution locale et gardez les preuves sur votre machine.