6.2 Bloom 可视化探索：给业务人员的图画布

6.2 Bloom 可视化探索：给业务人员的图画布

本节摘要：Bloom 面向的是"会提问题但不会写 Cypher"的人：运营、风控分析师、产品经理。它把图查询变成搜索框里的自然短语与可交互的画布，并用视角（Perspective）控制每个人能看到哪部分图。本节讲清它的定位边界、视角与搜索短语的配置方法，以及与 Browser 的分工。

Browser 服务工程师（4.2 节），Bloom 服务业务人员——两者界面像、定位不同。判断标准很简单：需要写 Cypher 才能回答的问题归 Browser，能用一句业务短语描述的问题归 Bloom。

一、搜索短语：把问题直接敲进搜索框

Bloom 的搜索框理解两类输入。第一类是内置动作与图模式短语：

搜索框输入：Tom Hanks 的合作演员
→ Bloom 解析为等价 Cypher 并渲染画布
→ 节点按标签着色，关系可点选展开

搜索框输入：风险分数大于 80 的账户
→ 带条件过滤的场景图，直接呈现
​

第二类是团队自定义短语（Search Phrase），把业务黑话绑定到固定 Cypher 模板：

自定义短语：{name} 的资金环路
绑定查询：MATCH path = (a:Account {name: $name})
                 -[:TRANSFER*3..5]->(a)
          RETURN path
→ 风控同事输入"张三 的资金环路"即得环路图
​

自定义短语是 Bloom 的价值核心：把团队最常问的十个问题做成十个短语，业务自助率立刻上一个台阶——工程师从"临时工单查询员"的角色里解放出来。

二、视角（Perspective）：谁能看到图的哪一面

生产图往往含敏感子图（工资、内部标识）。Bloom 用视角做呈现层的数据裁剪：

视角配置（示意）：
风控视角：Account、Device、IP、TRANSFER 关系
          （隐藏 PersonalInfo 属性）
运营视角：User、Order、Product、Buys 关系
          （隐藏成本与利润属性）
​

同一张底图，不同角色开不同的画布。注意视角的定位：它是展示层过滤，不能替代 3.5 的权限体系——真正的安全边界仍由角色与权限把守，Bloom 视角只决定"看哪些标签与属性"，账号鉴权仍在底层。

三、场景与分享：把一次探索固化下来

画布上的探索结果可保存为场景（Scene），连同参数与视图设置一起分享给同事：

典型工作流：
1. 风控分析师发现一个可疑环路 → 保存场景"0801-张三环路"
2. 带参数分享给团队 → 同事打开即见同款视图，可改参数继续探索
3. 结论截图进周报 → 图说比表说先被看懂
​

这条"探索 → 固化 → 分享"的链路，是 Bloom 与一次性截图工具的本质区别：图探索本身成为可协作的资产。

四、分工与边界

两个诚实的边界提醒：其一，Bloom 是探索工具不是报表工具——要精确口径的数据（财务对账、KPI），还是导出 CSV 或接 BI；其二，可视化渲染有节点数上限，"把全图画出来"不是合法需求，靠短语过滤与逐层展开才是正确姿势。

💡 推广 Bloom 的团队实践：上线时配套做一页"常用短语手册"，把分析同事的高频问题固化成短语清单——Bloom 的价值不在于工具本身，在于这十几个短语沉淀下来的业务问答资产。

五、一个完整的业务方工作流示例

让"风控分析师小周"的一天来说明 Bloom 的位置：

上午：收到"这个设备号可疑"的线索
  → Bloom 搜索框输入设备号 → 星形图展开：6 个账号挂着它
  → 点击其中一个账号，展开它的转账关系 → 两个收款卡浮出

中午：发现其中三个账号的资金绕了一圈
  → 换用团队短语"xxx 的资金环路" → 环路图直接呈现

下午：把环路场景保存为"0612-设备X团伙"分享给团队
  → 风控例会上打开场景，截图进周报
  → 工程师按图中线索写正式 Cypher 深挖（回到 Browser）
​

注意这条链路的分工：线索发现与呈现归 Bloom，深度取证归 Cypher。Bloom 是侦查员的望远镜，不是法医的解剖台——各取所长，证据链才完整。

六、什么情况不值得上 Bloom

诚实的反面清单同样重要：团队只有工程师、查询都能写成 Cypher、没有可视化呈现需求——Bloom 的授权成本就不划算，Browser 加 BI 导出已够用。工具跟着人走：先数一数"不写代码的图用户"有多少，再决定买不买这块画布。

七、Bloom 短语设计的三个技巧

自定义短语的质量决定 Bloom 的实用性，三个设计技巧：

技巧一：参数前置、语义自然。 短语写成"{账户} 的资金环路"而不是"资金环路 of {账户}"——让业务同事用说话的语序提问，自助率才上得来。

技巧二：一个短语回答一个问题。 贪多求全的"通用查询短语"会退化成让业务同事学 Cypher。宁可做十个各司其职的短语，不做一个大而全的。

技巧三：给短语配默认过滤。 绑定的 Cypher 里预置 LIMIT、时间窗与排序，让每次点击的结果都"能看"——业务同事不该操心结果集会不会把画布撑爆。

短语评审三连：
  业务同事能看懂名字吗？
  结果默认规模可控吗？
  与既有短语会混淆吗？
​

八、与权限体系联动的上线检查

Bloom 上生产前的最后一道检查，与 3.5 联动：

1. 每个视角对应的角色是否最小权限（不要借视角掩权限之不足）
2. 敏感属性在视角层隐藏的同时，底层权限是否也拒绝
3. 搜索短语的默认 LIMIT 是否与画布承载匹配
4. 分享的场景里是否包含敏感参数快照
​

第二行是原则性的一条：视角是"看不见"，权限是"拿不到"——只有前者是遮羞布，只有后者才合规。

本节要点回顾

• Bloom 服务不写 Cypher 的人：搜索短语 + 可交互画布；
• 自定义短语把业务黑话绑定 Cypher 模板，是价值核心；
• 视角做展示层裁剪，但安全边界仍在权限体系；
• 场景可保存分享，探索结果成为协作资产；
• 分工口径：业务短语问题归 Bloom，精确口径与调优归 Browser。

工具讲完两层。下一节把图直接接到前端——GraphQL 映射层。