La guía de las AI Evals: cómo testar, medir y monitorizar tus funcionalidades de IA en producción

Desarrollar una funcionalidad de IA es una cosa, pero garantizar que no haga cualquier cosa en producción es otra muy distinta. A diferencia del código convencional, la IA no valida un resultado binario, sino una intención. Entonces, ¿cómo salir del bucle infinito del "ya casi está bien" y evitar que tus usuarios sean tus primeros testers? En este artículo, Kevin Si comparte la metodología de 7 etapas que ha desplegado en una gran plataforma publicitaria para automatizar la evaluación de la IA.

Hoy en día, la mayoría de los equipos de producto saben cómo desarrollar una funcionalidad de IA. La parte que se atasca viene después: ¿cómo saber si lo que genera la IA es realmente bueno?

Un dato para poner el problema en perspectiva: según un informe de la RAND Corporation de 2024, alrededor del 80% de los proyectos de IA fracasan, es decir, el doble de la tasa de fracaso de los proyectos de IT clásicos. En el caso concreto de la GenAI, las tasas de fracaso son incluso más elevadas según las estimaciones de Gartner.

Cuando se testea código convencional, sabemos qué esperar. Un botón muestra una ventana emergente, la respuesta es A, comprobamos que sea A. Con la IA, esa seguridad desaparece. La respuesta nunca será exactamente igual dos veces. Peor aún, en una funcionalidad de IA no verificamos un resultado, sino una intención. Pide a dos personas que valoren la calidad de un texto generado: una verá un 70% de respuestas correctas, la otra un 47%.

Este artículo presenta el método que he desarrollado mediante iteraciones a lo largo de seis meses y que he podido presentar y validar con Google. También lo he aplicado en el ámbito empresarial, en una gran plataforma publicitaria online: generación de texto alternativo, modificación de imágenes y generación de contenido.

El bucle de evaluación IA en 7 etapas: visión general

Antes de detallar cada etapa, esta es la secuencia completa:

1. PRD de IA: definir los casos extremos, los límites de seguridad (entrada, proceso, salida) y el umbral de éxito antes de iniciar el desarrollo.
2. Dataset representativo: el volumen de este conjunto de datos varía según la funcionalidad, y suele oscilar entre unas decenas y unos cientos. Lo más importante es que refleje la diversidad del entorno de producción.
3. Análisis de errores: analizar los primeros resultados de la IA para identificar los modos de fallo específicos de tu dominio, en lugar de aplicar métricas genéricas.
4. LLM-as-a-Judge: crear uno o varios evaluadores especializados y calibrarlos comparándolos con las anotaciones del experto en la materia hasta alcanzar una tasa de validación suficiente.
5. Prueba offline: ejecutar el modelo sobre el conjunto de datos y verificar que se alcanza el umbral definido en el PRD.
6. Observabilidad: deplegar, conectar el LLM-as-judge en tiempo real y monitorizar las puntuaciones, los costes y los registros de interacción.
7. Impacto e iteración: Medir las métricas de negocio y la adopción, combinando datos cuantitativos y cualitativos. Reintroducir los datos reales en el dataset. Y volver a empezar.

Los riesgos de no realizar una evaluación

Antes de entrar en el cómo, unas palabras sobre el por qué. Porque la tentación de lanzar el producto sin evaluar es real, sobre todo cuando tu demo impresiona a todo el mundo.

Esto es lo que les ocurre a los equipos que se saltan etapas:

El bucle infinito del «ya casi está bien»: sin unos KPI explícitos, nos encontramos en un ping-pong permanente entre el desarrollador y el PM. Se hace una demo, decimos "funciona bien, pero aún se ve tal cosa". El desarrollador lo corrige, volvemos a hacer una demostración y encontramos otra cosa. Nunca se sabe en qué momento está lo bastante bien como para pasar a producción. He visto a equipos pasar tres meses en este bucle con funcionalidades que podrían haberse entregado mucho antes si hubieran tenido un umbral claro.

La detección de problemas por parte de los usuarios: sin monitorización automatizada, nos enteramos de los fallos cuando un cliente se queja… es decir, demasiado tarde. Un cambio de modelo, una actualización del prompt que provoca un error en un caso extremo, un nuevo tipo de datos que no habíamos previsto: sin observabilidad, estamos a ciegas. Es imposible iterar sobre la funcionalidad.

