Guías
Qué funciona hoy
Lo que puede evaluar con Oloproof hoy, cómo llega a ello (SDK de Python, oloproof.yaml y la CLI, o el navegador) y lo que no está construido. Se basa en la auditoría de capacidades del 8 de octubre de 2026, una revisión interna que comprobó cada línea frente al código y sus pruebas, no frente a los planes.
Cómo leer esta página
"SDK" significa el paquete de Python (import oloproof). "YAML" significa un proyecto que ejecuta con oloproof run desde oloproof.yaml. No son la misma superficie: algunos evaluadores existen solo en una de ellas, y esta página dice en cuál. "Navegador" significa el workbench alojado, que muestra lo que usted envía con oloproof push; no ejecuta evaluaciones que no haya definido en código o en YAML.
Oloproof llama a su sistema; no lo aloja, no lo aísla ni lo reinicia. Su aplicación gestiona su propio estado, sus sesiones y los efectos secundarios de sus herramientas durante una ejecución.
Por tipo de sistema
| Su sistema | Qué funciona | Dónde | No construido |
|---|---|---|---|
| Clasificador o salida estructurada | Coincidencia exacta, contiene, regex, esquema JSON, juez con rúbrica, juez de probabilidad, clasificador de modelo; tasas de aprobación con intervalos | SDK y YAML; model_classifier, probability_judge y cascade solo en YAML | n/a |
| Generación de texto, resúmenes, extracción | Las mismas comprobaciones sobre texto libre, jueces con rúbrica, acuerdo del juez con etiquetas humanas, preferencia por pares | SDK y YAML; la preferencia es el comando oloproof prefer | BLEU, ROUGE o similitud de embeddings (escriba uno con @evaluator) |
| RAG que ejecuta como caja negra | Tasa de aciertos, recall, MRR, nDCG, validez de citas, jueces de fundamentación y de respaldo de citas, a partir de artefactos de recuperación que su sistema registra o devuelve | SDK y YAML | Diagnóstico: diagnose necesita un sistema por etapas |
| RAG construido por etapas | Todo lo anterior, caché por etapa y oloproof diagnose con contexto de referencia, cambios de top-k o de reranker junto a un control | SDK @rag_system, YAML system.rag, CLI diagnose | Intervenciones más allá de esas tres |
| Agente que usa herramientas | Límites de pasos, herramientas requeridas y prohibidas, orden de herramientas, bucles, restricciones, a partir de una trayectoria registrada | SDK y YAML | Una comprobación de calidad de trayectoria juzgada por un LLM |
| Sistema multiagente | Enrutamiento, permisos de herramientas por agente, límites de traspasos | SDK y YAML | n/a |
| Repetición de agente | Volver a ejecutar un caso desde un punto de control para etiquetar un paso como necesario o no | Solo SDK (replay_case), para un sistema que admita puntos de control | Un comando de la CLI |
| Modelo de clasificación binaria | Exactitud, precisión, recall, Brier, log loss, ordenación (AUC) | SDK y YAML predictive: | n/a |
| Modelo multiclase | Un bloque por clase (una contra el resto) | SDK y YAML | Promedios macro o micro |
| Modelo de regresión | Error absoluto dentro de un target_range declarado | SDK y YAML | Error cuadrático, R cuadrado, error no acotado |
| Conversación de varios turnos | Si cada turno guionizado recibió respuesta, y un juez con rúbrica sobre toda la conversación | Solo SDK (ConversationCompleted, ConversationJudge) | Tipos YAML, puntuaciones por turno, un simulador de usuario, repetición de conversaciones |
| Imágenes, audio, vídeo | Nada nativo: un caso puede llevar una URL o un archivo codificado a través de su sistema, y @evaluator puede comprobar la salida | n/a | Los jueces solo ven texto JSON; sin artefactos multimedia ni renderizado |
Una solución alternativa para varios turnos: haga de cada turno un caso y dé a los turnos de una misma conversación el mismo group_id, para que el análisis los trate como un clúster (Clusters). Cada turno es entonces una llamada separada, no un diálogo registrado.
Conectar su sistema
- Invocable de Python: @system en el SDK o system.callable: module:function en YAML. Recibe el input del caso y devuelve un diccionario. Funcionan tanto las funciones síncronas como las asíncronas.
- HTTP: system.http con url, method, output_path, artifacts y timeout_s. La entrada del caso se envía como cuerpo JSON y la respuesta se lee como JSON. Las cabeceras y la autenticación todavía no se pueden configurar; ponga un endpoint que necesite una clave detrás de un invocable que la añada.
- Evaluadores personalizados: @evaluator en el SDK. oloproof.yaml todavía no puede nombrar uno.
Flujos de trabajo
| Flujo de trabajo | Qué funciona | No construido |
|---|---|---|
| Comparar dos versiones | Superioridad pareada, no inferioridad y equivalencia; segmentos con control de multiplicidad | n/a |
| CI | Códigos de salida de oloproof gate según el block_on de su política, aprobación, registros firmados; un resumen de pull request (--summary markdown) | n/a |
| Revisión humana | Etiquetas desde un archivo o la terminal; una cola de revisión en el navegador con revisores asignados en un espacio de trabajo alojado | Una cola de revisión en el navegador sobre un proyecto local |
| Workbench en el navegador | Ejecuciones, casos, comparaciones, diagnósticos, evaluadores, revisión y tráfico, tras oloproof push | Importación de conjuntos de datos, creación de jueces, programaciones, alertas y postmortems (mostrados como previstos) |
| Navegador local | n/a | Ningún comando de la CLI sirve el workbench en local; está alojado |
Qué se ha probado, y cómo
Cada familia anterior tiene pruebas automatizadas, ejecutadas sobre fixtures y proveedores simulados. Hay ejecuciones registradas contra sistemas reales con modelos reales para RAG, un agente único y una conversación de varios turnos; ninguna todavía para modelos predictivos ni sistemas multiagente. Los métodos estadísticos que deciden publicaciones están admitidos cada uno por su propia auditoría; una métrica sin intervalo admitido no decide una regla sobre un intervalo, y una regla que lo necesitaría devuelve MANUAL_REVIEW o INSUFFICIENT_EVIDENCE con su motivo.