Resumen Técnico: Marco de Trabajo para la Migración de Código Basado en LLM con Ajuste Fino (Fine-tuning)

Declaración del Problema

La migración de sistemas de gestión de bases de datos (DBMS) a gran escala de Oracle a PostgreSQL es un desafío complejo e interdisciplinario que se extiende mucho más allá de la simple conversión de sintaxis. Los autores identifican varias barreras críticas:

• Disparidades Semánticas y Estructurales: Existen diferencias significativas entre Oracle PL/SQL y PostgreSQL PL/pgSQL en cuanto a sintaxis, tipos de datos, comportamiento de cursores y estrategias de optimización de consultas.
• Escala y Dependencia: Las bases de código extensas suelen contener cientos de miles de archivos interdependientes, lo que dificulta el análisis y la transformación automatizados.
• Limitaciones de las Herramientas Existentes: Las herramientas tradicionales basadas en reglas (por ejemplo, AWS Schema Conversion Tool, Ora2PG) tienen dificultades con el análisis contextual profundo, el SQL dinámico, los disparadores (triggers) complejos y el manejo de excepciones, lo que a menudo resulta en traducciones incompletas o deriva semántica.
• Limitaciones de los LLM: Aunque los Modelos de Lenguaje Extensos (LLM) muestran potencial, frecusec de errores sistemáticos como la deriva semántica, desajustes en llamadas de API e inconsistencias en el mapeo de estructuras de control cuando se aplican directamente sin una adaptación específica al dominio.

El problema científico central es la falta de un marco unificado e iterativo que equilibre el ajuste fino (fine-tuning) con la ingeniería de prompts para garantizar la integridad semántica, minimizar los riesgos arquitectónicos y lograr una alta fidelidad en la migración de bibliotecas de código masivas y heterogéneas.

Metodología

La solución propuesta es un marco escalable e iterativo que integra la IA Generativa (GAI) con técnicas tradicionales de ingeniería de software. La metodología se estructura en torno a varios componentes clave:

1. Racional del Ajuste Fino en Dos Etapas

Los autores rechazan un evento de aprendizaje holístico único en favor de un pipeline de ajuste fino de instrucciones en dos etapas:

• Etapa 1 (Alineación Sintáctica): El modelo se entrena con un conjunto de datos que empareja código con descripciones en lenguaje natural (<Código> : <Descripción>). Esta fase se centra en aprender los patrones estructurales, los matices del dialecto, las firmas de tipos y las reglas de alcance de ambos (Oracle y PostgreSQL) sin realizar una conversión directa.
• Etapa 2 (Comportamiento de Transformación): El modelo se ajusta mediante pares de transformación directa (<Código Oracle> : <Código PostgreSQL>). Esta etapa desplaza al modelo de la comprensión sintáctica hacia la conversión de la lógica procedimental, asegurando la preservación semántica mientras se transforman bloques, cursores y excepciones.

2. Motor de Perfilado de Características de Código Híbrido (HCFPE)

Para gestionar la heterogeneidad del corpus, el HCFPE anota el corpus con metadatos de características SQL (marcadores de sintaxis, estructuras de flujo, operadores específicos de dialecto). Esto convierte el código no estructurado en una representación estructurada, permitiendo la creación de conjuntos de datos estratificados (pequeños, medianos, grandes) y asegurando que los datos de entrenamiento reflejen con precisión la distribución de características como RMAN, SQL*Plus y PL/SQL.

3. Arquitecturas de Base de Conocimientos y RAG

El marco emplea Generación Aumentada por Recuperación (RAG) con dos estrategias distintas:

• Estrategia A (Base de Conocimiento Híbrida): Utiliza tres bases de datos vectoriales separadas para el código de Oracle, la documentación de PostgreSQL y las reglas de transformación derivadas de Expertos en la Materia (SME). Esto permite al LLM triangular el contexto, aplicando reglas deterministas y documentación de sintaxis autoritativa junto con ejemplos de código.
• Estrategia B (Base de Conocimiento Unificada): Utiliza una única base de datos vectorial que contiene solo pares de transformación directa "Oracle-PostgreSQL". Esto pone a prueba la capacidad del modelo para generalizar basándose únicamente en ejemplos sin la aplicación explícita de reglas.

4. Humano en el Bucle (Human-in-the-Loop) y Corrección de Errores

El marco incorpora una lógica de iteración de bucle cerrado:

• Evaluación: Los resultados se evalúan mediante métricas de NLP (Recall, BLEU, ChrF) y validadores estructurales (comprobadores de sintaxis, analizadores estáticos).
• Análisis de Errores: Los errores se categorizan en grupos de sintaxis, semántica, estructural y funcional.
• Retroalimentación del SME: Los Expertos en la Materia intervienen solo en muestras ambiguas o complejas. Su retroalimentación se utiliza para expandir el conjunto de datos y refinar las anotaciones.
• Estimación del Conjunto de Datos: Un mecanismo matemático calcula una métrica de "Brecha" ($GAP_{Feature}$) para cada característica de SQL. Esta métrica combina la representación del conjunto de datos ($GAP_{Dict}$) y la calidad del modelo ($GAP_{Quality}$) para priorizar automáticamente qué características requieren muestras de entrenamiento adicionales para la siguiente iteración.

5. Pipelines Experimentales

El estudio evalúa cuatro pipelines distintos:

1. Conversión Directa: Conversión basada en prompts estándar sin contexto externo.
2. Conversión con Conciencia de Historial: Incorpora fragmentos generados previamente como contexto para mantener la consistencia de estado.
3. RAG Estrategia A: Recupera contexto heterogéneo (reglas, documentos, código).
4. RAG Estrategia B: Recupera únicamente ejemplos de transformación emparejados.

Resultados Clave

El estudio evaluó múltiples modelos (Qwen32B, Qwen7B, variantes de GPT-4) frente a la herramienta tradicional Ora2PG utilizando un conjunto de datos de más de 1,800 archivos estratificados por tamaño.

• Superioridad de los LLM con Ajuste Fino: El modelo Qwen32B ajustado (Qwen32B-ft2) superó consistentemente a todos los otros candidatos y a la herramienta Ora2PG. En el pipeline de Conversión Directa, alcanzó una eficiencia de conversión de archivos del 74.57%, comparado con el 49.66% de Ora2PG.
• Reducción de Errores: El ajuste fino redujo significativamente las Tasas de Error de Sintaxis (SER). El modelo Qwen32B-ft2 produjo la menor cantidad de archivos con errores (205) y el menor recuento total de errores (3,554) en el pipeline de conversión, mientras que los modelos base y los LLM más pequeños acumularon volúmenes de error significativamente mayores.
• Cobertura de Características: Los modelos con ajuste fino demostraron una alineación superior con las distribuciones esperadas de características de PostgreSQL. Por ejemplo, Qwen32B-ft2 logró una cobertura del 72.3% para CORE_SQL y del 69.1% para la conversión de PL/SQL a PL/pgSQL, mientras que Ora2PG mostró una pérdida sustancial de información (por ejemplo, 47.5% de cobertura de PL/SQL) y una subproducción sistemática de lógica procedimental.
• Impacto de RAG: Aunque RAG proporcionó beneficios adicionales, el pipeline con conciencia de historial y la conversión directa con modelos ajustados produjeron los resultados más estables. La Estrategia A (Híbrida) ofreció robustez para características complejas, mientras que la Estrategia B mostró un fuerte desempeño cuando se disponía de conjuntos de datos emparejados de alta calidad.
• Impacto Económico: Los autores estiman que una sola iteración de ajuste fino permitió la migración automática de aproximadamente 27,690 archivos más de los que Ora2PG habría podido migrar. Esto se traduce en una reducción de aproximadamente 9 meses-persona de labor manual de SME para un corpus de 100,000 archivos.

Significación y Reivindicaciones

El artículo afirma proporcionar una base metodológica para la migración de bases de datos a gran escala que aborda la brecha entre la automatización basada en reglas y la complejidad semántica de los entornos de código modernos.

• Control de Calidad Iterativo: La principal contribución es el mecanismo de "estimación de brecha basada en GAP", que transforma la migración de una tarea de ingeniería estática en un bucle de optimización impulsado por datos. Esto permite una expansión de datos dirigida, asegurando que las mejoras del modelo sean impulsadas por déficits de rendimiento específicos en lugar de una acumulación ciega de datos.
• Escalabilidad: El marco está diseñado para manejar bibliotecas de escala empresarial (100,000+ archivos) mediante la descomposición de la calidad de la migración en métricas a nivel de característica, evitando el crecimiento exponencial de la carga de trabajo manual asociado con los métodos tradicionales.
• Enfoque Híbrido: El estudio valida que una combinación de ajuste fino en dos etapas (para la competencia estructural) y RAG (para el anclaje contextual) produce resultados superiores en comparación con cualquiera de los dos enfoques por sí solos o con las herramientas tradicionales basadas en reglas.
• Viabilidad Económica: Al cuantificar la reducción del esfuerzo manual, el artículo argumenta que la migración basada en LLM no solo es técnicamente factible, sino también económicamente ventajosa, ofreciendo un ROI rápido incluso con una preparación inicial modesta de datos (30k muestras de entrenamiento preparadas en seis sprints).

Los autores concluyen que, si bien la validación a nivel de ejecución sigue siendo un objetivo futuro, el marco propuesto establece con éxito un enfoque escalable, preciso y económicamente viable para la modernización de bases de datos empresariales.