销售拜访与网点管理项目面向乳制品终端运营场景，围绕业务员拜访、有效网点覆盖、产品铺市、图像识别陈列、冰柜巡检、区域负责人看板、网服与 APP 活跃等问题，将分散在业务表、样本问题和历史脚本中的指标口径统一到可查询、可解释、可复核的语义模型中。
围绕 45 条 Ice POC 样本场景，把拜访、有效网点、开发数、重复拜访率、铺市、品项和冰柜巡检等指标沉淀为可解释口径。
通过 Neo4j 本体模型理解业务实体、关系和规则，再由 ClickHouse 执行真实数据查询，避免自然语言直接拼 SQL 的口径漂移。
从大区、省区、负责人、网点、产品、拜访和图像识别明细一路追溯到表字段与计算规则，支撑销售管理复核和持续优化。
销售一线问题覆盖拜访、铺市、陈列、冰柜、网服、APP 活跃和区域看板，业务对象多、指标口径分散。
同一个词在不同场景下含义不同，例如大区、省区、市场对应部门层级，有效网点、开发数、品项也都有明确字段规则。
历史 RPA 目录、样本问题和当前白名单之间存在映射关系，不能简单按用户自然语言命中旧脚本。
部分样本处于 business_pending 或 reference_only 状态，需要在可计算结果之外明确业务边界和待确认项。
数据来自 38 张 ClickHouse 表和脱敏 TSV 样本，如果没有本体关系，查询人员很难判断应该连接哪些表和字段。
销售管理层需要按大区、省区、负责人、门店和品项下钻，单张报表难以说明问题产生位置和后续动作。
| 使用本体前 | 使用本体后 |
|---|---|
| 依赖人工理解样本问题和 RPA 目录，容易把相近指标混用。 | 先用本体识别 Terminal、Visit、Department、User、Product 等实体，再按样本场景选择对应口径和表。 |
| 有效网点、开发数、品项等规则散落在 SQL 或说明文档里。 | 将 status='Y' AND ismnshop='Y'、pronum>=3、procode LIKE '1303%' 等规则固化为可复用业务语义。 |
| 只返回查询结果，业务人员难以判断结果是否来自正确层级、时间范围和对象池。 | 返回指标时同步说明场景编号、关键表、字段映射、层级规则和待确认边界。 |
| 铺市、陈列面和冰柜问题分别由不同脚本处理，难以形成统一门店视角。 | 通过网点、拜访、AI 识别、产品、冰柜和经销商关系，把多个经营问题汇聚到门店对象上。 |
| 待确认样本容易被当作失败或空回复处理。 | 按 technical_pass、business_pending、reference_only、failure_case 标注处理方式，可计算部分和待确认项分开呈现。 |
以 Terminal 为核心对象，覆盖网点编码、门店名称、渠道、区域、经纬度、状态、门店标识、主营店标识、产品数量和冰柜信息。
通过 Department、User、Grid、Route 表达大区、省区、市场、片区、负责人、业务员、网格和拜访线路，支撑区域和负责人维度统计。
围绕 Visit 和 VisitAgency 记录网点拜访、经销商拜访、拜访时间、执行人、部门、产品数和开发结果，是覆盖率、重复拜访率和开发数的主链。
以 Product、Order、OrderProduct、AIDataProInfo 等对象连接 SKU、订单明细、图像识别产品和品项规则，支撑铺市率和品项数分析。
覆盖 AIDataDetail、AICameraDetail、AICameraInspection、IceBox、MNShop 等对象，用于图像识别铺市、陈列面、纯净度、冰柜巡检和在控冰柜分析。
维护 B01-B12、P01-P10、S01-S06、R01-R06、W01-W04、I01-I02 等样本分组，以及 technical_pass、business_pending、reference_only、failure_case 的处理边界。
管理人员需要按本月、近 5 日、今日或近 30/90 天查看有效网点的非去重拜访、去重拜访、开发数、覆盖率和重复拜访率。
匹配 B01-B12 样本，使用 Visit、Terminal、Department、User 等实体确认有效网点和部门层级，再到 ClickHouse 查询拜访与网点数据。
业务人员可以按统一口径查看拜访执行情况，并继续下钻到人员、区域或门店定位问题。
铺市问题涉及图像识别资产、品项、年累资产、新增资产和历史对比，传统脚本容易混用验收口径和技术参考口径。
匹配 P01-P10 样本，优先使用图像识别铺市主链，明确 reference_only 场景只作技术演示，并通过产品编码规则识别品项。
系统能够区分正式可推进样本和参考 SQL 样本，避免把过期七品或品牌铺市口径误当作验收结论。
品项数、陈列面和纯净度通常来自图像识别明细，需要结合区域、门店和产品信息才能解释异常原因。
匹配 S01-S06 样本，关联 AIDataDetail、AIDataProInfo、Product、Terminal 和 Department，按 MN 品项、平均品项数、纯净度和历史差异组织结果。
销售团队可以从区域指标继续追到门店和产品层面，判断是铺市不足、陈列异常还是规则阈值待确认。
负责人看板需要同时回答日、周、月拜访、覆盖率、开发、系统必铺品达成和管理层关注对象，口径容易跨层级混杂。
匹配 R01-R06 样本，使用 Department level 规则区分大区、省区、市场和区域，并把 User、Visit、Terminal、app_impclientsys 等关系纳入查询链。
管理层能够按同一组织层级查看负责人表现，并看到覆盖异常、重复拜访异常或必铺低达成的业务边界。
网服问题涉及注册、责任网点、拜访、出勤、分销、巡检和 APP 活跃，部分数据源在当前链路中只支持降级计算。
匹配 W01-W04 样本，将传统渠道、现代渠道、分销和 APP 推广追踪分开处理；对缺少正式表的 APP 活跃场景，明确只能基于可用事件数据降级输出。
系统不会把缺失字段或表硬凑成完整答案，而是把可计算结果和待补数据源清楚分开。
冰柜巡检、麒麟绑定、在控冰柜、有效网点池和关键门店池需要长期维护，否则覆盖率和巡检指标的分母会不稳定。
匹配 I01-I02 样本，关联 Terminal、IceBox、MNShop、冰柜巡检和关键门店相关表，说明对象池来源、状态和可维护边界。
销售运营可以把指标异常追溯到对象池和资产维护问题，而不只停留在单次统计结果。
当业务人员询问“本月各大区有效网点非去重拜访、去重拜访和开发数分别是多少”时，系统先匹配 B01 场景，识别“大区”为 Department level=2，“有效网点”为 Terminal 中 status='Y' 且 ismnshop='Y'，“开发数”为 Visit 的 pronum>=3。随后语义层返回 Visit、Terminal、Department 的关系和表映射，数据层在 ClickHouse 中连接 app_visit_m_local、com_terminal_info_local 和 com_department_info_local 计算结果。最终输出不只是一张统计表，还会说明使用的时间范围、关键表、字段规则和指标口径，方便业务人员复核。
把销售口径转成网点、拜访、部门、产品、冰柜等业务对象，减少报表字段和自然语言之间的理解偏差。
从指标结果追溯到场景编号、实体关系、关键表和字段规则，定位数据来源和计算链路。
将客户、标签、渠道、活动、终端和经营指标统一校验，目标核心字段完整率达到 98% 以上，重复/冲突记录识别率达到 95% 以上，质量问题定位时间压缩到 15 分钟内，整改闭环率提升至 95% 以上。
将自然语言经营问题转化为语义查询和 ClickHouse SQL，形成可执行、可复核的销售问答流程。
样本场景、规则、本体和查询模板分层维护，后续新增指标或字段时可以沿同一语义框架扩展。
公开展示审核通过的会员留言，帮助案例经验持续完善。
成为第一个围绕这个案例提出问题或分享复现经验的会员。