Cómo Construir una Suite de Evaluación de IA para un Producto Vertical

Una suite de evaluación de IA es un conjunto versionado de casos de prueba etiquetados por expertos más evaluadores automáticos que califican la salida del modelo en cada deploy y en cada cambio de prompt o de modelo. Así la calidad se mide, no se adivina. Con una buena suite usted cambia a un modelo más barato o mejor sin rezar. Sin ella, cada cambio es una apuesta cuyas probabilidades usted no alcanza a ver.

Este es el playbook de construcción, el compañero práctico de nuestro argumento sobre por qué los evals específicos de dominio son un moat. Avante Ventures es un venture studio que construye empresas AI-native en Brasil y América Latina, y cada producto que lanzamos corre sobre una suite como esta. Aquí está como armar el golden set, escribir los evaluadores, conectar todo a su gate de deploy y convertirlo en un activo que se compone con cada uso del producto.

Cuando necesitas una suite de evaluación, y cuando bastan las pruebas

Una suite de evaluación no es una suite de pruebas, y tratarlas como lo mismo es el primer error. Las pruebas unitarias afirman un comportamiento determinista. Dada la entrada X, la función devuelve exactamente Y, siempre. La salida de un LLM es probabilística y abierta, así que la pregunta real no es si devolvió la cadena exacta, sino si acertó con suficiente frecuencia en los casos que importan. Anthropic enmarca la disciplina como definir primero los criterios de éxito y solo entonces diseñar evaluaciones para medir contra ellos, y llama a ese ciclo central para la ingeniería de prompts.

Usted necesita una suite en el momento en que un LLM entra en una ruta de decisión que le importa a un usuario o a un regulador. Clasificar un escrito legal. Poner precio a un riesgo. Extraer un número de un documento. Responder un ticket de soporte que carga una consecuencia de política. No la necesita para generación de bajo riesgo donde un humano ya revisa cada salida. La señal es simple. Si no puede cambiar un prompt sin un miedo silencioso de haber roto algo que no ve, ya pasó el punto en que revisar las salidas a ojo alcanza, y está operando por intuición.

El reporte DORA de 2024 le pone números duros a esa intuición. En el estudio, un aumento de 25% en la adopción de IA vino acompañado de una caída estimada de 1,5% en el rendimiento de entrega de software y de 7,2% en la estabilidad de la entrega, aun cuando la IA elevó señales individuales como la calidad de documentación y de código. Los autores son directos al decir que la IA no es una panacea, y que desarrollar más rápido no mejora la entrega sin lo básico, lotes pequeños y disciplina de pruebas. Una suite de evaluación es esa disciplina de pruebas para la capa de IA. Es lo que permite conservar la velocidad sin devolverla en inestabilidad.

Construye la suite de evaluación de IA en cinco pasos

Este es un flujo que usted empieza esta semana, no una lista de capacidades. El orden importa, porque cada paso es inútil sin el anterior.

• Arme un golden set. Reúna de 50 a unos cientos de casos reales de su distribución de tarea, cada uno con la respuesta correcta etiquetada por un experto de dominio, nunca por el modelo. Incluya los difíciles a propósito. Ese conjunto codifica su definición de correcto, y es lo más valioso que va a construir.
• Escriba evaluadores. Un evaluador es código que califica una salida contra su respuesta de referencia. Coincidencia exacta para tareas categóricas, un juez modelo puntuado por rúbrica para las abiertas, con desempate humano donde el juez y la etiqueta difieren.
• Mida una línea base. Corra el prompt y el modelo actuales contra el conjunto entero y registre el número. Exactitud, F1, tasa de acierto, lo que aplique. Esa línea es lo que todo cambio futuro tiene que superar o mantener.
• Conéctela a la CI como gate. Corra la suite en cada pull request y cada deploy, y rompa el build cuando la nota caiga por debajo de la línea base. La calidad deja de ser opinión y se vuelve condición de merge.
• Cierre el ciclo. Cada falla de producción que la suite no atrapó entra al golden set con su etiqueta correcta. La suite se vuelve un registro vivo de cada forma en que el sistema ha estado equivocado, y de cada regresión que ahora bloquea para siempre.

Eligiendo evaluadores y reuniendo casos difíciles

