Resumo Técnico: Estrutura de Migração de Código Baseada em LLM com Ajuste Fino (Fine-tuning)

Declaração do Problema

Migrar sistemas de gerenciamento de banco de dados (DBMS) de grande escala de Oracle para PostgreSQL é um desafio complexo e interdisciplinar que vai muito além da simples conversão de sintaxe. Os autores identificam várias barreiras críticas:

• Disparidades Semânticas e Estruturais: Existem diferenças significativas entre Oracle PL/SQL e PostgreSQL PL/pgSQL em relação à sintaxe, tipos de dados, comportamento de cursores e estratégias de otimização de consultas.
• Escala e Dependência: Grandes bases de código frequentemente contêm centenas de milhares de arquivos interdependentes, o que torna a análise e a transformação automatizadas difíceis.
• Limitações de Ferramentas Existentes: Ferramentas tradicionais baseadas em regras (ex: AWS Schema Conversion Tool, Ora2PG) têm dificuldade com análise contextual profunda, SQL dinâmico, gatilhos (triggers) complexos e tratamento de exceções, resultando frequentemente em traduções incompletas ou derivação semântica.
• Limitações de LLMs: Embora os Grandes Modelos de Linguagem (LLMs) mostrem promessa, eles frequentemente sofrem de erros sistemáticos, como derivação semântica, incompatibilidades de chamadas de API e inconsistências no mapeamento de estruturas de controle quando aplicados diretamente sem adaptação específica ao domínio.

O problema científico central é a falta de uma estrutura unificada e iterativa que equilibre o ajuste fino (fine-tuning) com a engenharia de prompt para garantir a integridade semântica, minimizar riscos arquitetônicos e alcançar alta fidelidade na migração de bibliotecas de código massivas e heterogêneas.

Metodologia

A solução proposta é uma estrutura iterativa e escalável que integra IA Generativa (GAI) com técnicas tradicionais de engenharia de software. A metodologia é estruturada em torno de vários componentes principais:

1. Racional do Ajuste Fino em Dois Estágios

Os autores rejeitam um evento único de aprendizado holístico em favor de um pipeline de ajuste fino de instrução em dois estágios:

• Estágio 1 (Alinhamento Sintático): O modelo é treinado em um conjunto de dados que pareia código com descrições em linguagem natural (<Código> : <Descrição>). Esta fase foca em aprender os padrões estruturais, nuances de dialeto, assinaturas de tipos e regras de escopo de ambos o Oracle e o PostgreSQL, sem realizar a conversão direta.
• Estágio 2 (Comportamento de Transformação): O modelo é ajustado em pares de transformação direta (<Código Oracle> : <Código PostgreSQL>). Este estágio desloca o modelo da compreensão sintática para a conversão de lógica procedimental, garantindo a preservação semântica enquanto transforma blocos, cursores e exceções.

2. Mecanismo de Perfilamento de Características de Código Híbrido (HCFPE)

Para gerenciar a heterogeneidade da base de código, o HCFPE anota o corpus com metadados de características SQL (marcadores de sintaxe, estruturas de fluxo, operadores específicos de dialeto). Isso converte o código não estruturado em uma representação estruturada, permitindo a criação de conjuntos de dados estratificados (pequenos, médios, grandes) e garantindo que os dados de treinamento reflitam com precisão a distribuição de características como RMAN, SQL*Plus e PL/SQL.

3. Arquiteturas de Base de Conhecimento e RAG

A estrutura emprega Geração Aumentada de Recuperação (RAG) com duas estratégias distintas:

• Estratégia A (Base de Conhecimento Híbrida): Utiliza três bancos de dados vetoriais separados para código Oracle, documentação do PostgreSQL e regras de transformação derivadas de Especialistas no Assunto (SME). Isso permite que o LLM realize a triangulação de contexto, aplicando regras determinísticas e documentação de sintaxe autoritativa junto a exemplos de código.
• Estratégia B (Base de Conhecimento Unificada): Utiliza um único banco de dados vetorial contendo apenas pares de transformação direta "Oracle-PostgreSQL". Isso testa a capacidade do modelo de generalizar baseando-se apenas em exemplos, sem imposição explícita de regras.

4. Humano no Ciclo (Human-in-the-Loop) e Correção de Erros

A estrutura incorpora uma lógica de iteração de ciclo fechado:

• Avaliação: As saídas são avaliadas usando métricas de NLP (Recall, BLEU, ChrF) e validadores estruturais (verificadores de sintaxe, analisadores estáticos).
• Análise de Erros: Os erros são categorizados em grupos de sintaxe, semântica, estruturais e funcionais.
• Feedback de SME: Especialistas no Assunto intervêm apenas em amostras ambíguas ou complexas. Seu feedback é usado para expandir o conjunto de dados e refinar as anotações.
• Estimativa de Dataset: Um mecanismo matemático calcula uma métrica de "Gap" ($GAP_{Feature}$) para cada característica SQL. Esta métrica combina a representação do dataset ($GAP_{Dict}$) e a qualidade do modelo ($GAP_{Quality}$) para priorizar automaticamente quais características requerem amostras de treinamento adicionais para a próxima iteração.

5. Pipelines Experimentais

O estudo avalia quatro pipelines distintos:

1. Conversão Direta: Conversão baseada em prompt padrão sem contexto externo.
2. Conversão Consciente de Histórico: Incorpora chunks gerados anteriormente como contexto para manter a consistência de estado.
3. RAG Estratégia A: Recupera contexto heterogêneo (regras, docs, código).
4. RAG Estratégia B: Recupera apenas exemplos de transformação pareados.

Principais Resultados

O estudo avaliou múltiplos modelos (Qwen32B, Qwen7B, variantes do GPT-4) contra a ferramenta tradicional Ora2PG usando um dataset de mais de 1.800 arquivos estratificados por tamanho.

• Superioridade dos LLMs com Ajuste Fino: O modelo Qwen32B ajustado (Qwen32B-ft2) superou consistentemente todos os outros candidatos e a ferramenta Ora2PG. No pipeline de Conversão Direta, ele alcançou uma eficiência de conversão de arquivos de 74,57%, comparado a 49,66% do Ora2PG.
• Redução de Erros: O ajuste fino reduziu significativamente as Taxas de Erro de Sintaxe (SER). O modelo Qwen32B-ft2 produziu o menor número de arquivos contendo erros (205) e o menor número total de erros (3.554) no pipeline de conversão, enquanto os modelos base e LLMs menores acumularam volumes de erro significativamente maiores.
• Cobertura de Características: Modelos com ajuste fino demonstraram melhor alinhamento com as distribuições esperadas de características do PostgreSQL. Por exemplo, o Qwen32B-ft2 alcançou 72,3% de cobertura para CORE_SQL e 69,1% para conversão de PL/SQL para PL/pgSQL, enquanto o Ora2PG mostrou perda substancial de informação (ex: 47,5% de cobertura de PL/SQL) e subprodução sistemática de lógica procedimental.
• Impacto do RAG: Embora o RAG tenha proporcionado benefícios adicionais, o pipeline consciente de histórico e a conversão direta com modelos ajustados forneceram os resultados mais estáveis. A Estratégia A (Híbrida) ofereceu robustez para características complexas, enquanto a Estratégia B mostrou forte desempenho quando havia conjuntos de dados pareados de alta qualidade disponíveis.
• Impacto Econômico: Os autores estimam que uma única iteração de ajuste fino permitiu a migração automática de aproximadamente 27.690 arquivos a mais do que o Ora2PG permitiria. Isso se traduz em uma redução de cerca de 9 meses-pessoa de trabalho manual de SME para um codebase de 100.000 arquivos.

Significância e Alegações

O artigo alega fornecer uma fundação metodológica para migração de banco de dados em larga escala que aborda a lacuna entre a automação baseada em regras e a complexidade semântica de bases de código modernas.

• Controle de Qualidade Iterativo: A principal contribuição é o mecanismo de "estimativa de dataset baseado em GAP", que transforma a migração de uma tarefa de engenharia estática em um loop de otimização orientado a dados. Isso permite a expansão direcionada do dataset, garantindo que as melhorias do modelo sejam impulsionadas por déficits de desempenho específicos, em vez de uma acumulação cega de dados.
• Escalabilidade: A estrutura é projetada para lidar com bibliotecas de escala empresarial (100.000+ arquivos) decompondo a qualidade da migração em métricas de nível de característica, evitando o crescimento exponencial do trabalho manual associado aos métodos tradicionais.
• Abordagem Híbrida: O estudo valida que uma combinação de ajuste fino em dois estágios (para competência estrutural) e RAG (para fundamentação contextual) produz resultados superiores do que qualquer uma das abordagens isoladas ou ferramentas tradicionais baseadas em regras.
• Viabilidade Econômica: Ao quantificar a redução do esforço manual, o artigo argumenta que a migração baseada em LLM não é apenas tecnicamente viável, mas economicamente vantajosa, oferecendo um ROI rápido mesmo com uma preparação inicial modesta de dataset (30 mil amostras de treinamento preparadas em seis sprints).

Os autores concluem que, embora a validação em nível de execução permaneça um objetivo futuro, a estrutura proposta estabelece com sucesso uma abordagem escalável, precisa e economicamente viável para a modernização de bancos de dados empresariais.