从本体论出发，实战拆解知识图谱

     某位客户近期投诉网络慢，究竟受哪些套餐、设备、基站、故障和工单影响？应优先怎么处理？   

那么你需要的图谱，是把客户、号码、合约、套餐、终端、位置、网络资源、服务事件和运营动作，连接成一张可追溯的业务网络。

本体：定义这些概念和规则。

节点：概念的具体实例。

关系：实例之间可查询、可推理的业务事实。

· · · ✦ · · ·

01 先写问题，再决定图谱里要有什么

一个图谱只服务于少数高价值问题，首先需要确定使用场景。

为什么客户感知网络变差？
需要连接：客户、号码、终端、小区、告警、投诉。核心关系：使用、接入、覆盖、影响、投诉。

哪些高价值客户可能流失？
需要连接：客户、套餐、账单、投诉、营销活动。核心关系：订购、产生、参与、投诉、触达。

某基站故障会影响哪些客户？
需要连接：基站、小区、服务地址、号码、工单。核心关系：包含、覆盖、常驻、服务于、影响。

某套餐调整的收入风险是什么？
需要连接：套餐、客户、合约、订单、账单。核心关系：订购、签署、变更、计费。

先选一个切口，例如“投诉根因定位”或“流失预警”。不要一开始就试图覆盖全电信业务场景   

02 本体到底是什么

可以把本体理解为一份全公司共享的“业务语言规范”。

它至少规定四件事：

有哪些类别：客户、手机号码、套餐、基站、工单等。

每类对象有哪些关键属性：客户等级、套餐月费、故障开始时间等。

类别之间允许有什么关系：客户订购套餐、号码接入小区、告警影响小区。

有什么约束与口径：一个号码在同一时刻只能归属一个有效客户。

本体不是数据库表结构，也不需要一开始就使用严格的 OWL/RDF 语言。第一阶段只要用一张“类型 + 属性 + 关系 + 规则”的说明表，就已经能让业务、数据和技术人员说同一种话。

03 三层拆法：本体、节点、属性

概念层：本体中的类别

类别回答“这是什么类型的东西”。建议按领域划分，而不是按系统划分。

客户与账户：Customer、Account、Organization。对应自然人客户、付费账户、政企客户。产品与合约：Product、Plan、Contract、Order。对应产品、套餐、在网协议、订购/变更订单。通信服务：Service、PhoneNumber、SIMCard。对应可开通的服务、手机号、SIM/eSIM。网络资源：NetworkSite、BaseStation、Cell、NetworkSlice。对应站址、基站、小区、网络切片。终端与位置：Device、Location、ServiceAddress。对应手机/CPE、地理位置、装机或常驻地址。运营事件：UsageEvent、Alarm、Incident、Ticket、Complaint。对应用量记录、告警、故障、工单、投诉。经营活动：Bill、Payment、Campaign、Offer。对应账单、缴费、营销活动、优惠。

数据层：节点是类别的具体实例

节点回答“具体是哪一个”。

     (:Customer {customer_id: "C10086", name: "张三", segment: "高价值"})
     (:PhoneNumber {msisdn: "13800138000", status: "在网"})
     (:Plan {plan_id: "P5G199", name: "5G 畅享 199", monthly_fee: 199})
     (:Cell {cell_id: "CELL-310115-042", name: "浦东 042 小区"})
     (:Alarm {alarm_id: "A20260714001", type: "传输中断", severity: "严重"})
     (:Complaint {complaint_id: "CP20260714008", category: "上网慢"})   

同一个现实对象只有一个稳定身份。customer_id、msisdn、cell_id 等业务主键应保留；数据库内部 ID 不能替代业务主键。

属性层：只放“描述”，不要把关系藏进字段里

属性适合回答“它的特征是什么”，如状态、金额、时间、等级、型号。

反例：不要把 customer_id、cell_id、affected_customer_ids 长期做成节点上的普通字段。只要它们需要跨对象追问、计算路径、按时间追溯或承载自身属性，就应该升级为关系或独立节点。

04 电信本体的最小可用版本

以下是适合“客户体验与网络故障联动”场景的最小本体，先用它跑通，再逐步扩展，比如：

Customer 客户：关键属性 customer_id、segment、risk_score。不应把所有订购过的套餐 ID 放在属性里。Account 账户：关键属性 account_id、account_type、credit_level。不应把名下号码列表塞成属性。PhoneNumber 号码：关键属性 msisdn、status、activation_date。不应把当前服务小区 ID 长期放成属性。Plan 套餐：关键属性 plan_id、name、monthly_fee、version。不应存已订购客户列表。Contract 合约：关键属性 contract_id、start_at、end_at、status。不应做客户与套餐 ID 的拼接文本。Device 终端：关键属性 imei、model、supports_5g。不应把当前使用人 ID 当普通属性。BaseStation / Cell：基站有 site_id、vendor、status；小区有 cell_id、rat、band、status。不应把覆盖客户 ID 列表、所属站点 ID 藏进属性。Alarm / Incident / Complaint / Ticket：分别记录告警、故障、投诉、工单的关键属性，但相关资源、相关工单、投诉客户、处理对象都不应只做成 ID 列表。

判断“该不该拆成节点”的四问

它是否有自己的唯一标识和生命周期？

