2026年6月14日星期日2026 年 6 月 14 日
- 在前往首尔的巴士上重新梳理了对 Godot 4 数据集/RAG 流水线的疑问
- 之前设想先爬取 Godot 官方文档，再把 GitHub 项目转换为
md、jsonl 格式，随后通过 RAG 聊天机器人判断是 Godot 3 还是 Godot 4
- 但实际担心是否能一次性把整个项目上下文和检索到的官方文档片段全部放入模型输入上下文中
- 思考 RAG 聊天机器人输入上下文的限制
- 单个 GitHub 项目就包含 README、目录结构、多个
.gd 文件、场景文件、资源路径等
- 再加上通过 RAG 检索到的官方文档，会导致输入体积膨胀，因此比起单纯收集文档，更需要设计如何挑选文件和文档片段
- 整理对问答数据集形式的疑问
- “帮我做个地图” 这类请求可能并非只需要一段代码答案就能解决
- 实际上需要先了解项目结构、确认使用的资源、分析已有代码风格、审查 Godot 4 语法、决定要修改的文件等多个推理步骤
- 因此在 instruction 数据集中仅放最终代码是否足够，还是需要把探索与判断过程也保留下来成为思考点
- 考虑在块级处理时 Python 权重可能再次占优势的风险
- 即使请求 “用 Godot 4 做个地图”，模型在块级读取项目和文档时，仍可能因预训练时的 Python 权重而倾向生成 Python 代码
- 需要在提示前部强力注入 Godot 4 上下文，并在数据预处理阶段更严格过滤掉混入的 Godot 3 代码或 Python 风格答案
- 今日总结
- RAG 或爬虫本身并非根本解决方案，关键是设计模型在实际请求中读取何种上下文、做何种判断
- 将项目上下文按文件/角色/依赖划分，instruction 数据不仅包含最终答案，还在必要时加入探索与判断流程的记录方向进行评估
- 为防止 Godot 4 上下文在推理过程中被稀释，需要在提示、标签、过滤、偏好数据标准上更强力地进行设计
- 开发回顾: docs/retrospectives/2026-06-14.md