存储表结构 RAG 与 Skill 哪个更优？

[TimG]

最近接到任务尝试使用 qwen3.8 搭建内部数据分析平台，目前还是第一次尝试，离线基础环境已经配置好，我使用 2 年前的过时经验把表结构存到 chromadb ，用 mcp 服务器暴露给 opencode 调用。因为在离线环境，模型无法查阅数据库支持的函数文档，想再去官网 curl 一个文档，分块再存进知识库，顺便问了一下 deepseek ，它建议我把文档与表结构都做成 reference 给模型，说是方便维护且保持文档连续完整。

在我 2 年前的保守想象中，给上下文载入一堆 skill+reference+表结构无疑会撑满，即使对表结构按照业务模块分文件，单个 500+字段的模块也遍地都是。并且我个人理解表结构并不特别需要连续性，只要知道是一个表的内容拼凑所需字段就可以。

我的原本的构思中，是想要将这些文档尽可能存入 RAG 数据库，然后通过 skill 声明主要业务表与业务流程概况。降低上下文长度，但如果模型能力强大，已经能保持长上下文依然注意力集中，那么毫无疑问就沦为了过度设计。但我对 llm 的了解大概就在两年前的水平，麻烦各位朋友给出个招，谢谢！

[zh3256]

先用 skill 做，遇到问题再解决，不要提前预设问题。

[TimG]

@zh3256 了解了，这确实是非常务实的方式。谢谢！

[lev1s]

首版上渐进式 skill 拆多个 ref ，一边先做着 RAG ，业务复杂上来了用 hook 触发 prompt 前的 RAG

[TimG]

@lev1s 了解，好专业！谢谢！

[Rat3]

是类似问数系统吗，关注下

[TimG]

@Rat3 是的，deepseek r1 刚引起本地化部署热潮时我们曾经探索过一次，但是当时的表现很差，基于单次问答+RAG 的模式就像个酒蒙子渣男：干完就跑路，再问就道歉。需要大量维护知识库不说，遇到稍微复杂的语句就开始胡言乱语，简而言之：只能忽悠一下，没法真正干活。
但具备 agent tool 能够自己探索的模型在目前的测试中表现亮眼，特别是这个 qwen3.8 ，连接 dbhub 这种 mcp 服务器有望在客户数据隐私要求严格的局域网环境下低成本完成一部分数据分析工作。

[Rat3]

@TimG #6 我最近也在尝试，首先我搞了个语义层，拆算子之类的，发现承接维护难度太高了，也在为流程发愁

[TimG]

@Rat3 我们想着能给内部数据工程师先用起来，内部库和表太多了，分担点写 SQL 的工作压力，所以没考虑语义层，哈哈哈。直通普通用户的话，难度确实挺大。

[Zhuzhuchenyan]

对于更新频率很低的文档查阅类的需求，现在我们团队都是统一用 https://llmstxt.org 提供的实践来让 agent 自行查阅了
更新比较勤的框架基本都自带了，例如
https://angular.dev/llms.txt
https://reactflow.dev/llms.txt
内网的话完全可以克隆一份当前版本的支持文档，在内网部署后更改 llms.txt 的链接即可
这套方案的优势就是不依赖外部工具，前提是文档本身质量很高，并且更新频率不能太高。

[Dav1s]

@Zhuzhuchenyan 请教一下控制更新频率的目的是什么呀

[TimG]

@Zhuzhuchenyan 谢谢！很有参考价值。

[Zhuzhuchenyan]

@Dav1s 因为还有维护 llms.txt 的成本，所以每次框架大版本更新的时候都要重新检查是否更新了 llms.txt 。
对于不更改整体文档结构的小修小补，不涉及到 llms.txt 的更新频繁点也无所谓。

[zxjxzj9]

做成 mcp 最好也是有结构的做, 比方说你的文档就和书一样有第几章第几节的, 你就写一个 mcp 来快速让 ai 能通过一小段话找到这个内容可能在第几章第几节,然后在通过第几章第几节拿到完整内容. 文档尽量剥离上下文,第几章第几节自己的内容就够 相当于利用树结构天然做嵌入了(而不是直接用 embeding 模型来做)

[TimG]

@zxjxzj9 了解了。有明确索引方式的，不能用 embedded 模型去索引，增加命中概率。谢谢。