超大型央企的万人AI问数实践

导读：

从传统BI到AI问数，数据分析的门槛正在被自然语言交互彻底拉低。面对真实世界中海量的数据表和复杂的业务口径，单纯依赖大模型的生成能力往往会导致幻觉频发。我们该如何在成本、速度与准确性之间找到平衡？

本文不仅指出了企业建设AI问数的三大常见误区，更分享了一套经过验证的 AI问数解决方案，并分享超大型央企是如何构建AI问数的全过程，将AI问数从简单的对话工具升级为可复用的业务底座，为大家带来一些参考。

分享嘉宾：

普元信息高级副总裁王克强、普元信息智能大数据研究院院长李书超

01 AI问数困境与解法

从20年前做数仓、数据分析、BI到现在，企业数据分析的问题一直存在，很难根治。

首先是技术和业务的协同断层。

技术人员不懂业务流程、指标定义和决策场景，业务人员又没有技术能力。业务把需求传达给技术时，双方往往说不清楚。

比如业务人员说“把这一条数据和下面那条数据加到一起”，这对做报表和BI来说很头疼，因为需要的是规则逻辑，而不是随意指定几条数据求和。

其次是数据分析效率低。

大型数仓和分析项目，年底立项、年初招标，团队入场调研、收集需求、设计建设、测试交付，等到验收时，业务人员会说“你做得对，但我当时提的需求已经变了”。这种IT项目模式难以满足很多快速迭代的想法和高时效性需求。

还有数据基础差、系统孤岛严重、数据质量差、工具和管理不足、门槛高等问题。

现在大家开始寻求突破，我认为企业数据分析的发展趋势分几个阶段：传统分析、自助分析，以及现在萌芽的AI问数。

传统分析由IT人员开发报表，周期长、成本高，只面向中高层管理者。

自助分析在传统BI基础上做了升级，把数据集定义做成可拖拽、中文化的方式，但本质上没有脱离BI建模、做看板和报表的过程，效率提升有限。

我们认为当下和未来的方向是AI生成式数据分析。

通过对话式提交问题，AI获取数据、生成报表、多维分析、深度分析，交付周期快，学习成本低。打字或语音输入即可，可以覆盖所有人，只要并发够，可以让每个人都来问，量级可达数万甚至十万级。

因此，AI问数对企业分析能力的提升有这样的定位：一问即得，降低数据分析门槛，以自然语言赋能业务人员自主开展指标和数据集的分析探索，让数据人人可用。

通过AI赋能的深度洞察，将数据智能转化为降本增效、精准决策的竞争力。通过零门槛对话、智能数据工程、指标SQL生成、智能辅助分析和决策建议，以及交互式探索，让用户通过一轮轮对话，逐步得到过程和结果。

所以，我们认为AI问数对企业分析能力的提升是模式的转变，和全面的能力提升，而不只是从传统BI到自助化的细微改进。

02 企业建设AI问数的三大误区

第一个误区：迷信大模型的Text-to-SQL能力可直接用于生产。

像Spider、BIRD这类公开基准测试，很多企业都在跑，几十张表、二三十行SQL的简单查询，准确率能达到80%以上，去年最高到了91.2%，但真实世界不是这样的。

MIT的教授迈克尔·斯通布雷克是图灵奖获得者，也是目前唯一数据库方向的图灵奖得主，去年发了一篇报告，他们用1400张表、口径有问题的情况下生成100多行查询，准确率只有10%。附加一些条件后也只提升到35%。

在这种规模下，SQL生成的稳定性存在很大问题，而且即使80%多的准确率也不能用，因为很多大型客户对问数的要求至少是90%、95%甚至更高。

核心症结不是模型不够强，而是它读不懂、理不清、辩不明，存在语域鸿沟，很多业务术语在数据库里没有对应字段。

对于业务的专有名词，大模型难以理解。还有口径冲突，同一个指标多套算法，打哪一版都像错。比如制造业的"产量"、"利用率"这些指标，定义非常多。

数据量过载也是个问题，上千张表、几万个字段，让大模型找到所需字段，准确率差距很大。

所以我们认为最合理的解决方案是先构建指标层，统一业务语义定义，建立指标和字段的映射，基于指标层问数来消除幻觉，这样才能达到95%甚至99%以上的准确率。

第二个误区：私有化模型的参数越大越好。

很多人觉得把所有问题交给大模型就行了，但大参数模型意图识别和复杂推理确实强，幻觉问题也很大。

参数量提升的同时，幻觉也会提升，而能力增益赶不上成本增长，显卡、设备、内存都很贵。

AI幻觉是不可能完全避免的。

