2026-06-17 Godot RAG 判别器基础数据生成结构备忘

结构图片

核心思路

此结构的核心是不给 LLM 最终标签的决定权。LLM 负责生成辅助工作，如修改代码、说明、SFT 问答、DPO 差答、patch 草案等，而实际标签和最终 JSONL 的组装/验证则由本地系统流水线决定。

概括如下原则。

LLM是生成辅助  
标签由系统决定  
最终 JSONL 由管道组装/验证

整体流程

文档准备  
-> 本地数据库构建  
-> 输入GitHub源数据  
-> 符号提取  
-> 规则/向量/关键词搜索  
-> 标签评分及决定  
-> LLM生成辅助  
-> 最终JSONL生成

这是一份用于在同一流水线中生成 Godot 3/4 分类、API 映射、迁移修复、指令 SFT、DPO 偏好、仓库浏览器、补丁生成、元数据验证 数据的草案。

1. 文档准备

在离线阶段收集并整理 Godot 官方文档。

• 收集 Godot 官方文档
• 删除不必要的文字
• 文档类型分类
• 基于结构的解析
• 生成文档块
• 嵌入并构建索引

生成的基本产出：

docs_chunks.jsonl

2. 构建的 3 种核心数据库

API 映射数据库

保存 Godot 3 API 与 Godot 4 API 的变更关系。

示例：

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

保存文件:

api_mapping.jsonl

官方文档向量数据库

将文档块进行嵌入，创建用于依据检索的向量数据库。

用途：

• 检索相关官方文档块
• 提供转换依据
• 说明 API 更改原因
• 减少幻觉

标签原型数据库

存储用于标签候选和相似度检索的原型。

示例标签：

godot3_code
godot4_code
mixed_code
broken_code

保存文件:

label_prototypes.jsonl

3. 搜索/标签决定

GitHub中收集的原始数据进入后，系统首先分析代码和文档。

输入示例：

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

系统提取符号。

示例：

KinematicBody2D
move_and_slide(velocity)
export var
yield

随后执行以下搜索。

• API 映射数据库查询
• 官方文档向量数据库搜索
• 标签原型数据库搜索

最终标签不是由 LLM 决定，而是通过系统评分决定。

示例：

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

4. LLM 生成辅助

LLM 并不直接决定标签，而是接受系统决定的标签和依据作为输入，以辅助生成任务。

可能的生成任务：

• 生成修改代码
• 生成说明/依据
• 生成 SFT 问题/答案
• 生成 DPO 差劲答案
• 生成文件浏览答案
• 辅助生成 patch
• 验证/问题分析

重要的点如下。

LLM 生成结果是草稿。  
标签、最终模式、confidence、是否验证由系统管理。

5. 最终 JSONL 生成

管道将系统结果和 LLM 生成结果组装为一个 JSON 对象。

在验证阶段检查以下内容。

• 必填字段是否存在
• 标签一致性
• 是否存在错误的 API 残留
• 重新计算 confidence
• 文档依据与输出的关联性

生成的 8 种数据集

1. 版本分类数据

文件：

version_classification.jsonl

内容：

• Godot 3/4/mixed/broken 分类
• valid_for_godot4 判断
• bad_apis 提取

2. API 映射 数据

文件：

api_mapping.jsonl

内容:

• old_api -> new_api 映射
• change_type, category 等

3. 转换/修改 正确 数据

文件:

migration_fix.jsonl

内容：

• before/after 代码
• 更改原因
• 设置列表

4. 问答 SFT 数据

文件：

instruction_sft.jsonl

内容：

• instruction/input/output
• 各种模式的示例

5. DPO 偏好数据

文件：

dpo_preference.jsonl

内容:

• chosen
• rejected
• 原因/条件

6. Repo Explorer 数据

文件:

repo_explorer.jsonl

• 为了解决工作/错误需要读取的文件预测
• 读取的原因

7. Patch 数据

文件：

patch_generation.jsonl

内容:

• before/after
• unified diff / patch
• 应用原因

8. 元/验证信息

文件:

metadata_verification.jsonl

内容:

• confidence
• 分数
• 依据
• 来源文档 chunk id
• 质量/风险 信息

执行摘要流程

GitHub 原始数据
-> 符号提取
-> 规则/数据库 搜索
-> 标签评分
-> LLM 生成辅助
-> 最终 JSON 组装及保存

核心原则

• 标签由系统决定。
• LLM仅承担生成辅助角色。
• 最终的 JSONL 由流水线组装并验证。
• 将依据文档、分数、confidence、来源信息一起保存。
• 务必检查是否仍有错误的 Godot 3 API。