Evaluar un LLM como una pieza de producción, no como una demo

GitHub ha compartido las lecciones de evaluar un sistema basado en un modelo de lenguaje para reducir falsos positivos en secret scanning. El artículo es útil porque trata la evaluación como una tarea de ingeniería de producto y no como una competición de benchmarks. Un modelo puede obtener buenos resultados con datos limpios y, aun así, fallar cuando recibe el contexto incompleto, ambiguo o ruidoso que encontrará en producción.

El primer paso que propone GitHub es definir la decisión que debe respaldar la evaluación. En su caso, el objetivo era reducir alertas innecesarias sin perder demasiados secretos reales. La reducción de falsos positivos y la precisión eran el resultado principal; el recall funcionaba como una restricción de seguridad; y latencia, coste, fiabilidad y compatibilidad actuaban como guardas operativas. Esta separación evita declarar como mejora un cambio que eleva la precisión mientras deja caer el recall por debajo de un límite aceptable.

El segundo principio es tratar la evaluación offline como una prueba de integración repetible. Cada modificación relevante del prompt, del modelo, de la construcción del contexto o de la lógica circundante debe compararse con una línea base conocida. Para poder atribuir los cambios, GitHub recomienda variar una variable principal cada vez y versionar prompts, configuraciones, modelos y conjuntos de datos. Sin ese registro, una mejora puede atribuirse al modelo cuando en realidad procede de un cambio de entrada o de una regla del pipeline.

La representatividad de los datos es igual de importante. En un flujo de secret scanning, el modelo no analiza siempre una cadena aislada: puede recibir código cercano, valores de prueba, nombres engañosos y contexto parcial. Un conjunto demasiado limpio puede ocultar que el sistema razona sobre el candidato equivocado. Por eso la evaluación debe conservar la forma real de las entradas y añadir casos sintéticos para cubrir situaciones raras, como placeholders, referencias indirectas o información ausente.

El artículo también advierte sobre las etiquetas procedentes de producción. Que un desarrollador descarte o cierre una alerta no demuestra por sí mismo que fuera un falso positivo. Puede haber rotado la credencial, aceptado el riesgo o despejado el aviso para desbloquear un flujo. Las etiquetas deben revisarse en los subconjuntos ambiguos y relacionarse con la pregunta exacta que la evaluación intenta responder.

El análisis de errores transforma una métrica agregada en trabajo concreto. GitHub clasifica los fallos según provengan del modelo, el prompt, la entrada, el pipeline, los datos o la etiqueta. También utiliza otro LLM como juez para priorizar revisiones, pero lo trata como una predicción adicional: los casos de baja confianza, desacuerdo o alto impacto siguen necesitando revisión humana.

En su conjunto evaluado, GitHub informa de una reducción del 95 % de falsos positivos manteniendo el recall dentro de su guardarraíl definido. El dato no prueba el comportamiento en todos los repositorios, pero sí ilustra una práctica transferible: antes de confiar en un sistema de IA, hay que medir la decisión que importa, registrar cómo se obtuvo el resultado y llevar la incertidumbre hasta el despliegue controlado.