今年4月19日，环球网和央视中文国际援引CNN报道的美军用AI做情报分析，发现一艘中国船只疑似有核零件，战机已经升空准备拦截，按下打击按钮前做了一次核验，结果发现是AI错误提示，连美军经过深度训练的大参数模型都存在幻觉。

所以私有化模型不是参数越大越好，小参数模型反而效果更好。

AI问数是非常垂直的专业工具，不是用来聊天或解答百科知识的。我们实测下来，27B到35B之间的模型问数准确度更高、幻觉更小。当然它的问题是意图识别弱于大参数模型，这可以通过语义层定义来解决。

第三个误区：用公网大模型就一劳永逸了。

除了幻觉问题外，还有费用、成本、时间和风险问题。中等规模企业的token费用在增加，未来可能还会有限额限制。

GPT-6发布后大家都在说"工作10分钟，休息5小时"，大量时间用在等token刷新。

还有时间成本和隐性投入，公网大模型每轮对话重复发送完整历史，浪费token，此外数据泄露和合规红线也是风险。

正确的解法是：敏感数据和核心业务在私有化小模型上做数据不出域的问数；公网大模型用于复杂推理，帮我们生成分析原理，但数据不给它。可以导出成Markdown再导入私有化问数平台作为分析Skill，实现复杂推理而数据不出域。高频简单查询则通过规则引擎和轻量化引擎处理。对于大型企业，多种场景要做复杂路由。

03 构建全员适用的企业AI问数应用

企业问数是面向全员的产品，每个人的侧重点不同。

高层管理者关注关键指标、异常波动、风险预判。

中层管理者关注经营概览、异常预警、根因分析和问题下钻。

一线执行层希望更快取到数据，比如门店店长看昨天经营情况、实时库存，以及探索式分析和经验指引。

专业分析师做深度分析方案、关联分析、知识沉淀，希望用大模型固化分析成果。

IT和数据人员关注指标定义、SQL生成、口径统一和数据链路。

每个角色对问数都有需求，所以我们提炼出三大关注点：

第一是速度。即问即答，问得快才有人用，秒级响应，多轮对话方式可以接受。

第二是准确。通过语义层定义实现准确，答得对才愿意用，消除歧义。

第三是深度。具备深度分析能力，比如生成月度报告、季度汇总分析，时间长一些没关系。

针对不同场景，我们构建了若干能力：精准取数、自然语言问答、多轮洞察、维度切换钻取、指标溯源分析、根因预测、异常发现、分析Skill固化分析逻辑、分析报告生成、指标标准化、知识库、数据权限、开发效率提升等。

Text-to-SQL虽然不稳定，但也有场景，更多是面向技术人员，可以通过它解决第一轮SQL生成，后续调优由人来完成，节省时间提升效率。

每种能力面向不同人员，会有两个核心亮点：

第一，经验即资产。任何人做分析不只是为了得到结果，还可以把经验沉淀下来。分析方案、指标组合、分析步骤、报告都可以定义为分析Skill。

这个Skill可以通过问数产品解析，个人技能可发布为公共分析技能，实现全企业复用。拿到技能的人可以安装使用，也可以修改，形成沉淀、发布、复用的闭环。

第二，快速模式和专家模式。快速模式秒级返回，适用于日常取数等高频轻量场景。专家模式做多步推理，输出深度分析结论，支撑经营分析、归因等复杂场景。

功能架构上分为底层基座、能力支撑和核心引擎三层。

底层基座包含数据集成能力，数据没算好可以帮你算，已经算好的可以直接用。数据分析模块支持多维分析模型和维度切换，有一套完整的多维体系。同时支撑大模型基座，与主流开源和闭源模型都有对接，采用MCP标准协议。

能力支撑层包括问数项目管理、标签、数据开发、权限、知识库等。

核心引擎能做背景调查，问数时可以联想之前的问题，理解前后关联，还包含计划编排、步骤执行、信息融合、结果评审等基础能力，支撑精准取数和深度分析。

AI问数模式的快速模式和专家模式，核心是让用户自主选择，想要速度就选快速模式，想要深度分析就选专家模式。

两者的最大区别在于综合分析环节。每种模式都会经历：提出问题、读取画像、拆解任务、汇集知识资料。综合分析时会确认分析口径、制定方案。

专家模式的核心特点是多步执行。多步执行必然带来多轮迭代，Agent自行与大模型交互，发现第一轮召回匹配度不高时，会做第二轮、第三轮优化。这个过程包括多步执行、真实数据查询整合、匹配度判断，最终形成结果输出、保存并沉淀为长期记忆。这需要时间，但结果更精准。

