2026 年 6 月 12 日 | idea_world

久违地决定重新撰写开发回顾
- 由于一直想留下完美的记录，反而拖延了记录
- 为了有意义地留下过去约 10 天的尝试和思考，整理了为 Godot 专用编码模型进行调查和架构设计的过程
为了降低 RunPod 使用费用，尝试在本地 PC 部署 Qwen 系列模型
- 在 RTX 3060 环境下尝试通过 WSL 运行 9B 模型
- 但网络连接速度和响应延迟问题严重，实际生成答案前的思考阶段就耗时超过 5 分钟，遂中止本地运行实验
为了训练 Godot 专用模型，先调查数据集收集方式
- 将 Hugging Face 的 wallstoneai/godot-gdscript-dataset 作为参考数据集
- 通过 Gemini 分析该数据集的生成方式
- 核心是将 GitHub 仓库层面的 README.md、.gd 文件、项目结构合并为一段文本，并利用 project.godot 配置文件和 GDScript 语法差异对 Godot 3/4 版本进行分类
- 特别是利用 config_version、config/features、onready var、@onready、KinematicBody、CharacterBody3D 等版本线索，可对没有 JSON 依赖文件的非主流语言进行版本过滤，获得了此类洞见
为了理解微调流程，参考了针对 OPL 这门古老编程语言的微调视频
- 参考链接: https://www.youtube.com/watch?v=5wGD92ktQL4
- 但感受到数据集收集与实际可用于训练的形式是两个不同的问题
向 SSAFY 教练请教如何高效收集特定版本的非主流语言数据
- 目前参考的 Godot 数据集更像是用于 assistant 训练的 Q&A 数据集，而更接近原始代码数据集
- 若要制作聊天机器人产品，需要先用 LLM 生成问答对并加工为 instruction 数据集，而不是直接使用原始代码
- 否则在“帮我设计地图”等请求时，模型可能会生成大量基于 Python 的答案，因为它在 Python 上的训练更充分
将 ise-uiuc/Magicoder-Evol-Instruct-110K 作为 instruction 数据集候选进行检查
- 大多数内容以 Python 为主，直接用于 Godot 4 专用训练数据并不合适
- 虽然思考“是否可以在不明确提及 Godot 的情况下让模型给出 Godot 答案”，但由于现有模型的 Python 权重较大，明确提供 Godot 语境更有助于提升正确答案的概率
向学校前辈请教 RAG 与 Prompting 的方向
- 建议相较于将全部数据注入模型，先构建基于 Markdown 文档的向量检索结构，让模型通过检索获取所需信息，这种方式更为现实
- 由于对大规模文档进行重新索引的成本和时间较高，当前阶段更适合采用检索/Prompting 为主的结构，而非大规模训练
为构建 Godot 专用编码模型设计初步架构
- 最初设想的是 数据集收集 → 问答数据集生成 → 模型训练 的简单流程
- 但要准确进行过滤和答案生成，需要充分了解 Godot 3 向 4 的变化，否则可能会把 Godot 3 代码、Python 代码或旧版 API 混入答案中
- 因此重新思考了整体架构
为实现 Godot 3/4 版本分类与转换，设计在前端部署基于官方文档的 RAG 聊天机器人结构
- 爬取 Godot 官方迁移文档和 Godot 4 文档，构建 RAG 聊天机器人，并利用该机器人判断收集的数据是 Godot 3 还是 4
- 仅对被判定为 Godot 4 的数据进行 instruction 数据集加工
通过 ChatGPT 进一步获取 SFT/DPO 学习方向的洞见
- 在 SFT 中可以设计任务，如 Godot 3/4 分类、Godot 3 → 4 转换、Godot 4 代码生成、Godot 4 错误修复、Godot 3 API 拒绝/纠正等
- 在 DPO/Preference 中可以将 “差答案 = 混有 Godot 3 代码的答案” 与 “好答案 = 纯粹 Godot 4 代码的答案” 作为偏好数据进行构建
使用 unclecode/crawl4ai 爬取 Godot 官方文档
- 起始文档: https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html
- 包含 Godot 4 官方文档、Godot 3 → 4 迁移文档、Godot 4 类参考、Godot 4 教程等，累计约 1,500 页左右
- 虽然看起来量很大，但相对于模型的上下文容量，仅约占 3%
向学校前辈进一步请教数据存储与训练流水线的磁盘 I/O 瓶颈问题
- 建议不要实时进行微调，而是将数据获取与前后处理尽可能实时化，训练采用批处理方式更为合适
- 当数据集累计到一定规模后，再进行强化学习或微调，采用基于指标的批处理策略
- 由于重新索引成本难以完全消除，数据获取与加工流水线的稳定性比训练实时性更为关键
当前整理的整体方向
- 爬取官方文档，构建基于 Godot 4 的 RAG 知识库
- 收集 GitHub 上的 Godot 项目，按仓库合并 README、项目结构、GDScript 文件
- 利用 project.godot 配置和 Godot 3/4 语法差异进行第一轮过滤
- 通过 RAG 聊天机器人进一步判断 Godot 3/4、旧版 API 使用情况以及 Godot 4 适配性
- 从经筛选的 Godot 4 数据中生成 instruction/response 对
- 使用 SFT 与 DPO/Preference 数据训练 Godot 4 编码模型
回顾
- 过去 10 天因为只想留下完整成果，反而没有记录过程
- 但失败的实验、卡住的点、以及中途的判断变化，才是指引下一步方向的关键记录
- 今后不再追求只留下完美结果，而是持续记录尝试与判断的过程，以此不断进步
开发回顾: docs/retrospectives/2026-06-12.md