共享电动车如何做 AI 认知中台（二）：从概念图谱到可运行架构

上一篇讨论了共享电动车业务中的本体、知识图谱和典型运营场景，但主要回答的是“认知中台可以做什么”。本文继续回答一个更重要的问题：这些能力怎样组成一套可建设、可运行、可治理、可验收的系统。

上一篇：共享电动车如何做 AI 认知中台？从本体图谱到运营诊断

摘要

共享电动车认知中台不是在数据中台旁边增加一个聊天机器人，也不是把车辆、订单、网格和任务画成知识图谱后接入大模型。

一套真正可运行的认知中台，需要把自然语言理解、业务语义、本体与知识、实时指标、预测算法、确定性规则、任务执行和效果复盘连接成闭环。大模型位于认知接口和编排层，负责理解问题、选择诊断流程、组织证据和生成解释；数据中台、规则引擎和算法服务负责提供可验证的事实与判断；调度、换电、维修和客服系统负责执行动作。

本文给出共享电动车 AI 认知中台的总体架构、组件边界、运行时序、数据与知识更新机制、工程治理方案，以及一个可以在 8～12 周内验证价值的 MVP 设计。

---

一、先明确：认知中台不是什么

在设计架构之前，需要先排除三种常见误解。

1. 认知中台不是大模型直接查询生产数据库

大模型不应该自由拼接 SQL，更不应该绕过数据权限直接访问车辆、订单、用户和运营数据库。它访问的应当是经过治理的数据服务、指标服务、图查询服务和业务工具。

这样做不是为了限制模型能力，而是为了保证：

• 指标口径一致；
• 查询范围可控；
• 用户隐私受保护；
• 每个结论都可以追溯；
• 生产系统不会被不可控查询拖垮。

2. 认知中台不是知识图谱展示系统

图谱的价值不在于把节点和连线展示出来，而在于帮助系统完成三件事：

1. 根据业务对象找到相关证据；
2. 根据对象关系确定诊断范围；
3. 把诊断结论关联到可以执行的动作。

如果图谱不能参与问题解析、证据检索、规则判断或任务生成，它就只是一个可视化附件。

3. 认知中台不是让大模型替代调度算法

供需预测、路径优化、换电优先级、异常检测等问题需要稳定的算法模型或规则系统。大模型更适合：

• 理解运营人员的问题；
• 把自然语言映射到业务对象和诊断场景；
• 调用已有的数据、规则和算法服务；
• 把机器结果组织为人能理解的证据链；
• 在授权范围内生成任务草案。

一句话概括：大模型负责理解与解释，确定性系统负责计算与执行。

---

二、总体架构：从业务系统到认知接口

共享电动车认知中台可以划分为六层：业务源系统层、数据与事件层、语义知识层、分析决策层、认知编排层和交互执行层。

各层的职责边界

层级	核心职责	不应该承担的职责
业务源系统层	记录订单、车辆、设备和任务的原始业务事实	直接向大模型暴露生产表
数据与事件层	清洗、关联、聚合并提供实时和离线数据服务	解释业务原因
语义与知识层	统一对象、关系、指标、规则和术语	替代实时指标计算
分析与决策层	预测、检测、优化和确定性规则判断	生成未经约束的自然语言结论
认知编排层	理解问题、选择工作流、组织证据、生成解释	自行伪造指标或越权执行动作
交互与执行层	面向人员提供入口，并承接确定性任务执行	把模型回答直接当作生产指令

这张架构图中最重要的不是组件数量，而是三条边界：

1. 大模型不直接访问业务库，而是访问经过授权的语义化工具；
2. 图谱组织关系和证据，但实时指标仍由指标平台或流计算产生；
3. 建议和执行分离，高风险动作必须经过规则校验或人工确认。

---

三、一次诊断请求是怎样运行的

以“为什么地铁东口网格现在缺车”为例，完整运行过程不应只是大模型调用一个 SQL，而应当经过场景识别、对象消歧、证据采集、确定性计算、结论生成和风险校验。

运行时必须产生“证据包”

为了避免模型把零散工具返回自由发挥成一个看似合理的故事，编排层应先形成结构化证据包，再交给大模型解释。

一个最小证据包可以采用如下结构：

