证据优先的检索

标准的建筑 AI 架构分三步：把文档向量化，检索最相近的片段，让模型回答。它演示起来非常漂亮，然后悄无声息地失效。

三种失效模式

时效性坍塌。 向量相似度对时间没有任何看法。一张图纸的 C 版和 A 版在嵌入空间里几乎一模一样，在后果上却截然不同。一个无法优先选择现行版本的检索系统，会信心十足地引用一份已作废的图纸。

权威性坍塌。 一份施工方案、一封分包商邮件、一条会议纪要，可能都提到了同一个节点。但它们的分量并不相同。相似度检索把建筑文档所依赖的权威层级压平了。

上下文坍塌。 「B 区为什么延误」的答案不在任何单一文档里。它分布在一条到货记录、一份施工日志、一次进度更新和一份验收记录之间——而这些文档单独看，没有一份包含问题里的那些词。片段检索找到的是「和问题长得像」的文档，它找不到成因。

把顺序倒过来。不要先检索文本再生成结论，而是先确立结论的结构，再为结构中的每一个要素索要证据。

对于一个延误问题，这个结构是固定且已知的：哪项活动、相对基线偏差多少、有哪些候选成因、每个成因由什么证据支撑、下游影响是什么、有哪些选项。这个结构来自项目世界模型，而不是来自检索器。

于是检索变成了一组针对已知实体关系的、有类型的定向查询——找出该活动在此时间窗内相关的到货记录——而不是一次模糊的相似度搜索加上一点运气。

每个答案自带来源。 不是在生成之后追加的脚注，而是因为答案本就是由这些来源构造出来的。如果某个关联缺乏证据，系统会说这个关联未被支撑，而不是产出一句听起来合理的话。

置信度变得有意义。 一个由证据密度、来源权威性与时效性推导出的置信度，是一个你可以据以推理的数字。而一个由 token 概率推导出的置信度，说的是模型的事，不是你项目的事。

错误答案可被诊断。 当一个证据优先的答案错了，你能准确看到是哪条记录误导了它。当一个聊天机器人的答案错了，你只能耸耸肩，再问一遍。

随便找一个建筑 AI 系统，问它一个关于延误的问题。然后要求它出示每条结论背后的具体记录，并把它们逐一打开。

如果这些记录并不存在、内容并非答案所说的那样、或者结果是一份已作废的版本——你面对的就不是一个智能系统，而是一个文笔不错的搜索框。