Un modelo lingüístico puede lograr resultados sólidos en un punto de referencia limpio y luego tropezar con los casos ambiguos que realmente importan a los usuarios dentro del entorno de producción. Esta es la lección central que presenta GitHub en un artículo escrito por Mariko Wakabayashi y Zixiao Chen el 25 de agosto de 2026, basado en una experiencia de evaluación de un sistema que utiliza un modelo lingüístico para ayudar a reducir las falsas alarmas en GitHub secret scanning.
El análisis de secretos busca credenciales, como tokens y claves, que podrían haberse depositado en un repositorio de software. Sin embargo, algunas cadenas de texto se parecen a secretos sin ser credenciales reales, lo que lleva a los desarrolladores a revisar alertas que no requieren ninguna acción. Por ello, la pregunta del equipo no era si el modelo podía clasificar una cadena de texto aislada, sino si podía reducir el ruido manteniendo un nivel de exhaustividad suficiente para que un flujo de trabajo de seguridad sensible fuera seguro.
Empieza por la decisión de producto, no por la elección del modelo
GitHub recomienda definir la decisión que la evaluación debe respaldar antes de modificar la instrucción, añadir contexto o cambiar el modelo. En el caso del análisis de secretos, el objetivo era reducir las falsas alarmas y aumentar la precisión, mientras que la exhaustividad se utilizó como restricción de seguridad. Ocultar por error una credencial real puede ser más peligroso que pedir a un desarrollador que revise una alerta adicional.
En la práctica, los criterios de evaluación se dividieron en tres capas: un resultado principal que mide el beneficio para el usuario, es decir, la reducción de falsas alarmas y la precisión; una restricción de seguridad representada por la exhaustividad; y barreras operativas que incluyen el tiempo de respuesta, el coste, la fiabilidad y la compatibilidad con el entorno de producción. De este modo, una mejora en la precisión no se considera automáticamente un éxito si va acompañada de una reducción inaceptable de la exhaustividad o si hace que el sistema sea lento, costoso o difícil de integrar.
Convierte la evaluación en una prueba de integración reproducible
La evaluación no es un único paso previo al lanzamiento. Las instrucciones, los modelos, la forma de construir las entradas y la lógica del sistema que los rodea cambian constantemente, y cualquier modificación puede producir una mejora, un retroceso o trasladar el patrón de error a otro lugar. Por ello, GitHub volvió a ejecutar la evaluación después de cada cambio importante y registró cada vez la versión de la instrucción, el modelo, el conjunto de datos y la configuración del sistema.
El equipo también aisló una variable principal en cada experimento y comparó una modificación de la instrucción con una línea base conocida antes de probar con ella una actualización del modelo. Las instrucciones y las configuraciones de evaluación se trataron como si fueran código: se versionaron, se documentaron los cambios y se mantuvo la posibilidad de volver a ejecutar y revertir las configuraciones anteriores. Esta práctica permite saber por qué se produjo una mejora o un retroceso, en lugar de atribuirlo erróneamente al último cambio.
Simula la tarea de producción y no te limites a datos limpios
Los resultados de la evaluación offline son más útiles cuando se parecen a la tarea real. En el análisis de secretos, el modelo no necesariamente observa un valor aislado, sino un candidato dentro de código circundante e información complementaria que puede estar incompleta o dispersa. Puede centrarse en otro valor que parezca más relacionado con la seguridad, como un token de prueba presente en el código, en lugar del candidato que debe evaluar.
Por ello, deben conservarse las características de la tarea de producción, entre ellas el candidato evaluado, el contexto circundante, la información complementaria, la forma de dar formato a las entradas y de imponer restricciones, y la lógica más amplia del sistema. Si la evaluación utiliza ejemplos más claros y un contexto más completo que la realidad, el resultado puede reflejar un problema más fácil que el que el sistema afrontará al desplegarse.
Trata las etiquetas y los datos como evidencias que pueden examinarse
El resultado de una acción concreta en el producto no significa que represente una verdad fundamental fiable. Cerrar una alerta en el análisis de secretos puede significar que la credencial fue rotada, que se aceptaron los riesgos, que la alerta se cerró para abrir un flujo de trabajo o que se clasificó incorrectamente. Estos casos parecen similares en los datos del flujo de trabajo, pero no responden a la misma pregunta en la evaluación.
Antes de utilizar datos de producción, hay que saber cómo se creó la etiqueta, si coincide con la pregunta de evaluación y si resultados diferentes se agruparon en una sola categoría. GitHub propone una revisión humana de las categorías importantes o ambiguas, en lugar de suponer que todas las etiquetas son correctas. Los datos sintéticos y los puntos de referencia abiertos pueden cubrir lagunas de cobertura, especialmente en casos poco frecuentes como contexto ausente, formato inusual y valores similares a credenciales, pero deben complementar los datos cercanos a producción, no sustituirlos.
Analiza los errores y utiliza con cautela el modelo evaluador
Las métricas globales indican al equipo si el sistema mejoró, pero no explican qué debería cambiarse después. Por ello, GitHub revisó muestras de falsos positivos y falsos negativos y clasificó sus posibles causas dentro del modelo, la instrucción, las entradas, el flujo de trabajo, el conjunto de datos o las etiquetas. Esta clasificación convierte un problema general de calidad en una tarea de ingeniería concreta: una mejor estructuración de las entradas, una construcción diferente del contexto, una limpieza de los datos o una política de producto más clara.
Puede utilizarse otro modelo lingüístico como evaluador para reducir la carga de la revisión humana, procesando los casos claros y priorizando los ambiguos. Sin embargo, sus resultados no son una verdad de referencia; puede equivocarse o coincidir con el modelo evaluado por la razón equivocada. El patrón más seguro consiste en derivar los casos de baja confianza, contradictorios o de alto impacto a personas, tomar muestras periódicas de los casos que el evaluador clasificó con alta confianza, hacer un seguimiento de sus discrepancias con el sistema y los revisores, y versionar y evaluar su instrucción.
¿Qué demostró realmente la experiencia?
GitHub informó de que logró una reducción del 95 % de las falsas alarmas en el conjunto de datos offline evaluado, manteniendo la exhaustividad dentro de la restricción de seguridad definida. Sin embargo, la empresa no presentó este resultado como prueba de que el sistema se comportaría de la misma manera en todos los escenarios de producción. El valor más importante estuvo en comprender cómo se llegó al resultado: una evaluación más cercana a la tarea real, líneas base reproducibles y patrones de fallo documentados.
Lectura editorial de certi.news: el cambio real aquí no consiste en presentar un modelo nuevo, sino en transformar la evaluación de sistemas LLM de un experimento basado en un punto de referencia en un proceso de ingeniería continuo, vinculado a una decisión clara y a límites de seguridad y operación. Esto importa a los equipos de software, seguridad y herramientas para desarrolladores porque la mejora de una sola métrica puede ocultar un retroceso peligroso en la exhaustividad o un aumento del coste. Al mismo tiempo, el resultado sigue limitado por el conjunto de evaluación, la calidad de las etiquetas y la brecha que no puede eliminarse entre las pruebas offline y el comportamiento en producción; por ello, las evaluaciones constituyen una base para pasar a una experiencia de producción controlada, no un sustituto de la supervisión de riesgos después del lanzamiento.