先说结论：仓库里攒的那一堆 SOP、设备手册、异常处理记录，如果想让员工和客服"开口就问大模型"，九成情况下该搭 RAG 知识库，不是去微调一个模型。微调是烧钱养模型，RAG 是给模型配一本随时能翻的活页手册。仓库的文档三天两头变，微调一次的功夫，RAG 早更新了几十版了。
去年一个做 3PL 的客户找我，洛杉矶东边一个 12 万平方英尺的仓库，托盘位两万多个，SOP 文件散落在共享盘、邮件附件和几个老师傅的脑子里。新员工入职，培训两周还是不敢独立上岗，夜班遇到异常只能打电话把主管从床上叫起来。老板一句话："能不能让员工直接问大模型，别老打电话问人？"两家供应商给了两套方案：微调一个专属模型，或者做 RAG 知识库，报价差了好几倍。客户问我选哪个，我只问了他三件事：你们的 SOP 多久更新一次？异常处理记录愿不愿意整理成干净文本？有没有人长期维护这个模型？三问下来，他自己就有了答案。
微调到底在调什么？
先拆一个最常见的误区：微调不是"把文档喂给模型，让它把内容记住"。微调真正改的是模型的行为习惯——让它说话像你们公司的口吻、回答按你们的流程框架来。但它对具体事实的记忆是糊的。今天刚更新的截单时间，昨天微调好的模型照样可能按旧时间回答你，还答得一脸自信。行内把这叫幻觉，微调治不了它，反而因为顶着"这是我们自己调的模型"的名头，让人更敢信，错得更踏实。
微调还有一个仓库行业特有的坑：样本量。你们手里有多少高质量的问答对？几百条 SOP 文档，撑不起一次像样的微调。数据不够还硬调，调出来的模型回答质量还不如直接问通用大模型。更麻烦的是后面：新开一个仓、换了一套分拣设备、接了个有特殊包装要求的大客户，数据又得重新准备、模型又得重新调、效果又得重新验。一轮下来几万美金量级砸进去，换来的只是一个"说话像我们公司"的模型，问到具体条款照样现编。
还有一笔账很少有人算：微调把你和某一家模型供应商绑死了。基座模型几个月就换一代，你调好的版本跟不上，等于白调。仓库的 IT 团队本来就薄，再养一个"模型维护"的长期包袱，多数公司扛不住。
更实际一点：微调的数据准备本身就是个大工程。问答对不是把 SOP 复制粘贴就行，得有人一条条写出"员工会怎么问、标准答案是什么、哪些说法是错的"。一个中等规模的 3PL，真要凑出够用的高质量样本，业务骨干得搭进去几个月的时间。这些时间如果花在整理知识库上，RAG 当天就能用上；花在准备微调数据上，几个月后才可能看到一个不确定的结果。这笔时间账，老板们最好先算清楚。
RAG 是怎么做到的？
RAG 的思路很土，但对仓库出奇地管用：员工提问时，系统先从你的知识库里把最相关的几段文档找出来，连着问题一起交给大模型，让它"照着材料回答"。材料变了，更新知识库就行，模型本身不用动。SOP 今天改了，明天员工问到的就是新版本。这个"模型不动、材料常新"的特性，恰恰对上了仓库文档高频变化的现实。
有意思的是，RAG 里"先找材料"这一步，玩的正是仓库人每天干的活——分类和索引。SOP 按作业流程分，设备手册按机型分，异常记录按原因代码分，客户特殊要求按客户编号分。做过仓储系统选型的人都懂：检索准不准，七分在索引建得好不好，三分在模型。那个 3PL 客户后来做了统计，客服接到的咨询翻来翻去就是几十条高频问题：截单时间、退货地址、某个大客户的特殊贴标要求。这些问题 RAG 答得又快又准，因为答案本来就躺在文档里，不需要模型"记住"任何东西。
当然 RAG 也有它的麻烦，而且很现实。第一条：文档写得烂，检索出来也是烂，"垃圾进、垃圾出"这句话在 RAG 上比在哪都灵。很多仓库的 SOP 是"仅供参考"的，真实操作靠老师傅口口相传，这种文档不先整理，RAG 就是个摆设。
我见过一个反例：达拉斯附近一个 8 万平方英尺的电商仓，SOP 里退货流程写了三版，分别躺在三个文件夹里，互相打架。RAG 上线第一周，员工问"退货怎么处理"，系统把三个版本一起找了出来，模型照着材料一总结，答得比文档还乱。后来他们花两周时间把文档合并成唯一版本，问题立刻消失。这个教训很实在：RAG 上线前，先回答一个问题——同一个问题，你的文档里有几个答案？超过一个，先合并文档，再谈 AI。
第二条麻烦是权限隔离。客户 A 的报价和操作要求，绝不能让服务客户 B 的客服问出来。知识库的权限得在设计第一天就想好，事后补非常痛苦。第三条：别指望 RAG 替你做判断。"这个月退货率偏高，根本原因是什么"这类需要跨文档推理的问题，RAG 只能给你找材料，下结论还得人来。
那微调什么时候才值得？
不是说微调一无是处，只是它的出场顺序在后面。当你发现 RAG 已经跑顺了、答得也对，但"味道"不对——客服话术要统一口径、异常上报要按固定格式输出、多语言站点要同一套说法——这时候拿少量高质量样本做一次轻量微调，是给 RAG 加分，不是替代它。顺序别搞反：先用 RAG 解决"答得对"，再考虑用微调解决"答得像"。
还有一种情况是极端合规或离线场景：数据不能出内网，检索和模型都得本地化部署。这种项目的预算和团队配置都不是普通仓库玩得起的，另当别论。对绝大多数仓库和 3PL 来说，RAG 是起点，也是很长一段时间的终点。等哪天你的 RAG 知识库里攒下了几千条被人工验证过的高质量问答，那才是一份真正值钱的微调数据资产——到时候再谈微调也不迟。
顺带说一句：下次再有供应商跟你推销"微调一个你们自己的大模型"，你就问他三句：训练数据谁来准备、模型多久重调一次、SOP 变了怎么办。这三问答不上来的，基本都是来卖 license 的，不是来解决问题的。
明天就能动手的一件事：别急着立项，先挑出员工和客服最常被问到的 50 个问题，把对应的 SOP 段落整理成干净文本，搭一个最小可用的 RAG 跑两周。两周后只看两个指标：回答准不准、大家愿不愿意用。这个试点花不了多少钱，但能回答那个最关键的问题：你们的知识库，到底有没有料。
