La prueba de realidad: cómo saber si una IA mejora de verdad

El lunes, una nueva versión del asistente responde con más soltura. El martes, alguien descubre que ha confundido dos referencias de pedido. El miércoles, el equipo ya discute si conviene volver al modelo anterior. La demostración había salido impecable; faltaba una forma compartida de decidir qué significaba «mejor».

Ese es uno de los problemas menos vistosos y más importantes de la IA empresarial. Un sistema puede escribir mejor y extraer peor, resolver los casos frecuentes y fallar precisamente donde el error cuesta dinero. La fluidez no sirve como acta de aceptación.

La documentación oficial consultada el 26 de octubre de 2026 coincide en una dirección útil: definir la tarea, reunir ejemplos representativos y evaluar de forma repetible. A partir de esas bases, proponemos un experimento propio, independiente del proveedor, para comparar dos versiones de una solución sin convertir la elección del modelo en una cuestión de gustos.

Qué estamos evaluando: el sistema completo

«Modelo A contra modelo B» parece una comparación limpia, pero una aplicación incluye instrucciones, documentos recuperados, herramientas, reglas y una interfaz. Si se cambian varias piezas simultáneamente, resulta difícil atribuir la mejora o localizar la regresión.

Para empezar, elige una tarea acotada: leer solicitudes de proveedores, clasificarlas y extraer una referencia y un importe cuando estén presentes. La salida será una propuesta para una persona; no enviará mensajes ni ejecutará pagos. Esta frontera permite estudiar calidad y utilidad con consecuencias controladas.

La guía de evaluación de OpenAI recomienda pruebas específicas de la tarea, datos próximos al uso real y evaluación continua. También advierte contra decidir por la impresión de que el sistema funciona. La consecuencia práctica es sencilla: el conjunto de pruebas debe existir antes de celebrar la siguiente mejora.

Un contrato de salida antes del siguiente prompt

Define qué puede devolver el sistema y cómo expresa la ausencia de información. Para nuestro experimento, basta este contrato:

{
  "categoria": "consulta_factura",
  "referencia": "PED-1042",
  "importe": "1250.00",
  "moneda": "EUR",
  "requiere_revision": true
}

El importe se representa como cadena decimal normalizada para evitar depender del formato local. Un dato ausente se devuelve como null. El catálogo de categorías se acuerda con negocio e incluye otro. Si el mensaje contiene importes contradictorios, se solicita revisión y no se elige uno por intuición.

Una salida válida como JSON todavía puede ser incorrecta. Validar estructura comprueba que el contenedor sirve; contrastar valores y evidencia comprueba que su contenido merece confianza. Mantén ambas medidas separadas.

Construir un banco pequeño que pueda crecer

Como punto de partida, proponemos 60 solicitudes revisadas por una persona conocedora del proceso: 30 habituales, 15 incompletas y 15 difíciles. Es una muestra para descubrir fallos e iniciar el trabajo; no demuestra por sí sola fiabilidad estadística para un despliegue amplio.

Incluye referencias parecidas, separadores decimales distintos, varios idiomas si existen en el servicio, mensajes con varios documentos y solicitudes sin ninguna referencia. Evita fabricar todos los casos con otro modelo: podrías terminar midiendo la comodidad de la IA con textos producidos por IA.

Los registros reales necesitan autorización de uso, minimización y anonimización adecuada. Sustituir solo el nombre de una persona puede dejar identificadores, firmas o datos bancarios en el texto. Aplica acceso restringido y una política de conservación también a los resultados y trazas.

Separar aprendizaje y examen

Usa 40 casos para desarrollar las instrucciones y reserva 20 para una comprobación final. No retoques el prompt después de cada error del examen y sigas llamándolo independiente: al hacerlo, esos ejemplos pasan a formar parte del desarrollo. Añade después un nuevo conjunto reservado.

La documentación de Anthropic distingue criterios de éxito medibles y métodos de evaluación mediante código, personas o modelos. Para este caso, las etiquetas y referencias acordadas con negocio constituyen la referencia; los desacuerdos humanos se resuelven antes de puntuar a la máquina.

Una matriz de decisión que no esconda los errores

La siguiente tabla es una propuesta de criterios para el piloto, no un estándar universal ni resultados obtenidos. El responsable del proceso debe ajustar los umbrales al impacto real del error.

Que no aparezca un error crítico en esta muestra no prueba que sea imposible. Es una condición de entrada al siguiente ensayo. En clasificación, informa cuántos ejemplos hay en cada categoría: un buen promedio puede esconder que el sistema falla en una clase poco frecuente.

La latencia p95 indica el tiempo por debajo del cual termina el 95 % de las solicitudes medidas. Es más informativa que una media aislada cuando algunos usuarios esperan mucho más que los demás. Incluye errores de servicio y reintentos en el informe operativo.

El experimento: dos versiones, las mismas entradas

Guarda la versión vigente como A. En B cambia una sola variable: por ejemplo, añade al prompt dos ejemplos de ambigüedad. Ejecuta ambas sobre las mismas entradas y repite tres veces por caso para detectar variación. Mantén constantes documentos, herramientas, límites de salida y parámetros de generación disponibles.

