自然语言查询数据

🏦 场景与客户

一家电商公司，运营团队二十多人。想要个数据得提需求给数据组：写清要什么、为什么、什么时候要，然后排队。临时取数平均等两三天，赶上大促节点要等更久。数据组三个人大部分时间在写一次性查询，建模和治理一直往后拖。

客户想解决的是取数的排队问题：运营自己用大白话问，当场拿到数，数据组只维护口径和语义层。

📅 实施节奏

• 第 1–2 周：翻历史取数工单，把最高频的几十种问法整理出来，作为首批必须答对的问题清单
• 第 3–4 周：建语义层——指标、维度、同义词、默认过滤条件
• 第 5–6 周：接入查询与结果校验，先只对数据组内部开放
• 第 7 周起：按团队灰度放量，收集问错的问题持续补语义层

🗝️ 方案要点

• 语义层是核心资产：「上月」「华东」「新客」这些词必须映射到明确的字段与条件，映射表由业务与数据组共建
• 只读账号加行级权限：按人的组织归属自动过滤数据范围，权限写在语义层，不靠模型自觉
• 执行前先校验：生成的查询要先过表名字段白名单、扫描量上限、超时限制，才允许提交执行
• 不确定就反问：命中多个口径或缺少时间范围时，返回澄清问题，而不是猜一个然后给出错误的数

⚖️ 选型与权衡

🚧 实施难点与排查

• 模型编造字段名：早期生成的查询经常引用不存在的字段。改为先做字段与表名白名单校验，不通过直接返回澄清问题
• 关联歧义：订单表里有多个金额字段（应付、实付、含税），模型常选错。做法是在语义层给每个字段写清业务含义与常用场景
• 聚合漏条件：问「上月销售额」时忘了排除测试订单。把这类默认过滤固化进语义层，不指望模型每次都想起来
• 拖垮从库：有人问全量明细导致慢查询。强制加行数上限与超时，超限提示换一种问法

💵 成本与收益

• 成本：语义层建设约 2 人 × 5 周；此后每月约半个人力维护
• 收益：临时取数需求明显下降，数据组把时间转回建模与治理
• 隐性收益：口径写在语义层里，比散在几十个一次性脚本里更容易审计和复用

🛡️ 风险与保障

• 越权取数：权限在语义层强制注入，不依赖用户提问方式
• 敏感字段：手机号、地址等脱敏后才可见，明细导出单独审批
• 结果误用：每条结果带口径与数据时点，避免被当成对外口径
• 审计：查询语句与结果留日志，出现争议可还原当时看到的是什么

♾️ 可复用与演进

• 语义层可同时支撑自助问答、固定日报、经营看板，一处定义多处使用
• 后续做取数需求自动分流：能被语义层覆盖的直接引导自助，覆盖不了的才进工单
• 再进一步分析问句日志，把高频问法转成固定报表，减少重复计算