Los modelos de lenguaje producen salidas variables y su calidad depende del contexto, del prompt, de las herramientas y de los datos. Una prueba manual sobre diez ejemplos agradables no permite elegir una arquitectura ni asegurar una actualización. Se necesita una disciplina de evaluación comparable a las pruebas de software, adaptada a las respuestas probabilísticas.
El objetivo no es reducir toda cualidad a una nota. Es hacer visibles los errores, comparar versiones en los mismos casos y definir lo que bloquea una puesta en producción.
Distinguir benchmark y evaluación de producto
Un benchmark público mide las capacidades generales sobre un corpus dado. Ayuda a comprender un modelo, pero no representa necesariamente el vocabulario, los formatos, los idiomas y los riesgos de la empresa.
Una evaluación de producto utiliza:
- tareas reales ;
- datos representativos;
- restricciones de formato ;
- herramientas y RAG;
- política de rechazo ;
- umbrales de oficio ;
- costo y latencia.
El mejor modelo público puede ser menos adecuado que un modelo más pequeño en una tarea acotada.
Descomponer el sistema
Una respuesta final depende de varios componentes: clasificación de intención, recuperación, aviso, modelo, herramientas y postprocesamiento. Evaluarlos por separado ayuda a localizar una regresión.
Para un RAG, medir recuperación y generación. Para un agente, medir selección de herramienta, parámetros, respeto de los permisos y resultado. Para una extracción, distinguir reconocimiento del documento y valor de los campos.
Construir un juego de casos representativo
El juego debe cubrir:
- casos frecuentes;
- caso de alto valor;
- formulaciones variadas ;
- idiomas ;
- datos incompletos;
- ambigüedades;
- rechazos esperados ;
- ataques ;
- cas históricamente deficientes.
Cada caso posee un identificador, una intención, entradas, un resultado esperado o una sección, un nivel de riesgo y etiquetas. Los ejemplos de producción están anonimizados y seleccionados según una política.
Pirámide combinando controles deterministas, evaluaciones de componentes, escenarios completos, revisión humana y seguimiento en producción.
Definir las dimensiones de calidad
Según la tarea, evaluar:
- exactitud de los hechos o valores;
- integridad de los elementos necesarios;
- fidelidad a las fuentes;
- formato y estructura;
- pertinencia ;
- utilidad para la acción;
- estilo y tono;
- seguridad ;
- calidad de la negativa ;
- explicabilidad o citas.
Cada dimensión recibe una definición y ejemplos de calificaciones. Una rúbrica vaga produce jueces incoherentes.
Los controles deterministas primero
Antes de un juicio semántico, verificar lo que pueda serlo por código: JSON válido, campos presentes, valores autorizados, referencias existentes, cálculos, longitud, idioma, citas y llamada a herramienta.
Estas pruebas son rápidas, reproducibles y fáciles de integrar en CI. Eliminan errores sin pedir a un modelo que juzgue un formato.
Construir una verdad sobre el terreno
Para una extracción o clasificación, los expertos pueden anotar el resultado correcto. Para una generación, a menudo es preferible definir elementos obligatorios, prohibidos y una rúbrica en lugar de una sola frase.
Los desacuerdos entre expertos son medidos. Si no están de acuerdo, pedir al modelo una respuesta única puede ser irrealista.
La verdad de campo se versiona y revisa cuando cambia la actividad.
Usar jueces humanos
Los humanos siguen siendo necesarios para la utilidad, los matices y los riesgos. La evaluación puede ser a ciegas, con orden aleatorio, para limitar el sesgo de marca o de posición.
Los evaluadores reciben instrucciones, ejemplos y un mecanismo de desacuerdo. Un subconjunto se califica dos veces para medir la coherencia.
Usar un modelo como juez con prudencia
Un juez LLM permite evaluar más casos, pero tiene sus sesgos. Puede preferir las respuestas largas, su propio estilo o la primera opción. Puede ser influenciado por el contenido a juzgar.
Las medidas de precaución incluyen:
- criterios precisos;
- salida estructurada;
- anonimización de los modelos;
- orden aleatorio;
- comparación con notas humanas ;
- varias repeticiones;
- vigilancia de los desacuerdos.
El juez acelera el triage; no convierte una opinión en verdad absoluta.
Comparar dos versiones
La comparación pareada ejecuta A y B en los mismos casos. El informe muestra ganancias, pérdidas y casos críticos, no solo un promedio global.
Los resultados están segmentados por intención, idioma y riesgo. Una mejora en los resúmenes puede ocultar un retroceso en los rechazos. El tamaño de la muestra y la incertidumbre son visibles.
Medir la variabilidad
Una misma entrada puede producir varias salidas. Para tareas sensibles, ejecutar varias repeticiones y medir la estabilidad del formato, de la elección de la herramienta o de la respuesta.
La temperatura, la semilla cuando está disponible, la versión del modelo y los parámetros se registran. Un sistema puede ser en promedio correcto pero demasiado inestable para la producción.
Latencia y disponibilidad
Medir el tiempo total y el tiempo de cada etapa: recuperación, modelo, herramientas, post-procesamiento. Seguir la mediana y los percentiles, no solo el promedio.
Los errores, los tiempos de espera, las cuotas y los reintentos forman parte de la evaluación. Un modelo ligeramente mejor pero a menudo no disponible puede ser menos útil.
Costo por tarea exitosa
El costo incluye tokens, embeddings, reranking, herramientas, almacenamiento y validación humana. Debe reportarse por caso exitoso, no solo por la solicitud.
Una salida incorrecta puede provocar una reanudación costosa. Los escenarios de volumen y de pico ayudan a comparar el enrutamiento y la caché.
Evaluar la seguridad
El juego incluye inyección de prompts, exfiltración, datos prohibidos, elusión de políticas, herramientas no autorizadas y contenidos tóxicos según el uso. Las pruebas se realizan en un entorno seguro.
Un error de seguridad crítica bloquea el lanzamiento independientemente de la puntuación media.
Definir los umbrales
Cada dimensión posee:
- objetivo;
- mínimo aceptable ;
- umbral crítico;
- propietario de la excepción.
Los umbrales provienen del riesgo del negocio. Una extracción financiera puede exigir una exactitud y un control muy elevados; un borrador creativo acepta más variación.
Integrar las evaluaciones en la entrega
Un pequeño juego rápido se ejecuta con cada modificación. Una secuencia completa se ejecuta antes de la versión o periódicamente. Los costos se controlan mediante muestreo y caché de componentes no cambiados.
El informe se compara con una línea base y bloquea las regresiones críticas. Los cambios de prompt, modelo, RAG, herramienta o política están todos versionados.
Monitorear en producción
Las evaluaciones fuera de línea no cubren todas las solicitudes. La producción sigue errores, rechazos, comentarios, escaladas, latencia y costo. Se revisan muestras según una política de privacidad.
Los incidentes reales se convierten en casos de regresión. Los datos de seguimiento no deben recopilar más información de la necesaria.
Evitar la contaminación del juego
Si el juego se utiliza para ajustar constantemente el prompt, se convierte en un juego de entrenamiento implícito. Conservar un conjunto oculto y renovar los casos protege la capacidad de generalización.
Los proveedores y modelos también pueden haber visto algunos puntos de referencia públicos, razón adicional para privilegiar casos propios.
Una evaluación como activo producido
El juego de casos, las secciones, los umbrales y los informes se convierten en una propiedad estratégica. Permiten cambiar de modelo, optimizar el costo y demostrar que una versión es mejor.
Partitech puede crear los juegos de evaluación, automatizar los controles, comparar los modelos e integrar las regresiones en la cadena de entrega. El objetivo es gestionar la calidad basándose en pruebas, no en la impresión de una demostración.
Hablemos de su proyecto
Poner en marcha una plataforma de evaluación de IA con Partitech. Contacte a Partitech.