Evaluaciones: de experimentar con IA a producir con confianza

• Aunque los modelos fundacionales han mejorado, el verdadero cambio que permite usarlos con confianza en producción proviene de unas prácticas de evaluación rigurosas

• Unas evaluaciones bien diseñadas ayudan a responsables de producto, responsables de gobernanza de la IA y directores de tecnología a desplegar agentes de IA de forma segura y a gran escala, convirtiendo la IA de un juguete aislado en una ventaja competitiva.

• Esa confianza nace de evaluar el comportamiento de los agentes de IA frente a consultas de usuarios reales, casos límite y situaciones específicas del sector que reflejen el contexto empresarial real, no de un índice de referencia público que afirme «este modelo es el mejor»

• El objetivo es justificar esa confianza mediante resultados medibles. El éxito exige definir qué se considera «bueno» en términos concretos y medibles, acordes con las necesidades de la empresa y su tolerancia al riesgo, ya sea exactitud factual, tono adecuado, velocidad o eficiencia de costes.

• Al integrar la evaluación en todo el sistema —instrumentación, registros, pruebas A/B y barreras de seguridad— y equilibrar rigor y eficiencia, los equipos podrán desplegar con mayor rapidez y solidez.

La mayoría de las empresas aceptan que sus empleados experimenten con ChatGPT o Gemini. Sin embargo, es mucho menos habitual emplear LLM en procesos o entornos críticos.

A menudo ha habido motivos fundados: la calidad era irregular y el riesgo de alucinaciones o comportamientos no deseados superaba las posibles ventajas de la tecnología.

Este equilibrio entre riesgo y beneficio ha cambiado notablemente durante el último año. Aunque parte del cambio se debe a las mejoras de rendimiento de los modelos fundacionales, también responde en gran medida al creciente rigor de la evaluación. Las evaluaciones nos dan, tanto a nosotros como a nuestros clientes, la confianza necesaria para desplegar en cuestión de semanas agentes a gran escala y orientados al cliente.

Esta guía explica los fundamentos de las evaluaciones y cómo diseñarlas, implantarlas y gestionarlas para casos de uso en producción.

El objetivo de la evaluación no es encontrar un modelo perfecto, sino generar una confianza justificada en que el modelo se comporta de acuerdo con las necesidades de la empresa, las expectativas de los usuarios y la tolerancia al riesgo de la organización.

Toda estrategia de evaluación parte de una pregunta sencilla: ¿Qué se considera «bueno»? La respuesta debe ser concreta. Para una organización, «bueno» puede significar exactitud factual dentro de tolerancias estrictas; para otra, puede primar la velocidad, la eficiencia de costes o un tono de voz distintivo. Todas las restricciones aplicables, desde los datos que pueden utilizarse hasta las obligaciones normativas, condicionan esta definición.

Es esencial que lo «bueno» incluya componentes que realmente puedan medirse. Si el éxito consiste en ofrecer orientación financiera útil, esa utilidad debe expresarse mediante atributos: corrección factual, advertencias adecuadas, razonamiento personalizado y límites seguros. Una vez definido lo «bueno» en términos medibles, la siguiente pregunta es cómo se analizarán e interpretarán los resultados. Actuar a partir de estos resultados convierte la evaluación en un método, en lugar de limitarla a juicios puntuales.

Toda canalización de evaluación se asienta sobre tres pilares interconectados:

1. Entradas e índices de referencia: ejemplos representativos del mundo real para medir el rendimiento general y conjuntos de datos internos seleccionados para comprobar la viabilidad en el sector.

2. Comportamiento del modelo: cómo se invoca el modelo —generación aumentada por recuperación, resumen, recuperación estructurada de información o uso de herramientas—.

3. Métricas: cómo se mide e interpreta el rendimiento.

Las entradas deben representar el mundo al que se enfrentará el sistema. La información más valiosa procede de ejemplos reales: consultas de clientes, situaciones financieras o casos propios del sector. Solo al realizar pruebas con estos ejemplos se puede saber si el modelo comprende realmente los matices que necesitan los usuarios y satisface las necesidades empresariales.

El comportamiento del modelo —cómo recibe el prompt, cómo se orquestan la recuperación o el uso de herramientas y cómo se proporciona el contexto— importa tanto como el propio modelo. Dos modelos idénticos pueden comportarse de forma muy distinta según cómo se desplieguen. Por tanto, esta capa debe incluirse en el diseño de la evaluación.

