GitHub revela su método para evaluar LLMs antes de producción: 95% menos falsos positivos en secret scanning

GitHub publicó en su blog oficial una guía práctica sobre cómo evaluar modelos de lenguaje de gran tamaño (LLM) antes de llevarlos a producción, a partir de la experiencia acumulada con su sistema de secret scanning. El equipo que trabajó en reducir los falsos positivos de esa herramienta — que identifica credenciales, como tokens y claves, que puedan haber sido subidas a un repositorio — alcanzó una reducción del 95% en los falsos positivos sobre el conjunto de datos de evaluación offline, manteniendo el recall dentro del umbral definido como seguro para un flujo de trabajo de seguridad. La guía reúne siete prácticas que van desde definir primero la decisión de producto que se quiere respaldar hasta usar LLM-as-judge para concentrar la revisión humana en los casos más difíciles, e incluye un checklist para evaluar si un sistema está listo para pasar a producción.

La publicación responde a una falla conocida en el desarrollo con inteligencia artificial: un modelo puede rendir bien en un benchmark limpio y aun así fallar en los casos que importan en producción. Los inputs reales suelen ser ambiguos, las etiquetas pueden ser inconsistentes y el contexto importante puede faltar o llegar truncado; los casos límite que rara vez aparecen en los benchmarks se vuelven fuentes comunes de error. En el caso de secret scanning, el objetivo no era determinar si un LLM podía clasificar una cadena de texto correctamente, sino entender si el sistema podía reducir las alertas ruidosas — que hacen perder tiempo a los desarrolladores con avisos que no requieren remediación — preservando suficiente recall para no dejar pasar credenciales reales. El equipo necesitaba generar evidencia que respaldara una decisión de producto, no solo un resultado técnico aislado; por eso, explican, antes de tocar el modelo definieron qué significaba éxito para el usuario y qué resguardos no se podían violar.

GitHub cuenta con secret scanning, una funcionalidad de seguridad que detecta credenciales que pueden haber quedado commiteadas en repositorios. Como algunas cadenas candidatas se parecen a secretos pero no son credenciales reales, los desarrolladores terminan investigando alertas que no requieren acción, y ese ruido era justamente el problema que el equipo buscaba resolver con un sistema basado en LLM. El artículo documenta ese recorrido: los desafíos aparecieron al evaluar el sistema, cuando descubrieron que los datasets curados sirven para comparar modelos en la etapa de prototipo, pero no reflejan la distribución real de producción, donde el contexto puede llegar incompleto o con elementos que distraen al modelo. De ahí surgieron las lecciones que estructuran la guía.

La guía propone un enfoque que cambia la forma en que los equipos suelen evaluar LLMs. En lugar de tratar todas las métricas como intercambiables, sugiere organizarlas en tres niveles: resultado primario (lo que mide el beneficio real para el usuario, como la reducción de falsos positivos y la precisión), restricción de seguridad (como el recall, que no puede caer por debajo de un umbral predefinido) y resguardos operativos (latencia, costo, confiabilidad y compatibilidad con producción). También recomienda tratar la evaluación offline como un test de integración de extremo a extremo, rerunándola ante cualquier cambio de prompt, modelo, construcción de inputs o lógica del sistema, y mantenerla lo más cerca posible de la tarea real de producción: un dataset más limpio que el entorno real puede dar un puntaje alto simplemente porque el problema es más fácil. Completar huecos de cobertura con datasets sintéticos y abiertos, clasificar cada error por su fuente probable (modelo, prompt, input, pipeline, dataset o etiqueta) y usar LLM-as-judge solo para el triage de la revisión humana son otras de las prácticas centrales. El resultado, según GitHub, no prueba cómo se comportará el sistema en todo escenario de producción, pero da evidencia estructurada suficiente para pasar a experimentación online con riesgos y resguardos entendidos: "la incertidumbre de producción es inevitable; la evaluación la hace visible, medible y manejable".