LLM evaluation: cómo demuestras que una función de IA funciona

Lanzar una función con un LLM en un fin de semana es hoy la parte fácil. Saber si funciona de verdad, con las preguntas que hacen tus usuarios reales y no las cinco que probaste tú mismo, es lo que decide si sobrevive al contacto con producción. Para eso sirve LLM evaluation: una forma de comparar la respuesta de un modelo con algo más fiable que la sensación de un fundador después de una buena demo. La mayoría de los equipos se saltan este paso hasta que algo falla delante de un cliente, y para entonces arreglarlo cuesta un ticket de soporte, un reembolso o, peor, un titular. Un sistema de evaluación real puede ser ligero. Tiene que existir antes del lanzamiento, y tiene que volver a correr cada vez que cambia el prompt o el modelo que hay detrás.

Un fundador que acaba de lanzar un MVP en un par de días conoce esa sensación: la demo funcionó, todo el mundo respira tranquilo y todavía nadie ha intentado romperla. Nuestra guía sobre cómo construir un MVP en 2 días con ingeniería de IA cuenta cómo los equipos se mueven a esa velocidad. Que el desarrollo sea rápido no dice nada sobre si la salida es precisa. Las métricas de LLM evaluation existen porque un modelo de lenguaje no falla como falla el software normal. Un botón roto funciona o no funciona. Un modelo puede responder bien ocho de cada diez preguntas y estropear las otras dos sin que nadie lo note, de formas que a nadie se le ocurrió probar. La revisión manual detecta los fallos obvios y luego se desmorona pasado un puñado de ejemplos, porque dos revisores muchas veces no se ponen de acuerdo sobre si una respuesta vale. La evaluación forma parte de la construcción desde el primer prototipo. Una función que nadie midió es una función en la que confías por fe.

Las métricas offline corren contra un conjunto fijo de ejemplos antes de que nada llegue a un usuario, repartidas en varias familias reales, cada una responde una pregunta distinta sobre la salida. La puntuación por coincidencia exacta o similitud mide cuánto se parece una respuesta a una referencia, útil para una etiqueta de categoría o un campo extraído, y pierde fuerza en cuanto dos respuestas pueden verse totalmente distintas y ser igual de correctas. Las métricas de fidelidad y groundedness importan sobre todo cuando una función trae contexto externo: un bot de soporte que lee tu documentación, una herramienta que cita un informe. Comprueban si la respuesta se ciñe a lo que recuperó, en vez de derivar hacia algo que suena plausible pero no está en la fuente. Nuestra guía sobre RAG frente a fine-tuning explica cómo esa decisión de arquitectura cambia lo que ve un modelo cuando responde. Vale la pena decirlo sin rodeos: la puntuación de un benchmark público, esos números de leaderboard al estilo MMLU que publican los proveedores, casi no te dice nada sobre tu caso. Esos benchmarks miden capacidad general en preguntas que nadie te pidió resolver. Un eval set construido con las preguntas reales de tus usuarios le gana a cualquier posición en un leaderboard.

La revisión humana es la señal más fiable que tienes, y la menos escalable. Una persona que lee una respuesta capta matices que ninguna puntuación automática pilla: un tono correcto pero fuera de marca, un dato sutilmente equivocado que solo un especialista notaría. Revisar a mano cada respuesta en producción exige un equipo que nadie presupuesta en la etapa de MVP. LLM-as-judge llena ese hueco: un segundo modelo puntúa la salida del primero contra una rúbrica que tú escribes. Es rápido, barato y escala a un volumen que ningún panel humano igualaría. También arrastra sesgos reales: los modelos jueces favorecen respuestas largas y con tono seguro, aporten algo o no (sesgo de verbosidad), y a veces puntúan mejor a su propia familia de modelos que a respuestas igual de buenas de otros (sesgo de autopreferencia). Calibra LLM-as-judge antes de confiar en él: puntúa con tu modelo juez un lote de ejemplos etiquetados por humanos, comprueba cuántas veces coinciden los dos, y apóyate en la puntuación automática en cuanto siga el criterio humano.

El mejor eval set sale de preguntas que hicieron usuarios reales: registros de soporte, transcripciones de chat, conversaciones del grupo beta en cuanto tengas tráfico del que tirar. Un set que escribiste tú solo en una tarde, afinado para que la demo luzca bien, solo cubre el puñado de cosas que se te ocurrió probar. Busca variedad de verdad: preguntas típicas, casos límite, preguntas ambiguas y alguna cerca de quedar fuera de alcance, porque saber cuándo un modelo debe declinar importa casi tanto como saber cuándo debe responder. Entre treinta y cincuenta ejemplos bien elegidos es un punto de partida realista en la etapa de MVP, y ese número crece según el tráfico de producción va sacando a la luz fallos que nadie predijo. Etiqueta cada ejemplo con el aspecto de una buena respuesta. Un simple sí o no esconde la razón detrás de un fallo. Una rúbrica que una persona, o un modelo juez calibrado, pueda usar para puntuar aguanta mejor con el tiempo.