La imposibilidad de priorizar: sin un análisis estructurado de los errores, se corrigen los problemas en el orden en que se detectan, no en función de su impacto. Podemos pasar una semana corrigiendo un caso extremo que afecta al 0,5% de los usuarios, mientras que un bug que afecta al 15% de los casos pasa desapercibido.

El coste de poner en marcha un bucle de evaluación es real: calcula entre 2 y 4 semanas para la primera feature. Pero el coste de no hacerlo es sistemáticamente más alto, y se paga en tiempo perdido, en credibilidad y en funcionalidades de IA que terminan desactivándose.

Etapa 1: redactar el PRD con las especificaciones de IA

En la práctica, en el PRD de un producto de IA, hay tres elementos que cobran especial importancia, además de todo lo que se suele hacer habitualmente.

Los casos extremos

Hay muchos más que con código clásico, porque el abanico de posibilidades es más amplio. Si se crea un chatbot conversacional, el usuario puede escribir cualquier cosa. Hay que enumerar estos casos límite desde el principio para aclarar lo que se espera y evitar que dos evaluadores difieran en 20 puntos en la tasa de éxito (los resultados que se consideran buenos).

Las barreras de seguridad

Intervienen en tres niveles:

En la entrada, al verificar lo que envía el usuario. En la plataforma donde trabajaba, no queríamos que una marca utilizara nuestra herramienta de generación de imágenes para procesar fotos familiares. Si eso ocurría, nosotros pagábamos el procesamiento y el usuario obtenía gratis una imagen generada para un uso que no tiene nada que ver con nuestro producto.

En el medio, es decir, en el propio proceso del modelo: cómo procesa el LLM la solicitud, qué instrucciones sigue y qué restricciones se le imponen en el prompt (formato de salida, longitud, idioma, ámbito temático). Ahí es donde delimitados qué puede hacer el modelo y cómo debe hacerlo.

En la salida, verificamos que no se generen resultados indeseados y que el resultado se corresponda con la intención que habíamos definido. Con el código clásico, esperamos una acción concreta. Con la IA, esperamos que el resultado vaya en la dirección correcta, sin poder predecir su forma exacta. En el caso del texto alternativo, la intención es «una descripción fiel del anuncio, con los elementos correctos en el orden adecuado». La barrera de seguridad en la salida comprueba que se respete esta intención: ¿se describe bien el anuncio y no otra cosa? ¿Es correcto el orden de los elementos? ¿No se ha generado un texto fuera de tema?

Un ejemplo concreto de lo que ocurre sin "guardrails": un chatbot de Chipotle que responde a preguntas sobre programación en Python en lugar de tomar pedidos de burritos. El modelo funciona a la perfección, pero también responde a preguntas que no le corresponden.

El umbral de éxito

Este es el aspecto que más eché en falta al principio. La solución: fijar una tasa de éxito objetivo antes de comenzar el desarrollo. Por ejemplo: si obtenemos un 85% de respuestas correctas en nuestros casos de prueba de aceptación, pasamos a producción.

Este umbral depende de la criticidad de la funcionalidad. En el caso del texto alternativo, sabíamos que el usuario podría modificarlo. Antes de nuestra funcionalidad, las marcas ni siquiera rellenaban ese campo. En el peor de los casos, borran lo que generamos y escriben otra cosa: el riesgo es limitado. Por lo tanto, un 70% de éxito ya suponía un verdadero avance.

Sin este umbral, corremos el riesgo de querer mejorar siempre, cuando pasar del 85% al 90% costará infinitamente más que pasar del 0% al 85%. En el fondo, el umbral de éxito es una herramienta de gobernanza. Es lo que pone fin a los debates subjetivos del tipo "a mí me parece que todavía no funciona lo suficientemente bien". Y es lo que permite arbitrar la inversión: ¿dedicamos dos semanas más de desarrollo para ganar 5 puntos o lanzamos el producto e iteramos en producción? Sin umbral, esta decisión es política. Con umbral, es objetiva.

Etapa 2: Construir un dataset de prueba representativo

