2026-06-14 回顾

在前往首尔的巴士上产生的想法

今天在前往首尔的巴士上再次思考了上次设计的 Godot 4 数据集/RAG 流程。6 月 12 日，我爬取了官方文档，收集了 GitHub 上的 Godot 项目，并构思了在前端放置 RAG 聊天机器人，用于判断是 Godot 3 还是 4 并生成 instruction 数据的结构。

但是今天重新思考后，发现要让这个结构真正正常工作，还需要解决相当多的疑问。尤其是“收集了文档”和“模型能够很好地利用这些文档”之间的距离比想象的要大，这一点一直困扰着我。

第一个疑问：RAG 聊天机器人能否承担全部上下文

之前我以为只要爬取 Godot 官方文档并制作 RAG 聊天机器人，就可以用来分类或验证收集到的 GitHub 项目。但如果设想把 GitHub 项目抓取后转换为 md、jsonl 形式，然后一次性把内容喂给聊天机器人，就会产生疑问。

模型能否接受全部输入上下文？

即使是一个 Godot 项目，也会包含 README、目录结构、多个 .gd 文件、场景文件、资源路径等。如果再加上通过 RAG 检索到的官方文档片段，输入很快就会变得庞大。仅仅因为爬取了文档，并不意味着模型能够在每次请求时稳定地读取整个项目及相关文档。

归根结底，制作 RAG 聊天机器人并不是把文档整体塞进去，而是构建一个决定在何种提问下取哪段文档的检索/筛选结构。如果这部分做得不够严谨，模型可能会遗漏关键文件，或者因为读取不必要的文档而失去真正需要的项目上下文。

第二个疑问：一个问题只给一个答案代码是否足够

第二个产生的疑问是 instruction 数据集的形式。例如，考虑“帮我制作地图”这个问题，答案未必只是一个简单的代码块。

LLM 要真正给出答案，需要经过多个步骤。它要查看项目结构，了解有哪些场景和脚本，确认可用的资源，阅读已有的代码风格，检查是否符合 Godot 4 语法，最后决定要修改的文件和代码。

也就是说，“帮我制作地图”表面上是一个请求，但内部需要经过多个推理层次。如果训练数据只留下最终的答案代码，模型是否能够学习到这些中间判断过程就成了疑问。

正确的数据不仅仅是完整的代码，还可能需要包含要读取哪些文件、依据哪些信息做出判断、为何选择特定 API 等过程。尤其是想让它像编码代理一样工作时，保留“问题 → 搜索 → 判断 → 修改 → 验证”这样的流程可能更为合适。

第三个疑问：在块级处理时 Python 权重会不会再次冒出来

第三个疑问是语言权重问题。即使给出 “用 Godot 4 制作地图” 的提示，模型在把已有项目或文档按块读取的过程中，Python 代码或 Python 式问题解决模式的权重是否会更强，从而主导回答？

通用的编码模型很可能对 Python 学习得更多。如果仅仅在前面加上 “Godot” 这个词可能不足以抵消这种倾向。尤其是检索到的块中 Godot 4 的上下文不够强，或者在中间推理阶段想起了常见的编码模式，模型可能会倾向于给出 Python 风格的答案。

因此，仅仅说 “用 Godot 4 编写” 可能不够，需要在提示和数据预处理阶段更强地固定 Godot 4 的上下文。例如在输入数据中添加专用的 Godot 4 标签，或更严格地过滤混有 Godot 3/其他语言代码的数据，亦或在生成答案前反复注入 “此任务基于 Godot 4 GDScript” 的约束。

今日总结

今天的核心认识是 RAG 或爬取本身并不是解决方案。比起收集大量文档，更重要的是设计模型在实际请求中读取何种上下文、做何种判断。

目前的结构需要进一步细分为以下阶段：

• 不是一次性把整个项目放进去，而是基于文件/角色/依赖构建可检索的结构。
• 需要审视 instruction 数据是否仅包含最终代码，还是也要包括搜索和判断过程。
• 为防止 Godot 4 上下文在推理中被稀释，需要在提示、标签、过滤、偏好数据等方面更强地设计。

最终，要打造 “Godot 4 编码模型”，仅仅收集 Godot 4 代码是不够的。必须在数据中反映模型阅读项目的顺序、判断为 Godot 4 的依据以及如何选择好的答案。

回顾

今天虽然没有大量编写代码，但却是再次看到之前设计漏洞的一天。在巴士上发呆思考时，反而看到了在书桌前忽视的问题。说起来制作 RAG 聊天机器人很容易，实际上检索单元、上下文大小、问答数据结构、语言权重控制等都紧密相连。

答案尚未出现。但产生疑问本身是个好信号。若在此阶段记录下疑问，后续实现流水线时就有了检验的依据。

接下来需要基于这些疑问细化：项目上下文应如何切分单元、instruction 数据应包含到何种程度的推理过程、以及如何制定保持 Godot 4 上下文的预处理规则。