Evaluar una funcionalidad con LLM sin montar un laboratorio de investigación

El momento que fuerza esto es siempre el mismo. Sale una versión nueva de un modelo, o alguien reescribe el prompt de sistema, y la pregunta es si desplegarlo. El equipo prueba diez preguntas a mano, las respuestas parecen más bonitas, se despliega, y dos semanas después soporte se da cuenta de que el asistente ha dejado de citar fuentes.

Nadie podía haber cazado eso con diez preguntas probadas a mano. Necesitas un conjunto de casos y un número, y la buena noticia es que la versión de esto que funciona es mucho más pequeña que un programa de investigación. Cien casos bien elegidos cazan la mayoría de las regresiones que importan.

Construye el conjunto desde el tráfico real y los fallos reales

El peor conjunto de evaluación es el que alguien inventó en una mesa. Prueba lo que esa persona imaginó que preguntarían los usuarios, que es sistemáticamente distinto de lo que los usuarios preguntan.

Tres fuentes, por orden de valor:

Tráfico de producción. Muestrea consultas reales, estratificadas para no estar probando solo el caso común. Coge preguntas frecuentes, raras, largas, ambiguas y en cada idioma que sirvas.

Fallos reportados. Cada queja, cada pulgar hacia abajo, cada escalado a soporte se convierte en un caso. Es la fuente de más valor porque cada uno es un fallo conocido con una respuesta correcta conocida, y significa que el conjunto mejora cada vez que algo sale mal.

Casos adversarios que escribes a propósito. Preguntas sin respuesta en el corpus, donde el comportamiento correcto es decirlo. Preguntas que mezclan dos temas. Preguntas que contienen una instrucción, para comprobar el manejo de inyecciones. Preguntas sobre datos de otro inquilino, para comprobar la frontera de permisos.

De cien a trescientos casos es el tamaño correcto para empezar. Lo bastante grande para ser estable, lo bastante pequeño para que una persona pueda revisarlo entero cuando algo parezca raro. Guárdalo en el repositorio como datos, versionado junto a los prompts como se describe en versionar prompts y evaluar automatizaciones, y hazlo crecer a conciencia en vez de dejar que se desborde.

Trata los datos personales como corresponde. Un conjunto de evaluación construido desde tráfico de producción es dato de producción, con las mismas reglas de conservación y de acceso.

Mide los componentes, no una puntuación global

Un único número de "calidad" te dice que algo cambió y nada sobre qué. Divídelo por lo que se mide, porque los arreglos son completamente distintos.

Recuperación. ¿Está el fragmento correcto entre los primeros resultados? No necesita llamada al modelo, no cuesta nada, y es donde viven de verdad la mayoría de los problemas de calidad. Mídela por separado y primero; el razonamiento está en fragmentación y embeddings.

Fundamentación. ¿Toda afirmación de la respuesta se apoya en el contexto recuperado? Es la métrica práctica de alucinación.

Corrección de la respuesta. ¿Coincide con la respuesta esperada, en los casos donde hay una?

Completitud. ¿Respondió a toda la pregunta o solo a la primera mitad?

Comportamiento de rechazo. En los casos donde la respuesta correcta es "no lo sé", ¿lo dijo? Los equipos se olvidan de medir esto y después se preguntan por qué el asistente se equivoca con aplomo en cosas que están fuera del corpus.

Cumplimiento de formato y de política, que suele ser una comprobación determinista.

Añade coste y latencia por caso al mismo informe. Un cambio que mejora la corrección dos puntos y duplica la factura es una decisión, no una mejora, y quieres los dos números en la misma tabla.

El juez, y por qué hay que calibrarlo

Casi ninguna de estas métricas se puede calcular con coincidencia de cadenas, así que usas un modelo para puntuar. Eso funciona e introduce un instrumento de medida con sus propios errores.

Los jueces tienen sesgos conocidos. Prefieren respuestas más largas. Prefieren respuestas con un estilo parecido al suyo, lo que significa que un juez de la misma familia que tu generador lo va a halagar. Son sensibles al orden de las opciones en las comparaciones. Y son inconsistentes en el margen, dando puntuaciones distintas a la misma respuesta en ejecuciones distintas.

