Resumen

  • draft-abak-ai-evaluation-claim-preservation-00 propone requisitos para que una conversión conserve la atribución, el significado, el alcance y las reservas materiales de una afirmación de evaluación de IA.
  • Redondear, normalizar o reagrupar no es una operación neutral cuando puede cambiar una comparación. La vista derivada debe quedar separada del valor y del veredicto atribuidos a la fuente.
  • Una firma válida sobre el informe convertido no demuestra que el criterio, la población, la métrica o la incertidumbre hayan sobrevivido a la conversión.

El decimal que cruzó un umbral sin moverse

El ejemplo sintético de la revisión 00 es pequeño porque el problema no necesita una arquitectura compleja. La fuente contiene la cadena decimal exacta 0.94996. Una interfaz la presenta como 0.950. El criterio es >= 0.95.

Aplicado al valor fuente, el criterio da fallo. Aplicado a la presentación redondeada, da aprobado. Los dos cálculos pueden estar bien ejecutados; lo que no pueden hacer es fingir que contestan la misma pregunta.

El redondeo no está prohibido. Sirve para mostrar resultados, comparar tendencias y reducir ruido. La obligación aparece cuando altera el sentido de una afirmación. En ese caso debe quedar registrado como una derivación con sus entradas, regla, precisión y actor. Si un consumidor decide evaluar deliberadamente el valor redondeado, produce un juicio nuevo. No puede atribuirlo al evaluador original ni sustituir silenciosamente la comparación previa.

La misma lógica cubre unidades, escalas, dirección del comparador, normalización, agregación e incertidumbre. La falta de un intervalo de confianza no equivale a incertidumbre cero. La incertidumbre del resultado no es la información perdida por el convertidor. Un entero que funciona como identificador no puede pasar por una representación numérica con pérdida y seguir considerándose exacto.

El proyecto llama a este problema «preservación de afirmaciones», no preservación de campos. Copiar el campo numérico puede ser insuficiente si desaparecen las condiciones que permiten decir qué significa.

Terminar una ejecución no es superar una prueba

Otro ejemplo sintético combina status: success con una exactitud de 0,734. Inspect documenta por separado el estado de la ejecución y los resultados de puntuación; el proyecto utiliza esa separación como punto de partida, no como acusación contra la herramienta.

El estado correcto puede indicar que el proceso terminó. El 0,734 puede ser una observación de una métrica. Ninguno demuestra que existiera un umbral original, y mucho menos que se superara.

Hay además una diferencia entre «la fuente declara que no aplicó criterio» y «la evidencia disponible no permite saber si había criterio». Un campo ausente sólo resuelve esa diferencia cuando el formato fuente define de forma inequívoca lo que significa la omisión.

El consumidor puede aplicar un límite propio, por ejemplo 0,70. Debe conservar el valor fuente y añadir una evaluación separada: actor, regla, versión, ámbito y resultado. También debe dejar como no establecido si ese criterio precedió a la ejecución. Un sello temporal aislado, un identificador coincidente o un compromiso mediante hash no prueban por sí solos esa cronología.

Un identificador de ejecución no elige la métrica

Una misma tarea puede contener varios resultados. El ejemplo inspirado en la estructura de LightEval coloca 0,62 para una métrica y 0,8 para otra bajo el mismo run ficticio. Decir «run-17 superó 0,75» no selecciona ninguna.

El perfil necesita distinguir tarea, scorer, métrica, intento, agregación, conjunto o partición de datos y población cuando afectan a la afirmación. No puede resolver la ambigüedad tomando el primer resultado, el último, el mayor o el más favorable.

JSON Pointer puede señalar una ubicación precisa en un objeto identificado. No conserva por sí solo la definición de la métrica ni la completitud de la población. Tampoco impide que una URL mutable muestre contenido distinto mañana. El selector debe aplicarse a una instantánea conocida, con una sintaxis conocida y una unión verificable entre fuente, regla de mapping y salida.

Un hash fija octetos, no su interpretación. Hacer hash del JSON original y hacerlo de una representación canónica son operaciones distintas. El algoritmo, la selección de bytes y la regla de canonicalización forman parte de la evidencia.

El 95 % de lo observado no es el 95 % de lo planeado

La revisión 00 presenta una campaña sintética con 100 muestras planeadas. Se ejecutan 80. Setenta y seis cumplen el criterio y cuatro no. La fracción entre las terminadas es 76/80, o 0,95.

Exportar únicamente 0.95 elimina las veinte muestras no ejecutadas. No autoriza a afirmar que 95 de las 100 planeadas cumplieron. Un consumidor puede adoptar una política que acepte cobertura incompleta, pero esa es su regla, no una propiedad oculta dentro del porcentaje.

