Comparaison
Oloproof face aux tests de prompts improvisés.
Vérifier au hasard dans un bac à sable est rapide et vraiment utile tant que vous explorez. Cela ne suffit plus dès qu’un changement arrive chez les utilisateurs.
| Question | Vérification au hasard dans un bac à sable | Oloproof |
|---|---|---|
| La qualité a-t-elle changé ? | Une impression tirée d’une poignée de sorties | Une différence avec un intervalle à 95% sur les cas appariés, et une décision prise sur l’intervalle |
| Pour qui a-t-elle changé ? | Inconnu | Par tranche déclarée : langue, intention ou toute clé de métadonnées, le premier outil appelé par un agent, son parcours |
| Pouvez-vous la relancer au prochain trimestre ? | Non : les prompts et les cas ont disparu | Oui : la suite, la version du système et les versions des évaluateurs sont adressées par leur contenu, et un échantillon garde sa graine |
| Bloque-t-elle une mauvaise publication ? | Seulement si quelqu’un pense à regarder | La porte se termine avec un code non nul et le job de CI échoue : 1 quand une règle échoue, 3 quand les preuves ne tranchent pas |
| Que montrez-vous au service des risques ou à un client ? | Des captures d’écran dans un fil de discussion | Un paquet exporté : l’exécution, sa suite, son système, ses évaluateurs, ses cas et ses validations |
| Délai avant le premier signal | Quelques minutes | Quelques minutes en local, puis à chaque changement sur lequel votre CI l’exécute |
Là où la vérification au hasard reste gagnante
L’exploration initiale, le débogage d’une sortie étrange isolée et les vérifications de bon sens pendant que vous écrivez un prompt. Continuez. Une suite d’évaluation est ce que vous construisez dès que le comportement compte assez pour être défendu.