Documentación
Escriba una suite. Úsela como gate.
Oloproof decide publicaciones con intervalos de confianza en lugar de estimaciones puntuales. Estas páginas explican cómo declarar qué medir, cómo convertir una decisión en un código de salida y qué debe superar un juez LLM antes de poder actuar como gate de algo.
Guía rápidaInstale el motor, genere un proyecto y obtenga una primera ejecución y una decisión de gate en su propia máquina. Nada sale de ella a menos que usted haga push.Conceptos básicosOloproof mide un sistema de IA de la misma forma en que un estudio mide cualquier cosa: los mismos casos, los mismos jueces, las mismas semillas, ejecutados en cada cambio. Lo que añade a una suite de pruebas es que cada número llega con su incertidumbre, y que una decisión de publicación se toma sobre el intervalo y no sobre la estimación.Escribir una suiteUna suite son dos archivos y un conjunto de datos. oloproof init genera ambos, y lo generado viene comentado porque en el primer recorrido de incorporación se perdieron cuatro intentos por una cadena ausente, no por una funcionalidad ausente.La API de PythonTodo lo que hace la CLI lo hace también la biblioteca. Úsela cuando la evaluación deba vivir dentro de un script, un notebook o una suite de pruebas, y no junto a un archivo de configuración.Recording what a system didA system's output is what an evaluator reads by default. Everything else it did — the prompt it built, the passages it retrieved, the tools it called, the tokens it spent — is recorded alongside the output as artifacts and usage, and every artifact is stored content-addressed with the execution that produced it.Progreso y concurrenciaUna suite contra un modelo en vivo tarda minutos, y la mayor parte se pasa esperando al modelo. Esta página explica cuántas llamadas mantiene Oloproof en curso, qué muestra mientras se ejecutan y cómo averiguar cuánta ejecución adicional resolvería una regla que no llegó a decidir.Gating CIA gate compares measured evidence against a threshold you declared, and exits with a code your CI understands. The decision is made on the interval, not on the estimate.Ejecución en CIGates en CI trata la política de publicación y lo que significa cada código de salida. Esta página cubre lo que ocurre dentro de un job de CI: cómo instalar Oloproof allí, dónde se guarda la evidencia mientras el job se ejecuta, cómo leer un resultado sin analizar una tabla y cómo comparar un pull request con la rama a la que apunta.Comparing a candidate to a baselineThe workflow the rest of this product exists for: you changed something, and you want to know whether it helped. A comparison pairs two runs case by case and reports the difference with an interval, so a two-point move is never mistaken for a win.Reglas de comparaciónComparar un candidato con una línea base muestra el flujo de trabajo. Esta página es la referencia de las reglas con las que se decide una comparación: qué tipos existen, qué pregunta cada uno, en qué se mide un margen y qué modifica el intervalo a partir del cual se leen.Casos agrupadosLa mayor parte de la aritmética de intervalos supone que cada caso es independiente de todos los demás. Tres turnos de una misma conversación no lo son: cuando la conversación sale mal, los tres suelen salir mal. Una suite que los trata como independientes informa un intervalo más estrecho de lo que la evidencia respalda, y un gate puede pasar con él.SegmentosUna tasa global puede mantenerse estable mientras una parte de la suite se desploma. Un segmento es una parte declarada de la suite, medida por separado, para que el desplome sea visible. Los segmentos vienen con dos disciplinas, porque examinar muchas partes de una suite es la forma en que una evaluación encuentra ruido y lo presenta como un hallazgo.JudgesAn LLM judge is one kind of evaluator, not all of them. Oloproof has three kinds — deterministic, LLM judge, and custom — and the rules on this page are about the second, because a model's verdict is the one that needs measuring against a human's.Evaluación RAGUna respuesta aumentada con recuperación puede ser incorrecta por cuatro motivos distintos: el pasaje correcto nunca se recuperó, se recuperó pero quedó demasiado abajo en el ranking, quedó lo bastante arriba y luego se eliminó del contexto, o llegó al modelo y el modelo se equivocó de todos modos. Una única cifra de exactitud no puede distinguirlos. Oloproof ejecuta un sistema RAG como dos etapas que puede observar, mide cada una y vuelve a ejecutar los casos fallidos bajo cambios controlados para averiguar qué motivo se aplica.Agentes y herramientasOloproof no dirige un agente. Su agente ejecuta su propio bucle, llama a sus propias herramientas y registra lo que ocurrió como un artefacto agent_trajectory/v1. Toda métrica de agente se lee a partir de ese registro, de modo que el registro es toda la integración.Clasificadores y regresoresUn modelo predictivo se evalúa como cualquier otro sistema: una función invocable devuelve una predicción para cada caso, y los evaluadores la leen. Lo que cambia son los denominadores. Exactitud (accuracy), exhaustividad (recall) y precisión son tres tasas sobre tres conjuntos distintos de filas, y un modelo puede verse bien en una mientras falla en la pregunta que se plantea el negocio.NotificacionesUna ejecución que pasa no notifica a nadie. Cuando Oloproof envía una notificación, significa que algo necesita una decisión o está a punto de dejar de funcionar: una release que un gate bloqueó, una ejecución gestionada que terminó, una asignación que se está agotando.ErroresLa distinción por la que existe esta página: una ejecución que falló y una ejecución que tuvo un error son cosas distintas, y presentar una como la otra le dice a un desarrollador que su cambio es malo cuando la verdad es que el harness se cayó.Referencia de la CLITodos los comandos que registra Oloproof, con lo que hace cada uno. Todos admiten --help, que imprime el texto completo del que salen estos resúmenes.