{
  "question": "为什么地铁东口网格现在缺车？",
  "scene": "grid_supply_diagnosis",
  "subject": {
    "type": "Grid",
    "id": "G1024",
    "name": "地铁东口网格",
    "city": "A市"
  },
  "observation_time": "2026-08-31T17:40:00+08:00",
  "facts": [
    {
      "metric": "rideable_vehicle_count",
      "value": 12,
      "unit": "辆",
      "metric_version": "v3.2",
      "source": "realtime_supply_service"
    },
    {
      "metric": "forecast_demand_2h",
      "value": 38,
      "unit": "单",
      "model_version": "demand_forecast_v7"
    },
    {
      "metric": "low_battery_vehicle_count",
      "value": 6,
      "unit": "辆"
    }
  ],
  "relations": [
    "G1024 NEARBY 地铁2号线东口",
    "G1024 ADJACENT_TO G1023",
    "G1024 GOVERNED_BY POLICY-A-2026-17"
  ],
  "rules": [
    {
      "id": "SUPPLY_GAP_HIGH",
      "result": true,
      "reason": "预测需求与可骑供给差值大于20"
    }
  ],
  "candidate_actions": [
    {
      "type": "DispatchTask",
      "quantity": 20,
      "source_grid": "G1023",
      "requires_confirmation": true
    }
  ],
  "missing_evidence": [],
  "confidence": 0.91
}

证据包应具备以下特点：

• 每项事实都有来源、时间戳和版本；
• 区分观测事实、算法预测和规则结论；
• 明确缺失证据，而不是让模型自行补全；
• 建议动作带有风险级别和是否需要人工确认；
• 最终回答能够反向定位到证据项。

---

四、本体不是对象清单，而是系统契约

只列出 Vehicle、Battery、Grid、ParkingArea 等名词，还不能构成本体。工程上可用的本体至少需要定义五类内容。

1. 对象类型

例如：车辆、设备、空间、人员、订单、事件、规则和任务。

2. 属性与数据类型

例如 Vehicle 不只有车辆编号，还应定义运营状态、电量区间、定位时间、所属城市、生命周期阶段等属性，并明确哪些属性来自事实表，哪些是实时派生值。

3. 关系、方向与基数

例如：

Vehicle --located_in--> Grid              N:1
Vehicle --parked_at--> ParkingArea        N:0..1
Vehicle --powered_by--> Battery           1:1
Trip --uses--> Vehicle                    N:1
FaultEvent --affects--> Vehicle           N:1
DispatchTask --moves--> Vehicle           1:N
Grid --governed_by--> CityPolicy          N:M

关系必须明确时间有效性。车辆当前位于哪个网格，与车辆在某个历史时刻位于哪个网格，是两种不同的查询。

4. 状态机

车辆状态不能只是一个字符串字段。认知系统需要知道哪些状态可以相互转换，什么事件触发转换，以及转换后能够执行什么动作。

5. 规则与动作约束

本体还应描述哪些对象在什么条件下可以触发哪些动作。例如：

当 Vehicle 位于高需求 Grid，
且 battery_soc < 20%，
且未来 2 小时 forecast_demand 超过可骑供给，
且 Vehicle 不存在未关闭的 FaultEvent，
则可以生成高优先级 BatterySwapTask 候选。

注意，“可以生成任务候选”不等于“大模型可以直接创建生产任务”。任务是否自动执行，应由动作策略、用户权限和风险等级共同决定。

---

五、图谱、指标、规则和算法各自负责什么

认知中台容易出现的架构问题，是把所有业务能力都归到知识图谱。实际上，不同问题应由不同组件解决。

问题	主要负责组件	示例
车辆当前电量是多少	时序数据/状态服务	最近一次有效 SOC
当前可骑车辆有多少	实时指标服务	过滤故障、低电、离线车辆后的供给
车辆与网格、点位有什么关系	图谱/GIS 服务	located_in、parked_at、nearby
某规则是否满足	规则引擎	是否超过点位容量、是否位于禁停区
两小时后需求是多少	预测模型	时序预测或时空预测
从哪里调车成本最低	优化算法	带约束的车辆调拨方案
为什么要这样调度	证据包 + 大模型	面向运营人员的可读解释

一条重要原则

图谱存关系，指标平台算指标，算法服务做预测优化，规则引擎做确定性判断，大模型组织认知结果。

这样可以避免两个极端：