Empareje el evaluador con la tarea. Anthropic ordena tres familias por velocidad y confiabilidad, y ese orden es un buen valor por defecto. La evaluación por código es la más rápida y confiable, una coincidencia exacta donde la salida es igual a la referencia, o una coincidencia de cadena donde una frase clave debe aparecer. La evaluación humana es la más flexible y de mayor calidad, y también la más lenta y cara, así que la evita cuando puede. La evaluación por modelo, donde un LLM juzga la salida contra una rúbrica, es rápida, flexible y escalable, y la herramienta correcta para juicios sutiles, pero se valida contra etiquetas humanas antes de confiar en ella a escala. OpenAI entrega el mismo formato en su framework abierto de evals, datos en JSON y plantillas de evaluación por modelo.

La rúbrica es donde el juez modelo vive o muere. Hágala detallada y empírica, fuerce un veredicto discreto de correcto o incorrecto o una nota de 1 a 5 en lugar de texto libre, y pídale al juez que razone primero y luego descarte el razonamiento, lo que mejora de forma medible la nota en los casos difíciles. Use un modelo distinto para evaluar del que generó la salida.

Los casos difíciles son el punto entero, y son donde la experiencia de dominio le gana a la astucia del modelo. Un equipo genérico escribe casos fáciles que el modelo ya pasa. Un operador de dominio conoce el escrito que parece rutinario pero no lo es, la condición de borde que un regulador sí castiga, la entrada que un competidor falla. Reúna esos casos de los logs reales de producción, de entrevistas con expertos y de los incidentes que ya costaron caro. Puede dejar que el modelo ayude a generar volumen, pero las etiquetas de los casos que importan siguen siendo humanas y expertas.

Conecta las evaluaciones al gate de deploy

Una suite que corre cuando alguien se acuerda no es un gate. Ponga la suite en la CI para que corra automáticamente en cada pull request y bloquee el merge cuando la nota caiga por debajo de la línea base que registró. Ahora un ajuste de prompt que en silencio cuesta tres puntos de exactitud no puede subir, porque el build se pone rojo antes de que alguien discuta.

Esto solo funciona si usted versiona lo que está en el gate. Trate el prompt como código fuente, con commit y comparable en diff, y fije el nombre y la versión del modelo junto a él. Cuando cambia uno de los dos, la suite califica el cambio contra la línea base y le dice qué costó o qué compró. Esa es la diferencia entre una decisión medida y una adivinanza. Un cambio de modelo se vuelve un experimento con un número anexado, no un salto de fe un viernes por la tarde.

Como el conjunto de evaluación se vuelve propietario

La suite es donde el flywheel copilot, dato, capital saca los dientes. Cada corrección que hace un experto de dominio y cada falla de producción devuelta con su respuesta correcta se vuelve una fila etiquetada que ningún competidor tiene y ninguno puede comprar. El conjunto de evaluación es propietario, específico de dominio y compuesto con el tiempo. Es la definición escrita de correcto para un vertical, y crece cada vez que el producto se usa y se corrige. Por eso el conjunto de evaluación, y no el modelo, es el activo durable, un argumento que hacemos completo en el flywheel copilot, dato, capital.

El mecanismo se conecta directo con la economía de la inferencia. La calidad de los modelos está convergiendo y el costo de la inferencia se está desplomando, así que el modelo base no es el moat, y apostar la empresa a uno solo es la trampa del wrapper. Según a16z, un LLM con calidad de GPT-3 cayó de cerca de 60 dólares por millón de tokens a finales de 2021 a cerca de 0,06 dólares, una caída de 1000x en tres años, cerca de 10x al año para un desempeño equivalente. Epoch AI ubica la caída mediana cerca de 50x al año entre benchmarks. Léalo como estrategia, no como dato curioso. Si un modelo base más barato o mejor aparece cada pocos meses, el equipo que puede cambiar a él sin perder calidad gana en costo y en capacidad, y la suite es el instrumento que hace seguro el cambio.

Modos de falla: medir el correcto equivocado

Una suite mal construida es peor que ninguna suite, porque le entrega al equipo una confianza falsa. Estas son las formas en que sale mal, y la corrección de cada una.

• La definición equivocada de correcto. Un golden set malo codifica un estándar errado, y la suite entonces certifica el comportamiento equivocado en cada build verde. Corríjalo con etiquetado por expertos y revisión periódica del conjunto mismo, no solo del modelo.
• Sobreajuste a la evaluación. Los equipos ajustan prompts para pasar la suite en vez de servir al mundo real, y la nota sube mientras la calidad en producción no. Mantenga un conjunto reservado que el equipo nunca usa para ajustar, y renueve casos desde el tráfico real.
• Un conjunto envejecido. Aparecen entradas nuevas, la distribución se corre, y un conjunto congelado poco a poco deja de representar la realidad. El ciclo cerrado es el antídoto.
• Un juez modelo sin validar. Un evaluador LLM nunca contrastado contra etiquetas humanas puede estar equivocado con confianza a escala. Valide primero, luego mantenga el desempate humano en las discrepancias.
• Lock-in vestido de seguridad. Una suite atada al formato de un solo proveedor derriba el propósito. Guarde el golden set y los evaluadores en su propio repositorio para que la suite sobreviva a cualquier modelo.