Registra identificador del caso, versión del prompt, identificador de modelo devuelto por el proveedor, configuración, fecha, respuesta, tiempo, consumo y resultado de cada comprobación. Si el proveedor solo ofrece un alias que puede cambiar, anota esa limitación: reproducir la configuración no garantiza recuperar exactamente el mismo comportamiento futuro.

Un comprobador mínimo en Python

Este ejemplo evalúa una salida ya generada frente a una referencia humana. No llama a ningún proveedor ni constituye una validación completa de esquema; sirve para mantener separados los errores de formato y de contenido.

import json

def comprobar(texto, esperado):
    try:
        salida = json.loads(texto)
    except (json.JSONDecodeError, TypeError):
        return {"json_valido": False, "campos": {}}
    if not isinstance(salida, dict):
        return {"json_valido": False, "campos": {}}
    campos = ("categoria", "referencia", "importe", "moneda")
    return {
        "json_valido": True,
        "campos": {
            campo: campo in salida
            and salida[campo] == esperado[campo]
            for campo in campos
        },
        "revision_correcta": (
            "requiere_revision" in salida
            and type(salida["requiere_revision"]) is bool
            and salida["requiere_revision"]
                == esperado["requiere_revision"]
        ),
    }

En una implementación real, valida además tipos, campos obligatorios, valores permitidos y propiedades adicionales con un esquema. Normaliza las referencias humanas y las salidas usando las mismas reglas documentadas; no borres diferencias de moneda o signo para conseguir más coincidencias.

Revisa cada diferencia A/B. Un acierto adicional y una nueva invención de importe no se compensan automáticamente. Clasifica los fallos por gravedad y conserva ejemplos concretos junto al resumen.

Cuándo utilizar otra IA como evaluador

Para clasificar o extraer campos conocidos, las reglas suelen ser suficientes. Para un resumen de un documento, la equivalencia literal deja de funcionar: dos textos diferentes pueden ser correctos. Aquí puede ayudar un modelo evaluador con una rúbrica explícita y acceso a la evidencia.

Por ejemplo: «¿Conserva las tres obligaciones que figuran en el documento?», «¿añade una fecha que no aparece?» y «¿distingue una propuesta de una decisión?». Pide un resultado por criterio y referencias al fragmento que sostiene el juicio. Comprueba manualmente una muestra y estudia los desacuerdos; el evaluador también puede equivocarse.

Google documenta métricas mediante rúbricas y métricas computacionales. Esa distinción es útil con independencia de la plataforma elegida: aplica reglas donde la verdad sea verificable y reserva los juicios semánticos para aquello que lo necesita. Si comparas textos A/B con un juez, alterna su posición para investigar posibles preferencias por el orden.

Coste, límites y decisión de despliegue

Con 60 casos, dos versiones y tres repeticiones tendrás 360 ejecuciones de la aplicación. Un evaluador adicional aumenta consumo y latencia. Presupuesta tokens de entrada y salida, recuperación documental, llamadas a herramientas, almacenamiento de trazas y revisión humana. El coste por llamada más bajo puede perder su ventaja si multiplica las correcciones.

La decisión final debe considerar calidad y trabajo posterior: minutos de revisión por solicitud, proporción resuelta y coste por caso correctamente completado. No anuncies ahorros antes de medirlos con usuarios y una línea base comparable.

Después del banco offline, prueba en paralelo sobre entradas reales autorizadas, sin actuar sobre sistemas de negocio. Si supera esa fase, amplía gradualmente y conserva una versión a la que volver. Cada cambio de prompt, documentos, modelo o herramientas debe volver a pasar las pruebas pertinentes. En sistemas conectados, complementa este banco con pruebas de integración como las que tratamos al conectar agentes SAP con herramientas MCP.

El equipo que convierte una prueba en capacidad

Esta disciplina reúne al experto de negocio que define lo correcto, al ingeniero de IA que diseña el experimento, al profesional de datos que prepara ejemplos fiables y al perfil de MLOps que automatiza regresiones y seguimiento. En un piloto, una persona puede cubrir varias funciones; las responsabilidades deben seguir siendo visibles.

La contratación también mejora cuando se pide evidencia: una matriz de errores, una evaluación reproducible y una explicación de sus límites dicen más que una colección de demos. Es una extensión práctica de la necesidad de trabajar con habilidades verificables.

Si tu organización está preparando un proyecto de IA, puedes pedir a Sapindex profesionales de ingeniería de IA, datos y MLOps acordes con la fase del proyecto. Definir la tarea y cómo se aprobará su resultado permite buscar el equipo adecuado desde el principio.

Una IA mejora de verdad cuando deja evidencia de esa mejora en el trabajo que importa. El banco de pruebas es modesto, pero cambia la conversación: de «esta respuesta me gusta» a «estos casos funcionan mejor, estos siguen fallando y sabemos cuánto cuesta resolverlos».

Fuentes oficiales

• OpenAI: Evaluation best practices.
• Anthropic: Define success criteria and build evaluations.
• Google Cloud: Gen AI evaluation service overview.

Fuentes consultadas el 26 de octubre de 2026. El banco de pruebas, el código y los umbrales de esta guía son una propuesta de implementación de Sapindex; no resultados de un ensayo ni garantías de los proveedores.