Para testar de forma fiable, se necesita un conjunto de datos que incluya datos de entrada, los resultados esperados (respuestas correctas e incorrectas) y suficiente diversidad para abarcar la realidad de la producción.

Tomemos un ejemplo concreto. En la plataforma publicitaria en la que trabajaba, las marcas subían creatividades para sus campañas. Desarrollamos una funcionalidad de IA que genera automáticamente el texto alternativo de esas imágenes. En mi PRD, había definido reglas de generación diferentes según el tipo de contenido visual: un anuncio con texto y un logotipo no debía describirse de la misma manera que una imagen que contuviera únicamente un logotipo.

Es precisamente este nivel de granulidad en la especificación el que determina posteriormente la diversidad del dataset de prueba. También necesitábamos anuncios estadounidenses, europeos y asiáticos, en proporciones representativas de lo que recibimos en producción. Porque cada variación del contenido visual es un caso de prueba potencial. Tuvimos la suerte de contar con un equipo dedicado (Product Analytics) que gestionaba esta parte. Es un requisito previo para cualquier producto o funcionalidad basada en IA: disponer de datos de calidad y bien organizados.

Si cuentas con un equipo de datos dedicado, también es posible generar los datos mediante la IA. Si verificas lo que genera la IA y eliminas las alucinaciones, los datos sintéticos siguen siendo mejor que no tener datos. Y si consigues construir un dataset sintético de varios cientos de registros limpios, estamos en una buena posición.

Etapa 3: El análisis de errores

Este es el paso que la mayoría de los equipos se saltan y, sin embargo, es probablemente el que ofrece un mejor ROI.

El análisis de errores consiste en examinar los primeros resultados de la IA, caso por caso, y dejar que emerjan las categorías de error específicas de tu aplicación.

Por qué las métricas genéricas no funcionan

El error más habitual consiste en aplicar métricas procedentes de la investigación académica (alucinación, toxicidad, utilidad) a un producto real. Estas categorías son demasiado amplias para que se puedan utilizar de forma práctica. En mi caso, la etiqueta «alucinación» no me aportaba ninguna información útil. Lo que sí me ayudaba era identificar problemas concretos como: "el modelo ignora el texto incrustado cuando hay un apóstrofo", "el modelo confunde determinados elementos gráficos con logotipos", "el modelo se limita a mencionar la marca en lugar de describir la imagen".

Estas categorías de errores específicos no se pueden adivinar de antemano. Surgen al analizar los datos.

Cómo hacerlo en la práctica

El proceso sigue una lógica inspirada en la investigación cualitativa (open coding y después axial coding).

Open coding. Se leen los registros (entrada + salida de la IA) uno por uno y se anotan los problemas observados. Sin categorías predefinidas, solo observaciones en bruto.

Axial coding. Se agrupan las observaciones similares en categorías. Estas categorías se convierten en los modos de fallo (failure modes) de la aplicación. Son estas métricas las que posteriormente habrá que automatizar mediante un sistema LLM-as-a-Judge, no métricas genéricas.

Re-coding. Se vuelven a revisar las trazas utilizando las categorías refinadas. Se comprueba la coherencia y, si es necesario, se fusionan o dividen categorías

¿Cuántos casos hay que probar? Trabajábamos con 400 casos de prueba. En Atlassian, he oído hablar de conjuntos de datos de más de 500 casos. Pero, en realidad, la cifra absoluta importa menos que la saturación teórica, es decir, el momento en el que cada nuevo error que descubrimos es un error que ya habíamos identificado. Mientras sigan apareciendo nuevas categorías de error, hay que continuar.

¿Quién debe realizar esta tarea? Depende de cada organización. Lo ideal es que sea un experto de dominio con la legitimidad para determinar si un resultado es bueno o malo: un médico para un chatbot sanitario, un abogado para una herramienta jurídica, un analista de precios para una solución de pricing. En los equipos donde existe este perfil, el PM define el proceso y el experto en la materia realiza las anotaciones. En las empresas donde no hay un experto en la materia dedicado, es el PM quien debe hacerlo. Requiere tiempo, pero no es negociable: sin esta etapa, todo lo que viene después se construye sobre una base inestable.

Saturación teórica: cuándo dejar de probar

