Como evaluar LLMs antes de produccion: lecciones de GitHub

GitHub ha publicado las lecciones que aprendio evaluando modelos de lenguaje para su sistema de escaneo de secretos. La idea central: un modelo puede aprobar un benchmark limpio y fallar en los casos que importan en produccion. Por eso, proponen una serie de practicas para que la evaluacion previa se parezca mas a la realidad.

Primero la decision de producto, no el modelo

Cuando un sistema con LLM no rinde como se espera, la tentacion es tocar el prompt, anadir contexto o cambiar de modelo. GitHub recomienda empezar por definir que decision de producto va a apoyar la evaluacion. En su caso, la pregunta era: puede el sistema reducir falsos positivos en el escaneo de secretos sin perder demasiada recall? Para responderla, establecieron tres niveles de criterios: el resultado principal (reduccion de falsos positivos, precision), la restriccion de seguridad (recall minima) y los guardarrailes operativos (latencia, coste, fiabilidad). No todos los cambios que mejoran una metrica son buenos si violan los guardarrailes.

La evaluacion offline como prueba de integracion

Una evaluacion unica no sirve de nada. GitHub trata la evaluacion offline como un test de integracion que se repite ante cualquier cambio en el prompt, el modelo o la logica del sistema. Registran cada ejecucion con su version de prompt, modelo y dataset, para poder comparar con una linea base. Ademas, cambian una variable principal a la vez: si modifican el prompt y el modelo en el mismo experimento, no saben que causo la mejora o el retroceso.

Tambien recomiendan probar actualizaciones de modelo con regularidad. A veces un modelo mas potente funciona mejor con un prompt mas simple que uno antiguo con mucha tuning. Y siempre hay que evaluar el cambio antes de llevarlo a produccion.

Mantener la evaluacion cerca de la produccion

Una evaluacion offline solo es util si se parece a la tarea real. En el escaneo de secretos, el modelo no evalua un valor aislado: tiene que tener en cuenta el codigo circundante, informacion incompleta o distractora. Si el dataset de evaluacion es demasiado limpio, puede omitir casos ambiguos o contexto que en produccion importan. GitHub puso un ejemplo simplificado: si hay dos variables, una llamada example_token y otra candidate_value, el modelo puede fijarse en la equivocada por su nombre. Ese tipo de fallo se pierde si la evaluacion no reproduce esas distracciones.

Las etiquetas de produccion no son verdad incuestionable

Los datos de produccion pueden hacer la evaluacion mas representativa, pero sus etiquetas reflejan resultados del flujo de trabajo, no necesariamente la verdad. Un alerta de secreto descartada no significa que sea un falso positivo: el desarrollador pudo rotar la credencial, aceptar el riesgo o despejar el aviso por otra razon. Antes de usar esas etiquetas, hay que preguntarse como se crearon y si coinciden con la pregunta que la evaluacion intenta responder. Para subconjuntos importantes o ambiguos, puede ser necesario revisarlos a mano.

Cubrir huecos con datos sinteticos y abiertos

Cuando los datos de produccion son limitados, sensibles o no estan disponibles, los ejemplos sinteticos, benchmarks academicos y datasets abiertos pueden ayudar a arrancar. Pero deben complementar, no sustituir, a los datos reales. GitHub adapta ejemplos externos a su tarea y revisa las etiquetas que no encajan con su definicion de producto. Tambien crean casos sinteticos dirigidos a patrones de fallo como valores similares a credenciales cerca, codigo de prueba, placeholders o contexto ausente.

El analisis de errores, lo que las metricas esconden

Las metricas agregadas dicen si el sistema mejoro en general. El analisis de errores dice que hacer a continuacion. Un aumento de precision no revela que tipo de errores siguen ocurriendo. Es ahi donde hay que mirar para decidir el siguiente paso.

Lo que queda por ver es si estas practicas se convierten en un estandar en la industria. GitHub ha compartido su experiencia, pero cada equipo tendra que adaptarla a su contexto. La evaluacion de LLMs sigue siendo un problema abierto, y este tipo de articulos ayudan a que la comunidad avance con criterios mas solidos.