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 为中心的预训练权重仍可能浮现
- 需要在提示前段强力注入 Godot 4 上下文，并在数据预处理阶段更严格过滤掉混入的 Godot 3 代码或 Python 风格答案
- 今日总结
- RAG 或爬虫本身并非解决方案，关键是设计模型在实际请求中读取何种上下文并作何判断
- 将项目上下文按文件/角色/依赖划分，instruction 数据不仅包含最终答案，还在必要时加入搜索与判断流程的记录方向进行评估
- 为防止 Godot 4 上下文在推理过程中被稀释，需要在提示、标签、过滤、偏好数据标准上更强力度设计
- 开发回顾: docs/retrospectives/2026-06-14.md