它是否会与两个以上对象产生关系？

我是否需要按它过滤、聚合、统计或沿它继续查询？

它是否有会变化的属性或历史？

任意两项为“是”，通常就值得成为节点。

客户等级：通常是客户的一个枚举描述，适合做属性。客户标签：视情况处理。只做筛选可作数组属性；需要治理或层级时拆为 Tag 节点。套餐：建议做节点，因为可被多个客户订购，且有版本、价格和权益。号码订购套餐：适合做带属性的关系，或拆成 Subscription 节点，因为需要记录生效时间、失效时间、渠道、状态。账单月份：只表示月份时为属性；账期需要汇总审批时为节点。

05 怎么写关系：动词、方向、粒度、时间

关系要用业务动词，不要使用无意义的 RELATED_TO。

每条关系先写成一句人能读懂的话：

     客户“拥有”账户；账户“绑定”号码；号码“订购”套餐；号码“接入”小区；告警“影响”小区；投诉“关联”号码；工单“处置”故障。   

Customer OWNS Account：客户拥有付费账户。Account BILLS_FOR PhoneNumber：账户为号码付费。PhoneNumber SUBSCRIBES_TO Plan：号码订购套餐。PhoneNumber SERVED_BY Cell：号码在某时段接入小区。Alarm AFFECTS Cell：告警影响小区工单处置故障。

关系本身的属性

关系不是只画一条线。电信数据几乎总要记录时间和来源。

     (:PhoneNumber)-[:SUBSCRIBES_TO {
       start_at: "2026-01-01",
       end_at: null,
       status: "有效",
       channel: "营业厅"
     }]->(:Plan)

     (:Complaint)-[:ASSOCIATED_WITH {
       confidence: 0.82,
       evidence: "时间和服务小区重合",
       identified_by: "规则+模型"
     }]->(:Incident)   

关系属性适合放：生效/失效时间、状态、来源系统、置信度、次数、角色、渠道。这样既能看到当前状态，也能解释“当时为什么发生”。

06 何时把关系升级为节点

如果一条关系只有少量属性，直接放关系上最简单：

     (号码)-[:SUBSCRIBES_TO {start_at, channel}]->(套餐)   

出现下列任一情况时，应升级为独立的过程节点（如 Subscription）：

关系需要被多个对象引用（订单、优惠、账单都要指向某次订购）。

关系自身有复杂状态流转（申请、审核、生效、暂停、退订）。

关系有很多属性，或会持续增加属性。

关系需要作为分析和统计主体。

     (:PhoneNumber)-[:HAS_SUBSCRIPTION]->
     (:Subscription {
       subscription_id: "S20260101001",
       start_at: "2026-01-01",
       status: "有效"
     })-[:FOR_PLAN]->(:Plan)

     (:Order)-[:CREATES]->(:Subscription)
     (:Bill)-[:CHARGES_FOR]->(:Subscription)   

07 一份可直接落地的“投诉根因定位”图谱

真实场景叙述

张三在浦东连续两天感觉上网慢，于 7 月 14 日投诉。

系统发现他的号码在投诉时段频繁接入浦东 042 小区；该小区所属基站同时发生传输中断告警，已被汇聚为一次 P1 网络故障；运维工单正在处理。

这个图能回答什么

这个投诉是否可能由已知网络故障导致？

同一故障影响了多少客户，其中多少是高价值客户？

哪些投诉可以主动告知处理进度，而不是再次派单？

该工单处理后，相关投诉是否显著下降？

08 建模时最常见的五个错误

错误 1：按源系统建模。
“CRM 客户”“BOSS 客户”“网管客户”不应天然成为三种实体。应保留 source_system 和对齐规则，而不是复制三张平行的客户图。

错误 2：把代码值当成本体。
customer_type = 1、alarm_level = 3 是系统编码，不是业务定义。本体中要写成“个人客户/政企客户”“一般/重要/严重”，编码放作映射属性。

错误 3：一条万能关系走天下。
RELATED_TO 虽然省事，却无法表达方向和语义。优先使用 USES、AFFECTS、HANDLES、PART_OF 等有明确含义的动词。

错误 4：只保存当前状态。
电信业务处处会变：套餐变更、号码过户、终端更换。关系应包含时间，或使用事件节点保留历史。

错误 5：把推断当事实。
“投诉与故障有关”通常是推断。关系上应保留 confidence、evidence、identified_by，让结果可解释、可复核。

09 从零开始的执行顺序

选定一个业务问题，例如“网络投诉根因定位”。

收集 20～50 条真实案例，写成自然语言叙述。

圈出名词，候选为实体类型；圈出动词，候选为关系类型。

用“四问法”决定哪些名词成为节点，哪些只是属性。

给每个节点和关系补上唯一标识、时间、数据来源和负责人。

只先实现能回答核心问题的最小图谱。

用真实查询验证：能否定位原因、列出影响范围、解释推断依据。

再逐步加入账单、营销、家庭宽带、政企专线、渠道等领域。

10 判断口诀

     名词不等于节点，字段不等于属性，连线不等于关系。
     能被独立识别、复用、追问和追溯的，才值得成为节点。
     能说成清晰业务动词、且需要表达时间证据，才值得成为关系。
     先让一个问题能被解释，再让图谱逐渐完整。