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

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

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

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