Skip to content
Évaluation de systèmes d’IA

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.

oloproof / compare · olotalk-docs-assistant
Résumé Comparer Diagnostics Preuves
RÉFÉRENCE
olotalk docs assistant · rerank désactivé
CANDIDAT
olotalk docs assistant · rerank activé
JEU DE DONNÉES
olotalk golden panel · 58 cas
MÉTRIQUE RÉFÉRENCE CANDIDAT Δ APPARIÉ IC 95% STATUT
page_hit_1 0.618 0.745 +6.2 [-36.3, +45.5] — Non concluant
page_hit_3 0.683 0.742 +3.7 [-73.9, +76.2] — Non concluant
answer_correct 0.685 0.760 +6.5 [-39.4, +48.4] — Non concluant
page_hit_1 observé 55 / 58 51 / 58 −4 dans l’intervalle ! Borné
page_hit_3 observé 41 / 58 31 / 58 −10 dans l’intervalle ! Borné
answer_correct observé 54 / 58 50 / 58 −4 dans l’intervalle ! Borné
POURQUOI ÉVALUER

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.

01
Régressions silencieuses

Une modification de prompt corrige une classe d’échecs et en casse discrètement une autre. Personne ne le remarque avant un client.

02
Résultats non reproductibles

Sur un système RAG en service, environ un cas observé sur neuf a changé de verdict entre deux mesures identiques.

03
Des scores sans signification

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.

04
Aucun relevé à montrer

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.

CAPACITÉS PRINCIPALES

Quatre choses dont toute décision de publication a besoin.

MESURER
Des évaluations reproductibles

Jeux de données versionnés, graines fixées et juges déclaratifs. Chaque exécution se reproduit à l’identique, des mois plus tard.

COMPARER
Référence contre candidat

Des écarts avec intervalles de confiance et seuils, pour qu’un mouvement de deux points ne soit jamais pris pour une victoire.

DIAGNOSTIQUER
Des modes d’échec, pas des moyennes

Échecs regroupés par segment, intention et chemin d’outils, chacun relié aux traces exactes qui les sous-tendent.

DÉCIDER
Des relevés dignes d’une décision

Une recommandation de publication accompagnée de ses preuves — exportable pour revue, audit et clients.

Diagnostics23 cas en échec, contexte de référence
Non résolu : le contexte de référence n’a pas tranché11 cas
Échec de génération : bon contexte, mauvaise réponse7 cas
Échec de récupération : réponse accessible, non récupérée5 cas
Rerank activé moins désactivéIntervalle à 95 %, points
hit@1
hit@3
correct

Chaque intervalle franchit la ligne zéro en pointillés. À ne lire que les estimations ponctuelles, le reranker aurait été livré.

PLATEFORME

Conçu pour les équipes qui doivent justifier la publication.

Les suites d’évaluation sous forme de code

Définissez jeux de données, juges et seuils sous contrôle de version. Relisez les changements d’évaluation comme vous relisez du code.

Des juges que vous pouvez auditer

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.

Des portes de régression dans la CI

Faites échouer une pull request quand une métrique franchit son seuil. La porte indique quels cas ont bougé et de combien.

Des preuves au niveau de la trace

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.

Budgets de coût et de latence

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.

Des preuves pour ceux qui ont besoin de la décision

Partagez l’exécution, les diagnostics et la recommandation sans modifier la décision mesurée qu’elle contient.

COMMENT ÇA MARCHE

Trois étapes, puis tout tourne seul.

1
Définir la suite

Apportez vos propres cas sous forme de fichier JSONL. Déclarez les juges et les seuils qu’une publication doit franchir.

2
Exécuter à chaque changement

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.

3
Décider avec les preuves

Lisez les écarts, ouvrez les traces en échec et gardez les preuves attachées à la décision que vous avez prise.

~/olodemo · après oloproof init
 oloproof run
Run run_01M3B0CCPA0JFQQ7HWRKYNWFJC [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)

  Rule         Metric       State  Reasons
  label-floor  exact_label  PASS   lower_bound_meets_minimum

  Metric       Estimate  Interval          N
  exact_label  100.0%    [88.4%, 100.0%]   30 / 30 observed · 0 missing

Cache: execution 0 hit/30 miss; judgment 0 hit/30 miss

 oloproof run
Run run_01M3B0CXTTVPTBXAFK3WNGFX42 [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)
Cache: execution 30 hit/0 miss; judgment 0 hit/30 miss
DES PREUVES QUE VOUS POUVEZ TRANSMETTRE

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é.

Immuables
exécutions, avec leur lignage complet
Auto-hébergé
sur votre infrastructure, vos données restent les vôtres
Bornés
cas manquants chiffrés, jamais écartés

À 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.

Oloproof face à un système RAG en service, 22 septembre 2026
Oloproof
Lot de preuves
oloproof export RUN_ID
run.jsonl’exécution, sa suite, son système et ses évaluateurs
cases.jsonlchaque cas : entrée, sortie, jugements, empreintes
diagnoses.jsonlinterventions et ce qu’elles ont récupéré
signoffs.jsonlqui a livré malgré une porte bloquée, et pourquoi
Un lot de preuves exporté : l’exécution et chaque cas derrière ses chiffres, sous forme de fichiers que vous conservez.
LA MÊME DISCIPLINE, APPLIQUÉE ICI

Ce que ce n’est pas, pas encore.

Tout ce qui suit est vrai le jour où vous le lisez.

  1. 01

    Il n’existe aucun déploiement hébergé auquel vous inscrire. L’accès se fait sur invitation.

  2. 02

    Il n’y a pas de tarifs. L’unité est un cas évalué ; les tarifs ne sont pas fixés.

  3. 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é.

  4. 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.

  5. 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.

  6. 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.