Reintentos, mediciones repetidas, duplicados, exclusiones e invalidaciones modifican el denominador. El perfil debe explicar cómo se cuentan. Cuando el total es desconocido, sigue siendo desconocido. Preservar todos los registros entregados tampoco prueba que el operador revelara todos los intentos reales.

Esta distinción muestra por qué un resumen más corto puede ser más autoritario. Al retirar el denominador, deja un porcentaje fácil de comparar y difícil de cuestionar.

La referencia restringida no son los bytes

Un editor puede recibir la URL privada de un log sin permiso para descargarlo. Puede transportar la referencia y declarar que no la recuperó, que no recalculó el digest y que la existencia del objeto procede de una afirmación de la fuente.

No puede inventar un hash para satisfacer un campo obligatorio. Tampoco afirmar que comprobó el contenido, que el log es completo o que seguirá disponible. Ubicación, permiso, recuperación y retención son propiedades diferentes.

Incluso cuando hay un digest, importa quién lo calculó. Copiar el valor que anuncia la fuente no equivale a recomputarlo sobre bytes disponibles para el consumidor. Y disponer de los bytes no demuestra que el modelo declarado sea el que realmente se ejecutó; ese salto requiere otra base de verificación.

Una referencia tampoco otorga permiso para descargar o ejecutar su destino. Logs, prompts y salidas de herramientas siguen siendo datos no confiables dentro de un registro firmado. El verificador necesita límites de tamaño, expansión, profundidad, destinos, redirecciones y esquemas.

Autenticar el resumen no recupera lo perdido

RATS distingue evidencia, apreciación y política del relying party. SCITT aporta transparencia y recibos para declaraciones. in-toto ofrece sujetos ligados a digest y predicados tipados. Son mecanismos útiles para proteger una conversión y documentar relaciones.

No deciden si una métrica fue interpretada fielmente. Si el primer convertidor descarta las veinte muestras no ejecutadas y conserva sólo 0,95, una firma del segundo convertidor autentica ese resumen reducido. No reconstruye la población.

Un actor posterior puede volver a la fuente original y producir una vista nueva. Debe declarar esa comprobación directa y distinguirla de la cadena anterior. No puede presentar la información recuperada como si hubiera atravesado intacta el salto con pérdida.

Por la misma razón, un manifiesto de pérdida firmado sigue siendo una afirmación; no prueba que enumere todas las pérdidas. Una envoltura puede verificar mientras el consumidor no admite el perfil semántico. En ese caso puede guardarla como opaca, pero no elevarla a afirmación establecida.

Validación estructural, recomputación de digest, verificación de firma, apreciación de attestation, comprobación del mapping y juicio sustantivo son resultados distintos. Un único indicador verde que los mezcle es otra transformación semántica, esta vez en la interfaz.

Una afirmación bien preservada puede seguir siendo falsa

La preservación no prueba honestidad de la fuente, competencia del evaluador, validez científica del benchmark, identidad exacta del modelo ni seguridad de despliegue. Un convertidor impecable puede transportar una afirmación falsa con total fidelidad.

Tampoco demuestra autoridad o efecto. Una evaluación derivada puede alimentar una decisión bajo una política identificada. El registro no prueba que el actor tuviera mandato, que el control llegara al sistema, que se ejecutara ni que produjera el resultado esperado.

La revisión 00 no define un formato de red ni una certificación. Declara que hace falta un perfil concreto. Sus escenarios son sintéticos. Aceptar un esquema no es comprobar equivalencia semántica. Las pruebas del mismo autor no son interoperabilidad independiente.

La prueba de las capas de realidad

La doctrina de Heng Lu ayuda a ordenar el expediente: bytes, valor seleccionado, afirmación, portador autenticado, evaluación del consumidor, decisión, ejecución y efecto observado son capas diferentes.

La especificación inicial mínima debe decir qué afirmaciones limitadas sabe conservar el perfil y qué casos deja sin establecer. La mínima especificación no es el mínimo número de campos; es el mínimo conjunto completo para la afirmación elegida.

La primacía del código en funcionamiento exige pruebas observables y versionadas. ¿Dos implementaciones independientes conservan el valor exacto que no supera el umbral? ¿Mantienen visible el denominador parcial? ¿Rechazan el perfil nuevo bajo reglas antiguas? Sin esas respuestas, «claim-preserving» sigue siendo una descripción, no un resultado operativo.

Fuentes y límites

Las fuentes se congelaron el 30 de septiembre de 2026, zona Asia/Shanghai. La revisión 00 es un Internet-Draft individual activo con destino Informational. No es RFC, consenso IETF, producto de grupo de trabajo, benchmark, certificación, implementación ni medición de despliegue. Sus ejemplos son sintéticos. La lectura mediante la doctrina de Heng Lu es análisis de Daniel Kade.