设计一个ChatBI/智能问数Agent，业务说一句话就能出数

用户问题："上周华东区新客的复购率是多少"
   │
   ▼
① 问题理解：意图分类(查数/解释/闲聊)、时间解析(上周=?)、实体识别(华东区/新客)
   │       信息不足 → 澄清："复购率按 30 日还是按自然月？"
   ▼
② 语义召回：从语义层召回候选指标/维度/枚举值 + 相似历史问答(few-shot)
   ▼
③ 查询生成：优先生成结构化查询(指标+维度+过滤)，复杂问题再生成 SQL
   ▼
④ 校验：语法 / 权限 / 分区过滤 / 预估扫描量 / 口径一致性
   ▼
⑤ 执行：只读账号、超时、行数上限、结果缓存
   ▼
⑥ 解释与反馈：数字 + 图表 + 口径说明 + 生成的 SQL；用户点赞/纠错回流

// 模型输出：结构化查询意图（而不是直接写 SQL）
{
  "metric": "repurchase_rate_30d",       // 必须是语义层里已定义的指标
  "dimensions": ["region"],
  "filters": [
    {"field": "region", "op": "=", "value": "华东"},
    {"field": "user_type", "op": "=", "value": "新客"}
  ],
  "time_range": {"start": "2026-09-28", "end": "2026-10-04"},
  "time_grain": "week"
}
// 语义层负责：校验指标/维度是否存在、是否允许组合，再编译成 SQL

实际系统通常是两者结合：高频标准问题走语义层，语义层覆盖不了的长尾问题降级到 Text-to-SQL，并且明确提示用户“这是基于明细表的探索性结果，口径未经认证”。

展开三：时间和实体解析，最容易翻车的地方

问数系统里，模型最容易出错的往往不是复杂 SQL，而是“上周”“昨天”“华东”“新客”这种看起来很简单的词。

• 时间：“上周”是自然周还是最近 7 天？周一开始还是周日开始？“昨天”按哪个时区？

• 枚举值：用户说“华东”，数据里可能存的是“华东大区”或者区域编码“EC”。

• 业务概念：“新客”是首单用户、注册 30 天内用户，还是当月首次活跃用户？

跨时区这一点我深有体会。我在某短剧出海公司做跨时区数据处理时，同一个“昨天”，按北京时间和按美国西海岸时间切日，差了十几个小时，数字完全对不上。所以在问数系统里，时间解析不能交给模型自由发挥，而要用确定性的规则：默认时区、默认周起始日写进配置，解析结果显式展示给用户。

# 时间解析走确定性规则，模型只负责识别"上周"这个短语
TIME_RULES = {"week_start": "MONDAY", "default_tz": "Asia/Shanghai"}
 
def resolve_time(phrase: str, now: datetime, site_tz: str | None):
    tz = ZoneInfo(site_tz or TIME_RULES["default_tz"])  # 站点时区优先
    today = now.astimezone(tz).date()
    if phrase == "上周":
        this_monday = today - timedelta(days=today.weekday())
        return this_monday - timedelta(days=7), this_monday - timedelta(days=1)
    if phrase == "昨天":
        return today - timedelta(days=1), today - timedelta(days=1)
    raise NeedClarify(f"无法确定时间范围：{phrase}")      # 解析不了就澄清
 
# 枚举值：用维度值索引做模糊匹配，"华东" → region_code='EC'

展开四：结果可信——让业务能自己判断对不对

智能问数最大的风险不是“答不出来”，而是“一本正经地答错”。所以返回结果时必须附带“解释包”：

• 口径说明：用的是哪个认证指标，定义是什么（复购率 = 30 天内再次下单的新客数 / 新客数）。

• 查询条件：时间范围（2026-09-28 至 2026-10-04，北京时间）、过滤条件。

• 数据新鲜度：数据更新到哪一天，是否有延迟。

• 可展开的 SQL：给懂行的人核对。

• 置信提示：走的是认证指标还是探索性查询。

这几项看起来琐碎，但它们决定了业务敢不敢用这个系统。一个可解释的错误答案能被快速发现和纠正，一个不可解释的正确答案也没人敢信。

追问链

追问一：准确率怎么评估？做到多少可以上线？

我会从历史取数工单、群聊提问里收集真实问题，每个问题配上标准答案（标准的结构化意图或 SQL，以及执行结果）。评估时比较的是执行结果是否一致，而不是 SQL 文本是否一致，因为同一个结果可以有多种写法。

评测集要按难度分层：单指标单维度、多维度过滤、同比环比、多指标计算、需要澄清的模糊问题。上线标准不是一个笼统的数字，而是高频简单问题要非常高、复杂问题可以降级为“给出 SQL 让人确认”。另外“该澄清时澄清、该拒答时拒答”也要单独评估。

追问二：表有几千张，模型上下文放不下，怎么办？

不让模型看全部表。第一层，语义层只暴露经过认证的几十到几百个指标和维度；第二层，每次请求先根据问题检索最相关的指标、维度、枚举值和历史问答，只把 TopK 放进上下文；第三层，长尾问题需要查明细表时，也是先检索候选表，再把候选表的结构和样例数据给模型。这就是“先召回、再生成”的思路，和推荐系统一样。

追问三：用户纠错的数据怎么用起来？

纠错是最宝贵的数据。我会把它分成几类处理：如果是口径理解错，补充语义层的同义词和描述；如果是枚举值没匹配上，补充维度值别名；如果是SQL 逻辑错，把纠正后的问答对加入 few-shot 示例库和评测集。每次迭代后用评测集回归，确保改一个问题不会引入新问题。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
七分靠数据、三分靠模型，核心在语义层	用大模型直接生成 SQL 就行
模型生成结构化意图，SQL 由语义层编译	把所有表结构塞给模型
时间、枚举、业务概念用确定性规则解析	准确率靠换更强的模型解决
结果附带口径、条件、新鲜度和 SQL	只返回一个数字，不给任何解释
评测按执行结果比对，按难度分层	没有评测集，靠感觉说效果不错

怎么挂到你的项目上

话术模板：“如果做智能问数，我会把重点放在数据侧：先把高频指标沉淀到语义层，让模型输出结构化查询意图，由语义层编译 SQL，保证口径一致。时间解析这类容易出错的地方我会用确定性规则，因为我之前做跨时区数据时吃过切日不一致的亏。”

如果你所在公司已经有指标平台或者数据字典，一定要讲出来：这就是智能问数最核心的资产。

总结

智能问数的设计题，要把重心放在语义层、校验和可解释上，而不是模型本身。记住六个环节和“模型是翻译、语义层是地图、校验是刹车”这个比喻，再用跨时区、枚举匹配这类真实的坑证明你做过数据，这道题就能答得很扎实。

下一篇深挖智能问数最大的痛点：Agent 查数总是用错表、算错口径，到底该怎么解决？

你们公司的智能问数上线了吗？业务用得多吗？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长