智能问数、ChatBI 火了两年，厂商把预期拉满：像聊天一样分析、多轮深挖、AI 自动出结论。仿佛怼上数据库就能跑。但真正做过实施的人都知道——十个项目，九个半一地鸡毛。

原因一：期望太高。又要自然对话，又要多轮交互，又要 AI 自己出结论。AI 远没那么聪明，能把问数本身做准，已经是硬功夫了。大家都还在努力卷准确率，说明现在连数都算不准，后面的分析报告就只能是随便看看了。

原因二：实施太难。很多人以为装上就能用，但真正的门槛在语义层。业务术语千奇百怪，“华北区”“在途订单”“动销率”怎么映射到数据表？语义层不仅要建，还得足够复杂、足够丰富，否则描述能力太弱，用户换种问法就懵了。这事不认真做，跑起来的就永远是个 DEMO。

是不是就没法做了？

那当然也不是，就是摆正上面这两点：首先把期望降下来，别一上来就要全自动分析，先把数算准；然后还要把实施当回事，特别要重视语义层，下功夫做扎实。

怎么才能把数算准？

像润乾 NLQ 就换了一条路，不卷准确率，实现确定性。大模型有幻觉，就不要让它直接生成 SQL，而只是负责翻译成用户可读的“规范文本”，用户确认“是这个意思”之后，不能再由大模型负责执行，而由确定的规则引擎编译成 100% 准确的 SQL，这解决了算不准的问题。

语义层又该有些啥？

润乾 NLQ 的语义层不是简单画个表映射就完事了。它包含字段映射、表间关系、维度层次、度量定义，还有一套可扩展的词汇体系，字段词、比较词、聚合词、宏词、动词……各种词类型。用户问“华北区”“在途订单”“动销率”，系统得知道对应哪些字段、涉及哪些表、走什么关联路径。词典够丰富，描述能力才够强，复杂查询才能被准确翻译成规范文本，覆盖范围更广更复杂的查询场景。

做智能问数别被概念忽悠了，想落地还得务实。