AI数据平台，要补的恰恰是"模型不知道的事
作者于曦借华为全联接大会 2026 上副总裁袁远的发言，把"存储厂商为什么开始操心知识组织"这件事讲得相当清楚。文章不是给华为带货，而是借华为的产品路线，倒推企业落地 AI Agent 时真正会撞上的墙。
模型强了，麻烦才刚开始
把内部资料喂给模型就能用——这个"顺理成章"的想法在动手后会迅速破灭：
- 一份文档里的"客户"和另一系统里的"客户"口径不同；
- 检索出的几条规定都对，但适用条件彼此冲突；
- 智能体记住前几轮对话后，任务一长，响应开始拖慢直至崩溃。
过去靠老员工"心里有数"的那些默认约定，一旦交给智能体"靠谱地干活儿"，就必须显式记录下来。模型不知道的事，才是数据平台要补的。
三条路线，对应三类"模型不知道"
华为提出的三条升级路线，初看跨度大，实则分别打的是知识组织、推理性能、操作风险三个钉子。
1. 数据本体——知识该怎样表达，而不只是检索得到
国内某三甲医院实践：AI 辅助诊断采纳率从 50% 升到 90%，智能体日调用从 2000 次涨到 16000 次。调用频率的跃升比一次精彩 Demo 更能说明工具是否真正进入了日常工作。
但医疗场景很快暴露 RAG 的天花板：疾病、药物、症状的单点资料都能找到，可当患者同时有多种疾病、正在服药、又有异常检查结果时，如何组合这些信息做判断？资料齐了，判断还没完成。
数据本体要做的，是把一个领域里的对象、属性、关系定义清楚——疾病是什么、哪些信息构成诊断依据、哪些药物互为禁忌。它和"切分+向量化+检索"有本质区别：检索找到语义相关的内容，本体进一步说明为什么相关、关联成立需要什么条件。采购场景同理：供应商在合格名单上、能提供设备，但资质是否覆盖当前地区、是否过期、项目是否有额外要求——这些关系条件不表达出来，智能体引用了真实资料仍可能得出不适用的结论。
一个判断：本体建设的难点不在抽取（模型能帮），而在校验与持续维护——一个名称对应多个业务含义、两套系统对同一指标口径不同，都是企业里的常态；制度改了，旧关系何时失效、哪些推理依据要跟着调整，这些细节决定本体能否长期可用。今天画出一张漂亮的关系图，或许只完成了一部分。
华为的指标口径：通过数据本体定义知识间关系，可将智能体任务正确率提升至 90% 以上。
2. 原生 KV 语义直通——推理性能问题延伸到存储侧
AI 编程用户最熟悉的痛点：任务一长，需求说明、代码文件、修改意见越积越多，智能体每次继续工作都要等。背后是 KV Cache 的保存与复用。
KV Cache 保存推理中的注意力键值缓存，满足复用条件时能减少已有上下文的重复计算。长任务越多，保存和复用缓存的需求越突出——一个原本属于推理框架的性能问题，就此延伸到存储侧：缓存放哪？容量够不够？取回来够不够快？全塞进显存和内存会"捉襟见肘"，出现溢出和频繁淘汰，反而拖累加速效果。
华为的解法是用 OceanStor A800 的 SSD 作第三级缓存，承接显存与内存溢出的数据。披露的企业 AI 编程案例数据：前缀缓存实现"以查代算"后，首 Token 时延降低 80%，可降至 10 秒以内。
更激进的一步是缩短数据访问路径本身。以文件方式承载 KV 数据时，要"先转文件→查目录→找文件→读取→再转回来"，作者比喻为"坐几段地铁再转公交"。华为提出的原生 KV 语义直通与参数面网络直通，砍掉协议转换和中间访问环节：存储 I/O 时延从 350 微秒降到 55 微秒，单框带宽 1TB/s，KV Cache 加载速度提升 2 倍。
这反映了一个明确的需求变化：推理正在产生大量需要保存、共享、复用的数据，传统访问方式必须随之调整。
3. 智能体数据韧性——速度慢能等，数据改错不能忍
用户要求清理某项目历史数据，智能体却把"历史"的时间范围理解错了——工具调用本身正常执行，结果却可能造成损失。这类问题让"数据韧性"有了具体含义。
华为的第三条路线包括：实时分析智能体意图和异常行为，联动告警、阻断、安全快照及恢复，目标秒级风险拦截、分钟级数据一致性恢复；加上 AI 勒索检测与主存/备份联动应对外部攻击。
真正的难点不在拦截本身，而在判断什么值得拦截：批量删除可能是危险操作，也可能是合法的数据清理。拦得过多业务难以继续，拦得太少保护失去意义。华为给的目标是预测并提前拦截 99% 高风险操作、99% 勒索软件检测率，但实际部署仍要结合检测范围、误报漏报和业务规则评估。
数据恢复同理：一次任务修改了多份关联数据，只恢复其中一份，后续流程仍可能出错。企业愿意扩大智能体权限的前提，是实现风险可控。
三库一体，但各有难处
华为现有 AI 数据平台集成了知识库、KV Cache 库与记忆库，依托 UCM（Unified Cache Manager）支持推理应用：知识库提供专业信息，KV Cache 服务计算复用，记忆库积累任务中的信息与经验。三者用途不同，后续建设也各有难处。
写在最后：怎么测一个 AI 数据平台
作者的收尾建议值得工程团队借鉴：评估 AI 数据平台时，别再比"接入了多少份文档"，而是请业务专家带来一道公司内部真正棘手的问题——把分散在几份文件条款里的规定（有老旧的、有更新的、有特殊的）丢给智能体，看它能不能找到依据、处理冲突、又会在哪一步请求帮助。这比再接入多少份文档，更接近企业真正要交给它的工作。
能力也最朴素。