随着 AI 广泛应用，企业用户期待商业智能 BI 系统也能实现 AI 式数据查询。业务人员可以在 BI 系统中输入自然语言，比如“我要查今年广东省客户的空调订单金额”，就能得到想要的结果，效率一定会大幅提升！
实现 AI 式自然语言数据查询的现有思路并不复杂，BI 调用大模型接口，把自然语言转换为查询语句（比如 SQL），提交给数据库执行并返回结果。但是，这种方案却面临一个巨大的难题。
大模型技术实现自然语言数据查询的难题
对于企业 BI 来说，数据查询的准确性是最重要的。而大模型则存在幻觉，就是常常会“一本正经的胡说八道”。大模型给出的查询语句，很可能看起来符合语法，执行后却会得到错误结果。
尝试过大模型写代码的程序员都知道，效率是能提高很多，但因为无法保证 100% 正确，还是需要人工确认才行。对于能看懂代码的程序员来讲，这不是大问题。但是 BI 用户是业务人员，绝大多数不会编程，无法判断查询语句的正确性，也不能纠正错误。
如果是语法错误那还好办，执行时就会报错，但若是语义错误，执行也能得到结果，业务人员就无法判断了。比如输入中有“北京”字样，大模型会理解成地名，但也许正好有一款产品代号是“北京”，倘若业务人员应用了错误的查询结果，很可能给生产经营带来损失。
其实，无论用户输入怎样的问题，大模型永远都会给出一个结果，即使数据库中数据根本就无法计算这个任务目标，大模型也不会拒绝，不懂编程的业务用户根本没办法发现和纠正大模型的错误。
现有方案难以解决大模型困难
大模型写不出正确的数据查询语句，有相当部分原因是缺乏企业数据查询的领域知识造成的，包括：
大模型可以采用微调的方式来获取这些领域知识，即用相关的标注数据对现有模型进行训练。不过微调的过程是“黑盒子”，很难检查大模型是否真学会了这些领域知识，很可能学歪了、记混了，而我们几乎没办法察觉和调试。
而且，微调需要用大量计算资源和高质量的标注数据对大模型进行训练，技术难度大，资源成本高，开发周期长。一旦业务规则或者数据结构发生变化，模型就要重新微调，非常不灵活。
另一种方法是使用 RAG（检索增强生成）来提高大模型正确性，但效果也不理想。RAG 引入外部知识库存放领域知识，但知识库检索存在精度问题，找不到关键领域知识的可能性很大。而且，大模型常常更倾向于依赖内部参数而忽略知识库的检索结果，还是会得到错误的查询语句。
还有一种方法是利用“提示工程”，把领域知识都放到提示词中。这种做法本质上和 RAG 区别不大，也无法确保生成正确的查询语句，而且还导致性能下降，token 费用上升。
实际上，大模型的本质是概率模型，它的训练目标是生成流畅、连贯的文本，而不是绝对精确的查询语句。
润乾报表新突破，实现精确 AI 式数据查询
润乾报表 NLQ 组件采用规则引擎技术，通过抽象汉语规律得到规则模型，可以实现精准的 AI 式数据查询。
NLQ 组件预先用领域知识建立词典，导入数据结构，定义数据表、字段、维度、指标等专用词。词典中还包含比较词、量纲、聚合词、连接词等查询要素。
这些词承载了领域知识，词典则构成了领域知识的完美容器。从用户输入的自然语言词句匹配到词典中的词，就是应用领域知识的过程：
打个比方，规则引擎的领域知识是“手册”中的明文规定, 大模型的知识则是“模糊记忆”。比如用户要查“昨日存款总金额”，规则引擎可以明确定义这个指标的计算公式，各个币种要折合成人民币再汇总。缺乏领域知识时，大模型就很可能忽略币种和汇率，按照一般思路对金额求和得出错误的结果。
当 NLQ 组件识别不了用户的输入时，会提示无法查询，请用户换一种说法再尝试。而不会像大模型那样总是给个不知对错的答案。
NLQ 组件给出结果后，会以用户看得懂的形式对这个语句进行解释，如果有多种解释也会让用户选择，比如日期可以是发货日期或者收货日期：
润乾报表 NLQ 搭配大模型，让 AI 式自然语言数据查询锦上添花
规则引擎对自然语言的规范性有一定要求，不能使用太随意的词句。我们可以通过适当的培训，让用户习惯用相对规范的自然语言表达，就可以达到很好的使用效果。实际上，用户使用大模型也常常要学习“提示工程”，了解如何写提示词才能得到较好的结果。
润乾报表 NLQ 组件不依赖大模型就可以工作，搭配大模型后还能进一步提升用户体验，可以用更为随意的自然语言来查询数据：
这样做一举两得，易用性和正确性都能得到保证。
智能 BI 要实现精准 AI 式数据查询，关键在于如何准确承载并应用领域知识。大模型因其概率本质难以担此重任，而润乾报表的 NLQ 组件通过规则引擎明确定义领域知识，是领域知识最完美的容器，从根本上确保了查询的准确性，让 AI 式数据查询从概念迈向实用，从而真正释放数据价值。