快速模式则是一次性直接锁定目标，只做一轮。它也能出深度报告，但匹配度不如专家模式高。由于是一轮锁定、一轮返回，效率非常高，适合快速问答。对于指标层面的查询，一轮就能精准锁定并返回结果。

04 超大型央企AI问数案例分享

客户已在CRM客户经营管理体系中全面推广AI问数，API方式已接入大量现有业务，但仍存在许多查询类场景，希望进一步产出报告型成果。因此，我们在客户管理、寄递/投递、报刊等领域开展了大量深入的业务场景实践。

4.1 项目背景

客户在数据领域从早期建设至今已近十年，积累了海量报表，也具备灵活的钻取和探索能力。然而，当业务真正需要更高效、更精准地解决问题时，挑战依然显著。

业务人员常提出“能否将数据导出，由我在Excel中进行定向加工”的需求，现有工具尚无法充分满足灵活数据处理的需要。

如何打通技术与业务之间的壁垒，成为我们早期客户最迫切的需求。

4.2 AI问数路径

AI问数核心难题在于，机器难以理解人类语言，不同部门的口径难以统一。

以“逾期率”为例：运营部门关注快递特快口径，强调按时送达；而全口径需覆盖所有业务领域。出数规则差异巨大，但业务人员提问时只有一句“我就想问逾期率”。

我们的核心思路是将自然语言转化为精准的执行与计算。

起初的实践中，我们尝试从传统指标平台中精准提取规则，但无法达到100%准确率。最终，我们找到了基于指标业务化语义定义的解决方案，只要实现准确的指标召回，就能做到百分百精准输出。

该方法论是将大量抽象问题拆解为若干细分单元，每个单元通过更小的模型实现快速精准执行。

而单点准确远远不够，高价值分析需要融合多领域、多维度的数据。

我们实现了跨域数据的精准召回与多指标召回，通过内存加工计算进行深度分析。例如运营舆情分析，涉及干线运营、调拨中心、客服和快递员等多个维度，通过多指标融合实现跨域根因分析，这是AI问数中真正重要的突破。

4.3 客户能力建设

高价值分析必然涉及多领域、多维度的数据融合。传统模式下，数据部门需与各业务部门逐一沟通后再加工融合，我们的做法是通过精准召回、多指标召回，配合内存加工计算，实现深度分析，使传统上耗时漫长的场景得以通过AI指导完成融合。

在此基础上，业务产生了大量跨领域报告需求。

我们设计了独特机制，让AI既扮演超级专家辅导深度分析，又扮演精算师确保数据准确，形成高价值报告体系。

在大规模跨业务应用中，不同领域会形成大量知识技能的积累，我们在可控权限基础上向整个组织开放复用，实现专业知识不再局限于个人。

4.4 海量保障机制

我们曾遇到一个启发性场景：大模型需调取逾期量指标却未执行，并回应“对不起，我没有调，下次会记住”。

这让我们意识到工程化设计必须引入防护机制，我们采用小模型方案，加入大量门禁和校验机制，反复核实数据来源，虽然增加了调用损耗，但换来了数据精准。

在上下文工程方面，我们采用持续压缩上下文的方式，确保缓存命中率，提升响应效率。在性能受限时，我们引入内存计算能力，大量分析场景不交由AI处理，而在缓存内存中叠加计算逻辑。

根据实践经验，一台常规推理服务器约可支撑100至200名在线用户（非高频使用）。

此外，我们推出极速版，将大模型调用转化为高性能API场景，实现高性能并发，适配极致性能场景。

最终形成完整链路，将传统API调用整合至客户管理体系，通过反复追问形成报告，再转化为可自动触发的行为，与业务人员APP直接对接，使AI问数从对话工具升级为可用的业务底座。

所以AI问数必须具备良好的数据治理基础、有效的数据融合能力，以及快速反馈机制。

05 总结

单点分析容易做深做透，但成本极为高昂，我们反复思考：在具备基础能力的前提下，智能体能否真正释放数据与AI的潜能？

过去几年实践表明，单点场景开发快、效果好，但面对通用场景，对智能体的智能化水平和开发难度都提出了极高要求。

如果未来业务能以自然语言表达方式进行建模，并将业务规则执行关系建立起来，就能真正打通实体业务规则与技术事件之间的壁垒，由AI辅助完成全过程。

AI不会替代人类执行，它的价值在于建立语义推理和行为定义，最终交由计算层执行，这是下一轮以本体建模为基础的智能体建设中极具意义的方向。

