案例价值
该证券公司研究所所长过去想了解"近一月哪些研究员发布的报告被机构客户阅读量最高"，需要让秘书联系IT部门，从研报发布系统导出报告列表，再关联机构客户的访问日志，最后手工汇总排名，整个过程至少需要2个工作日。现在所长直接用自然语言提问，系统30秒内返回完整排名数据。研究员的绩效考核终于有了实时、客观的数据支撑。
价值详解
研究所的日常工作围绕研究报告展开——宏观策略报告、行业深度报告、公司点评报告。研究员的核心产出是报告，衡量产出质量的核心指标之一是机构客户的阅读量。但过去这个问题很难回答：阅读量数据分散在PC端网站、移动端H5、APP三个平台，各平台独立统计，没有统一口径；研究员与报告的关联也依赖人工维护，一旦研究员岗位调整，关联数据就可能错乱。
智能问数平台将分散的阅读量数据整合到统一的本体语义层下：研究员本体、报告本体、阅读量本体分别建模，阅读量再细分为PC端阅读、移动端H5阅读、APP阅读三个维度，每个维度都有明确的计数规则。所长提问时，系统自动聚合三个数据源的阅读量，按研究员维度汇总，排除内部测试账号的访问，最终输出有据可查的排名。"哪些研究员的报告被机构客户看得最多"，一句话，10秒出结果。
技术路径
本案例的技术路径以多源数据整合与聚合语义计算为核心，解决了跨平台数据统一口径的核心难题。
本体建模：研究员、报告、阅读量三本体
技术团队构建了研究所域核心本体。研究员本体包含工号、姓名、所属团队、入职时间、岗位等属性，以及与报告之间的"撰写"关系；报告本体包含报告ID、标题、发布时间、类型（宏观/策略/行业/公司）、对接研究员等属性，以及与阅读量之间的"产生"关系；阅读量本体则细分为三个维度：PC端阅读数（记录IP地址+Cookie）、移动端H5阅读数（记录设备ID）、APP内阅读数（记录用户账号）。本体层定义了跨平台阅读量的合并规则：同一机构客户（通过IP段或账号体系识别）在同一报告上的多次阅读，计为一次有效阅读，避免刷量。
语义映射：聚合与排名语义
"近一月哪些研究员发布的报告被机构客户阅读量最高"这句话，系统解析出：时间范围（近30天）、主体（研究员）、聚合对象（报告的阅读量）、筛选条件（机构客户，非个人客户）、排序方式（阅读量降序）。语义映射层将"机构客户"识别为一个特殊维度——通过客户注册信息中的客户类型字段（机构 vs 个人）进行过滤，而非通过IP范围粗略判断。若机构客户中有部分访问记录缺失账号信息，系统会标注该部分数据为"未识别来源"，不纳入排名分母，确保分子分母清晰。
查询执行：跨平台去重与研究所内权限过滤
查询执行需要聚合三个平台的数据。每个平台有独立的查询接口，耗时不等（PC端最快，APP端最慢）。系统采用异步并行查询+超时兜底策略：三个平台同时查询，60秒内返回已到的结果，已超时平台标记为"数据获取中"，用户可稍后刷新看到完整数据。结果返回前经过研究所内权限过滤：只有当前用户有权限查看的研究员报告才会出现在排名中。
过程难点
项目实施过程中，团队逐一攻克了三个核心难点，每一个都直接影响最终数据的准确性。
难点一：阅读量数据源分散（PC/移动/APP）
三个平台的阅读量数据独立存储，统计口径各异：PC端记录"页面访问"，移动端H5记录"触底曝光"，APP记录"停留时长超过10秒的阅读"。直接相加会重复计算——同一客户可能同时通过PC和APP访问同一篇报告。技术团队在本体层定义了去重合并规则：同一报告+同一客户（通过手机号或身份证号识别）跨平台的多次访问，合并为一次有效阅读。去重后数据与各平台原始数据差异超过30%，经过与业务部门反复确认后，采用去重后数据作为统一口径。
难点二：研究员与报告关联需人工维护
研究报告的发布流程中，报告系统里记录的是"撰写人"字段，但实际署名可能有多人，且存在联合署名、审核人署名等情况，导致报告与研究员的关联并不精确。技术团队与研究所行政人员协作，建立了"研究员-报告关联表"，每季度更新一次，重大报告（如深度报告）由研究员本人确认署名信息。系统支持追问："这篇报告的阅读量构成里，机构客户占比多少？"——通过客户类型字段与报告类型的交叉分析，验证数据的合理性。
难点三：内部测试流量与僵尸账号干扰
研报发布系统上线前，测试人员产生了大量测试阅读记录；研究所内部同事在报告正式发布前也会提前"预读"。这些流量如果不排除，会严重扭曲阅读量排名。技术团队建立了白名单机制：测试IP段、内部员工账号统一纳入白名单，阅读量计入系统测试统计但不展示在排名中。同时，设置了"沉默账号"过滤——近90天内没有任何真实交易行为的账号，其阅读记录不纳入统计。经过清洗，研究所内排名数据与业务部门预期基本吻合。