💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

Este artículo presenta OpenCoder, un marco de trabajo consciente de la incertidumbre que estima y aprovecha la incertidumbre específica de la fuente para filtrar y clasificar evidencia de recuperación heterogénea, mejorando así la corrección de la generación de código a nivel de repositorio mientras demuestra que sus beneficios dependen del backend de LLM específico y de las interacciones de la evidencia.

Autores originales: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Publicado 2026-07-29

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando construir un complejo castillo de LEGO, pero te han entregado un único manual de instrucciones que solo cubre la puerta principal. Conoces la puerta, pero el castillo necesita ventanas, un techo y un túnel secreto subterráneo. Este es el lucha diaria de la Inteligencia Artificial (IA) cuando intenta escribir código informático para proyectos del mundo real. Si bien la IA se ha vuelto increíblemente buena escribiendo fragmentos de código pequeños y aislados, a menudo se pierde cuando se le pide construir algo que encaje en un "vecindario" de software masivo y existente. Para resolver esto, los investigadores utilizan una técnica llamada Generación Aumentada por Recuperación (RAG, por sus siglas en inglés). Piensa en RAG como darle a la IA un motor de búsqueda superpotente: antes de escribir una sola línea de código, busca proyectos similares, consulta las reglas del vecindario (las convenciones específicas del proyecto) y encuentra las herramientas adecuadas (APIs) para usar.

Sin embargo, hay un inconveniente. El hecho de que el motor de búsqueda encuentre mucha información no significa que esa información sea útil. A veces, la IA encuentra una pieza de código que parece similar pero que en realidad rompe el proyecto; otras veces, encuentra una herramienta que no encaja en el trabajo específico. La información está ahí, pero es ruidosa, conflictiva o simplemente errónea. La gran pregunta que los investigadores se han estado haciendo es: ¿Cómo le enseñamos a la IA no solo a encontrar la información correcta, sino a saber cuánto confiar en ella? Si la IA no puede distinguir entre una pista útil y una pista falsa engañosa, construirá un castillo que colapsará en el momento en que intentes abrir la puerta.

Aquí es donde entra en juego un nuevo estudio de investigadores de la Universidad de Beihang. Ellos presentan un sistema llamado OpenCoder, que actúa como un gerente de proyectos escéptico y ultra organizado para la IA. En lugar de confiar ciegamente en cada pieza de información que el motor de búsqueda encuentra, OpenCoder asigna una "puntuación de duda" a cada una de las pistas. Se pregunta: "¿Qué tan inciertos estamos de que esta API sea la correcta?" o "¿Qué tan probable es que este código similar choque con nuestro proyecto?". Al tratar la incertidumbre no como un error, sino como una señal útil, OpenCoder filtra el ruido, clasifica las pistas basándose en qué tan confiables parecen e incluso sabe cuándo detenerse y corregir sus propios errores.

Los investigadores probaron este sistema pidiéndole a la IA que escribiera código para 32 tareas diferentes del mundo real. Descubrieron que cuando se utiliza un modelo de IA potente llamado GPT, OpenCoder aumentó significamente la tasa de éxito del código final del 56.25% (con métodos de búsqueda estándar) al 78.13%. Sin embargo, los investigadores descubrieron un matiz crucial: esta mejora igualó el rendimiento de un grupo de control que utilizó la búsqueda estándar pero añadió un paso de "verificación y reparación". Esto sugiere que, si bien el filtrado de incertididad de OpenCoder ayudó, el salto masivo en el éxito fue impulsado en gran medida por la capacidad del sistema para verificar y reparar errores, más que por el filtrado por sí solo. La salsa secreta no era solo encontrar más información; era la capacidad del sistema para decir: "Esta pieza específica de evidencia parece dudosa, así que vamos a ignorarla", y "Esta otra pieza parece sólida, así que vamos a usarla", todo ello mientras cuenta con una red de seguridad para atrapar errores.

No obstante, la historia no es un simple "la IA gana para siempre". Los investigadores fueron cuidadosos al señalar que este éxito depende en gran medida de qué cerebro de IA está realizando el pensamiento. Cuando intercambiaron GPT por un modelo diferente llamado Gemini, los resultados fueron mucho menos claros. Las mejoras no fueron estadísticamente significativas, lo que sugiere que el "radar de incertidumbre" de OpenCoder funciona de manera diferente dependiendo de la personalidad de la IA. Además, el sistema chocó contra un muro cuando al proyecto le faltaba demasiada información. En estos casos de evidencia incompleta, un sistema estándar con verificación y reparación superó realmente a OpenCoder. Esto indica que cuando el motor de búsqueda no puede encontrar las herramientas necesarias para empezar, el mecanismo de filtrado de OpenCoder puede, a veces, suprimir los pocos fragmentos de evidencia que estaban disponibles, en lugar de mejorar la decisión final.

