企业官网建设流程全解析

AI / Agent 接入难：数据治理是 LLM 落地的反向 KPI

Why LLM Applications Fail in Power Equipment Manufacturing

—— 电力装备制造业数据治理系列 · Vol.1 · 07

1. 引言：LLM 应用为什么落地难

2023 年 ChatGPT 引爆 LLM 浪潮后，企业普遍希望「用 LLM 替代人工做业务」。但 2024-2025 年的实际落地，多数 LLM 应用停留在 PoC 阶段——demo 时表现惊艳，上线后准确率惨不忍睹。常见的失败原因：

• 幻觉率高（字段名错、表名错、函数名错）；
• 查询语义错误（理解了字面但理解错业务）；
• 权限缺失（误读未授权数据）；
• 结果不可解释（用户无法验证 LLM 的回答是否正确）。

本文将论证：这些失败原因的根源都是「数据治理薄弱」——LLM 应用要落地，必须先有「数据治理基础设施」。这一关系是「反向 KPI」：数据治理越薄弱，LLM 应用越难落地。

2. 痛点扫描：LLM 应用的典型失败

2.1 治理水平 vs LLM 准确率

图 1：数据治理水平 vs LLM 应用准确率

Figure 1 给出基于行业典型场景的「治理水平 vs LLM 准确率」对比：

• **治理空白（0% 治理）**：Text-to-SQL 准确率仅 25%，Function Calling 50%；
• **基础治理（30% 字段标准）**：Text-to-SQL 42%，Function Calling 65%；
• **中度治理（70% Glossary）**：Text-to-SQL 58%，Function Calling 78%；
• **完整治理（100% 语义层）**：Text-to-SQL 72%，Function Calling 91%。

结论一目了然：**数据治理水平越高，LLM 应用准确率越高。** 在「治理空白」企业部署 LLM 应用，准确率仅 25-50%，根本无法用于生产；在「完整治理」企业，准确率可达 91%，达到生产可用门槛。

2.2 典型失败案例

电力装备制造业的 LLM 应用典型失败案例：

• **「查询 A 客户的毛利」失败**：因主数据混乱（A 客户在 5 套系统有 5 个名字），LLM 不知道用哪个；
• **「这单铜价能不能接」失败**：因实时数据缺失（铜价是 T+1 数据），LLM 给出过时建议；
• **「这批硅钢片质量怎么样」失败**：因血缘断裂（硅钢片批次 → 生产工序 → 成品 损耗 链路未打通），LLM 无法追溯；
• **「我想看销售毛利」失败**：因 Metric 定义缺失（不同部门对「销售毛利」定义不同），LLM 给出有歧义的回答；
• **「为什么这台变压器空载损耗偏高」失败**：因数据治理薄弱，LLM 幻觉地编造原因。

3. 共性壁垒 B5 的根因

图 2：5 重共性壁垒中的 B5 位置

3.1 LLM 的「幻觉」是数据治理的镜子

LLM 幻觉的根因不是 LLM 模型本身的能力问题（GPT-4 / Claude 在公开数据集 Spider 上准确率 78%+），而是「企业 schema 不规范」给 LLM 制造了大量歧义：

• 字段名不标准（如 customer_id / cust_id / user_id 混用）→ LLM 猜不出 ；
• Metric 无定义（「销售毛利」是 ((订单 - 成本) / 订单) 还是 ((订单 - 成本 - 税) / 订单)）→ LLM 自由发挥；
• 主数据混乱（同一物料 5 套编码）→ LLM 选哪个？
• 实时数据缺失（铜价 T+1）→ LLM 用过时数据；
• 血缘断裂（无法追溯字段来源）→ LLM 无法验证。

3.2 「先治理后 AI」的必然顺序

B5 的根因决定了「AI / Agent 落地」必须遵循「先治理后 AI」的顺序：

1. **L1 数据基础设施层**先打通（破除孤岛、统一接入）；
2. **L2 元数据治理层**先建立（主数据标准、Glossary、血缘、DQC）；
3. **L3 语义消费层**先就绪（SemanticObject、Metric、Compiler、权限）；
4. **L3+ AI Agent 接口**最后接入（Function Calling、Semantic Plan、MCP）。

颠倒顺序（先做 AI 应用，再补治理）的项目几乎全部失败——这一现象在 2024 年中国制造业 AI 应用项目中已经反复验证。

4. 解决方案：把数据治理做到「AI 友好」