En investigación, la saturación teórica parte de una idea sencilla: no existe un número universal y absoluto de casos de prueba que garantice resultados concluyentes.

Me explico: a medida que añadimos casos de prueba, llega un momento en que cada nuevo error descubierto pertenece a una categoría ya conocida. Los patrones empiezan a repetirse, ya no se descubre nada nuevo. Ese es el indicador de que hemos cubierto prácticamente todos los escenarios relevantes.

Cuando estaba analizando mis 400 líneas de texto alternativo, me di cuenta de que, tras unos cien casos, había alcanzado la saturación. Había identificado los patrones de error recurrentes: cuando la imagen contenía un texto con un apóstrofo, el modelo nunca lo tenía en cuenta; cuando había un parche en la imagen, el modelo lo interpretaba como un logotipo e ignoraba el texto incluido en él… Y así sucesivamente. Aun así, probé las 400 líneas, pero no encontré nuevas categorías de errores.

Es el mismo principio que se aplica a las entrevistas a usuarios bien orientadas: al cabo de cinco o seis entrevistas, se vuelven a encontrar los mismos problemas. Lo que importa es más la diversidad de los casos cubiertos que el volumen bruto.

Qué implica para las siguientes etapas

El análisis de errores determina qué va a evaluar el LLM-as-a-Judge.Sin esta fase, construiremos un juez que verifica las cosas equivocadas. Es la diferencia entre un test unitario que valida aquello que realmente se rompe y otro que comprueba aspectos que nunca fallan.

Etapa 4: automatizar la evaluación con un LLM-as-a-Judge

El análisis de errores funciona. Pero no es escalable. Comprobar 100 casos uno por uno me llevaba medio día. En producción, con miles de usuarios al día, es imposible mantener ese ritmo. Y, sobre todo, una vez que la funcionalidad está en producción, hay que poder detectar un deterioro rápidamente, no tres semanas más tarde, cuando a alguien se le ocurra volver a realizar una comprobación manual. Ahí es donde entra en juego el LLM as a Judge.

La idea es sencilla. En lugar de comprobar yo mismo línea por línea si cada resultado es correcto, delego esta tarea a otro LLM. Ejecutamos la funcionalidad de IA sobre cada elemento del dataset y el juez evalúa automáticamente si la respuesta es correcta o no, según los criterios definidos en su prompt.

En comparación con la anotación manual, la ventaja es doble. En primer lugar, en cuanto al volumen: donde yo apenas podía revisar 100 casos en media jornada, el "juez" puede procesar miles en pocos minutos. En segundo lugar, en cuanto a la continuidad: el "juez" puede funcionar de forma permanente en producción. Genera una puntuación (por ejemplo, entre 0 y 1) y, si un día esa puntuación cae de 0,95 a 0,70, lo detectamos inmediatamente. Se puede rastrear la causa: una modificación del prompt, un cambio de modelo, un nuevo tipo de datos que no habíamos previsto. Sin esta monitorización, estamos a ciegas. Descubrimos los problemas cuando un cliente se queja, es decir, demasiado tarde.

Por eso, el LLM «as a Judge» se crea antes del desarrollo de la funcionalidad y no después. En cuanto el desarrollador entrega una primera versión, podemos probarla automáticamente en todo el conjunto de datos, en lugar de pasar medio día comprobando 100 casos a mano. Y el día del despliegue, el sistema de evaluación ya está preparado para funcionar en producción.

Cómo estructurarlo

El LLM-as-a-Judge no tiene por qué ser un único prompt monolítico. De hecho, es recomendable dividirlo en varios jueces especializados. En el caso de la funcionalidad para el texto alternativo:

• Un juez que verifica el orden de los elementos en la descripción.
• Un juez que comprueba la coherencia general.
• Un juez que revisa la longitud del texto.

La ventaja de esta división es que algunos jueces son reutilizables. Por ejemplo, el juez encargado de validar el número de caracteres podría emplearse en otras funcionalidades sin necesidad de modificaciones.

La anotación manual: calibrar el criterio

La anotación manual funciona. Pero no es escalable. Comprobar 100 casos uno por uno me llevaba medio día. En producción, con miles de usuarios al día, es imposible mantener ese ritmo.