• 把图数据库当成万能业务数据库；
• 把大模型当成万能计算引擎。

---

六、数据怎样进入认知中台

共享电动车的数据同时具有实时、时序、空间和事件属性，因此不能只依赖离线数仓同步。

1. 事件数据

典型事件包括：

• 车辆上线、离线和定位变化；
• 开锁、关锁和订单状态变化；
• 电量变化和电池更换；
• 故障告警和维修结果；
• 进入或离开电子围栏；
• 投诉创建、归因和关闭；
• 调度任务创建、领取、完成和质检。

这些事件进入消息流后，可以更新实时状态、触发规则、生成指标，并增量更新图谱关系。

2. 事实与快照

认知系统需要同时保留：

• 原始业务事实：订单、设备事件、任务记录；
• 当前状态快照：车辆当前状态、当前位置、当前电量；
• 聚合指标：网格供给、点位周转率、低电率；
• 算法结果：需求预测、异常分数、调度候选方案；
• 语义关系：车辆属于哪个网格、点位受哪些规则约束。

不能只保留当前图谱状态，否则系统无法回答“昨天为什么缺车”“策略调整前后有什么变化”等复盘问题。

3. 数据与知识更新闭环

闭环的关键是：任务执行结果必须回流。没有回流，系统只能不断生成建议，不能判断建议是否有效，也不能持续优化规则和模型。

---

七、认知编排层如何设计

认知编排层是整套系统的核心。它不应只是一个 Prompt，而应是受约束的工作流系统。

1. 意图识别

把问题映射到有限的业务场景，例如：

• grid_supply_diagnosis：网格供需诊断；
• vehicle_fault_diagnosis：车辆异常诊断；
• battery_swap_priority：换电优先级；
• parking_compliance_diagnosis：停车合规诊断；
• complaint_root_cause：投诉归因；
• task_effect_review：任务效果复盘。

场景应注册在场景目录中，每个场景明确输入对象、必需证据、可调用工具、输出格式和风险等级。

2. 对象解析与消歧

“地铁东口”“大学城”“A 区”等自然语言名称可能对应多个网格、点位或 POI。系统必须结合用户所在城市、组织权限和对话上下文完成对象解析。如果仍有多个候选，应要求用户选择，而不是任意猜测。

3. 工作流编排

每类问题使用预定义工作流。例如网格供需诊断可以固定为：

对象解析
  → 当前供给查询
  → 车辆可用性拆解
  → 历史需求与预测需求查询
  → 天气、POI、活动和城市规则补充
  → 供需缺口规则判断
  → 调度候选方案计算
  → 证据包组装
  → 大模型生成解释
  → 风险与权限校验

这类工作流比完全自由的 Agent 更适合第一阶段，因为它可测试、可审计，也更容易定位问题。

4. 工具注册与权限

每个工具都应声明：

• 输入输出 Schema；
• 支持的城市和时间范围；
• 数据新鲜度；
• 权限要求；
• 超时和降级策略；
• 是否会产生外部动作；
• 幂等键和审计字段。

查询类工具与执行类工具必须隔离。模型可以自主调用低风险查询工具，但创建调度、退款、清运等动作时需要额外授权。

5. 生成约束

大模型输出应采用结构化格式，至少包括：

{
  "conclusion": "当前缺车主要由晚高峰需求上升和低电车辆占比增加共同导致",
  "evidence_refs": ["fact-1", "fact-2", "rule-1"],
  "uncertainty": "天气客流数据延迟约10分钟",
  "recommended_actions": [],
  "need_human_confirmation": true
}

系统应校验引用的证据是否存在，阻止回答引用不存在的指标或规则。

---

八、从“回答问题”走向“执行闭环”

认知中台真正产生价值的地方，是把诊断结论转化为可执行任务，并能够复盘结果。

但不同动作的风险不同，自动化等级也应该不同。

动作	建议自动化等级	原因
查询指标、生成诊断	可自动	不改变业务状态
生成任务草案	可自动	仍需人员确认
调整任务优先级	有条件自动	需规则边界和审计
创建普通换电任务	灰度自动	影响有限且易回滚
跨区大规模调度	人工确认	影响供给与成本
用户退款或费用调整	人工确认或严格规则	涉及资金和客诉风险
修改围栏和城市规则	双人复核	影响范围大

