我花三天时间构建了大模型自助指标查询，零训练弱幻觉

探索大模型在BI自助查询领域的创新应用，一个关键突破在于无需额外训练就能实现低幻觉效果。这为数据科学领域带来了全新的思路。本文的核心将围绕以下几个问题展开：大模型在数据查询中的幻觉问题如何解决？从技术到产品的思维转变如何落地？业务导向的分层设计又怎样提升查询准确性？

_{“世界以痛吻我，我却报之以歌” ——泰戈尔}

大模型之痛

从最初回复的捉摸不定，到后来逐步迈向高准确率，这个过程如同驯服一匹野马，充满挑战也带来成就感。每一次看似“痛苦”的调整，实则像音符般串联起来，最终谱写出新的思路。这种撕裂感与成长感，恰恰推动了技术边界的拓展。

正题

原本打算从RAG、Agent等方向逐步展开，但近期大量客户聚焦于大模型驱动的BI自助查数分析，因此优先做了突击实践。以下是过程中的一些思考。想直接看成品可滑至末尾，附有演示视频。这个DEMO构建耗时约三天，其中Prompt的反复调试占据了大量时间，再加上前端页面搭建并非强项，且对视觉效果颇有要求，因此比原计划多花了一些时间。顺便一提，首次正式使用Streamlit这个工具，感受不错，算是向全栈工程师迈进的一小步。

先抛出两个近期反复思考的问题：

• 大模型的幻觉问题在数据科学领域极易造成差之毫厘、谬以千里的后果。如何解决？这是许多客户甚至投资人反复追问的。
• 基于大模型的数据查询功能，到底是给谁用的？他们以往的查数习惯是什么？这是需要从产品视角去自问的。

这篇文章会主要围绕这两个问题展开。故事开始了。

迷茫

NL2SQL（Natural Language to SQL）是一个“古老”的话题，在大模型兴起之前就已经在研究和发展。技术视角下，自然而然会想到去Spider榜单看看各路大神的刷分表现。Alibaba Group的名字映入眼帘，但随之而来的是更多疑问：不同规模的企业到底有多少张表？企业中是什么角色在查数？查数时Query的类型又是什么？这些问题，或许Spider榜单本身无法给出答案。

聊天

偶然了解到有同行正在做类似的工作，并且计划在11月下旬的AiDD软件研发数字峰会上分享ChatBI的技术实践，核心聚焦于NL2SQL领域的模型训练。聊天中有一句话值得深思：“这不是一个算法，而是产品。”从技术角度看，大模型自身的幻觉是其天性，没有幻觉就没有“创造性”，这是一把双刃剑。在垂直领域，需要通过人类对齐来训练。但回到Spider问题，从业务或产品角度，似乎还没有很好的实践案例可供参考。

灵感

过去长期关注营销域的智能化，对公司的指标平台产品理解较浅，一直觉得它复杂、规则化、枯燥。但近几天初步领会了它的内涵之后（或许只领会了不到一半），灵光一现——它恰好填补了业务KnowHow甚至技术KnowHow的空白。

• 第一：以终为始，以业务为导向。
  查数需求由业务方提出，查哪些指标、哪些维度、哪些过滤条件，这些都有“标准”。这些标准是现成的，已经被同事默默总结出来，这一点至关重要。

• 第二：流程分层，而非端到端。
  过去的认知是从海量数据表中直接查询SQL，但只要在中间加一层包含业务知识的数据结构，一切豁然开朗。

这个“含业务知识的数据结构”究竟是什么？举个例子，查询“近3天各个省份的销量和销售额”，这里有两个指标（销量、销售额）和一个维度（省份）。销量必须拥有省份维度，销售额也必须拥有省份维度，否则行不通。同时这两个指标还应能按天存储。再复杂一点，“近3个月净值增长率”，遇到这类问题，不是交给大模型去写SQL，而是把整体当作一个指标，取名为“派生指标”。它由“单位净值”这个“原子指标”派生而来（这一派生过程已经由底层查询引擎完成并做了大量优化，既然如此，何必再让大模型重复劳动）。此外还有一类称为“衍生指标”，比如“人均消费金额”，由“总销售额”和“客户数”相除得到，这个过程同样不需要大模型介入。