Por último, están las métricas. Las cifras por sí solas rara vez cuentan toda la historia, pero unas métricas bien elegidas permiten interpretar el comportamiento del sistema. Latencia, exactitud, seguridad, coherencia, sesgo, coste y satisfacción del usuario forman, en conjunto, una imagen multidimensional de un sistema en producción. La clave está en elegir métricas acordes con los KPI del proyecto o la empresa y que revelen las cualidades más importantes para los usuarios. Las métricas más sencillas suelen ser más exactas y menos costosas, mientras que una mala elección puede llevar al equipo a conclusiones erróneas. Así debe plantearse la selección de métricas:

Ejemplos de buenas métricas:

• Chatbot de atención al cliente: tasa de resolución en el primer contacto —¿se resolvió el problema del usuario sin derivarlo?—, tiempo medio de gestión, puntuación de satisfacción y tasa de derivación a agentes humanos

• Herramienta de investigación financiera: exactitud de las citas —porcentaje de afirmaciones con fuentes adecuadas—, precisión factual validada con datos de referencia, relevancia de la recuperación —¿encontró los documentos correctos?— y coherencia del razonamiento puntuada por especialistas del sector

• Asistente de generación de código: corrección sintáctica, tasa de pruebas superadas, número de vulnerabilidades de seguridad y tiempo hasta obtener una solución funcional

Ejemplos de malas métricas:

• Usar únicamente la longitud de la respuesta como indicador de calidad —más largo ≠ mejor—

• Medir la velocidad sin considerar su relación con la exactitud

• Registrar las puntuaciones de confianza del modelo sin contrastarlas con la corrección real

• Depender únicamente de la perplejidad interna del modelo sin validación de cara al usuario

Errores habituales con las métricas que deben evitarse:

• Métricas contradictorias: optimizar a la vez la velocidad y la exhaustividad sin reconocer que hay que buscar un equilibrio

• Sobreajuste a índices de referencia: lograr un 95 % en el conjunto de pruebas, pero fracasar en producción porque los usuarios reales se comportan de otra manera

Para un cliente de servicios financieros sujetos a una regulación estricta, la exactitud de su solución de investigación avanzada era primordial. Diseñamos conjuntos de datos de preguntas y respuestas creados por especialistas y los combinamos con otros generados mediante herramientas. Así pudimos evaluar la precisión, la capacidad del sistema para elegir las herramientas adecuadas y recuperar la información correcta, y obtener una visión equilibrada de la exactitud y la calidad del razonamiento. La clave fue medir varias dimensiones: exactitud factual —validación por especialistas—, calidad de la recuperación —precisión y exhaustividad de documentos relevantes— y coherencia del razonamiento —evaluación estructurada del flujo lógico—.

Cuándo usar un LLM como juez para evaluar una calidad con matices

El enfoque de LLM como juez emplea un segundo modelo de IA como evaluador y sustituye la revisión humana por una puntuación de calidad automatizada y escalable. A menudo se abusa del LLM como juez cuando unas métricas más sencillas proporcionarían la exactitud necesaria. Puede resultar útil cuando las comprobaciones deterministas no permiten evaluar la calidad, por ejemplo, si la métrica es semántica —utilidad, fundamentación, calidad del razonamiento, tono o interpretación de políticas— y no es posible asignar una puntuación determinista. Puede que se necesiten comentarios escalables para muchas variantes de prompts y modelos, así como una rúbrica clara y un esquema de resultados estructurados. Para que funcione, sigue estos pasos:

• Define explícitamente las dimensiones de la rúbrica: corrección, fundamentación, cumplimiento de políticas, viabilidad práctica y tono.

• Usa resultados estructurados —esquema JSON— para las respuestas del juez.

• Registra tanto las puntuaciones binarias de control como el texto de diagnóstico para analizar los fallos.

• Calibra en cada ciclo de lanzamiento los resultados del juez frente a muestras etiquetadas por personas.

• En ámbitos críticos, utiliza dos jueces o comprobaciones periódicas de consenso.

• Controla a lo largo del tiempo la deriva del juez y la tasa de desacuerdo.

Un conjunto de datos de referencia es una selección fija de ejemplos de prueba con respuestas conocidas, utilizada para evaluar los modelos de manera uniforme y comparar los resultados de distintas versiones con equidad. Suele incluir entradas —por ejemplo, consultas de usuarios—, resultados esperados o valoraciones de referencia y criterios o etiquetas de evaluación para asignar puntuaciones. Las pruebas públicas de referencia sirven para comparar el rendimiento de los modelos más avanzados y pueden resultar útiles como primera consulta al diseñar el sistema y decidir qué modelo podría ser un buen candidato.

Sin embargo, no puedes utilizarlas como indicador del rendimiento de tu propio sistema en el contexto empresarial, ya que presentan problemas conocidos:

• Contaminación: los modelos pueden haberse entrenado con datos del índice de referencia; evaluarlos con ese mismo conjunto equivale a calificarlos con una chuleta.

• Saturación: los mejores modelos ya alcanzan puntuaciones máximas, por lo que las mejoras o pérdidas de rendimiento se limitan a unos pocos puntos porcentuales y suelen quedar dentro de la variabilidad natural de los resultados.

• Alcance limitado: los datos de referencia no reflejan las tareas reales, pues están muy seleccionados y depurados. Algunos incluso los generan LLM y no reflejan la complejidad ni los casos límite de tus datos —erratas, giros inusuales o imágenes con ruido—.

Un estudiante pide a la aplicación que le ayude a resolver problemas redactados.

Ejemplo de índice de referencia público que puedes utilizar: GSM8K —razonamiento matemático de primaria—

• Conjunto opcional más difícil: MATH.

Por qué es útil este índice de referencia:

• Permite comparar rápidamente qué modelo razona mejor en matemáticas generales,

• Es un buen primer filtro antes de invertir en evaluaciones completas del producto.

Por qué sigues necesitando tu propio conjunto de datos:

Tu aplicación tiene requisitos que GSM8K no comprueba:

• La redacción de tu plan de estudios y el orden de los temas,

• El estilo de las explicaciones para la edad de tus usuarios,

• Cómo responder a preguntas ambiguas o con muchas erratas,

• Reglas de uso —por ejemplo, cuándo dar pistas y cuándo ofrecer respuestas completas—.

Una validación eficaz depende de crear índices de referencia específicos para la aplicación. Estos conjuntos de datos deben proceder de interacciones reales, casos límite habituales y modos de fallo plausibles. Esta tarea puede resultar difícil al implantar un producto o proceso nuevo. Sin embargo, en la mayoría de los casos es posible recopilar datos de un producto existente o hacerlo cuanto antes, incluso durante una fase inicial de pruebas. Tras desarrollar la aplicación, estos índices de referencia deben evolucionar con el producto y hacerse más completos y representativos con el tiempo.

La relación entre el índice de referencia específico de la aplicación y la selección del modelo es fundamental. El índice de referencia no solo revela si una solución funciona, sino también qué combinación de tamaño del modelo y técnicas de posentrenamiento ofrece el rendimiento necesario con la mejor relación coste-eficacia. Las mejoras más potentes de los modelos preentrenados —la «PT» de ChatGPT— no proceden de volver a entrenarlos, sino de métodos de «posentrenamiento».

Estos métodos se centran en determinar a qué información puede acceder el modelo, cómo se estructura y cómo se guía y orquesta el modelo durante la inferencia. Técnicas de posentrenamiento como:

• Prompts de cadena de pensamiento y asignación dinámica de capacidad informática —dedicar más razonamiento a los problemas difíciles—

• Autoconsistencia, que genera varios resultados y selecciona el mejor

• Construcción y orquestación del contexto, como la generación aumentada por recuperación —RAG—, los ejemplos de pocos ejemplos y los flujos de trabajo con agentes

• Uso de herramientas y acceso a conocimiento externo, que permiten al modelo actuar más allá de sus parámetros internos

• Estrategias de representación y almacenamiento del conocimiento, diseñadas para recuperar información y razonar con eficiencia sobre datos estructurados y no estructurados

Aunque estas técnicas de posentrenamiento pueden mejorar notablemente el rendimiento del sistema, también exigen buscar ciertos equilibrios. Cada capa adicional de orquestación, recuperación o razonamiento aumenta la complejidad del sistema, el tiempo de inferencia y el coste operativo. Sin embargo, si se aplican con criterio, la combinación adecuada de técnicas de posentrenamiento suele permitir el uso de modelos más pequeños, rápidos y baratos sin dejar de cumplir los requisitos de rendimiento. En lugar de aumentar el tamaño del modelo, el rendimiento se logra mediante un mejor diseño del sistema.

Encontrar este equilibrio depende de cada aplicación y debe basarse en sus evaluaciones específicas para determinar la combinación óptima de técnicas. Estas evaluaciones permiten identificar el punto a partir del cual añadir más orquestación deja de aportar mejoras significativas, para que los equipos elijan el nivel mínimo de complejidad de posentrenamiento necesario para alcanzar el rendimiento objetivo.

Una solución de IA debe entenderse como un sistema completo: bases de datos, API, interfaces de usuario, capas de orquestación, infraestructura de supervisión y mucho más. Por tanto, la evaluación debe abarcar toda la arquitectura tecnológica. Conviene supervisar los componentes clave del sistema para mantener visibles los posibles problemas y acelerar de forma responsable.

