2026-06-17 Memória da Estrutura de Geração de Dados Baseada no Classificador Godot RAG

Imagem da Estrutura

Ideia Principal

O ponto central dessa estrutura é não delegar a decisão final do rótulo ao LLM. O LLM assume papéis auxiliares de geração, como código de correção, explicações, perguntas/respostas SFT, respostas ruins de DPO, rascunho de patch, enquanto a montagem/verificação final do rótulo e do JSONL é determinada pelo pipeline do sistema local.

Em resumo, seguem os princípios.

LLM é assistente de geração  
O rótulo é decidido pelo sistema  
O JSONL final é montado/verificado pelo pipeline

Fluxo geral

Preparação do documento
-> Construir DB local
-> Inserir dados de origem do GitHub
-> Extrair símbolos
-> Busca de regras/vetores/palavras‑chave
-> Pontuação e decisão de rótulos
-> Auxílio na geração de LLM
-> Gerar JSONL final

Esta estrutura é um rascunho para criar dados de classificação Godot 3/4, mapeamento de API, correção de migração, SFT de instrução, preferência DPO, explorador de repositório, geração de patches e verificação de metadados em um único pipeline.

1. Preparação da documentação

Na fase offline, coleta e refina a documentação oficial do Godot.

• Coleta da documentação oficial do Godot
• Remoção de texto desnecessário
• Classificação do tipo de documento
• Análise baseada em estrutura
• Geração de blocos de texto da documentação
• Criação de embeddings e índice

Produtos básicos gerados:

docs_chunks.jsonl

2. Três bancos de dados principais que serão construídos

Banco de Dados de Mapeamento de API

Armazena as relações de mudanças entre a API do Godot 3 e a API do Godot 4.

Exemplo:

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

Arquivo salvo:

api_mapping.jsonl

Documentação oficial Vetor DB

Transforme trechos de documentos em embeddings para criar um banco de dados vetorial para busca de evidências.

Uso:

• Busca de trechos de documentos oficiais relacionados
• Fornecimento de evidências de conversão
• Explicação dos motivos de alterações na API
• Redução de alucinações

Banco de protótipo de rótulos

Armazena um protótipo para busca de similaridade com candidatos a rótulos.

Exemplo de rótulo:

godot3_code
godot4_code
mixed_code
broken_code

Arquivo salvo:

label_prototypes.jsonl

3. Decisão de pesquisa/etiqueta

Quando os dados brutos coletados no GitHub chegam, o sistema primeiro analisa o código e a documentação.

Exemplo de entrada:

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

O sistema extrai símbolos.

Exemplo:

KinematicBody2D
move_and_slide(velocity)
export var
yield

Após isso, execute as seguintes buscas:

• Consulta ao banco de dados de mapeamento da API
• Busca no banco de dados vetorial da documentação oficial
• Busca no banco de dados de protótipos de rótulos

O rótulo final é determinado por pontuação do sistema, não por LLM.

Exemplo:

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. Auxílio à geração de LLM

O LLM não determina o rótulo diretamente, mas auxilia a tarefa de geração recebendo como entrada o rótulo e a justificativa decididos pelo sistema.

Tarefas de geração possíveis:

• Geração de código de correção
• Geração de explicação/justificativa
• Geração de perguntas/respostas SFT
• Geração de respostas ruins DPO
• Geração de respostas corretas para exploração de arquivos
• Auxílio à geração de patches
• Análise de validação/problemas

O ponto importante é o seguinte.

O resultado da geração do LLM é um rascunho.  
Rótulo, esquema final, confidence e verificação são gerenciados pelo sistema.

5. Geração final de JSONL

O pipeline monta o resultado do sistema e o resultado gerado pelo LLM em um único objeto JSON.

Na fase de validação, verifica‑se o seguinte:

• Existência dos campos obrigatórios
• Consistência dos rótulos
• Presença de APIs incorretas remanescentes
• Recálculo da confiança
• Conexão entre a evidência documental e a saída

8 conjuntos de dados gerados

1. Dados de classificação de versão

Arquivo:

version_classification.jsonl

Conteúdo:

• Classificação Godot 3/4/mixed/broken
• Determinação valid_for_godot4
• Extração de bad_apis

2. Dados de mapeamento da API

Arquivo:

api_mapping.jsonl

Conteúdo:

• old_api → new_api mapeamento
• change_type, category etc.

3. Dados de resposta de conversão/edição

Arquivo:

migration_fix.jsonl

Conteúdo:

• código before/after
• Razão da mudança
• Lista de configurações

4. Dados SFT de Perguntas/Respostas

Arquivo:

instruction_sft.jsonl

Conteúdo:

• instruction/input/output
• Amostras de padrões variados

5. Dados de preferência DPO

Arquivo:

dpo_preference.jsonl

Conteúdo:

• chosen
• rejected
• Razão/Condição

6. Dados do Repo Explorer

Arquivo:

repo_explorer.jsonl

Conteúdo:

• Previsão de arquivos que devem ser lidos para resolver tarefas/erros
• Razão para ler

7. Dados de Patch

Arquivo:

patch_generation.jsonl

Conteúdo:

• before/after
• unified diff / patch
• Razão da aplicação

8. Meta/Informação de validação

Arquivo:

metadata_verification.jsonl

• confiança
• pontuação
• fundamento
• ID do trecho do documento de origem
• informações de qualidade/risco

Fluxo resumido de execução

GitHub dados fonte
-> Extração de símbolos
-> Busca de regras/DB
-> Pontuação de rótulos
-> Assistência na geração de LLM
-> Montagem e armazenamento final do JSON

Princípios Fundamentais

• O rótulo é decidido pelo sistema.
• O LLM desempenha apenas o papel de assistência à geração.
• O JSONL final é montado e verificado pelo pipeline.
• Armazene juntamente os documentos de referência, pontuação, confiança e informações de origem.
• Certifique-se de verificar se há APIs do Godot 3 incorretas restantes.