El principio

En lugar de verificar personalmente línea por línea si cada resultado es correcto, delego ese trabajo en otro LLM. Ejecutamos la funcionalidad de IA sobre cada elemento del dataset y el juez evalúa automáticamente si la respuesta es correcta o no, según los criterios definidos en su prompt.

¿Por qué confiar más en el juez que en la propia funcionalidad? Porque evaluar (¿es correcta esta respuesta, sí o no?) es una tarea más sencilla que generar (produce la respuesta correcta). Con un modelo equivalente, un LLM es mejor para discriminar que para crear. Y como la evaluación se realiza offline, podemos utilizar un modelo más potente que el empleado por la funcionalidad sin preocuparnos por la latencia.

La ganancia es doble. Por un lado, el volumen: donde yo apenas podía revisar 100 casos en media jornada, el juez puede procesar miles en cuestión de minutos. Por otro, en continuidad: el juez puede ejecutarse permanentemente en producción. Genera una puntuación y, si esta cae, lo detectamos de inmediato.

Cómo estructurarlo

El LLM-as-a-Judge no es un único prompt monolítico. Se puede (y se debe) dividir en varios jueces especializados, cada uno centrado en un único modo de fallo identificado durante el análisis de errores. En el caso del texto alternativo:

• Un juez que verifica el orden de los elementos en la descripción.
• Un juez que comprueba la coherencia general.
• Un juez que revisa la longitud del texto.

La ventaja de este enfoque es doble:

• Algunos jueces pueden reutilizarse en otras funcionalidades sin modificaciones.
• Cuando una puntuación cae, sabemos inmediatamente qué aspecto está generando el problema.

Algunas buenas prácticas derivadas de investigaciones recientes sobre los LLM judges:

• Limitar las evaluaciones a decisiones binarias (Pass / Fail) en lugar de utilizar escalas tipo Likert. Los LLM son poco fiables generando puntuaciones consistentes en escalas de 1 a 5.
• Incluir ejemplos (few-shot) claros de casos válidos y no válidos dentro del prompt del juez.
• Añadir rúbricas detalladas (definiciones precisas de lo que constituye un Pass y un Fail) para reducir la ambigüedad.
• Utilizar un formato de salida estructurado (por ejemplo, JSON) para facilitar el procesamiento automático.
  

   

Calibrar el juez mediante anotaciones humanas

Antes de confiar en el juez, hay que calibrarlo. El proceso es el siguiente: el desarrollador ejecuta el modelo sobre todo el conjunto de datos y genera una hoja de cálculo con la entrada y la salida. A continuación, el experto de dominio revisa cada línea. Este experto es la persona legitimada para juzgar si un resultado es correcto o incorrecto. En muchos casos será el propio PM, aunque también puede ser un médico para una solución sanitaria o un abogado para una herramienta jurídica.

Una vez realizadas estas anotaciones, se añade una columna: la puntuación que el LLM-as-a-Judge ha otorgado a cada registro. Se comparan los resultados. En los casos donde aparecen discrepancias, reajustamos el prompt del juez.. Se trata de un ciclo iterativo: ajustamos, volvemos a ejecutar, comparamos, y repetimos hasta obtener una tasa de validación suficientemente alta.

Las tres métricas que hay que seguir para evaluar la fiabilidad del juez:

• TPR (True Positive Rate): cuando el resultado es realmente correcto, ¿el juez lo identifica como correcto? Es la métrica más importante de maximizar.
• TNR (True Negative Rate): cuando el resultado es incorrecto, ¿el juez lo detecta?
• MCC (Matthews Correlation Coefficient): es la métrica más importante. Evalúa la calidad de las clasificaciones binarias y varía entre -1 y +1. Una puntuación de +1 representa una predicción perfecta, 0 una predicción aleatoria media y -1 una predicción inversa.

Nunca se alcanzará un 100% de alineamiento entre humanos y juez. Pero cuando nos acercamos al 90%, podemos confiar razonablemente en que el juez opere de forma autónoma.

Gestionar la imperfección de una funcionalidad de IA

Una funcionalidad de IA cometerá errores. La cuestión no es cómo eliminarlos, sino cómo diseñar la experiencia para que esos errores no supongan un problema para el usuario.

