物流问题很少只存在于一份文档里。一个包裹延迟，可能同时涉及订单、仓库扫描、车辆路线、天气、承运商状态和客户约定。大语言模型能组织答案，却不能凭记忆知道这些持续变化的事实。
检索增强生成，也就是 RAG，先从外部资料中找到相关证据，再让模型基于证据回答。它为物流提供自然语言入口，但真正的难点不是接上向量数据库，而是让多方系统中的身份、时间和权限能够对齐。
## 物流检索有三种不同知识
第一种是相对稳定的规则与手册，例如设备说明、包装要求和异常处理流程。它们适合按章节切分、建立版本和关键词索引。
第二种是持续变化的状态，例如订单节点、库存、车辆位置和场站拥堵。它们不应被当作普通文档缓存，而要通过数据库或实时工具按需查询。
第三种是关系网络：订单属于哪个客户，由哪个承运商负责，经过哪些仓库，与哪些批次和设备关联。知识图谱或事件图可以表达这种连接，帮助系统从一个编号沿关系寻找证据。
把三者全塞进同一个向量库，会让过期状态、静态规则和关系查询互相干扰。
## 共同身份是生态协作的地基
不同系统可能用不同编号表示同一地点或货物。仓库写内部库位码，承运商写路线站点，客户只知道订单号。RAG 若无法解析它们的对应关系，就会检索到“相似但不是同一件事”的资料。
生态共建首先要建立主数据映射，并保留来源。系统可以把多个标识连接到统一实体，但不应抹掉原始编号。出现冲突时，回答要指出哪一方提供了什么状态、更新时间分别是多少。
时间同样关键。物流事实通常是事件序列，先到站、后复核、再改派。只检索最新一条可能失去原因，只按相似度找历史又可能混入旧订单。索引需要事件时间、记录时间和有效区间，查询也要明确“当前状态”还是“为何发生”。
## 混合检索比单一相似度更可靠
订单号、批次号和地点码适合精确或关键词检索，异常描述和自然语言问题适合语义检索，跨实体追踪则适合图查询。成熟系统会先识别意图，再组合这些方式。
例如，用户问“这批冷藏货为何延迟”，系统可先精确定位批次，沿事件图找到车辆与场站，再语义检索相关异常记录和操作规范。最后由模型按时间顺序归纳，并附上每条证据。
重排模型可以提高前几条结果质量，但必须用本地查询评测。通用相关性不一定理解物流中的时序和编号重要性。
## 回答必须带证据，也要允许没有答案
RAG 降低幻觉的关键，不是模型看到过文档，而是最终陈述能与具体证据对应。引用应指向稳定记录，显示来源、版本与更新时间。
当不同系统冲突时，模型不能挑一个看起来更顺的结论。它应并列展示差异，并说明需要哪一方确认。若关键事件缺失，则明确“目前无法确定”，触发补录或人工调查。
生成答案前还可做证据充分性检查：是否找到目标实体，时间是否覆盖问题，来源是否在用户权限内，引用能否支持结论。缺一项就降级为搜索结果或求助路径。
## 权限不能在生成之后才补
物流生态包含客户价格、路线、库存和承运商运营数据。检索必须在查询阶段执行权限过滤，不能先把全部资料交给模型，再试图从答案中删除敏感内容。
权限还会随组织与项目变化。索引项需要继承源系统的访问控制，并在人员离职、合同结束或订单关闭后及时更新。缓存也要按租户隔离。
共享知识可以采用分层方式：公开操作规范、合作方可见状态、组织内部记录和个人敏感信息分别管理。共同建设不等于共同看到一切。
## 评测要使用真实失败问题
标准问答集应覆盖编号查询、跨系统追踪、时间冲突、缺失事件、多语言描述和权限边界。只用知识库里能直接复制的常见问题，会高估系统能力。
检索层可以测召回率、前几位准确率和证据新鲜度；生成层检查事实支持、引用覆盖和拒答质量；业务层则看调查时间、人工转交和错误行动是否减少。
还要保存失败查询。用户换一种说法、扫描记录晚到、地点更名，都会产生新的长尾。各参与方共同标注这些案例，比一次性扩大文档量更能改善系统。
## 共建的是证据链，而不是一个聊天框
RAG 的界面可以很简单，背后却需要仓库、承运商、平台和客户一起维护主数据、事件时间、文档版本和访问规则。任何一方只提供无版本文件，都会让整个答案链条变脆弱。
物流生态的价值最终体现为更快找到可行动的事实，同时保留谁在何时提供了证据。模型负责把复杂记录讲清楚，真实系统负责提供状态，人负责处理冲突与例外。
当检索准确、引用可追、权限前置、缺失可见时，RAG 才不只是给物流系统加一个会说话的入口，而是成为多方协作中的共同知识层。
## 参考资料