Como Avante construye evaluaciones con operadores de dominio

La razón por la que nuestras suites se sostienen es quién escribe el golden set. Avante Ventures lanza 3-4 ventures por año mediante un sistema de seis etapas, Research, Partner, Build, Traction, Revenue, Compound, desplegando $500K-1.5M por venture y reteniendo economía de co-founder. El operador de dominio, la persona con una década de cicatrices en el vertical, es la fuente de las etiquetas correctas, y se sienta dentro del equipo de producto desde la etapa Partner. El gate entra en vivo en Build y se endurece a lo largo de Traction y Revenue. El conjunto de evaluación que se compone es un activo de etapa Compound que acompaña a la venture en su ronda.

Es también por eso que un equipo esbelto entrega un producto defendible sin una Serie A. Inferencia barata más una suite disciplinada significan que el moat es el dato y las evaluaciones, no un cofre de guerra para cómputo. La suite misma es plomería de empresa que un studio resuelve una vez y enruta por cada venture, convirtiendo la infraestructura compartida en cerca de $300K-500K de capital efectivo por venture que va a producto en lugar de overhead.

La presión es real en nuestro mercado. El uso de IA entre las empresas industriales brasileñas saltó de 16,9% en 2022 a 41,9% en 2024, cerca de 2,5x en dos años, según el IBGE. La adopción corre por delante del control de calidad, que es la brecha de DORA en un solo país. En un mercado donde los servicios son cerca del 70% del PIB brasileño con baja penetración de software, el premio de la IA vertical es grande, y va para los equipos cuya calidad se mide, no se afirma. Lea la tesis en /why-avante. El equipo que puede probar que su modelo aún funciona después de un cambio es el equipo que sigue pudiendo cambiar.

Preguntas frecuentes

Que es una suite de evaluación de IA?

Una suite de evaluación de IA es un conjunto versionado de casos de prueba etiquetados por expertos más evaluadores automáticos que califican la salida del modelo en cada deploy y en cada cambio de prompt o de modelo. Convierte la calidad de algo que usted revisa a ojo en algo que mide. A diferencia de las pruebas unitarias, que afirman una salida exacta, evalúa salida probabilística en los casos que importan para su vertical.

Como construir una suite de evaluación de IA?

Construya en cinco pasos. Arme un golden set de casos reales etiquetados por expertos incluyendo casos de borde difíciles, escriba evaluadores que califican cada salida contra su referencia, registre una línea base, conecte la suite a la CI como gate de deploy y devuelva cada falla de producción al conjunto. El orden importa, porque cada paso depende del anterior.

Cual es la diferencia entre una suite de evaluación y las pruebas unitarias?

Las pruebas unitarias revisan código determinista, donde una entrada dada debe devolver una salida exacta. Una suite de evaluación califica la salida probabilística de un LLM, donde la pregunta es si la respuesta está bien con suficiente frecuencia en una distribución realista de casos. Usted necesita la suite en el momento en que un LLM entra en una decisión que le importa a un usuario o a un regulador.

Que tipo de evaluador usar para evals de LLM?

Empareje el evaluador con la tarea. Use coincidencia exacta o de cadena por código para tareas categóricas y de extracción, por ser la más rápida y confiable. Use un juez modelo puntuado por rúbrica para salida abierta, validado antes contra etiquetas humanas, con desempate humano en las discrepancias. Evite la evaluación humana pura a escala porque es lenta y cara.

Por que las evaluaciones importan más a medida que la inferencia se abarata?

Porque el costo cayendo de la inferencia es lo que hace que valga la pena un cambio de modelo, y las evaluaciones son lo que lo vuelve seguro. El costo de un LLM con calidad de GPT-3 cayó cerca de 1000x en tres años según a16z, así que un modelo base más barato o mejor aparece todo el tiempo. Un equipo independiente de modelo captura esa ventaja solo si una suite de evaluación prueba que la calidad se mantuvo en el cambio.