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 prácticas de evaluación rigurosas.

• Las evaluaciones bien diseñadas ayudan a gerentes de producto, responsables de gobernanza de IA y directores de tecnología a implementar agentes de IA de forma segura y a gran escala, para convertir la IA de una herramienta aislada en una ventaja competitiva.

• Esa confianza surge de evaluar el comportamiento de los agentes de IA con consultas de usuarios reales, casos extremos y situaciones específicas del dominio que reflejen el contexto real de la empresa, no de un benchmark público que afirme “este modelo es el mejor”.

• El objetivo es justificar esa confianza mediante resultados medibles. El éxito implica definir lo “bueno” en términos concretos y medibles, acordes con las necesidades de la empresa y su tolerancia al riesgo, ya sea precisión factual, tono adecuado, velocidad o eficiencia de costos.

• Al incorporar la evaluación en todo el sistema —instrumentación, registros, pruebas A/B y barreras de protección— y equilibrar el rigor con la eficiencia, los equipos lograrán implementaciones más rápidas y robustas.

La mayoría de las empresas se sienten cómodas permitiendo que sus empleados experimenten con ChatGPT o Gemini. Sin embargo, es menos común poner los LLM a trabajar en flujos o entornos de alto impacto.

Los motivos han sido a menudo válidos: la calidad ha sido inconsistente y el riesgo de alucinaciones o conductas no deseadas ha superado los posibles beneficios de la tecnología.

Ese equilibrio entre riesgo y beneficio cambió considerablemente durante el último año. Aunque parte de ese cambio se atribuye a las mejoras en el rendimiento de los modelos fundacionales, mucho se debe a la creciente rigurosidad de la evaluación (o “evals”). Las evaluaciones nos dan, tanto a nosotros como a nuestros clientes, la confianza para implementar en pocas semanas agentes a gran escala y orientados al cliente.

Esta guía explicará los elementos fundamentales de las evaluaciones y cómo diseñarlas, implementarlas y operarlas 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.

En la base de cualquier estrategia de evaluación hay una pregunta sencilla: ¿cómo se ve lo “bueno”? La respuesta debe ser específica. Para una organización, lo “bueno” puede significar precisión factual dentro de tolerancias estrictas; para otra, puede priorizar la velocidad, la eficiencia de costos o un tono de voz distintivo. Cada restricción aplicable, desde los datos que pueden utilizarse hasta las obligaciones regulatorias, da forma a esta definición.

Es fundamental que lo “bueno” tenga componentes que realmente puedan medirse. Si el éxito consiste en brindar orientación financiera útil, la utilidad debe expresarse mediante atributos: exactitud factual, avisos adecuados, razonamiento personalizado y límites seguros. Una vez que lo “bueno” se define en términos medibles, la siguiente pregunta es cómo analizar e interpretar los resultados. Actuar en función de estos resultados es lo que convierte la evaluación en un método, en lugar de una simple serie de decisiones subjetivas.

Todo flujo de evaluación se apoya en tres pilares interconectados:

1. Entradas/benchmarks: ejemplos representativos del mundo real para medir el rendimiento general y conjuntos de datos internos seleccionados para comprobar la viabilidad en el dominio.

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

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

Las entradas deben representar el mundo con el que se encontrará el sistema. Los hallazgos más valiosos provienen de ejemplos reales: consultas de clientes, situaciones financieras o casos específicos del sector. Solo al probarlo con estos ejemplos se puede saber si el modelo comprende realmente los matices que necesitan los usuarios y satisface la necesidad empresarial.

El comportamiento del modelo —cómo se le proporcionan prompts, se coordinan la recuperación y el uso de herramientas, y se aporta el contexto— importa tanto como el propio modelo. Dos modelos idénticos pueden comportarse de maneras muy distintas según cómo se implementen. Por lo tanto, esta capa debe incluirse en el diseño de la evaluación.

Por último, están las métricas. Los números por sí solos rara vez cuentan toda la historia, pero unas métricas bien elegidas permiten interpretar el comportamiento del sistema. La latencia, la precisión, la seguridad, la coherencia, el sesgo, el costo y la satisfacción del usuario forman en conjunto una imagen multidimensional de un sistema en producción. La clave está en elegir métricas alineadas 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 precisas y económicas, mientras que una mala elección puede inducir a error a los equipos. Así debe plantearse la selección de métricas:

Ejemplos de buenas elecciones de métricas:

• Chatbot de atención al cliente: tasa de resolución en el primer contacto (¿se resolvió el problema del usuario sin escalarlo?), tiempo promedio de atención, puntuación de satisfacción del usuario y tasa de escalamiento a agentes humanos.

• Herramienta de investigación financiera: precisión de las citas (% de afirmaciones con fuentes adecuadas), precisión factual validada frente a datos de referencia, relevancia de la recuperación (¿encontró los documentos correctos?) y coherencia del razonamiento calificada por expertos del dominio.

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

Ejemplos de malas elecciones de métricas:

• Usar solo la longitud de la respuesta como indicador de calidad (más larga ≠ mejor).