Un cambio de prompt que arregla un fallo puede romper otros tres sin que te des cuenta, simplemente porque no los estabas probando. Trata tu eval set como un equipo de backend trata su suite de tests: corre la evaluación antes de lanzar un cambio, antes de que un usuario reporte algo raro. Esto importa incluso cuando tú no tocaste nada. Un proveedor que despliega un nuevo modelo por defecto detrás de una API puede cambiar el comportamiento de tu función de un día para otro, sin que muevas una línea de código. Los equipos que fijan una versión y aun así ven cambios de comportamiento suelen estar viendo cómo el proveedor retira el modelo antiguo en favor de uno nuevo con costumbres distintas. Automatiza la corrida de regresión si puedes. Un script que puntúa tu eval set y marca cualquier cosa por debajo de un umbral detecta más que una persona que se acuerda de revisar de vez en cuando. Mantén un registro breve de cambios y puntuaciones. Se convierte en el único historial real de qué ajustes de prompt sirvieron.

Los evals offline corren contra un conjunto fijo. La producción corre contra todo lo demás, las preguntas que nadie anotó antes del lanzamiento. Un puñado de señales detecta lo que los evals se pierden: más respuestas muy cortas o muy largas, un pico de respuestas tipo 'no lo sé', y alguien que repite la misma pregunta dos veces seguidas, casi siempre señal de que la primera respuesta no dio en el clavo. Los botones de pulgar arriba o pulgar abajo recogen feedback real, pero hay que ponderarlos con cuidado. La mayoría de los usuarios no hace clic en nada aunque una respuesta les decepcione, así que un flujo escaso de valoraciones esconde más fallos de los que muestra. Vigilar la calidad es un eje. Vigilar el mal uso es otro, y una función que recibe input de usuarios o acceso a herramientas necesita los dos vigilados a la vez. Nuestra guía para prevenir prompt injection cubre el lado de seguridad: guardrails que evitan que un input manipulado lleve al modelo a donde no debe.

Hay un puñado de errores que aparecen en casi todos los setups de evaluación que revisamos.

• Evaluar a ojo. Un revisor le echa un vistazo a diez salidas, decide que se ven bien, y da la función por probada. Diez ejemplos no son una muestra de nada.
• Probar solo el camino feliz. Los usuarios reales escriben con erratas, hacen preguntas ambiguas e intentan romper las cosas a propósito. Un eval set que se salta esos casos aprueba una función que falla en la primera semana.
• Confiar en una sola puntuación agregada. Una tasa de aciertos del 85 por ciento esconde qué 15 por ciento está fallando, a menudo la parte que más le importa a un segmento de clientes.
• Dejar que el eval set se quede desactualizado. Un set construido en el lanzamiento y nunca actualizado deja de reflejar el uso real en cuestión de meses.
• Saltarse la calibración humana de una puntuación de LLM-as-judge. Un juez automático que nunca se contrastó con una persona es una suposición disfrazada de número.

Evaluar una función en etapa de MVP necesita una lista corta de preguntas reales, una forma de puntuarlas y la disciplina de volver a correr esa puntuación cada vez que algo cambia. Un equipo de investigación y un presupuesto grande de herramientas pueden esperar. Un setup que aguanta se parece a esto:

• De 30 a 50 preguntas reales sacadas del uso, el feedback o los tickets de soporte, con más peso en los casos límite
• Una rúbrica simple (pasa o no pasa, más una razón breve) puntuada a mano al principio
• Una pasada de LLM-as-judge calibrada contra esa ronda humana, revisada de nuevo cada pocos meses
• Una corrida de regresión enganchada a tu proceso de despliegue, o como mínimo ejecutada antes de cada cambio de prompt o de modelo
• Un chequeo ligero en producción: longitud de las respuestas, tasa de rechazo y una forma de marcar una mala respuesta

Ninguna métrica por sí sola garantiza una función perfecta. Los evals detectan lo que está roto antes de que lo note un cliente, y demuestran que un arreglo funcionó de verdad. Si estás definiendo el alcance de una función con LLM y quieres que la evaluación esté integrada desde el primer día, escríbele a nuestro equipo de integración de IA para dimensionar el setup según la función.