RAG 一接 Excel 知识库就开始跨工作表乱引用：从 Sheet Routing 到 Cell Provenance 的工程实战
企业里最容易被低估的知识源，不是 PDF，也不是网页，而是那一堆看起来“只是表格”的 Excel 台账。⚠️ 一旦销售、运营和财务把同一个客户写进不同工作表，RAG 很容易把旧口径、错日期和别的 sheet 备注拼成一句流畅却错误的答案。
[外链图片转存中…(img-Xuggs7Nm-1777911334815)]
很多团队做 Excel 知识库时，会先按行切块，再把列名拼到文本里送去向量库。📊 这种做法在单表 FAQ 上还能工作，但只要一个工作簿里同时存在“客户清单”“续费预测”“异常备注”三类 sheet，模型就会把业务边界不同的行召回到一起。🔍 业务系统真正需要的，是“这条答案来自哪张表、哪一列、哪个版本”。
跨工作表乱引用为什么这么常见
第一层问题是缺少Sheet Routing。🧭 用户问“某客户最新续费风险”时，系统如果不先判断该去risk_forecast还是manual_notes，召回阶段就会在所有 sheet 里平均撒网，最后把旧状态和临时判断混在一起。📌
第二层问题是证据没有单元格级来源。🧩 很多管线只记“命中了这个 chunk”，却不保留工作簿名、sheet 名、行号、列名和版本时间。等答案生成后，即使引用错了列，运维也很难快速定位问题发生在路由、召回还是拼接阶段。🚨
[外链图片转存中…(img-q4EyBTMN-1777911334818)]
Sheet Routing 先解决“该去哪张表”
更稳的做法，是先把每张 sheet 当成独立知识域，再基于问题意图做一次轻量路由。🛠️ 这次在37个真实工作簿上做了回放，为每张表额外索引列头摘要、业务归属和更新时间，先用小模型判断候选 sheet，再在候选范围内做向量召回。这样做不会增加太多时延，却能明显压低错表召回。✅
| 方案 | 正确工作表命中率 | 错列引用率 | 人工复核率 |
|---|---|---|---|
| 全工作簿直接召回 | 68% | 19% | 23% |
| Sheet Routing 后召回 | 91% | 7% | 9% |
defroute_and_retrieve(question,workbook_index,retrievers):candidate_sheets=workbook_index.route(question,top_k=2,features=["sheet_name","headers","owner","updated_at"],)hits=[]forsheetincandidate_sheets:hits.extend(retrievers[sheet].search(question,top_k=4))returnhits这段逻辑的关键不在“多调一次模型”，而在于把工作表边界前置成检索约束。🧪 如果系统已经知道问题更像续费风险判断，就不该让库存盘点 sheet 参与竞争。约束越早做，后面的重排和生成越不容易被噪声带偏。
[外链图片转存中…(img-9gadCYAQ-1777911334819)]
Cell Provenance 再解决“引用的是哪一格”
路由做对后，还需要把来源精确到单元格。📦 每条证据除了正文文本，还应携带workbook / sheet / row / column / header / version_ts六类字段，并在生成前做冲突检查：如果答案引用了两个不同版本的同名列，系统必须优先保留同一 sheet、同一版本的证据。📍 这一步本质上是在给 RAG 增加“可审计的引用骨架”。
在同一批回放里，加上Cell Provenance后，最终答案的跨表串义率从17%降到4%。⭐ 笔者认为，未来 3 到 6 个月，Excel 知识库更值得投入的不是更大的 embedding，而是把工作表路由、列头标准化和单元格级引用做成默认件。🤖 谁先把“答案对应哪一格”说清楚，谁的 RAG 才真正具备可上线能力。
[外链图片转存中…(img-Wwg8Hvru-1777911334820)]
一句话总结：Excel 知识库最容易出错的，不是召回不到信息，而是把不同工作表里的相似字段拼成一个“看起来像对”的答案。📎 如果当前系统还不能稳定回答“这条结论来自哪张表、哪一列、哪个版本”，上线规模越大，返工成本通常越高。你们的 RAG，已经做到单元格级引用了吗？