En nuestro caso aplicábamos diferentes mecanismos según la funcionalidad. Para la generación de imágenes, ofrecíamos tres variantes y el usuario elegía la que más le convenía, con un botón para volver a generar si ninguna de las tres le convencía. En cuanto al texto alternativo, el texto generado se podía modificar: si el usuario no estaba de acuerdo, hacía clic y lo corregía manualmente. En ambos casos, se mostraba un mensaje advirtiendo de que el resultado podía ser imperfecto.

El punto en común de estos enfoques es sencillo: el usuario mantiene el control. No se le presenta el resultado de la IA como una verdad absoluta, sino que se le ofrece un punto de partida que puede ajustar. Se trata de una diferencia fundamental de enfoque en el diseño del producto.

Etapa 5: Supervisar la funcionalidad en condiciones reales (observabilidad)

Por muy bien construido que esté un dataset de prueba, sigue siendo una aproximación de la realidad. En producción, nos enfrentamos a usuarios reales con datos reales, y las discrepancias entre lo que habíamos previsto y lo que realmente ocurre aparecen muy rápido. Por eso, lo primero que hay que poner en marcha tras el despliegue es la observabilidad, incluso antes de analizar las métricas de negocio.

En concreto, supervisábamos tres aspectos:

• Las puntuaciones del LLM-as-a-Judge en tiempo real. Utilizamos el mismo juez empleado durante la fase de pruebas. 

  La diferencia es que ahora se ejecuta continuamente sobre una muestra de datos reales (normalmente entre el 1 % y el 5 % del tráfico, procesado de forma asíncrona). Una caída en la puntuación es la primera señal que hay que investigar. 

• Los costes de uso del modelo. Si los usuarios regeneran resultados con frecuencia, la factura sube, y eso suele ser síntoma de que la funcionalidad no ofrece un resultado satisfactorio a la primera.
• Los logs de interacción. Analizamos cómo utilizan realmente los usuarios la herramienta. Además, estos logs alimentan el dataset que utilizaremos en futuras iteraciones.

Siempre recomiendo trabajar primero esta capa de observabilidad antes de analizar el impacto de negocio, porque si la funcionalidad no funciona correctamente con datos reales, cualquier métrica de negocio será engañosa.

¿Cómo se aplica la observabilidad en la práctica?

Todo lo que acabo de describir (puntuaciones, costes, registros) requiere una herramienta que lo centralice. Personalmente, utilizo Langfuse. Existen otras plataformas que centralizan la observabilidad de las funciones de IA: LangSmith, Arize, Weave (W&B), DeepEval… Lo importante es disponer de un único lugar que ofrezca una visión general por funcionalidad de IA con los registros, las puntuaciones y los costes.

Un aspecto que a menudo se pasa por alto: la deriva de los criterios de evaluación. Los criterios de evaluación de los LLM pueden desviarse con el tiempo, debido a actualizaciones del modelo subyacente o a cambios en tus criterios de calidad. Es necesario fijar las versiones de los modelos utilizados para la evaluación y volver a validar periódicamente los criterios de evaluación comparándolos con anotaciones humanas recientes.

Algunas funcionalidades prácticas de estas herramientas:

Registros. Cada interacción del usuario se registra como una secuencia lógica: la acción desencadenada, el prompt enviado al modelo y el resultado recibido. Esto permite reconstruir exactamente lo que ocurrió en un caso concreto y recuperar datos reales para enriquecer el dataset.

Puntuación de evaluación. La puntuación del LLM-as-a-Judge, complementada con otras métricas nativas de la plataforma.

Coste de funcionamiento. El coste de funcionamiento desglosado por funcionalidad y por proyecto. Permite identificar rápidamente cuánto cuesta una funcionalidad determinada y cuál es su nivel de calidad.

Gestión de prompts. Todavía he utilizado esta funcionalidad, pero su potencial es enorme. Se trata de un sistema de control de versiones de prompts, algo parecido a Git, pero aplicado a las instrucciones que se dan al modelo. En la práctica, por ejemplo, permite realizar una prueba A/B entre dos versiones de un prompt y comparar sus resultados.