图 3：3 层架构对 AI Agent 的支撑

4.1 Function Calling 替代 Text-to-SQL

LLM 与数据系统的交互有三种范式：

• **Text-to-SQL**：LLM 直接生成 SQL → 幻觉率高、安全风险、跨方言难；
• **Function Calling**：LLM 调用预定义函数 → 安全、可验证、但函数颗粒度难定义；
• **Semantic Plan**：LLM 生成符合 JSON Schema 的语义查询 IR → 表达力 = SQL 完整, 安全、跨方言、可验证。

工程实践：Function Calling 是「最低限度可生产」的方案；Semantic Plan 是「最优」的方案。两者都比 Text-to-SQL 准确率高 20-40 个百分点。

4.2 Semantic Plan + Self-Repair

Semantic Plan 的工程价值：

1. **JSON Schema 强约束**：LLM 输出符合 schema 的结构化 IR, 不能随意编造；
2. **5 道验证防线**：Schema 验证 → 类型推导 → 引用完整 → 权限验证 → 代价估算；
3. **Self-Repair 错误恢复**：LLM 验证失败时收到结构化错误信息, 自我修复, 准确率从 80% 推到 91%；
4. **跨方言通用**：LLM 输出 IR, Compiler 编译为目标方言 SQL。

4.3 Context Engineering

AI Agent 的另一个关键工程能力是「Context Engineering」——LLM 上下文窗口虽大但有限, 必须精选给 LLM 的信息:

• **Schema RAG**：从 1000 张表中检索 Top-5 相关表的 schema 给 LLM, 而非全量灌；
• **Conversation 摘要**：长对话压缩为摘要 + 关键事实, 而非线性增长；
• **Prompt Caching**：把 system prompt + schema + few-shot 缓存, 降低单次调用成本 90%。

5. 实施路径

1. **Phase 1（M1-M3）：基础治理**——L1 + L2 必须先做到「中度治理」（70% Glossary 覆盖）；
2. **Phase 2（M3-M5）：语义层建模**——L3 SemanticObject + Metric, 覆盖核心业务场景；
3. **Phase 3（M5-M7）：Semantic Plan 接入**——LLM 通过 Semantic Plan 调用语义层；
4. **Phase 4（M7-M9）：MCP 协议**——把语义层包装为 MCP server, 任意 LLM 可消费；
5. **Phase 5（M9+）：业务场景上线**——把 AI Agent 接入具体业务（如「自然语言报价查询」「智能客诉归因」）。

6. 价值数据

7. 工程见解与边界

7.1 「AI Native Catalog」的趋势

2024-2026 年最大趋势是「AI Native Catalog」——元数据治理平台向「LLM 可消费」演化：

• 向量索引（schema embedding）支持语义搜表；
• LLM 自动生成字段注释、自动归类 PII；
• 智能血缘推断（基于 SQL log）；
• Catalog 作为 LLM 的 MCP server 被消费。

7.2 「LLM 是 IT 的反向 KPI」

本文的核心洞察值得反复强调：「LLM 是 IT 的反向 KPI」——LLM 应用准确率反向印证企业 IT 治理水平。

• LLM 准确率 < 50% → IT 治理薄弱（B1-B5 多重壁垒未解决）；
• LLM 准确率 50-80% → IT 治理中等（部分壁垒已解决）；
• LLM 准确率 > 90% → IT 治理良好（5 重壁垒基本解决）。

投资人评估制造企业的数字化转型水平时, 可问一个简单问题:「你们的 LLM 应用现在生产环境准确率多少？」——这个数字比任何 IT 部门的自述更可信。

7.3 局限性

「AI Agent 落地」的局限：

• **LLM 模型成本**：高准确率依赖好模型（GPT-4 / Claude）, 单次调用成本不低；
• **模型选型与升级**：3-6 个月模型更新一次, 应用层需要持续适配；
• **数据安全**：发给 LLM 的数据涉及隐私时需特殊处理（脱敏 / 本地化模型）；
• **长尾决策**：LLM 对「极少见的决策场景」准确率仍较低, 需要人脑兜底。

参考资料

[1]Yu T, et al. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL. EMNLP 2018.

[2]Li J, et al. BIRD: A Big Bench for Large-Scale Database Grounded Text-to-SQL. NeurIPS 2023.

[3]Liu N F, et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024.

[4]Anthropic. Model Context Protocol (MCP) Specification. https://modelcontextprotocol.io/

[5]Madaan A, et al. Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023.