存储表结构 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 的工作压力，所以没考虑语义层，哈哈哈。直通普通用户的话，难度确实挺大。