任务闭环需要记录什么

每个由认知中台建议或生成的任务，应记录：

• 触发问题和场景；
• 使用的证据包版本；
• 规则与算法版本；
• 模型生成的原因；
• 操作人和审批人；
• 实际执行过程；
• 执行前后指标变化；
• 是否被人工修改、拒绝或撤销。

只有这样，系统才能回答：“这次任务为什么生成”“谁确认的”“执行后是否改善”。

---

九、工程治理：准确之外，还要可控

共享电动车认知中台进入生产环境后，至少需要关注以下治理能力。

1. 权限治理

权限不只控制用户能否进入系统，还要控制：

• 能查看哪些城市、区域和指标；
• 能查看到什么粒度的订单和用户数据；
• 能调用哪些诊断工具；
• 能创建或审批哪些任务；
• 能否查看敏感设备日志和投诉内容。

2. 隐私保护

用户身份、手机号、精确轨迹和支付信息不应进入通用模型上下文。诊断投诉时，应优先传入脱敏后的订单事实和必要证据。

3. 可追溯性

每次回答至少记录：

• 用户问题；
• 识别出的场景和对象；
• 调用过的工具；
• 证据包；
• Prompt 与模型版本；
• 最终结论；
• 用户反馈和后续动作。

4. 数据新鲜度

回答中需要显示关键数据的观测时间。车辆供给是 30 秒前的数据，还是昨天的离线快照，会直接影响结论可信度。

5. 降级策略

当图谱、预测模型或某个数据服务不可用时，系统不应编造完整结论，而应明确降级：

• 只有实时供给，没有需求预测：仅展示现状，不生成调度量；
• 缺少定位数据：不能判断停车合规；
• 规则版本未知：不自动生成处罚或退款建议；
• 证据冲突：展示冲突并要求人工判断。

6. 成本与性能

不是每个问题都需要调用大模型。简单指标查询可以直接由语义查询服务返回；只有涉及多源归因、解释和方案组织时才进入完整认知链路。

---

十、一个可落地的 MVP 架构

第一阶段不建议同时建设八个场景。可以只选择一个城市、两类用户和四个诊断问题，形成最小闭环。

MVP 范围

试点城市： 选择数据质量较好、运营团队配合度高的一个城市。

试点用户： 城市运营经理、网格调度主管。

试点问题：

1. 这个网格为什么缺车？
2. 这个点位为什么堆车？
3. 哪些车辆应该优先换电？
4. 这个调度任务执行后是否有效？

允许动作： 查询、诊断、生成任务草案；正式下发仍由人工确认。

MVP 组件图

MVP 不必一开始建设什么

• 不必把全部历史数据导入图数据库；
• 不必让模型自由规划所有工具调用；
• 不必自动下发大规模调度任务；
• 不必建设覆盖所有城市的统一复杂本体；
• 不必追求一个模型回答所有运营问题。

图谱也可以先使用关系数据库加语义查询层实现。只有当多跳关系查询、规则关联和关系演化确实成为瓶颈时，再引入专门图数据库。认知中台的目标是解决运营问题，不是为了使用某一种技术而设计系统。

---

十一、8～12 周的实施路径

第 1～2 周：问题与口径收敛

• 选择试点城市和角色；
• 固定四个高频问题；
• 对齐供给、可骑、低电、缺车和堆车等指标口径；
• 盘点数据源、接口和权限；
• 收集不少于 100 个真实问题及人工答案。

第 3～4 周：数据与语义服务

• 建立轻量本体和术语词典；
• 完成网格、点位、车辆和任务的对象 ID 映射；
• 提供实时供给、历史需求、需求预测和任务结果 API；
• 为每个数据项增加来源、时间戳和版本。

第 5～6 周：诊断工作流

• 实现意图识别和对象消歧；
• 编排四条固定诊断工作流；
• 实现证据包生成和证据引用；
• 接入大模型生成结构化解释；
• 增加无数据、数据冲突和超时降级。

第 7～8 周：任务闭环与治理

• 接入调度任务草案接口；
• 建立人工确认机制；
• 记录回答、证据、版本和操作审计；
• 建立任务执行前后效果对比。

第 9～12 周：灰度与评测