Supervisar los componentes clave del sistema implica:

• Instrumentar las canalizaciones para obtener resultados medibles.

• Registrar los experimentos para observar el efecto de cada ajuste.

• Utilizar comparaciones A/B sencillas antes de desplegar cambios importantes para detectar posibles regresiones.

La iteración basada en datos acorta el camino del prototipo a la producción sin dejar puntos ciegos. El registro y la supervisión también son importantes para comprender el uso real de la aplicación. Este es un ejemplo para garantizar la observabilidad:

• Paso 1: la solicitud del usuario llega con request_id, user_segment e intent.

• Paso 2: la traza registra la versión del modelo, la versión del prompt, los documentos recuperados y las llamadas a herramientas.

• Paso 3: el LLM juez puntúa la respuesta —corrección, fundamentación y policy_risk—.

• Paso 4: el motor de reglas evalúa los umbrales.

• Paso 5: si se incumple un umbral, activa una alerta y deriva al mecanismo alternativo o a una revisión humana.

• Paso 6: el fallo se añade a la cola de clasificación y después a la lista pendiente del índice de referencia.

Los usuarios reales rara vez se comportan exactamente como esperan los diseñadores. Algunos interpretarán mal las instrucciones. Otros pondrán a prueba deliberadamente los puntos débiles. Estos casos límite no son anomalías, sino señales de valor incalculable. Una canalización de evaluación bien implantada los captura, analiza e incorpora a futuras pruebas. Solo se puede iterar con rapidez y sin puntos ciegos cuando la evaluación forma parte del sistema desde el principio, en lugar de añadirse tras el desarrollo.

Recomendamos incorporar barreras de seguridad y supervisión desde el primer día:

• Controla periódicamente las métricas y regresiones del modelo mediante el índice de referencia específico de la aplicación.

• Captura y revisa casos límite o entradas adversarias —y añádelos al conjunto de datos del índice de referencia específico de la aplicación—.

• Asegúrate de que estas métricas de evaluación estén alineadas con tus KPI principales.

• Cuestiona periódicamente el conjunto de datos y el índice de referencia para asegurarte de que no ignoras nuevos riesgos ni incurres en sesgos.

• Implanta alertas automáticas ante el deterioro de las métricas —por ejemplo, si la exactitud cae por debajo del 85 %, activa una revisión—.

• Mantén un proceso de revisión humana para decisiones críticas —asesoramiento jurídico, orientación médica o transacciones financieras—.

Cada ejecución del índice de referencia consume capacidad informática y energía. Cada experimento redundante aumenta el coste. Una evaluación responsable debe equilibrar rigor y eficiencia.

Pueden adoptarse varias medidas prácticas para evitar que se disparen el consumo energético y los costes:

• Utiliza modelos más pequeños cuando sea posible: realiza los experimentos iniciales con modelos más baratos y aumenta su escala solo después de validar el enfoque.

• Almacena en caché los prompts y las llamadas a API.

• Planifica las tareas teniendo en cuenta la energía —procesamiento por lotes, instancias puntuales y prioridad flexible—.

• Controla el uso de recursos informáticos junto con el rendimiento.

Asimismo, mantente al tanto de las nuevas normativas sobre IA. Incluso cuando no exista una ley específica, siguen siendo aplicables los marcos vigentes y las medidas necesarias, como estas:

Protección de datos:

• Garantiza que los conjuntos de datos de referencia no contengan información de identificación personal sin el consentimiento adecuado

• Implanta políticas de conservación de datos para las consultas registradas

• Ofrece mecanismos para solicitar la eliminación de datos

Igualdad y sesgos:

• Comprueba el rendimiento en distintos grupos demográficos

• Incluye una representación diversa al crear el índice de referencia

Derechos humanos y transparencia:

• Documenta claramente para los usuarios las limitaciones del modelo

• Ofrece explicaciones sobre las decisiones críticas

• Permite la supervisión humana en aplicaciones críticas

La evaluación no es un acto puntual, sino un sistema en evolución. En un ámbito que avanza con rapidez, la ventaja reside en la capacidad para probar, aprender y adaptarse deprisa, y así desplegar modelos y nuevas soluciones con mayor eficacia.

Al integrar la evaluación como actividad fundamental de ingeniería y gestión de producto, los equipos pueden innovar con mayor rapidez y seguridad. Empieza por definir qué se considera bueno en el contexto de tu aplicación de IA, configura una plataforma de evaluación y hazla evolucionar hasta disponer de un índice de referencia específico para la aplicación que, en cada iteración, te permita confiar en que está lista para producción.