Cross-Context Verification: Hierarchical Detection of Benchmark Contamination through Session-Isolated Analysis

Resumen Técnico: Cross-Context Verification (CCV)

1. El Problema: Crisis de Credibilidad en los Benchmarks de LLM

Los benchmarks de codificación para Grandes Modelos de Lenguaje (LLM), específicamente SWE-bench Verified, enfrentan una crisis de fiabilidad.

• Fugas de Soluciones (Contaminación): Estudios previos indican que una proporción significativa de "éxitos" se debe a que los modelos han memorizado las soluciones presentes en los datos de entrenamiento (leakage), en lugar de razonar genuinamente.
• Defectos en las Pruebas: Muchos fallos de los modelos se deben a errores en los propios tests (restricciones excesivas, dependencias de entorno) y no a limitaciones del modelo.
• Limitaciones de los Métodos Actuales: Las técnicas existentes (consistencia de paráfrasis, superposición de n-gramas, análisis de perplejidad) analizan solo los artefactos (el texto final) y no observan el proceso de generación. Además, la repetición simple de la verificación (revisión multi-turno) tiende a generar falsos positivos más rápido que errores reales debido a la presión de confirmación.

2. Metodología Propuesta

El artículo introduce dos componentes principales: Cross-Context Verification (CCV) y la Arquitectura Jerárquica de Contexto Cruzado (HCCA).

A. Cross-Context Verification (CCV)
Es un método de "caja negra" basado en la premisa de que la memorización es determinista, mientras que el razonamiento genuino es no determinista.

• Aislamiento de Sesiones: Se resuelve el mismo problema $N$ veces en sesiones de API independientes y aisladas (sin historial, repositorios limpios, sin historial git futuro).
• Métricas Clave:
  • Diversidad de Código: Se mide la similitud estructural (AST), BLEU a nivel de línea y distancia de edición entre las $N$ soluciones.
  • Proximidad al Oro (Gold Proximity): Similitud con la solución de referencia (gold patch).
• Lógica de Detección:
  • Si el modelo ha memorizado la solución, reproducirá la misma respuesta (baja diversidad, alta proximidad al oro) independientemente de la sesión.
  • Si el modelo razona, la variabilidad natural de la inferencia (incluso con temperatura 0) producirá soluciones diversas.
• Puntuaciones:
  • Contamination Score (CS): Combina proximidad al oro, diversidad y varianza.
  • Test Flaw Score (TFS): Detecta problemas donde las soluciones son plausibles pero fallan los tests (indicando defectos en el benchmark).
• Clasificador de Razonamiento: Un heurístico simple que analiza los primeros 100 tokens. Si el modelo salta directamente al diff sin preámbulo analítico, se clasifica como "Sin Razonamiento" (típico de memorización).

B. Arquitectura Jerárquica de Contexto Cruzado (HCCA)
Para evitar el sesgo de confirmación en el análisis de los resultados de CCV, se propone una estructura multi-agente con restricción intencional de información.

• Capas:
  • Diseñador: Define el protocolo (nunca ve datos).
  • Ejecutor: Genera los datos brutos (parches, métricas).
  • Analistas (Capa 2): Tres analistas independientes que revisan grupos de problemas específicos. Crucial: Cada analista solo ve los datos brutos de su grupo, nunca las conclusiones de los otros analistas.
  • Integrador: Combina los resultados finales.
• Principio: La división del trabajo estructural sin compartir conclusiones intermedias previene el efecto de anclaje y la sycophancy (adulación del modelo hacia la conclusión previa).

3. Contribuciones Clave

1. Método CCV: Primera técnica que observa directamente si un modelo razona o recuerda durante la generación de código, utilizando la diversidad de sesiones aisladas.
2. Marco HCCA: Una arquitectura que demuestra que la restricción de información es más efectiva que la complejidad estructural o la repetición para evitar sesgos en la verificación.
3. Validación Empírica: Separación perfecta entre comportamientos contaminados y genuinos en 9 problemas de SWE-bench.
4. Descubrimiento de Mecanismo: Evidencia convergente de que la restricción de información es la condición necesaria para una verificación efectiva, mientras que la repetición o roles compartidos sin aislamiento fallan.
5. Herramientas Prácticas: Código de fuente abierta, fórmula de puntuación de contaminación y un clasificador de razonamiento.

4. Resultados Experimentales

El estudio se realizó en 9 problemas de SWE-bench Verified (3 grupos: sospecha de contaminación, defectos de prueba y control) usando Claude Opus 4.6 (temperatura 0) con 5 ensayos por problema.

• Separación Perfecta: CCV logró una separación total entre casos contaminados y razonamiento genuino (Mann-Whitney U = 0, $p \approx 0.012$, $r = 1.0$).
  • Contaminados: Puntuación de contaminación (CS) $\ge 0.6$ (rango 0.641 - 1.0). Diversidad de código casi nula (0.0).
  • Genuinos: CS < 0.6 (rango 0.368 - 0.529). Alta diversidad de código.
• Contaminación Binaria: Los datos sugieren que la contaminación es un fenómeno binario: los modelos o recuerdan perfectamente la solución o razonan genuinamente; no hay un espectro intermedio significativo.
• Detección de Falsos Positivos: El 33% de las etiquetas de contaminación previas (ej. astropy-13236) se identificaron como falsos positivos al demostrar que el modelo estaba razonando genuinamente en la nueva versión.
• Composites Contaminación-Defecto: HCCA descubrió casos complejos (como astropy-7606) donde el modelo memorizó una solución incorrecta (no oro) debido a un defecto en la prueba, algo que un solo analista habría pasado por alto o clasificado erróneamente.
• Tiempo de Respuesta: Las soluciones memorizadas fueron un 3.2 veces más rápidas (5.8s) que las generadas por razonamiento (18.5s).
• Fallo de la Verificación Jerárquica sin Aislamiento: Un experimento piloto con un flujo Worker $\to$ Verificador $\to$ Director (donde el verificador veía las conclusiones del trabajador) resultó en un 100% de confirmación sycophántica, demostrando que sin restricción de información, la estructura jerárquica no aporta valor.

5. Significado e Implicaciones

• Paradigma de Verificación: El trabajo establece que la restricción de información (aislamiento de contexto) es el mecanismo fundamental para la verificación efectiva de LLMs, superando a la simple repetición o a la complejidad de roles.
• Herramienta de Auditoría: CCV no solo detecta contaminación, sino que valida la calidad de los propios benchmarks, identificando defectos en las pruebas (test flaws) que invalidan los resultados de los modelos.
• Generalización: Aunque probado en Python, el principio de "diversidad a través de resolución independiente" es agnóstico al lenguaje y aplicable a otros dominios (matemáticas, QA).
• Recomendación: Para evaluaciones rigurosas, se debe evitar la revisión secuencial donde el revisor conoce la conclusión previa; en su lugar, se deben utilizar enfoques paralelos e independientes con cegamiento mutuo.

En conclusión, el artículo presenta una solución robusta y reproducible para la crisis de integridad en los benchmarks de LLM, demostrando que la observación directa del proceso de generación mediante aislamiento de sesiones es la única forma fiable de distinguir entre memoria y razonamiento.