• 由运营专家盲评诊断准确性；
• 统计证据完整率和任务采纳率；
• 分析被拒绝或修改的建议；
• 调整规则、工作流和模型提示；
• 达到门槛后再扩展新场景或自动化等级。

---

十二、怎样验收，而不是只看演示效果

认知中台的验收不能只看回答是否流畅。建议从五个维度建立指标。

1. 语义准确性

• 场景识别准确率；
• 业务对象解析准确率；
• 时间范围和指标口径识别准确率。

2. 事实与证据

• 关键结论证据覆盖率；
• 无来源事实比例；
• 指标时间戳完整率；
• 证据引用正确率。

3. 诊断质量

• 运营专家认可率；
• 根因 Top 3 命中率；
• 建议动作合理率；
• 不确定性表达准确率。

4. 业务效果

• 平均诊断耗时下降比例；
• 任务草案采纳率；
• 调度后缺车率改善；
• 换电后可骑供给提升；
• 重复投诉下降比例。

5. 系统治理

• 越权访问次数；
• 高风险动作未经确认执行次数；
• 请求可追溯率；
• 工具调用成功率和 P95 响应时间；
• 降级策略正确触发率。

对于第一阶段 MVP，可以设置更具体的上线门槛：

对象解析准确率 ≥ 95%
关键结论证据覆盖率 ≥ 98%
运营专家认可率 ≥ 85%
任务草案采纳率 ≥ 60%
高风险动作未经确认执行次数 = 0
请求全链路可追溯率 = 100%

---

十三、几个容易失败的做法

1. 先建一个“大而全”的企业知识图谱

如果没有从具体问题和工作流反推图谱范围，最终很容易得到大量节点和关系，却没有稳定的业务入口。

更合理的方式是：从“网格为什么缺车”这样的真实问题出发，确定回答所需对象、关系、指标和规则，再逐步扩展本体。

2. 用 Prompt 代替工程架构

一个很长的系统提示词，不能替代工具权限、结构化证据、工作流、审计和降级机制。Prompt 是认知编排的一部分，不是全部。

3. 让模型直接计算关键指标

大模型可以解释“可骑供给为何下降”，但可骑供给数量必须来自统一指标服务。否则不同人员在不同时间可能得到不同口径的答案。

4. 一开始就追求全自动 Agent

共享电动车运营涉及真实资产和线下人员。第一阶段更需要可控工作流和人工确认，而不是让模型自由尝试各种动作。

5. 只评测语言效果

回答读起来专业，不代表事实正确。认知中台应把评测重点放在对象解析、证据引用、根因判断和执行效果上。

6. 没有任务结果回流

如果系统不知道建议是否被采纳、任务是否完成、指标是否改善，就无法形成真正的认知闭环。

---

十四、最终应该形成什么能力

成熟的共享电动车认知中台，不只是“能问数”，而应形成四条闭环链路。

1. 从问题到证据

理解自然语言问题，识别业务对象，找到正确指标、规则和关联事实。

2. 从证据到判断

通过规则、算法和图谱关系形成可验证的诊断，而不是依赖模型猜测。

3. 从判断到动作

把结论转化为调度、换电、维修、清运、围栏校准或策略调整任务，并按风险等级执行审批。

4. 从动作到复盘

跟踪任务执行效果，把结果反馈给规则、算法和运营知识体系。

---

十五、总结

共享电动车 AI 认知中台的核心，不是多画几张实体关系图，也不是让大模型替代原有数据平台和调度系统。

它真正要建设的是一套连接业务语义、实时数据、知识关系、确定性计算、大模型解释和任务执行的认知基础设施。

在这套架构中：

• 本体统一业务语言；
• 图谱连接对象与证据；
• 数据平台提供可信事实；
• 规则和算法完成确定性判断；
• 大模型理解问题并组织解释；
• 编排层控制过程、权限与风险；
• 业务系统承接任务执行；
• 评测与反馈推动系统持续改进。

因此，认知中台建设的正确起点不是“先接哪个大模型”，而是三个更具体的问题：

1. 我们最希望系统稳定回答哪几个运营问题？
2. 回答这些问题需要哪些可验证的证据和确定性能力？
3. 诊断结论如何变成受控动作，并通过执行结果完成复盘？

把这三件事做通，认知中台才会从概念图谱和演示样例，真正走向可运行、可治理、可创造业务价值的城市运营系统。