我要投稿

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

发布日期：2025-06-16 06:14:47 浏览次数： 1752

作者：瀚海方舟

微信搜一搜，关注“瀚海方舟”

“世界以痛吻我，我却报之以歌” ‍
泰戈尔

大模型之痛

从最开始，大模型的回复捉摸不定，到后来的高准确率，这一过程好像在驯服一匹野马，也是自我成长的撕裂感和成就感。

每一次痛苦的吻，都是一段美的音符，它们并非摧毁，而是启发了我们内心深处的歌声。

正题

本来想先从RAG、Agent这些方向开始梳理思路，但最近很多客户在关注基于大模型的BI自助查数分析，所以上手突击了一下，感悟颇多，想直接看成品的话可以滑到最后，我录了一段演示。

这个DEMO原计划两天做完，但Prompt的极限拉扯，加上我既不擅长前端页面搭建又对视觉效果颇为在意，所以耽误了许久。（第一次正式用streamlit这个工具，非常推荐，走向全栈工程师的一个里程碑）

先抛出两个最近一直在思考的问题：

大模型的幻觉问题在数据科学领域容易造成差之毫厘谬以千里的状况，如何解决，这是很多客户甚至是投资人提出的；
基于大模型的数据查询功能到底是给谁用的，他们以前的查数习惯是啥，这是我自己在想的；

这篇记录会主要围绕这两个问题。

故事开始了。

迷茫

NL2Sql（Natural Language/Text-to-SQL）是个“古老”的话题，大模型出来之前就一直在研究和发展了，技术男第一个想到的就是打开Spider榜单（https://yale-lily.github.io/spider），看看各路大神是如何刷分的，Alibaba Group熟悉的名字映入眼帘。

不同规模的企业有多少张表呢？企业里是什么角色在查数呢？企业在查数时Query的类型都是哪些呢？

这些问题，也许是Spider回答不了的。

聊天

前两天无意了解到一位旧友就在做类似的事情，并且要在11月下旬的AiDD软件研发数字峰会上做ChatBI的技术分享，核心是关于Nl2Sql领域模型训练的，简单的聊天过程中，有一句话点醒了我，“这不是一个算法，而是产品”。

从技术角度，单看大模型自身，“幻觉”是它的天性，没有幻觉就没有“创造性”，这是一把双刃剑，而在垂直领域内，需要人类对齐来训练它，这就回到上面的Spider问题上了。从业务角度或者产品角度，好像还没有很好的实践案例供参考。

灵感

以前一直把精力放在营销域的智能化上，对公司的指标平台产品了解的很浅，一直觉得这是一个很复杂、很规则化、很枯燥的东西，这几天初步领会了它的内涵之后（我可能只领会了不到一半），灵光一现，它正好填补了业务KnowHow甚至是技术KnowHow啊！

第一：以终为始，以业务为导向。查数需求是业务方提出的，查哪些指标、哪些维度、哪些过滤条件，这些都会有“标准”，这些标准是现成的，我可爱的同事们已经默默地总结出来了，这个尤为重要；
第二：流程分层，而不是端到端。以前我的认知是从海量数据表中查Sql，但是只要在中间加一层包含业务知识的数据结构，一切都豁然开朗了。

这个“含业务知识的数据结构”是什么呢，我举个例子，比如我想查“近3天各个省份的销量和销售额”，这里有2个指标数据“销量”、“销售额”，还有1个维度叫“省份”，他们的关系是，“销量”必须要拥有“省份”这个维度，“销售额”也必须要拥有“省份”这个维度，否则行不通。同时，这俩指标还应该能按天存储。

复杂一点的，“近3个月净值增长率”，遇到这种问题，我们不是交给大模型去写sql，而是把整体当成1个指标，取名“派生指标”，它是由“单位净值”这个“原子指标”派生而来的（这个派生的过程，我们已经交给底层的查询引擎了，并做了大量的优化，既然已经做了，为什么还要让大模型来做呢）。另外还有一类称为“衍生指标”，比如，“人均消费金额”，它是由“总销售额”和“客户数”这俩指标相除得到的，这个过程同样不需要大模型来做。

干活

以上不用全部理解，像我一样理解一半就可以了。

所以，我们并不需要大模型太苦太累，从原始的海量数据表开始，像ETL工程师一样写几百行的代码，稍有差池，额。

我们只是做翻译，我觉得用NL2DSL比较合理，或者叫NL2X，也就是让大模型将“文本”翻译成我们希望得到的一段结构化表达式，可能是json，可能是xml。再往后，由DSL到sql的过程，凝结了很多数据工程师的汗水，因为里边包含了大量的优化过程，也许以后可以由大模型来辅助优化，可以放到第二阶段再考虑吧，目前把能用工具先用上。

具体这个DSL长什么样子，我不能全部列出来，大致是包含了指标、维度、过滤条件等这几大元素，细节字段很多。这时也许你有疑问，只让大模型将文本翻译成DSL就不会出错了吗，会，但足够标准化的字段能够让这一过程可控，我们有很多手段来干预它，无论是提示工程，还是模型微调，另外，我们可以输出很清晰的“业务语言”（大模型思考过程），即使出错了，也能让人一下就知道是哪里出的错。

具体流程

下面还是整体介绍一下流程，断断续续地做，前后大概花了三天时间：

第一步：获取元数据。也就是上面提到的“含业务知识的数据结构”，它是我们的地图。
第二步：召回。做过搜索的都知道，这张地图太大了，一定不能全部塞进大模型，要做删减，所以召回的目的，与其说是保留相关度高的，我更喜欢说是尽可能去掉不相关的（细品）。方法有很多，包括最近RAG领域大火的向量召回，但是为了快速实现DEMO，我用关键词召回发现效果也很好。当然，除了你一定要查询“全部的线上渠道”，而我却没办法实现把“京东”、“淘宝”、“拼多多”一网打尽。
第三步：大模型思考。为什么不做排序呢，哈哈，也许大模型时代的范式变了，后面再分享一些关于压缩、长上下文相关的探索。这里我们直接丢给大模型做思考，因为使用的是ChatGPT，所以进行了大量的提升工程开发，这个过程很虐，需要点耐心和文字的敏感度。另外感受到的一点，以前我们说大模型和人类在双向奔赴，这次确实感受到了，以前看autoGPT的代码里为了让大模型生成的json格式更规范要加一句“生成的json需要被Python的json.loads所解析”，直呼666，现在可能不需要了，加上之后反而它会在末尾给你输出一段用Python写的json.loads的代码，手把手教你解析。未来大模型会进化到什么程度呢，语言的水下冰山会被机器读懂多少呢……
第四步：查数。查数前其实还要把大模型返回的结果解析一下，因为我们并不是直接让大模型翻译成最终的DSL，而是结合大模型的能力，降低DSL的难度，把弱化版的DSL手工对齐到终极DSL，然后做查询。
第五步：呈现。没有太多说的，只能说开头提到的streamlit实现了我全栈工程师的梦想，让我想怎么画图就怎么画图，具体的就看结尾的视频演示吧。