干活

以上内容不需要全部理解，理解一半即可。所以，不必让大模型从原始海量数据表开始，像ETL工程师一样写几百行代码——稍有差池就前功尽弃。核心工作是做翻译，更合理的说法是NL2DSL（Natural Language to Domain-Specific Language），或者叫NL2X，即让大模型将文本翻译成希望得到的结构化表达式，可能是JSON，可能是XML。从DSL到SQL的过程，凝结了许多数据工程师的汗水，包含了大量优化步骤。未来或许可以让大模型辅助优化，但那放到第二阶段再考虑即可，目前先把手头能用的工具用起来。这个DSL具体长什么样？不能全部列出，大致包含指标、维度、过滤条件等几大元素，细节字段较多。你可能会问：只让大模型将文本翻译成DSL就不会出错吗？会，但足够标准化的字段能让这一过程可控。可以通过提示工程、模型微调等多种手段干预，而且可以输出清晰的“业务语言”（大模型的思考过程），即使出错，也能让人一眼看出问题所在。

具体流程

下面整体介绍流程，断断续续地做，累计耗时约三天：

• 第一步：获取元数据。
  即上述提到的“含业务知识的数据结构”，它是地图。

• 第二步：召回。
  做过搜索的都知道，这张地图太大，不能全部塞进大模型，必须做删减。召回的目的，与其说是保留相关度高的，不如说是尽可能去掉不相关的（细品）。方法很多，包括RAG领域大火的向量召回，但为了快速实现DEMO，使用关键词召回效果也不错。当然，除非你一定要查询“全部的线上渠道”，而无法将“京东”“淘宝”“拼多多”一网打尽，这种场景除外。

• 第三步：大模型思考。
  为什么不做排序？或许大模型时代的范式已经变了。后面会再分享关于压缩、长上下文相关的探索。这里直接丢给大模型做思考。因为使用的是ChatGPT，进行了大量提示工程开发。这个过程很磨人，需要耐心和文字敏感度。另外明显感受到的一点：以前我们说大模型和人类在双向奔赴，这次确实体会到了。早些时候，为了让大模型生成的JSON格式更规范，要在提示里加一句“生成的JSON需要被Python的json.loads所解析”，现在可能不需要了——加上之后它反而会在末尾输出一段用Python写的json.loads代码，手把手教你解析。未来大模型会进化到什么程度？语言的水下冰山会被机器读懂多少……

• 第四步：查数。
  查数前还要把大模型返回的结果解析一下。不是直接让大模型翻译成最终的DSL，而是结合大模型的能力降低DSL的难度，将弱化版的DSL手工对齐到终极DSL，然后再做查询。

• 第五步：呈现。
  没什么太多说的。开头提到的Streamlit实现了全栈工程师的梦想，想要什么图就能画什么图。具体效果看结尾视频演示。

下一步

距离真正落地还有很长的路要走，可梳理出几个方向：

• 目前DEMO实现的能力还比较简单，涉及派生/衍生指标、复杂约束条件、同比/环比等还需要进一步完善。
• 回归客户，回归真实场景，

  Go to Market
  ——自助取数是否是真命题？
• 取数只是第一步，分析才是数据里的宝矿。如何做好分析？之前做的“小模型”就需要登场了：指标趋势预测、异常预警、因果推断……大模型+小模型+Agent，将是一部鸿篇巨著。
• 领域模型微调是必须要做的，私有化部署是必选题，但又是耗费人力、财力的事情。待后续在行业大会上交流学习，站在巨人肩膀上，再来总结分享。