Depuración. La parte técnica. Acceso a logs detallados que ayudan a entender por qué algo ha fallado cuando una funcionalidad deja de comportarse como debería.

La trampa de la monitorización pasiva

Incluso con verificadores automatizados bien calibrados, hay que seguir revisando manualmente registros aleatorios.Los jueces automáticos solo detectan los modos de fallo que hemos programado explícitamente. Los nuevos tipos de errores, aquellos que no habíamos previsto, solo aparecen cuando observamos directamente los datos. Es una inversión de tiempo constante, pero es lo que evita que la calidad se deteriore de forma silenciosa.

Etapa 6: Medir el impacto real en el negocio y en el uso

Una vez que sabemos que la funcionalidad funciona correctamente en producción, podemos centrarnos en lo que realmente aporta.

La diferencia entre métricas de IA y métricas de producto

Es un punto crítico que suele confundirse:

• Las métricas de evaluación de la IA (puntuaciones de los jueces, tasa de éxito, etc.) miden si la IA hace bien lo que se le pide.
• Las métricas de producto (adopción, satisfacción, impacto en el negocio) miden si lo que hace la IA aporta valor al usuario y al negocio.

Podemos tener métricas de IA excelentes y un producto que no funciona: la IA hace lo que se le pide, pero lo que se le pide no resuelve el problema del usuario. Lo contrario también es cierto: unas métricas de producto al alza pueden ocultar una IA cuya calidad se está degradando.

Lo que medíamos en la práctica

En la plataforma publicitaria, hacíamos un seguimiento de la adopción de la funcionalidad (cuántos usuarios la activaban y cuántos la utilizaban habitualmente), la tasa de modificación tras la generación (si el 80 % de los usuarios modifica el texto generado, es una señal de calidad insuficiente) y el coste por uso (que, combinado con la tasa de regeneración, daba el coste real de un "buen" resultado de la IA). También teníamos botones de "me gusta" y "no me gusta" en la interfaz. Algo sencillo, pero que ofrece una señal inmediata.

Dimensiones importantes, pero a menudo ignoradas

¿Quién establece el umbral de éxito?

El PM dice 85%, el CTO quiere 95% y negocio quiere lanzar el producto la semana que viene. Sin un proceso claro, el umbral se convierte en un terreno de negociación política en lugar de una decisión sobre el producto.

Mi recomendación: en nuestro caso, el umbral lo define el PM en colaboración con el experto en la materia, lo valida la dirección y se documenta en el PRD antes del desarrollo. Una vez fijado, se necesita un consenso explícito para modificarlo. De lo contrario, acabamos moviendo la portería en cada demo. Definid una matriz RACI clara para establecer el papel de cada persona.

La demo funciona bien, no necesitamos evaluar

Es el escenario más habitual y es normal; así es como todas las empresas empiezan con las funcionalidades de IA. Un stakeholder ve una demo impresionante y quiere lanzarla al mercado de inmediato. El problema es que una demo son cinco casos cuidadosamente seleccionados. La producción, en cambio, son 5.000 casos al día que nadie ha seleccionado y que todo el mundo quiere intentar llevar al límite.

Es cierto que la configuración inicial de la observabilidad y el aprendizaje de todas las etapas requiere algo de tiempo. Pero después, desarrollaréis tan rápido como si no estuvierais evaluando, con un nivel de confianza y fiabilidad mucho mayor.

El coste real de la evaluación

Implementar todo este ciclo lleva tiempo.

Para una primera funcionalidad, hay que contar con entre 2 y 4 semanas de trabajo conjunto entre PM y desarrollo.

Pero toda esa infraestructura es reutilizable. El segundo producto basado en IA se desarrollará mucho más rápido porque ya tendréis en marcha: el sistema de LLM-as-a-Judge, las herramientas de observabilidad, los procesos de anotación, el mecanismo de ejecución del dataset sobre la funcionalidad.

Se trata de una inversión inicial, no de un coste recurrente por cada nueva funcionalidad.

Al principio, tampoco seas demasiado dogmático. Es posible que ya tengas funcionalidades de IA en producción, no esperes a que todo esté perfectamente montado, empieza por el análisis de errores y haz pruebas manuales tú mismo. Eso ya os aportará una gran cantidad de aprendizajes e insights.