客户经营问数

经纪业务部每日需要回答大量类似的经营问题：哪些营业部的新客户户均资产更高？本月新开户中风险等级为C4的客户占比是多少？高净值客户（资产前10%）的月度交易频率较整体客户高出多少？以往这些问题都需要业务人员提交数据需求工单，IT人员从各系统取数、口径对齐、清洗汇总，最快也要3天才能给出初步数据，且不同人取出的数据经常因口径差异而"打架"。

智能问数平台上线后，经纪业务总监可以随时提问："本月新增客户里资产前10%的平均佣金率是多少？"。系统基于本体语义层直接理解"新增客户""资产规模前10%""平均佣金率"三个概念，自动对接CRM、交易、财务三个数据源，在权限控制下只返回当前用户有权限查看的营业部数据，30秒内返回结果，业务人员无需等待，数据分析师解放出来专注更复杂的专题分析。

技术团队首先对经纪业务的核心业务实体进行抽象建模。客户本体涵盖客户号、开户时间、所属营业部、风险等级、资产规模等属性；资产本体记录客户在各时点的总资产、市值、现金余额；佣金本体则细分为佣金收入、规费、印花税、过户费等明细科目。本体层定义了各实体之间的关联关系：客户→所属营业部→营业部下辖客户群，客户→资产变动（时序），客户→交易→产生佣金。本体建模的关键是统一业务术语与数据字段的映射关系，例如"本月新增客户"映射到CRM系统的开户日期在当月1日至今的客户，"资产规模前10%"通过聚合客户当前总资产并计算百分位数。

当业务人员提问"本月新增客户中资产规模前10%的平均佣金率"时，系统首先通过NLP解析识别出四个语义单元：时间范围（本月）、客户范围（新增客户，定义=当月开户）、资产条件（前10%，定义=户均资产排名）、聚合指标（佣金率=佣金收入/成交额）。语义映射层将上述理解映射为本体中的实体和关系路径，并通过权限语义自动加上"当前用户可访问的营业部"过滤条件。语义映射还需要处理模糊表达，例如"佣金率"在不同营业部可能有不同理解（有的含规费，有的不含），系统通过预定义的语义规则统一处理，并支持用户在问数时指定口径。

查询执行层将语义映射的结果转化为底层SQL或API调用。本案例涉及三个数据源的联合查询：CRM系统提供客户基础信息和营业部归属，交易系统提供交易量和佣金数据，财务系统提供收入明细。由于不同数据源的数据更新频率不同——CRM客户资产数据为T+1更新，而交易系统佣金数据为实时——系统需要处理时间对齐问题。最终查询结果经过权限过滤后返回，并附带数据口径说明，让业务人员了解这个数字是怎么算出来的。

CRM系统中的客户资产数据每日凌晨批量更新，这意味着下午提问"本月新增客户资产前10%"时，看到的资产数据可能是昨天收盘后的数据，与当日实时资产情况存在偏差。业务部门明确要求"今天开户的客户，今天就要能看到其资产排名"。技术团队与业务部门协商后，采用分层策略：对于需要实时性的场景，优先使用交易系统的当日成交额作为资产近似指标；对于日终资产比对场景，则使用CRM的T+1数据。系统在同一问数中自动识别场景并选择数据源，但会标注数据时效性，让用户知道这个数字是"实时估算"还是"T+1确认"。

"佣金率"在不同营业部有不同理解。有的营业部按"净佣金"计算（不含规费），有的按"全佣金"计算（含规费、印花税、过户费），还有的用"佣金收入/代理买卖证券收入"的口径。在没有统一标准的情况下，不同营业部报上来的数据横向比较毫无意义。技术团队耗时6周与每个营业部确认佣金计算规则，并在本体层定义了三种佣金率口径，业务人员提问时可以明确指定，也可以让系统使用默认的"全佣金"口径。结果返回时系统会标注"本结果采用XX口径"，避免数据争议。

经纪业务总监权限覆盖全国20家营业部，但各营业部之间数据互不可见。当总监问"资产规模前10%的客户平均佣金率"时，系统需要先筛选出前10%的客户，再计算其佣金率。但在权限过滤后，某些营业部的客户可能因为样本量太少而无法返回有效结果。技术团队设计了一种"聚合脱敏"策略：当某个子单元（如单一营业部）样本量低于阈值时，该子单元数据不单独显示，但纳入全局聚合计算。这样既保证了数据合规，又让总监能看到有意义的全局统计。