• Medir la velocidad sin considerar las concesiones en materia de precisión.

• Dar seguimiento a las puntuaciones de confianza del modelo sin validarlas frente a la exactitud real.

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

Errores comunes de las métricas que deben evitarse:

• Métricas contradictorias: optimizar simultáneamente la velocidad y la exhaustividad sin reconocer la concesión entre ambas.

• Sobreajuste a benchmarks: alcanzar un 95 % en el conjunto de pruebas, pero fallar 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 precisión de su solución de investigación profunda era primordial. Diseñamos conjuntos de datos de preguntas y respuestas elaborados por expertos y los combinamos con otros generados por herramientas. Así pudimos evaluar la precisión, la capacidad del sistema para elegir las herramientas correctas y recuperar la información adecuada, y obtener una perspectiva equilibrada de la precisión y la calidad del razonamiento. La clave fue medir varias dimensiones: precisión factual (validación de expertos), calidad de recuperación (precisión/exhaustividad de los documentos pertinentes) 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 utiliza un segundo modelo de IA como evaluador y sustituye la revisión humana por una puntuación de calidad automatizada y escalable. El enfoque de LLM como juez suele usarse indebidamente cuando métricas más sencillas pueden brindar la precisión necesaria. Puede ser útil cuando las comprobaciones deterministas no captan 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. Es posible que se necesiten comentarios escalables para muchas variantes de prompts y modelos, además de definir 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: exactitud, fundamentación, cumplimiento de políticas, aplicabilidad 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 fallas.

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

• Usa dos jueces o comprobaciones periódicas de consenso en dominios de alto impacto.

• Da seguimiento a la desviación del juez y a la tasa de desacuerdo a lo largo del tiempo.

Un conjunto de datos de benchmark es una colección fija y seleccionada de ejemplos de prueba con respuestas conocidas, que se usa para evaluar modelos de manera consistente y comparar equitativamente los resultados entre versiones. Por lo general, incluye entradas (p. ej., consultas de usuarios), resultados esperados o juicios de referencia, y criterios o etiquetas de evaluación para asignar puntuaciones. Las pruebas de benchmarks públicos se usan para comparar el rendimiento de modelos de última generación y pueden servir como referencia inicial al diseñar el sistema y decidir qué modelo sería conveniente utilizar.

Sin embargo, para tu propio sistema no puedes depender de estos benchmarks como indicadores del rendimiento en tu contexto empresarial, pues presentan problemas conocidos:

• Contaminación: los modelos pueden haberse entrenado con los datos del benchmark; evaluarlos con el mismo conjunto de datos puede ser como calificarlos con una hoja de respuestas.

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

• Alcance limitado: los datos del benchmark no reflejan tus tareas reales, pues están cuidadosamente seleccionados y depurados. Algunos incluso son generados por LLM y no reflejan la complejidad ni los casos extremos presentes en tus datos, como errores tipográficos, giros inusuales o imágenes con ruido.

Un estudiante pide ayuda a la aplicación para resolver problemas matemáticos redactados.

Ejemplo de un benchmark público que puedes usar: GSM8K (razonamiento matemático de nivel escolar).

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

Por qué es útil este benchmark:

• Permite comparar rápidamente qué modelo ofrece un mejor razonamiento matemático general.

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

Por qué aún necesitas tu propio conjunto de datos:

Tu aplicación tiene requisitos que GSM8K no prueba:

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

• El estilo de explicación adecuado para el grupo de edad.

• Cómo abordar preguntas ambiguas o con muchos errores tipográficos.

• Las reglas de las políticas (p. ej., cuándo dar pistas en vez de respuestas completas).

Una validación eficaz depende de crear benchmarks de evaluación específicos para la aplicación. Estos conjuntos de datos deben basarse en interacciones reales, casos extremos habituales y modos de falla plausibles. Esta tarea puede ser difícil al implementar un producto o proceso nuevo. Sin embargo, en la mayoría de los casos es posible recopilar datos de un producto existente o hacerlo tan pronto como sea posible, incluso durante una fase inicial de pruebas. Después de desarrollar la aplicación, estos benchmarks deben evolucionar junto con el producto y volverse más completos y representativos con el tiempo.

La relación entre el benchmark específico de la aplicación y la selección del modelo es fundamental. El benchmark no solo revela si una solución funciona, sino también qué combinación de tamaño de modelo y técnicas de posentrenamiento brinda el rendimiento necesario con la mayor eficiencia de costos. Las mejoras más potentes de los modelos preentrenados —el “PT” de ChatGPT— no provienen de volver a entrenarlos, sino de métodos de “posentrenamiento”.

Estos métodos buscan definir a qué información puede acceder el modelo, cómo se estructura esa información y cómo se guía y coordina el modelo durante la inferencia. Técnicas de posentrenamiento como:

• Prompts de cadena de pensamiento y asignación dinámica de capacidad de cómputo (razonar más para problemas difíciles).

• Autoconsistencia, donde se generan varios resultados y se selecciona el mejor.

