指标平台-从语义底座到智能消费的实践路径-得物技术

一句话概括

得物技术总结指标平台从业务口径、数仓宽表和产品上架流程建立语义底座的实践：以指标字典沉淀隐性知识，用语义相似度和口径冲突检测拦截二义性，再用 Text2SQL、AI Coding 和消费热度验证并反哺治理。

实践内容

三条线建设语义底座

业务侧从存量报表、看板和 SQL 逆向梳理高频指标，对尚未规范化的长尾指标先登记再按复用价值转正；数仓侧把多表关联、粒度和口径收敛到域内精品宽表，先做命名和血缘核查，再按依赖分批改造并明确跨域字段协议；产品侧用结构化表单、自动校验、YAML 批量生成和多技术来源映射，把指标上架做成可复制的生产线。

在源头拦截歧义和质量问题

指标名称和口径必须唯一，提报阶段就要做语义相似度检测与冲突预警，避免“新客”等相同名称对应不同定义。覆盖率分母应锁定经过认证的精品资产目录，不能由各域自行估算；精品宽表上线前强制执行分布验证、NULL 检查和主键唯一性校验，让数据资产同时可被人理解和被 AI 直接消费。

Text2SQL 与 AI Coding 消费

Text2SQL 被拆为理解层和事实层：引擎不仅要理解自然语言，还必须从指标字典知道指标去哪张表、使用哪个字段和哪套口径。文章记录系统测评 SQL 准确率从 85%+ 提升到 95%+，主要归因于条件拼接修复、时间解析固化、字段消费元数据和二义性检测。AI Coding 则依赖同一批指标、OneData 资产、开发原则和反模式作为上下文，支撑数仓模型生成和迁移。

用消费驱动治理

平台通过指标下游调用热度和变更及时率安排治理优先级，让高频被 Text2SQL 或 Agent 使用的资产优先完善；同时继续管理离线、实时等多技术来源的统一口径，并把“字段应如何被查询”的消费元数据提前提供给 Agent。终局标准从“人能看懂”提升为“AI 能依据表名、字段名和语义边界正确取数”。

摘录

指标平台的下一站不是再叠加一个宏大的名词，而是让每一条语义描述都真实、唯一、可信。业务侧要把个人经验里的隐性指标显式化，数仓侧要把散射式依赖收敛成精品宽表，产品侧再把提报、校验和发布做成可规模复制的流程。

Text2SQL 的瓶颈很多时候不在模型推理能力，而在事实层是否存在。字段的逻辑名、物理名、取值方式、时间解析规则和业务边界如果没有被语义层明确声明，模型即使生成语法正确的 SQL，也可能选错口径；语义标注密度提升后，系统测评准确率随治理动作从 85%+ 上升到 95%+。

指标字典还要接受真实消费的检验，并把消费反过来作为治理输入。高频调用的指标优先补充口径和消费元数据，多技术来源继续统一对外结果，最终让 AI 取数准确率成为 OneData 和指标资产建设的验收标准之一。

涉及实体

• 指标字典 —— 指标名称、口径、别名、边界与物理来源的权威语义资产
• NL2SQL —— 先做指标—维度语义映射，再生成并验证 SQL
• 知识库工程 —— 以版本化、可检索和可回写的方式维护指标与开发知识
• Harness-Engineering —— 编排语义检索、代码生成、校验和反馈回写

涉及主题

• []