智能问数生成式BI这两年几乎是 AI 产品经理岗位面试和项目复盘里出现频率最高的方向之一。很多人一听到“智能问数”第一反应是大模型加 SQL觉得只要接上 API用户就能直接问“上个月华东区卖了多少”系统自动出图出数。实际做完一个落地项目之后你会发现真正难的不是接大模型而是数据、口径、交互、权限、评估和迭代这一整条链路。这篇文章就按我自己做智能问数项目的拆解顺序讲清楚生成式 BI 到底怎么落地、产品经理要盯哪些关键环节以及最容易踩的坑在哪里。适合正在做 AI 产品、数据产品或者准备转 AI 产品经理方向的人看。1. 智能问数到底是什么先分清它解决的和不解决的1.1 一个最小场景从“数据在系统里”到“答案在对话里”先看一个最简单的用户诉求。运营人员想知道“上个月华东区的订单金额是多少”。在没有智能问数之前他通常要走这么几步打开报表系统找到订单模块筛选时间范围选择华东区再看汇总数字。如果报表里没有这个维度组合就要提需求给数据团队排期、开发、上线最短也要一两天。智能问数要解决的问题就是把这套流程压缩成一句话。用户打开对话框输入“上个月华东区订单金额是多少”系统理解“上个月”是时间条件“华东区”是区域维度“订单金额”是指标然后自动生成查询逻辑从数据库里取数最后以数字加图表的形式返回结果。这个能力在行业里叫自然语言转 SQL通常也归在生成式 BI 的范畴内。最小场景拆开之后你会发现它其实包含五个环节理解用户问题中的指标、维度、时间条件和筛选条件。把自然语言映射到对应的数据表、字段和指标口径。生成可执行的查询语句。在数据库里执行查询并拿到结果。把结果转成用户能看懂的数字、图表和文字解释。任何一个环节断了用户都会觉得“不好用”。所以做智能问数不能只关注模型能不能生成 SQL还要把前后环节一起设计好。1.2 智能问数和传统 BI 不是替代关系而是互补关系传统 BI 解决的是“已经知道要看什么指标怎么高效看”的问题。它的强项是固定报表、看板、数据透视稳定、可控、权限清晰。弱点是灵活性差用户一旦要新维度、新口径就得重新配置。智能问数解决的是“用户不确定具体怎么查或者不想记菜单”的问题。强项是交互门槛低输入一句话就有结果。弱点是结果可能不稳定容易受语言表达、数据质量、提示词配置的影响。我自己在做项目时并不会把智能问数定位成传统 BI 的替代品而是把它定位成一个“查询入口”。固定看板继续保留智能问数覆盖临时查询、探索式分析、新员工找不到报表入口这三类场景。这里有一个很重要的产品判断智能问数适合处理“查询路径短、口径明确”的问题不太适合处理“复杂多表关联 严谨财务口径 需要多轮确认”的重型分析。如果一上来就要求它覆盖所有财务月报场景落地难度会成倍增加。1.3 它解决不了的问题比能解决的问题更值得关注常见误区是以为智能问数能“凭空知道企业数据”。它做不到。它所有的回答能力都建立在数据表结构、字段注释、指标字典和已配置的业务口径之上。如果底层数据本身就是脏的字段命名全是拼音缩写指标口径在不同部门之间不一致那模型再强也回答不出正确结果。它也不解决权限问题。用户能不能看华东区能看订单金额还是只能看订单数量这些必须由权限系统控制。不要把权限验证完全交给模型模型生成的 SQL 必须经过一层执行侧的安全校验。另外智能问数不负责帮你把数据质量提升。它更像一个放大器数据质量好它能放大数据的使用价值数据质量差它也会把问题更快暴露出来。产品经理在立项阶段就要把这些边界跟业务方讲清楚否则很容易被当成“万能查询工具”然后因为预期过高而被打上不好用的标签。2. 需求拆解阶段先拆四层再谈技术选型我不建议产品经理拿到需求后直接去看 LangChain 怎么写、SQL 怎么接。建议先把整个系统拆成四层每一层分别想清楚要做什么、谁来负责、成功标准是什么。这样后面无论用什么模型、什么框架你的核心逻辑都不会乱。2.1 数据层表、字段、指标口径这一层决定上限数据层是一切的基础。你要先梳理清楚这些问题用户会问到哪些业务表例如订单表、用户表、商品表、退款表。每张表有哪些字段字段含义是什么字段类型是什么。时间字段用哪个是下单时间、支付时间还是发货时间。维度字段有哪些比如区域、城市、渠道、商品类目。指标口径是什么比如订单金额是含税还是不含税是否包含退款订单。数据刷新频率是多少是实时还是 T1。这些内容最终会形成一份“指标字典”和“表结构说明”这是智能问数系统的核心知识库。大模型不知道你的表里有什么也不知道“销售额”和“GMV”在你的业务里有什么区别你必须把这些信息喂给它。我当时做的时候先拉了数据团队和业务方开了一次口径对齐会把所有高频指标的定义统一成一张表。看似是文档工作实际决定了后续提示词和问答效果的基线。这里最容易被忽略的是同义词比如用户说“卖了多少钱”可能指订单金额“营收”可能指支付金额。这些同义词要在数据字典里提前列出来或者通过示例让模型学会。2.2 问答层自然语言理解、条件抽取和 SQL 生成问答层是智能问数的核心技术层主要包含三个子任务。第一个是意图理解。用户的问题可能是查数值、看趋势、做对比、找异常也可能是问“为什么”。不同意图需要的处理逻辑不一样。比如“对比华东和华南的销售额”需要做分组对比“销售额为什么下降了”则可能需要拆时间、拆区域、拆品类来分析。第二个是条件抽取。要把“上个月”“华东区”“订单金额”这类的表达拆成结构化信息指标是订单金额维度是区域条件值是华东时间范围是上个月。这步抽取不准后面 SQL 生成一定错。第三个是 SQL 生成。模型根据数据字典、表结构、提示词和抽取结果生成一条查询语句。这里要注意SQL 生成完不能直接丢给数据库执行要先做安全检查确认表名、字段名、条件值都来自系统已授权的范围。从产品角度看问答层的关键不是“模型能不能写出 SQL”而是“模型写错时被拦截的概率有多大”。所以在设计上一定要留出“用户确认条件”的环节而不是把生成结果直接当作最终答案。2.3 展示层图表选择、结论生成和导出很多团队做完 SQL 查询就结束了其实还差展示层。用户要的不只是一串数字而是能快速理解的结果。展示层要做三件事第一根据查询结果自动选择合适的图表。单个时间序列用折线图区域对比用柱状图占比用饼图数值明细用表格。这部分不一定用模型判断也可以靠规则确定。第二生成一句结论性文字。比如“华东区上个月订单金额为 1200 万较前一个月增长 8%”。这句话来自数据计算不是模型编出来的。产品要避免让模型根据概括性描述编数字正确做法是把真实计算结果传给大模型让它组织语言。第三提供导出能力。用户可能需要截图、下载 CSV 或生成分析报告。如果问数结果不能导出很多业务方会认为它只是个“看看还行”的玩具。导出功能和权限要绑定敏感字段不能导出。2.4 交互层追问、澄清、权限和多轮上下文最后一个坑多的地方是交互层。第一系统要会“承认自己没听懂”。用户说“看下销售情况”时销售指标有很多时间范围也没有说清楚。系统需要反问是看订单金额还是订单量是看本月还是本季度这就是澄清机制能大幅提升准确率。第二系统要支持多轮追问。用户先问“华东区订单金额”再问“那华南呢”系统要能理解“那”指的是订单金额这个指标只是把区域换成华南。这需要维护一个会话上下文把上一轮抽取到的指标和维度记住。第三权限要在交互层实时生效。用户能问哪些字段、哪些维度、哪些区域必须在数据查询时做过滤不能只靠模型自觉。权限过滤通常有三种实现方式在数据库账号层做行列权限控制在查询生成后追加权限过滤条件在结果返回后做字段脱敏。实际项目里组合使用更稳妥。第四反馈机制。用户点赞、点踩、标记“结果不对”的按钮一定要有。这些反馈是后面迭代评估集和提示词的重要数据来源。3. 最小验证怎么做环境、样例和判断标准3.1 环境准备不一定要高配置但一定要有边界智能问数项目的最小验证环境并不像训练模型那样需要高端显卡。它主要依赖三部分大模型服务、数据库服务、应用服务。大模型服务可以是外部 API也可以通过本地部署的模型来跑。最小验证阶段先用外部 API 最省事因为你主要验证的是产品逻辑不是模型部署能力。本地部署则要考虑显存、内存、并发和模型体积适合后面做私有化部署时再深入。数据库服务需要一套可以读取的业务数据。不要拿生产环境直接连最好复制一份脱敏数据到测试环境。这样即使 SQL 生成错了也不会影响线上数据。应用服务就是一个能跑后端逻辑和前端对话框的环境。后端负责把用户问题拼装成提示词调用大模型执行 SQL返回结果。前端负责展示对话框、图表和反馈按钮。我建议最小验证阶段的数据范围不要太大先选一个业务域比如“订单域”包含 3-5 张表20 个以内的字段20 条以内的高频问答样例。这样既能把主流程跑通又不会因为数据复杂度过高而很难排查问题。3.2 最小问答流程怎么设计先做一条端到端用例最小验证的目标是一条完整的“自然语言-查询-结果-展示”链路能跑通。先不要追求覆盖很多问题也不要把流程做得太复杂。建议先用这样的调用链用户输入问题 - 系统把问题发送给大模型附带数据字典和表结构信息 - 返回结构化查询条件或 SQL - 系统解析后执行查询 - 拿结果生成图表和结论 - 前端展示并允许用户点“对/错”。先用一条测试问题比如“上个月的订单总额是多少”跑通这条链路。跑通之后再换几种不同表达“上个月订单金额”能不能识别成同一指标。“华东区上个月订单金额”能不能抽出区域条件。“上月和这个月比订单金额是涨还是跌”能不能做对比。每条用例跑完记录三个结果模型识别是否准确、SQL 是否执行成功、返回结果是否与手工查询一致。3.3 成功标准准确率、执行率、响应时间和用户反馈判断最小验证成不成功不能只看模型有没有输出。我一般会盯四个指标第一个是条件抽取准确率。模型有没有正确识别指标、时间、维度和筛选值。只要有一个识别错最终结果基本就是错的。第二个是 SQL 执行成功率。生成的 SQL 在目标数据库里能不能正常跑。语法错误、表名错误、字段不存在都会导致执行失败。成功率要尽量到 95% 以上否则用户感受会很差。第三个是结果一致性。系统返回的数字跟直接用 SQL 查出来的数字是否一致。注意这里不能只看“看起来差不多”要拿数值精确比对。第四个是响应时间。从用户发出问题到看到结果最好控制在 5 秒内。如果超过 10 秒用户会觉得不如自己开报表查。这个时间不只是大模型生成时间还包括 SQL 执行时间。- [你的上一轮文字在此时结束] - 我还没写完——让我继续。我把前面的内容继续补完。最小验证里如果没有提前定好这四个指标很容易出现“Demo 看着很厉害一测问题一堆”的情况。我习惯把这些指标写进项目周报里每轮迭代都贴出来让团队看到变化趋势。另外最小验证阶段还要记录一个问题清单。每个失败案例都要记录用户问了什么、系统回答了什么、失败在哪一层。这个清单就是后续优化提示词和构建评估集的一手素材。4. 产品设计里的关键细节意图、参数、上下文4.1 用户输入不一定是标准问法先做输入归一化智能问数最常遇到的不是复杂 SQL而是用户“不好好说话”。比如“上个月一共多少单” 和 “上个月的订单量” 是同一个指标。“卖得最好的是哪个城市” 和 “按城市统计订单金额降序排名第一” 是同一个逻辑。“为什么这个月少了” 其实要先知道上个月的值、这个月的值再做对比分析。“华东呢” 这种输入单独看完全无法理解要结合上一轮上下文。这些情况单独靠模型很难全部处理对。我建议产品侧增加一个“输入归一化”环节就是把用户输入转换成系统内部统一的查询结构。结构一般长这样{ intent: query_trend, metrics: [order_amount], dimensions: [region], filters: { region: 华东区, time_range: last_month }, compare: null }这个结构就是问答层的输出标准。模型先把自然语言转成 JSON 结构再由另一段逻辑根据结构生成 SQL。这样做的好处是即使模型输出的 SQL 有语法错误你还可以用结构化参数重新生成也方便做日志记录和评估。这里的“另一段逻辑”可以是模型也可以是自己写模板。我一开始用的就是模型直接生成 SQL后面发现结构化抽取更好排查问题。你可以根据团队能力选择但产品上建议把“中间结构”作为系统设计的一部分而不是让它黑盒化。4.2 系统必须有的三个交互机制第一个是澄清机制。当系统识别到条件模糊时不要直接猜而是反问用户。比如“上个月”有歧义时可以问“您指的是自然月还是最近 30 天”这个机制能显著降低错误率。第二个是修改机制。用户问完第一轮之后可能会说“不对我要看数量不是金额”这时候系统要能更新上一轮的指标而不是开启一个全新会话。修改机制的核心是支持对历史条件做增量更新。第三个是下钻机制。用户看到全国订单金额后可能会问“那华东区呢”或者“按月份拆开看”。这类问题不是新查询而是对已有结果的下钻。下钻机制要求系统能记住上一轮的聚合条件并在此基础上新增维度或缩小范围。这三个机制做得好智能问数才像一个“能对话的分析助手”而不是一个“单轮翻译工具”。4.3 权限、血缘和可追溯性不能省权限问题在智能问数里比普通报表更敏感因为用户可以用自然语言绕过固定的报表菜单。虽然底层还是查数据库但如果权限校验没做好用户通过对话就可能看到不该看的数据。安全基线要注意几点数据库只读账号不要给写入权限。查询结果强制 LIMIT避免超大结果集拖垮数据库。行级权限要注入到 SQL 条件中比如“当前用户只能看华南区”。列级权限要控制字段输出比如果客户手机号、身份证号不能出现在结果里。敏感字段在展示层做脱敏处理。血缘和可追溯性也要一起设计。每次问答都要能回答“这个问题查了哪张表、哪个字段、执行了什么 SQL、返回了什么数据”。这既是审计需要也是排查问题的依据。我会在每轮问答的日志里保存用户原话、中间结构、生成的 SQL、实际执行结果、耗时、模型版本、提示词版本。这样线上出了问题能按时间线回溯。这里建议加一个引用块注意智能问数项目的权限设计不能只依赖大模型“不去编造”必须在 SQL 执行层加上强制校验。产品经理在需求文档里要把这条写成硬性要求。5. 从单条问答到批量落地评估、日志、运营5.1 先建评估集再谈模型优化智能问数类项目有一个很容易犯的错误直接拿线上用户的真实问题去调试提示词调完觉得“好像好多了”但没有量化基准。这样迭代几轮之后团队都不知道整体准确率到底有没有提升。正确做法是先建一套离线评估集。评估集由历史真实问题、典型业务问题和边角问题组成。每一条要标注用户原始输入。期望的中间结构。期望的图表结果类型。期望的指标值或者 SQL 逻辑。是否允许通过追问实现。评估集建好之后每次修改提示词、调整数据字典、更换模型都要先跑一遍评估集。对比之前的准确率、执行率和结果一致性。只有整体不回退才允许上线。评估集规模不用太大100 条左右就能有参考价值。关键是覆盖度要够包括简单查询、带时间筛选、带区域筛选、对比查询、趋势查询、模糊表达、缺省表达、多轮追问、超出数据范围的表达。每条失败案例要标注失败阶段识别错、条件抽取错、SQL 语法错、执行超时、结果不一致。5.2 日志和失败率线上问题要看得见、能定位上线之后光有评估集还不够。线上用户不会按你的评估集提问这时需要靠日志监控发现问题。我建议每个问答事件至少记录以下字段用户 ID、会话 ID、问题内容。中间结构抽取结果。生成的 SQL。SQL 执行是否成功、耗时。最终返回结果是否为空、有没有数量级异常。用户是否点了“不对”、是否追问、是否直接离开。触发的是哪个模型版本和提示词版本。这些字段积累起来就可以算出线上的核心指标条件识别准确率、SQL 执行成功率、用户反馈“不正确”占比、平均响应时长、单用户使用频次。一个问答功能如果只有 Demo 时很漂亮上线几周后没有数据的反馈基本就是在靠运气运行。5.3 提示词的迭代是产品工作不只是算法工作智能问数里提示词的实际迭代频率很高。我把提示词相关的配置都叫“知识配置”因为它的内容来自业务知识不来自模型本身。提示词通常包含这几个模块角色定义比如“你是公司数据分析助手负责把用户问题转成查询 SQL”。业务口径说明比如“订单金额订单明细金额之和不含退款”。表结构描述表名、字段名、字段类型、字段含义。同义词表比如“卖了多少钱”对应“order_amount”。示例对列出 10 到 20 个典型的用户问法和对应的中间结构或 SQL。约束说明比如“时间默认为最近 30 天”“金额保留两位小数”。迭代提示词时不要每次全量重写。建议在示例对里增加线上高频的失败案例。比如用户经常问“环比”但模型老是生成错误的日期逻辑就把“某个月环比上个月”的示例加到提示词里。这样改动更可控也不会让前面好的能力退化。提示词版本要管理。每次改动记录版本号并和评估集跑分的结果一起归档。否则改动多了会混乱不知道当前线上跑的是哪一版。5.4 性能和并发别等用户量上来再想智能问数的性能瓶颈主要有两块大模型生成耗时和数据库查询耗时。大模型生成耗时可以通过流式输出优化用户体验让用户先看到“正在识别查询条件”再逐步看到 SQL 或结果。也可以给模型设置合理的 max_tokens避免生成太长内容。最小验证阶段并发通常不是问题但到企业内推广的时候就要考虑同一时间很多人提问API 的速率限制够不够数据库连接池会不会被打满查询结果缓存能不能命中。数据库查询耗时可以在时间范围上做约束限制默认查询时间跨度。比如默认只查最近 90 天防止用户问一句“全年的销售明细”把数据库跑挂。还要对查询结果做缓存相同或相似问题在短时间内直接从缓存返回。6. 常见问题和排查路径遇到问题时先看这几层6.1 报错不一定是模型问题很多时候是输入、数据或权限问题做智能问数项目时线上反馈“回答不对”第一反应不要直接怪大模型。我建议按照“输入-配置-数据-执行-展示”这个顺序排查。第一步看输入。用户原始问题有没有歧义有没有加载到上一轮的上下文。如果用户只说“那华东呢”系统没记住“订单金额”这个指标那结果肯定不对。第二步看配置。数据字典里有没有这个字段同义词表里有没有这个表达指标口径有没有写进提示词。如果表结构描述里字段叫“ord_amt”而你没告诉模型它代表“订单金额”模型只能猜。第三步看数据。字段里是不是有空值、脏数据、异常值。比如时间字段有大量 1970 年或者 2099 年的数据那查“上月”就很容易出现数量级异常。第四步看执行。SQL 是否成功有没有超时有没有被权限过滤掉。很多“没结果”的情况实际上是查询结果为空而不是系统坏了。第五步看展示。数据返回正确但图表类型选错或者结论文字描述跟数据对不上也会让用户觉得“答错了”。模型生成结论文字时数字一定要来自真实计算结果不能让它自由发挥。6.2 智能问数项目最常见的五个坑第一个坑是把所有指标口径都交给模型自己悟。实际上只有把口径明确写进数据字典和提示词准确率才能稳定。第二个坑是不做条件确认。用户输入“华东区销售额”系统直接查询如果用户其实想表达“除华东区之外的其他区域”结果就完全错了。比较稳妥的方式是系统把识别出的条件先展示给用户“华东区近 30 天订单金额对吗”用户确认后再执行。第三个坑是只评估“能跑通”不评估“答得对”。Demo 里问几个问题看着正常就以为系统可用。要注意构建评估集跑分对比再看能否上线。第四个坑是忽略权限。大模型不会天然遵守“当前用户只能看华南区”必须在 SQL 执行层注入权限条件。第五个坑是上线后不迭代。智能问数不是一次性交付。它需要持续收集用户问题、失败案例每周迭代提示词和示例库。如果没有专门的人或机制做这件事准确率会停留在上线初期的水平甚至因为业务变化而逐渐下降。6.3 项目启动前我建议先做好的五件事在做智能问数项目时我会先推动业务方和数据团队一起完成五件事否则后续每个环节都会返工。第一确定一个业务范围和不超过 5 张表的查询范围。不要一开始就铺开到全公司。第二建立一份高频问法清单。找业务方聊列出他们最常用、最想查的 30 个问题。这既是需求来源也是评估集的基础。第三统一指标口径。尤其在“金额、数量、时间”这三个最容易有歧义的指标上必须形成书面定义。第四准备好数据字典和表结构说明。字段名、字段含义、字段示例、同义词和指标口径全部写清楚。第五和运维或后端确认数据库只读账号、连接数、执行超时和结果集限制。这些安全措施必须在项目早期就介入。这些准备工作做完智能问数项目才能从“论文演示”进入“可上线产品”。否则后面多半会在排查问题的阶段反复消耗。最后想说的经验从功能验证到真正在企业里被业务方每天使用智能问数项目里最核心的不是模型选得多强而是你有没有把数据字典建清楚、把评估集跑起来、把权限和日志做扎实。我见过不少团队花了很大精力调大模型最后发现 70% 的问题出在数据字段没描述清楚、指标口径不统一、权限过滤漏掉。先把这几件事做好智能问数就不只是 Demo 里好看而是能真正替用户省下打开报表找数的时间。如果你们团队刚启动这个方向我的建议是先选一个业务域用 50 到 100 条高频问题建评估集把端到端链路跑通再逐步扩大覆盖范围。不要着急把所有业务表一次性接入也不要过早追求复杂图表和报告生成。把单条问答的稳定性和可排查性做扎实比堆砌更多功能重要得多。