• Construcción y coordinación del contexto, como la generación aumentada por recuperación (RAG), ejemplos con pocos ejemplos y 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 eficientemente sobre datos estructurados y no estructurados.

Aunque estas técnicas de posentrenamiento pueden mejorar considerablemente el rendimiento del sistema, también implican concesiones. Cada capa adicional de coordinación, recuperación o razonamiento aumenta la complejidad del sistema, el tiempo de inferencia y los costos operativos. Sin embargo, si se aplican con criterio, la combinación adecuada de técnicas de posentrenamiento suele permitir usar modelos más pequeños, rápidos y económicos sin dejar de cumplir los requisitos de rendimiento. En lugar de aumentar el tamaño del modelo, el rendimiento se consigue 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 permitirán identificar el punto en que una coordinación adicional deja de aportar mejoras importantes, de modo que los equipos puedan elegir el nivel mínimo de complejidad de posentrenamiento necesario para lograr el rendimiento deseado.

Una solución de IA debe concebirse como el sistema completo: bases de datos, API, interfaces de usuario, capas de coordinación, infraestructura de monitoreo y mucho más. Por lo tanto, la evaluación debe abarcar toda la pila tecnológica. Se deben monitorear las partes clave del sistema para mantener la visibilidad de posibles problemas y avanzar de manera responsable.

Monitorear las partes clave del sistema implica:

• Instrumentar los flujos para obtener resultados medibles.

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

• Usar comparaciones A/B sencillas antes de implementar 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 el monitoreo 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 ingresa con request_id, user_segment e intent.

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

• Paso 3: un LLM juez puntúa la respuesta (exactitud, fundamentación y policy_risk).

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

• Paso 5: si se infringe un umbral, activa una alerta y deriva el caso a una alternativa o a revisión humana.

• Paso 6: la falla se agrega a la cola de triaje y luego a la lista de pendientes del benchmark.

Los usuarios reales rara vez se comportan exactamente como esperan los diseñadores. Algunos interpretarán mal las instrucciones. Otros explorarán deliberadamente los puntos débiles. Estos casos extremos no son anomalías, sino señales muy valiosas. Un flujo de evaluación bien implementado los registra, analiza e incorpora en pruebas futuras. La iteración rápida sin puntos ciegos solo es posible cuando la evaluación forma parte integral del sistema, en lugar de añadirse después del desarrollo.

Recomendamos incorporar barreras de protección y monitoreo desde el primer día:

• Da seguimiento periódico a las métricas y regresiones del modelo mediante el benchmark específico de la aplicación.

• Registra y revisa casos extremos o entradas adversarias, y agrégalos al conjunto de datos del benchmark 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 benchmark para asegurarte de no ignorar riesgos nuevos ni estar sujeto a sesgos.

• Implementa alertas automatizadas ante el deterioro de las métricas (p. ej., si la precisión cae por debajo del 85 %, activa una revisión).

• Mantén un proceso de revisión humana para decisiones de alto impacto (asesoría legal, orientación médica y transacciones financieras).

Cada ejecución de un benchmark consume capacidad de cómputo y energía. Cada experimento redundante aumenta los costos. Una evaluación responsable debe equilibrar el rigor y la eficiencia.

Se pueden tomar ciertas medidas prácticas para evitar que el consumo de energía y los costos se disparen:

• Usa modelos más pequeños cuando sea posible, realiza los primeros experimentos con modelos más económicos y aumenta la escala solo después de validar el enfoque.

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

• Usa una programación que considere el consumo energético (procesamiento por lotes, instancias de spot y prioridad flexible).

• Da seguimiento al uso de recursos de cómputo junto con el rendimiento.

Asimismo, mantente atento a las nuevas regulaciones sobre IA. Incluso donde no haya una ley específica, siguen aplicándose los marcos existentes y las medidas necesarias, como las siguientes:

Protección de datos:

• Asegúrate de que los conjuntos de datos de benchmarks no contengan información de identificación personal sin el consentimiento adecuado.

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

• Ofrece mecanismos para solicitar la eliminación de datos.

Igualdad y sesgo:

• Prueba el rendimiento en distintos grupos demográficos.

• Incluye una representación diversa al crear el benchmark.

Derechos humanos y transparencia:

• Documenta claramente para los usuarios las limitaciones del modelo.

• Ofrece explicaciones sobre las decisiones de alto impacto.

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

La evaluación no es un evento aislado, sino un sistema en evolución. En un campo que avanza rápidamente, la ventaja reside en la rapidez con que se pueda probar, aprender y adaptar para implementar modelos y soluciones nuevas con mayor eficacia.

Al incorporar la evaluación como una actividad central de ingeniería y gestión de productos, los equipos pueden innovar con mayor rapidez y seguridad. Primero, define cómo se ve lo bueno en el contexto de tu aplicación de IA; luego, configura una plataforma de evaluación y perfecciónala hasta contar con un benchmark específico de la aplicación que, en cada iteración, te dé confianza en que está lista para producción.