企业的标准和规范不能仅停留在文档层面，智能体需要配备复合检查与门禁机制，业务层面需实现数据指标上下游与横向融合，才能真正提升探索式分析的质量。

06 QA问答环节

爱分析：问数和本体有什么关系？

王克强：可以从两个层面来理解这个问题。

第一，本体是什么？​本体是一套复杂的建模方法论，不要求数据有多规整，而是通过属性、关系、规则、推理等多层体系来实现数据关联。但它的问题在于太复杂了，绝大部分企业很难完整落地，Palantir的平台成本高且体系复杂，国内也没有更轻量的替代方案。所以本体更多是指明方向，而不是要建一个完整的平台。

第二，问数和本体怎么衔接？​我们的做法是在指标定义上延展。指标本身就是一种轻量级的建模，它把真实的业务需求转换成技术可执行行为，相当于在本体和执行之间搭了一座桥。我们会在指标之上告诉AI按照某种条线去推理，而不是去建完整的本体模型。

李书超：我们在实践中发现，大量业务规则需要被精准执行，但以前用自然语言表达的需求只能建立弱连接，导致知识和执行是分离的。有了AI之后，这个鸿沟比过去更容易跨越，但要加好门锁，因为AI推理可能出错，所以需要人工审核。

至于具体落地，要找折中的方式，我们也在探索。

爱分析：企业原来买的BI平台和问数是什么关系？BI以后会逐渐被废弃，还是会变成AI问数的底座？

李书超：国内企业用BI，绝大部分其实做的不是真正的BI，而是三类东西：第一类是报表，比如财务报表、经营分析报表；第二类是主题分析，有一定深度，但做完可能用三五年不变；第三类是大屏可视化。

这三类和问数的方向完全不同。

不是说BI本身做不到，而是国内企业很难像国外那样让业务部门去做多维建模、建cube做分析，这在过去二十年几乎推不动。

所以BI未来还会存在，但更多做固化报表、固化主题分析和可视化大屏，这是它所擅长的。问数则定位于面向全员，门槛很低，谁都可以用。

王克强：问数本质上是一个所问即得的工具，解决的是随意、个性化、即时触发的分析需求。所以两者各有侧重：BI解决固化问题，问数解决灵活问题，它们会长期共存。

更深一层的问题是：在做BI的过程中，我们是否真的把数据梳理好、管理好了？

AI时代，如果你的数据本身就有问题，无论AI还是BI，价值都很有限，BI建设本身推动了数据治理，而AI会进一步强化这个动作。所以AI和BI应该在治理体系下真正融合，一起往前推进，这是一个值得探索的方向。

爱分析：企业希望私有化部署问数、不接公网，因此考虑27B稠密或35B MOE这类小模型，从实际落地看，企业在选型上是两个都布、分场景用，还是有明显倾向？

王克强：模型选择现在变化很快，但我们的落地经验很直接：问数类深度分析优先用稠密模型。我们以千问3.6的27B为主，也对比过DeepSeek V4的Flash版，27B在回答质量、规则理解和执行准确性上明显更好；千问的3.8刚出，偶尔会出现绕进去出不来的情况，所以当前不太作为主力。

若场景没有特别复杂、特别多形态的诉求，优选27B。35B的MOE架构速度优势很大，但更适合要求不高、追求极速响应的轻量场景；这类场景在问数里占比不多。

因此私有化问数我们建议以27B稠密为主，35B MOE仅在有低时延、浅分析需求时作为补充，不必双模型全量并行。

爱分析：做垂域问数时，数据质量或结果容易出现结构性问题，需要业务专家和算法调优人员协调。从内部组织协作角度，如何进行业务专家、算法和IT专家之间的协作？

王克强：在邮政场景中，我们首先面对的是IT部门，他们内部也承接了业务专家的角色，技术口的人希望快速拿到结果。

我们的做法是先把精准的行为和目标跟大家达成共识，在管理协作上，核心还是业务价值驱动。大型机构里专业业务分析师比较多，如果他们能快速获得感知，再和技术口对接，就容易形成协作闭环。

先用效果驱动，拿了AI先看效果，有了效果，大家的兴趣和力量自然就聚拢过来了，不能事事靠一把手工程。

李书超：我认为有两点建议：

第一，找好驱动力。想清楚这个事为谁做、谁关注，用的人和关注的人自然会替你站台、替你推动，要学会借力。

第二，找好厂商。普元不只是做方案，还会帮客户选设备、分析问题。在国产化背景下，如何把软硬件结合做出有价值、高效率的方案，确实不容易。找一个有经验的团队，帮你诊断软件、硬件和推动上的问题，共同解决，也是一个重要的支撑点。