El estudio también descubrió algo sorprendente sobre cómo funcionan juntos los diferentes tipos de información. Podrías pensar que tener "código similar", "contexto del proyecto" y "conocimiento de la API" es siempre mejor que tener solo uno. Pero los investigadores encontraron que no existe una regla universal. A veces, añadir "código similar" en realidad confundió a la IA, a menos que estuviera emparejado con el "contexto del proyecto" adecuado. Es como tener un mapa, una brújula y un GPS: si solo tienes el GPS, podrías perderte; si tienes el mapa y la brújula pero no el GPS, podrías estar bien; pero si tienes los tres y se contradicen entre sí, podrías terminar dando vueltas en círculos. El valor de cada pista depende enteramente de qué otras pistas estén presentes.

Para que esto funcione, OpenCoder realiza una danza de cinco pasos. Primero, construye una biblioteca de todas las reglas y herramientas del proyecto. Segundo, descompone la solicitud del usuario en pasos pequeños. Tercero, sale en busca de pistas, pero esta vez las califica según qué tan "inciertas" se sienten. Cuarto, genera el código, pero mantiene un ojo atento en la "puntuación de incertidumbre" para evitar usar pistas dudosas. Finalmente, y quizás lo más importante, actúa como su propio inspector de control de calidad. Ejecuta el código a través de una serie de pruebas. Si el código falla, no se rinde; identifica el error e intenta reparar el código basándose en esa retroalimentación de validación.

Al final, el artículo sugiere que el futuro de la programación de IA no se trata solo de hacer a la IA más inteligente o de darle más datos. Se trata de enseñar a la IA a ser humilde y crítica. Al tratar la incertidumbre como una herramienta para guiar las decisiones —filtrando datos malos, verificando la salida y reparando errores sobre la marcha—, sistemas como OpenCoder pueden construir software más confiable. Pero, como advierten los investigadores, esto no es una varita mágica que funcione en todas las situaciones. Funciona mejor cuando la IA tiene suficiente información buena con la que trabajar y cuando el modelo de IA específico está ajustado para entender correctamente las "puntuaciones de duda". Por ahora, OpenCoder es un paso poderoso hacia adelante, demostrando que, a veces, saber lo que no sabes es la parte más importante para resolver el rompecabezas.

Resumen Técnico: Más allá de "qué recuperar": La incertidumbre en la generación de código con recuperación aumentada

Declaración del Problema

La generación de código a nivel de repositorio requiere que los Modelos de Lenguaje de Gran Escala (LLMs) sinteticen implementaciones que respeten las dependencias entre archivos, las convenciones del proyecto y las APIs privadas. Si bien la Generación Aumentada por Recuperación (RAG) aborda la limitación del conocimiento paramétrico al suministrar evidencia externa del repositorio, los enfoques existentes se centran principalmente en optimizar qué información recuperar (por ejemplo, código similar, contexto del repositorio, conocimiento de la API). En gran medida, descuidan la incertidumbre inherente asociada con esta evidencia.

La evidencia recuperada suele ser heterogénea y poco fiable: los ejemplos de código similar pueden estar relacionados semánticamente pero ser funcionalmente incompatibles; el contexto del repositorio puede contener dependencias redundantes o conflictivas; y el conocimiento de la API puede estar incompleto o incorrectamente delimitado. Los métodos actuales optimizan la relevancia de la recuperación sin modelar explícitamente cómo la incertidumbre en estas fuentes afecta la generación, verificación y reparación posteriores. En consecuencia, la combinación de evidencia adicional puede introducir ruido y propagar errores de recuperación, lo que conduce a un código ejecutable que aún contiene defectos funcionales o de uso indebido de la API sustanciales.

Metodología: OpenCoder

Los autores presentan OpenCoder, un marco de trabajo consciente de la incertidumbre diseñado para tratar la incertidumbre como una señal de control accionable en lugar de una puntuación de confianza post-hoc. El marco opera a través de cinco fases:

Perfilado de Conocimiento del Repositorio e Incertidumbre: Construye un índice que contiene tres fuentes de evidencia: APIs específicas del proyecto ( $A$ ), código contextual del repositorio ( $X$ ) y ejemplos de código semánticamente similares ( $S$ ).
Descomposición de la Incertidumbre de la Consulta: Descompone la consulta del usuario en pasos de implementación y predice la evidencia requerida para cada paso.
Recuperación Multifuente Consciente de la Incertidumbre: Recupera candidatos de $A$ $A$ , $X$ $X$ y $S$ $S$ . Crucialmente, OpenCoder asigna una puntuación de incertidumbre específica de la fuente $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ a cada elemento recuperado, donde valores más altos indican una menor confianza en la relevancia, completitud o compatibilidad.
- La evidencia se califica mediante una combinación de similitud de coseno ( $r_m$ ), peso de intención de la fuente predicha ( $w_m$ ) e incertidumbre: $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ .
- La evidencia de baja confianza se filtra, y los elementos restantes se deduplican y clasifican bajo un presupuesto de contexto compartido.
Generación de Código Guiada por la Incertidumbre: El LLM genera código candidato condicionado por la consulta, el conjunto de evidencia filtrado y el rastro de incertidumbre por fuente.
Verificación y Mitigación de la Incertidumbre: Los candidatos generados se someten a comprobaciones estáticas y pruebas ejecutables. Se selecciona el primer candidato que pasa. Si ningún candidato bruto pasa, el sistema identifica el candidato "modo" (del grupo de autoconsistencia más grande) y realiza hasta dos rondas de reparación guiada por validación.

