采购分析

一、下午三点，老板丢过来一张截图 截图上是一个手打的表格：五家供应商的名字、每家供什么货，旁边一行手写的折扣——94 折、93 折、87 折。配一句话：「这几家，去年 9 月到今年 8 月，一共采购了多少？」 看起来是个再简单不过的问题。 如果你手上有系统，标准动作是这样的：找导出文件、按供应商筛选、求和、检查一下财年有没有对上、再算一遍打折前的金额。顺利的话一小时，不顺利的话，一下午就没了。 而我花了 90 秒。 不是因为我手快，也不是因为我记得住这些数字。是因为这个问题里所有会卡住你的地方，我的知识库早就知道了。 二、这个"简单问题"里藏着五道关 我把它拆开，你就明白"导个表就行"是个错觉。 第一关：哪个文件才是权威源？ 采购数据在我手上至少有两个来源：业务系统的导出，和财务部发的正式入库明细。更要命的是，从今年 1 月起财务口径替换了旧口径——旧的那套已经作废，但文件还好好地躺在硬盘上。选错文件，数字全错，而且错得特别像对的。 第二关：财年不等于自然年。 老板说的"去年 9 月到今年 8 月"，是 2025-09-01 到 2026-08-31。但你的系统默认按自然年汇总，所以导出来的第一版一定是错的，而且往往要等你对完总数才发现。 第三关：一个窗口，两套数据源，不能重复算。 旧系统的数据到 2026 年 6 月截止，财务新数据从 2026 年 1 月开始。中间有大半年是重叠的。直接拼起来会重复计算，只用旧的又会少掉两个月。 第四关：老板给的名字，不一定是系统里的名字。 这次最典型的是压缩机——我按老板说的那个品牌名去筛供应商，结果是零。系统是零。后来才发现，它是品牌，不是供应商：量分散在四个不同的代理商名下，只能靠物料名称里的品牌词把它捞出来。如果当时就停在"查无此家"，这个数就永久漏掉了。 第五关：要的是打折前还是打折后？含税还是不含税？ 老板问"采购了多少"，通常指实付。但一谈到返点（Rebate），双方真正博弈的是打折前的盘子——87 折的价目表里到底留了多少空间，才是谈判的战场。这两个数差了将近一成，答错一个，报价当场就漏了底。 五道关，每一道都不难。但每一道都要你自己"想起来"，而想起来这件事，在下午三点被人追问的时候，是最不可靠的。 所以"导个表就行"的真相是：你根本不是在跟一个求和操作搏斗，你是在跟五个从来没人记录过的判断搏斗。每做一个判断都要停下来想、去翻记录、去问人，或者赌一把。更要命的是这些判断之间没有提示，错了也不会报错——只有最后总数对不上的时候，你才知道前面某一关塌了。 这就是为什么这件事"顺利一小时，不顺利一下午"。差别不在你的 Excel 熟不熟，在你有没有把这五个判断提前固化下来。 三、有知识库的人，这五道关变成了一句话 我实际做的事只有一句：「调这五家供应商 FY26 的采购数据」。 后面发生的一切，全靠知识库里早就写好的东西： 关卡 靠什么自动解决 存在哪 用哪个文件 数据目录的 README 写明正式口径、作废文件及作废原因 数据源目录 财年怎么算 项目策略文件写死"FY = 9 月到次年 8 月" 根目录策略文档 中间重叠期 口径切换点 + 覆盖范围 + 已知缺陷，全部标注 数据说明文件 名字对不上 品牌、代理商、供应商的对照关系 索引与实体表 含税/不含税 金额口径、明细条数、重复行留档状态 每条数据说明 所以 AI 做的事不是"猜"，是照着已经固化好的口径去取数。这是本质区别——前者是概率，后者是流程。 ...

我有一个已经跑了一年多的本地知识库：PARA 结构、单索引 RAG + 卡片索引层、每日增量同步、21 题召回回归。检索能力经过验证——问"青春期孩子怎么沟通"它能从 300 问 Q&A 里精准捞出答案。 但上个月我问它一个问题，它露馅了。 我问：“铜管是不是涨价了？涨了多少？” RAG 给我捞回来几段文字，每段都说得像模像样。但我一对原始数据——数字对不上。模型从 78,647 行的采购长表里"挑"数字，挑错了行、错了口径，还挑得理直气壮。 这就是 RAG 的天花板：它能找到"哪份文件讲了什么"，但它算不准"数字到底是多少"。 长表格塞进上下文窗口，模型挑数就像让人在电话簿里核对账单——看错行的概率永远不为零。 这篇文章记录我怎么解决这个问题：给知识库加一层「SPU 卡片索引」，让 AI 从"在长表里挑数"变成"读一张预聚合的小卡片"。文末有完整的搭建方法和踩坑清单。 一、核心思路：三层分工 升级后的知识库分三层，每层只干自己擅长的事： 1 2 3 4 5 6 7 8 9 ┌─────────────────────────────────────┐ │ L4 输出层 聚合报告（TOP10/预警/对标） │ ├─────────────────────────────────────┤ │ L3 分析层 粗筛→族归组→下钻（prompt链） │ ← 新增 ├─────────────────────────────────────┤ │ L2 索引层 SPU 卡片 × 23,743 │ ← 新增 ├─────────────────────────────────────┤ │ L1 数据层 行级明细 78,647 行 │ ← 已有（Cost-DNA） └─────────────────────────────────────┘ RAG 层（原有）：负责"哪份文件讲了什么"——模糊知识、背景、方法论 卡片层（新增）：负责"数字到底是多少"——每个 SPU 一张预聚合的标准答案 LLM 层：只负责"这意味着什么"——解读、判断、建议 关键设计：卡片是 JSON 格式，刻意不进 RAG 索引。RAG 擅长语义匹配，不擅长精确算数——让它俩各守边界，互不污染。 ...