El arreglo es calibrar, y es una tarde de trabajo. Que una persona etiquete de treinta a cincuenta casos. Pasa el juez por los mismos casos. Mide la concordancia. Si el juez coincide con la persona la mayor parte de las veces, puedes fiarte de sus números agregados. Si no, arregla el prompt del juez, normalmente haciendo la pregunta más estrecha y pidiendo una decisión binaria con un motivo declarado en vez de una puntuación sobre diez.

Dos prácticas que hacen a los jueces mucho más fiables: pide un veredicto binario o de tres valores en vez de una puntuación numérica, porque los modelos son mucho mejores en "¿se apoya esta afirmación, sí o no?" que en "puntúa esto del uno al diez"; y dale al juez la evidencia en vez de preguntarle de memoria, para que la fundamentación se juzgue contra el contexto realmente recuperado.

Recalibra cuando cambies el modelo juez. El juez es una dependencia con versión.

La evaluación fuera de línea bloquea el despliegue, la de en línea dice la verdad

La evaluación fuera de línea ejecuta el conjunto en integración continua ante cada cambio de prompt, de modelo y de recuperación. Es rápida, repetible y lo bastante barata para ejecutarse en un pull request. También es artificial: un conjunto fijo no puede cubrir lo que los usuarios harán mañana.

La evaluación en línea mide producción. Pulgares arriba y abajo, aunque la señal es escasa y sesgada hacia las quejas. Señales implícitas, que son mejores: ¿reformuló el usuario la pregunta inmediatamente?, ¿escaló a una persona?, ¿se fue? Y un juez asíncrono sobre una muestra del tráfico real, que es la medición continua más útil y cuesta una fracción de juzgarlo todo.

Haz las dos. La de fuera de línea caza regresiones antes de publicar. La de en línea caza la deriva que un conjunto fijo no puede ver, incluido un proveedor que actualiza un modelo en silencio detrás de un extremo estable.

La puerta que bloquea un despliegue

Haz la regla explícita, o la evaluación se convierte en un informe sobre el que nadie actúa.

Un valor por defecto viable: ninguna métrica puede bajar más que una tolerancia pequeña, ningún caso que antes pasaba puede fallar ahora en el subconjunto crítico, y el coste por consulta no puede subir por encima de un umbral declarado sin una decisión. Mantén un subconjunto crítico de veinte o treinta casos que tienen que pasar sin excepción, cubriendo los fallos que serían inaceptables: fuga de datos entre inquilinos, un compromiso de política inventado, una negativa a responder algo esencial.

Las puntuaciones agregadas esconden regresiones. Un cambio que mejora ochenta casos un poco y rompe tres a lo grande puede mostrar ganancia neta. Informa siempre de qué casos concretos cambiaron de dirección, y míralos.

Lo que se olvida

• El no determinismo. Pon la temperatura a cero para evaluar cuando puedas, y ejecuta varias veces cuando no. Un punto de diferencia en una sola ejecución es ruido.
• El corpus cambia debajo de ti. Si se actualizan documentos, una respuesta esperada puede volverse incorrecta. Versiona la foto del corpus junto al conjunto.
• Cobertura de idiomas. Si sirves varios idiomas, el conjunto también tiene que hacerlo, y la calidad suele diferir bastante entre ellos.
• Evaluar cuesta dinero. Trescientos casos con un juez en cada pull request se acumulan. Ejecuta el conjunto completo al fusionar y un subconjunto en cada empuje.
• Nadie lee un panel. Pon la diferencia en el pull request, junto al código, igual que el coste va ahí.

Qué hacer esta semana

Coge las últimas veinte quejas o pulgares hacia abajo de tu asistente, escribe la respuesta correcta de cada una y guárdalas como un fichero en el repositorio. Ese fichero es tu conjunto de evaluación. Ejecuta tu sistema actual contra él y cuenta cuántas acierta. Sea cual sea el número, ahora tienes una línea base, y todo cambio futuro tiene algo con lo que compararse. Lo construimos en la primera quincena de un proyecto de IA aplicada.