TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

Resumen Técnico: TICoder

Planteamiento del Problema

La generación de código a nivel de repositorio utilizando Modelos de Lenguaje de Gran Escala (LLMs) enfrenta desafíos significativos debido a las complejas dependencias de código y las ventanas de contexto limitadas. Aunque los enfoques existentes utilizan Generación Aumentada por Recuperación (RAG) y mecanismos de planificación para reutilizar funciones de un repositorio, los autores identifican dos limitaciones críticas en los métodos actuales del estado del arte (SOTA):

1. Falta de Guía Conductual Basada en Pruebas en la Planificación: Los métodos basados en la planificación existentes derivan los pasos de implementación directamente de los requisitos de lenguaje natural (NL). Sin embargo, los requisitos de NL suelen ser vagos o incompletos, lo que conduce a planes poco fiables. Los métodos actuales de generación impulsada por pruebas aplican principalmente los casos de prueba durante las etapas de generación de código o post-generación, dejando sin explorar su potencial para guiar el proceso de planificación.
2. Falta de Conciencia de la Implementación a Nivel de Código en la Reutilización: Las estrategias de recuperación existentes dependen fuertmente de la similitud semántica entre los pasos de implementación y las descripciones de las funciones. A menudo pasan por alto la lógica de implementación real incrustada en el código. Además, las funciones recuperadas se insertan con frecuencia en los prompts sin comprender cómo se utilizan realmente (patrones de uso) dentro del repositorio, lo que conduce a una reutilización ineficaz.

Metodología: Marco de Trabajo TICoder

Los autores proponen TICoder, un marco diseñado para mejorar tanto las fases de planificación como de reutilización en la generación de código a nivel de repositorio. El marco consta de tres etapas principales:

1. Planificación Iterativa Impulsada por Pruebas

En lugar de generar planes únicamente a partir de requisitos de NL, TICoder aprovecha los casos de prueba como especificaciones de comportamiento para refinar los pasos de implementación. Esta etapa emplea un mecanismo de "juez y reflexión" que involucra dos roles de LLM:

• LLM-como-Planificador: Genera una secuencia inicial de pasos de implementación basada en el requisito y los casos de prueba, guiada por principios como la claridad, la conciencia de las condiciones límite y las dependencias explícitas.
• LLM-como-Juez: Evalúa los pasos generados frente a tres dimensiones: cobertura/consistencia funcional, independencia y granularidad.
• Refinamiento Iterativo: Si los pasos no cumplen con los umbrales de calidad, el juez proporciona retroalimentación y el planificador refina los pasos. Este bucle continúa hasta que el plan es satisfactorio o se alcanza un límite máximo de iteraciones.

2. Reutilización de Código Consciente de la Implementación

Esta etapa se centra en recuperar las funciones llamadas (callees) relevantes e identificar cómo utilizarlas de manera efectiva.

• Recuperación de Funciones Callee de Doble Vista: Para recuperar funciones, TICoder calcula una puntuación de similitud conjunta que combina:
  • Similitud Funcional ($Sim_F$): Similitud semántica entre el paso de implementación y la descripción de la función.
  • Similitud de Implementación ($Sim_I$): Similitud entre una representación de código del paso de implementación (generada por un LLM) y el código de implementación real de la función.
  • La puntuación final es una suma ponderada ($Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$).
• Selección de Patrones de Uso de Dos Etapas: Para asegurar que las funciones se utilicen correctamente, TICoder selecciona patrones de uso representativos del repositorio:
  • Identificación Basada en Grafos: Construye un Grafo de Llamadas del Repositorio (RCG) para identificar todas las funciones llamadas por una función callee.
  • Clasificación Basada en Estructura: Agrupa las funciones llamadas basándose en el conjunto de funciones que invocan (equivalencia estructural).
  • Filtrado Basado en Perplejidad: Dentro de cada grupo, se selecciona el llamador más relevante (menor perplejidad) como el centro. Un filtro global luego clasifica estos centros por perplejidad para seleccionar los $n_p$ patrones superiores, equilibrando la riqueza del contexto con la eficiencia de tokens.

3. Generación de Código Mejorada

La fase final de generación de código integra los pasos de implementación refinados, las funciones callee recuperadas, los patrones de uso seleccionados, los casos de prueba y el requisito original en un único prompt para que el LLM genere el código final.

Principales Contribuciones

El artículo reclama tres contribuciones primarias:

1. Marco de Trabajo TICoder: Un nuevo marco de generación de código a nivel de repositorio que integra la planificación iterativa impulsada por pruebas y la reutilización de código consciente de la implementación.
2. Estrategia de Reutilización Consciente de la Implementación: Un mecanismo de recuperación de doble vista (similitud funcional + de implementación) y una estrategia de selección de dos etapas (clasificación + filtrado de perplejidad) para identificar y reutilizar con precisión las funciones del repositorio.
3. Evaluación Empírica Extensa: Experimentos exhaustivos que demuestran que TICoder supera a las líneas base SOTA a través de múltiples LLMs y benchmarks.

Resultados Experimentales

Los autores evaluaron TICoder en dos benchmarks ampliamente utilizados, CoderEval (Python y Java) y DevEval (Python), utilizando tres LLMs de base: GPT-4o-mini, DeepSeek-V3 y Qwen2.5-Coder-7B.

• Rendimiento General: TICoder superó consistentemente a todas las líneas base (incluyendo SimpleRAG, RepoCoder, AllianceCoder y RepoScope). Logró una mejora promedio del 11.52% sobre la mejor línea base.
• Significancia Estadística: Una prueba t de dos colas confirmó que las ganancias de rendimiento fueron estadísticamente significativas ($p < 0.05$).
• Estudio de Ablación: Eliminar cualquier componente clave (planificación, casos de prueba, refinamiento iterativo, recuperación de doble vista o patrones de uso) resultó en una degradación del rendimiento, validando la necesidad de cada módulo.
  • Notablemente, eliminar el módulo de planificación causó una caída del 6.87% en Pass@1.
  • Eliminar los casos de prueba de la etapa de generación causó una caída sustancial del 10.42%.
• Sensibilidad de Hiperparámetros:
  • Iteraciones: El rendimiento generalmente mejoró con las iteraciones pero fue no monotónico; las iteraciones excesivas podrían introducir ruido.
  • Pesos de Similitud: La similitud funcional fue generalmente más importante, pero la similitud de implementación proporcionó ganancias significativas, particularmente para Java.
  • Patrones de Uso: Un número moderado de patrones (por ejemplo, 2) produjo los mejores resultados; demasiados pocos limitaban el contexto, mientras que demasiados introducían ruido.

Significado y Reivindicaciones

El artículo afirma que TICoder aborda las limitaciones específicas de los enfoques previos de planificación RACG al incorporar explícitamente casos de prueba en la fase de planificación y fundamentar la recuperación en la lógica de implementación de código real. Los autores sostienen que, al cerrar la brecha entre los requisitos de lenguaje natural y el código ejecutable mediante especificaciones de comportamiento (pruebas) y contexto estructural (patrones de uso), TICoder permite a los LLMs generar código más preciso y contextualmente apropiado en entornos de repositorio complejos. El trabajo destaca que la generación exitosa a nivel de repositorio requiere no solo encontrar código similar, sino comprender cómo ese código está especificado conductualmente e integrado estructuralmente dentro de la base de código existente.