El marco también emplea el Refinamiento de API Consciente del Objetivo para eliminar APIs auto-recuperadas, redundantes o incompatibles con la intención antes de la generación.

Contribuciones Clave

Formulación: El artículo formula la generación de código a nivel de repositorio como una toma de decisiones bajo incertidumbre sobre evidencia heterogénea, yendo más allá del simple ranking de relevancia.
Marco de Trabajo: OpenCoder es un sistema unificado que estima la incertidumbre específica de la fuente y la operacionaliza a través del filtrado de evidencia, la integración de múltiples fuentes, la generación, la verificación y la reparación.
Análisis Factorial: A través de un análisis factorial completo de la evidencia de conocimiento de la API, el contexto del repositorio y la evidencia de código similar, los autores demuestran que la utilidad de la recuperación es dependiente de la interacción. No existe un ranking aditivo universal de las fuentes; el valor de una fuente específica depende de la evidencia acompañante y del backend del LLM.
Evaluación Controlada: Los autores llevan a cabo una evaluación rigurosa y emparejada en backends GPT y Gemini sobre tareas ejecutables de nivel de repositorio, aislando el impacto del procesamiento consciente de la incertidumbre de la verificación y reparación posteriores.

Resultados Experimentales

La evaluación utiliza un conjunto expandido de 32 tareas RepoExec-inline emparejadas y una prueba de estrés en 10 tareas ExecRepoBench de contexto parcial.

Rendimiento de GPT: En el conjunto de 32 tareas RepoExec-inline, OpenCoder mejoró la corrección de la salida seleccionada del 56.25% (Baseline RAG) al 78.13% (una ganancia de 21.88 puntos porcentuales, $p = .039$ nominal). Sin embargo, empató con el control RAG + Verify/Repair (que utiliza la misma evidencia pero carece de filtrado consciente de la incertidumbre), lo que sugiere que la ganancia sobre el Baseline RAG está impulsada principalmente por el presupuesto de verificación/reparación más que por el filtrado de incertidumbre por sí solo.
Rendimiento de Gemini: Para Gemini, las diferencias entre OpenCoder, Baseline RAG y el control no tuvieron soporte estadístico. El control (RAG + Verify/Repair) fue el más fuerte en la mayoría de las métricas.
Efectos de Interacción: El análisis factorial (RQ1) reveló que ninguna fuente de evidencia individual tuvo un efecto marginal estadísticamente significativo en el rendimiento. En cambio, se observaron interacciones significativas entre fuentes (por ejemplo, el contexto del repositorio y la evidencia de código similar mostraron una interacción positiva para GPT).
Recuperación de API: El refinamiento consciente del objetivo mejoró sustancialmente la recuperación del conjunto de APIs, aumentando el macro F1 del 43.4% al 64.8% para GPT y al 59.1% para Gemini.
Condiciones Límite: En la prueba de estrés de contexto limitado de ExecRepoBench, el control RAG + Verify/Repair superó sustancialmente a OpenCoder. Esto indica que, cuando la evidencia del repositorio es incompleta, el filtrado consciente de la incertidumbre puede suprimir alternativas útiles en lugar de mejorar la decisión final.

Significado y Reivindicaciones

El artículo sostiene que la incertidumbre es más útil no como una estimación de confianza aislada, sino como una señal de control operacional acoplada con la fusión de evidencia, la validación ejecutable y la reparación.

Dependencia del Backend: Los beneficios de OpenCoder dependen del backend. Si bien mejoró significamente la selección de salida de GPT sobre el RAG simple, no mostró ventajas estadísticamente significativas sobre un control de verificación y reparación, ni mostró beneficios claros para Gemini.
Completitud de la Evidencia: La efectividad del marco depende de la completitud de la evidencia del repositorio. En escenarios con evidencia incompleta, el mecanismo de incertidumbre puede filtrar inadvertidamente información necesaria.
Control Accionable: La principal contribución es el cambio de optimizar qué recuperar a modelar qué tan fiable es la evidencia recuperada, utilizando esa señal para guiar el filtrado y la generación.

Los autores concluyen que, si bien OpenCoder demuestra el potencial de la integración consciente de la incertidumbre, sus ventajas dependen del backend de LLM específico y de la calidad/completitud de la evidencia del repositorio recuperada. Enfatizan que el código generado aún requiere la revisión del desarrollador y pruebas específicas del proyecto.