Cómo evaluar una función de LLM antes de lanzarla

"Lo probé con algunos ejemplos y funcionó" es lo más común que escuchamos cuando un equipo describe cómo probó una función de IA, y no es una evaluación, es una demo. La brecha entre "funcionó en los ejemplos que probé" y "lo bastante fiable como para ponerlo delante de los clientes" es exactamente donde las funciones de IA fallan después del lanzamiento, y se puede cerrar antes del lanzamiento si construye un proceso de evaluación real en lugar de uno informal.

Un conjunto de evaluación real empieza con consultas reales, no inventadas. Extraiga ejemplos reales de tickets de soporte, registros de búsqueda, o de cómo los usuarios realmente interactuarían con la función, no las preguntas limpias y bien formuladas que un desarrollador escribe mientras la construye. Los usuarios reales hacen preguntas ambiguas, cometen errores de tipeo, y formulan las cosas de formas que sus casos de prueba nunca anticiparon si usted mismo los escribió.

Cada ejemplo necesita una respuesta correcta etiquetada, decidida por alguien que realmente conoce el dominio, antes de ejecutar nada contra el modelo. Sin una respuesta etiquetada contra la cual comparar, "cómo le fue" se convierte en un juicio hecho en el momento, que es exactamente el tipo de evaluación inconsistente que permite que una función se lance basada en impresiones.

Dimensione el conjunto según la variación real de sus entradas, no según un número redondo que se sienta exhaustivo. Cincuenta ejemplos bien elegidos que cubran sus patrones de consulta reales, incluyendo los difíciles, detectan más regresiones que quinientos ejemplos que son todos pequeñas variaciones del caso fácil. Construimos estos conjuntos de forma iterativa, empezando pequeños y añadiendo ejemplos a medida que aparecen nuevos patrones de fallo en producción.

El conjunto solo se gana su lugar si se vuelve a ejecutar en cada cambio, no solo antes del primer lanzamiento. Un ajuste de prompt, una actualización de modelo, un cambio en lo que se recupera antes de generar, cada uno de estos puede mejorar algunos casos y romper otros en silencio. Volver a ejecutar el mismo conjunto etiquetado después de cada cambio es lo que detecta "arreglamos lo que notamos y rompimos tres cosas que no notamos".

Rastree los fallos por categoría, no solo como una tasa de aprobación. Un solo porcentaje le dice que algo está mal; no le dice qué arreglar. Separar los fallos en categorías, recuperación incorrecta, recuperación correcta pero razonamiento incorrecto, respuesta correcta pero tono o formato incorrecto, le dice si el siguiente arreglo pertenece a sus datos, a su prompt o a su pipeline de recuperación.

Decida qué significa "suficientemente bueno para lanzar" antes de ver los resultados, no después. Es fácil racionalizar una puntuación mediocre una vez que la está mirando y quiere lanzar. Fijar un umbral de antemano, y qué pasa con los fallos por debajo de él (respaldo humano, un tratamiento de interfaz de menor confianza, bloquear la función por completo), mantiene la evaluación honesta en lugar de convertirla en una formalidad que se pasa por alto hablando.

Nada de esto es una compuerta única antes del lanzamiento. El conjunto de evaluación es un activo vivo: cada fallo real de producción que se reporta se convierte en un nuevo ejemplo etiquetado añadido a él, de modo que el conjunto se vuelve mejor detectando los fallos exactos con los que se topan sus usuarios reales, no solo los que anticipó al construirlo. Una función evaluada una vez antes del lanzamiento y nunca más es una función con la que vuela a ciegas al mes de haberla lanzado.