Evals de LLM en la práctica: cómo probar funciones de IA antes que los usuarios
El primer fallo vergonzoso de una función de IA rara vez parece un fallo de benchmark. Parece un bot de soporte aplicando la política equivocada, un asistente de código tocando un archivo prohibido o un copiloto de ventas inventando un dato porque el CRM estaba vacío. La demo funcionó. El prompt parecía correcto. Luego un usuario real encontró el caso que nadie probó.
Para eso sirven las evals de LLM: no para perseguir rankings, sino para convertir expectativas de producto en pruebas repetibles, puertas de regresión y revisión humana.
Por qué las evals de LLM no son QA normal
En QA tradicional se espera una salida concreta para una entrada conocida. En productos con LLM puede haber varias respuestas aceptables. La rúbrica debe seguir el riesgo: consistencia factual, completitud, tono, refusals, selección de herramientas, permisos, recuperación y cuándo detenerse. Nuestra pieza sobre fiabilidad de agentes de IA lo resume bien: el producto no es solo el output, sino los controles alrededor.
Crea un golden dataset antes de tocar el prompt
Un golden dataset reúne casos realistas con comportamiento esperado, notas de scoring y metadatos. Empieza con 50 a 200 ejemplos: tareas frecuentes, fallos caros y edge cases incómodos. Para soporte, incluye tickets enfadados, idiomas, información incompleta y escalaciones. Para herramientas de desarrollo, incluye bugs pequeños, refactors ambiguos, tests rotos y límites de permisos.
Guarda tipo de tarea, riesgo, fuentes necesarias, acciones permitidas y motivo de aprobado o fallido. El artículo práctico de Hamel Husain sobre LLM evals es útil porque prioriza ejemplos del producto y juicio humano frente a benchmarks abstractos.
Compara prompts y modelos como experimentos de producto
Usa el mismo dataset para el prompt de producción, el prompt candidato y el modelo candidato. Mira resultados por tarea, idioma, riesgo y segmento, no solo el promedio. ChainForge ayuda a comparar prompts y respuestas; Vellum ofrece workflows de prompts, evals y despliegue; DeepEval es un framework open source para probar aplicaciones LLM.
Registra versión de prompt, modelo, retrieval, schema de herramientas, temperatura e instrucciones del sistema. Esto es crítico en workflows multi-modelo como los de nuestro artículo sobre desarrollo de software con LLMs.
Lleva puertas de regresión a CI/CD
Convierte una parte pequeña del golden dataset en smoke tests: consejos peligrosos, JSON roto, tool calls prohibidos, alucinaciones severas y casos donde la escalación es obligatoria. Todo PR que cambie prompt, modelo, retrieval, schema o routing debe ejecutar esas evals. Los fallos de alto riesgo bloquean; los movimientos menores pueden advertir.
Empieza con checks deterministas: schema válido, citas requeridas, acciones prohibidas, refusals y elección simple de herramientas. Después añade rúbricas o LLM-as-judge para tono, utilidad y completitud. Para agentes, toma patrones de MCP en producción y automatización web tipo Operator: logs de herramientas, errores clasificados, schemas versionados y pruebas de rutas de fallo.
La revisión humana convierte fallos en mejores tests
Las evals envejecen. Revisa outputs, quejas, escalaciones y near misses. Etiqueta tipos de fallo: contexto faltante, herramienta incorrecta, afirmación sin fuente, mal tono, acción insegura, fuente obsoleta, exceso de refusal o falta de refusal. Luego promueve los mejores ejemplos al golden dataset.
PMs y expertos de dominio deben participar, sobre todo en casos de alto riesgo. Si ya tienes dashboards de agentes, conecta fallos de eval con ese flujo; nuestro embudo de operaciones de agentes ofrece una forma práctica de verlo.
Cuándo ayudan las evals abiertas tipo juego
La mayoría de equipos debe empezar con golden datasets y gates. Las simulaciones abiertas valen la pena cuando la función necesita planificación larga, recuperación o muchos pasos con herramientas. Factorio Learning Environment usa Factorio para evaluar agentes que planifican, recolectan recursos, construyen y se adaptan. No hace falta para un FAQ bot, pero puede ayudar en agentes de navegador, coding u operaciones.
Las buenas evals no vuelven perfecto un producto de IA. Hacen visibles los riesgos antes de que los descubran los usuarios. Los equipos maduros saben qué fallos importan, detectan regresiones temprano y mantienen humanos en el loop donde hay juicio y responsabilidad.