企业数据 AI 的两半，以及几乎没人把它们接起来

问一位采购负责人，为什么上个季度某条线路的到岸成本涨了，你会看到他打开两样东西：一个 BI 看板，和一份承运合同的 PDF。看板里有数字，合同里有原因。没有哪个工具能同时读这两样，所以分析师本人就是那个集成层，而这个答案要花两天。

这道缝不是某一家产品的疏忽。它就是这个市场当前的形状。

文档这一半

一类工具索引企业的文档资产——合同、报告、备案文件、wiki、工单、邮件——并从中作答。Glean、Hebbia 这类企业搜索与检索产品就在这里，而且它们把自己那件事做得很好：找到段落、标注页码、跨上千份文件做归纳。

它们不具备的，是和你受管的数字之间的连接。它们能找到那句“附加费按实际成本转嫁”的条款，却说不出成都—鹿特丹线路上的附加费科目上季度动了 3.4 个百分点——因为这个数字不在任何文档里。它在一张数仓表里，藏在一个指标定义后面，再后面还有一层权限模型。

指标这一半

另一类工具从数仓出发。Text-to-SQL 和对话式分析产品——Dot、Zenlytic、Tellius、Snowflake 的 Cortex Analyst 等等——把自然语言问题翻译成针对语义层的查询，返回一个数字。做得好的那些相当克制：它们依赖已定义的指标而不是猜关联，并且会把 SQL 亮出来。

它们不具备的，是对你文档的感知。系统能告诉你毛利下滑了 3.4 个百分点，却说不出七月换承运商才是原因——因为那次换约是一份协议里的条款、一段物流复盘里的文字，再多的 SQL 也够不着。

真正的问题永远横跨两边

下面这点让它不只是一次产品对比。便宜的问题完全落在某一半里；而昂贵的问题——那些真的会被逐级上报的问题——落在连接处。

• 我们的毛利是多少？——一半。
• 毛利为什么动了，合同允许我们把它转嫁回去吗？——两边。
• 有多少供应商逾期了？——一半。
• 哪些逾期供应商有我们还没执行的罚则条款？——两边。
• 这个项目花了多少钱？——一半。
• 这笔花费在工作说明书授权的范围内吗？——两边。

第二列里的每个问题，都是总监会问的问题。而它们每一个都要求系统能在同一步推理里，同时握住一个数字和一条条款。

为什么各买一个不管用

最直观的做法是买一个文档工具、再买一个分析工具，让大家两个都用。这产生不了那个连接，原因有三个。

没有人做核对。 当报告说的和表里说的不一致时——在企业规模下它们经常不一致，因为那份报告是按上季度的定义写的——两个独立的工具会给你两个都很自信的答案，且没有任何信号提示它们冲突。能横跨两边的系统才能发现这件事，而正确的行为是把分歧摆出来，而不是取平均糊过去，或者悄悄偏向那个恰好索引得更好的来源。

两套权限模型无法叠加。 文档工具有它自己的访问控制，分析工具继承数仓的。当一个问题横跨两边时，没有任何一个地方能单独决定“这个人此刻能看到什么”。实际结果通常是其中一套比另一套更宽松，而企业内部的 AI 推广就是这样被叫停的。

推理过程没有留在任何地方。 如果这个连接发生在分析师脑子里，那么方法本身——查了哪些来源、信了哪一个、为什么这样调整——会随他一起离开。下个季度这活儿重做一遍，做法略有不同，两个数字对不上。

真正横跨两边需要什么

这不是把一个模型指向两个数据源就完事的。有四件事必须同时成立，而且每一件都不光鲜：

1. 文档要按结构解析，而不是压平。 一个被压平成错误行的合并单元格，比一份你根本没索引的文档更糟，因为它是静默失败的。这本身就是一个工程问题。
2. 指标必须是被定义、带版本、可复现的，这样系统今天引用的数字和它四月引用的是同一个，否则它至少能准确告诉你中间改了什么。
3. 两条通道共用一套权限模型，每次检索都在服务端生效——而不是在提示词里请求模型自觉。
4. 分析方法本身要作为可复用对象存下来，而不是每次提问临场发挥。这一点几乎没人做，而它正是快答案和站得住脚的答案之间的分界。

DataFact 站在哪里

我们是冲着这个连接去建的，所以架构长成了现在这样：文档和数据库共用一个入口，其上是一份受管的统一记忆，再往上是能跨两条通道规划检索、并把结果相互核对的智能体。可以按订阅使用；数据不能出网时，也可以装进你自己的网络。

最后这个选项比听上去更要紧。手握这个问题最有价值版本的那些企业——二十年的合同、一个没人完全说得清的数仓、一个按时到访的监管方——往往恰恰是不能把这些东西送去第三方云的。一个只存在于别人租户里的连接，对他们来说等于不存在。

如果你想看这个连接在你自己的材料上成不成立，而不是在我们的演示材料上，发一份你们真的会为它争论的报告和一张表过来。那才是值得跑的那个测试。