来源/作者：爱分析

随着大模型带来能力突破，让AI与数据分析相互结合，使分析结果更好支撑业务，促进企业内部数据价值释放，成为了当下企业用户尤为关注的话题。本次分享主要围绕数据分析场景下大模型底座的选型思路，以及当下热点问题解答展开。 

分享嘉宾｜张逸凡 Kyligence 研发副总裁

01 AI 对数据分析带来的变革

1.1 AI技术变革

在AI诞生以后，我们面临的变化主要在于其具备更加卓越的泛化能力。这种能力使我们能够更为准确地理解用户需求，将其转化为具体的指令，乃至进一步完成数据层面的总结和文档的撰写。此外，AI也能够灵活运用工具，例如通过AI Agent来执行一些复杂的任务。

这些都是AI实现持续迭代后带给我们的重大变化，且能明显感觉到这种变化的速度十分迅速。像是GPT4最新版本只需简短的描述就能创建一个新的Agent，如此一来，许多用户甚至可以在没有任何专业知识的情况下，创新性地开发自己的应用。

1.2 大模型+数据分析产品能力介绍

在大模型与数据分析结合的方面，目前我们已实现以下能力。

这里所呈现的是从指标的搜索到指标的展示，再到分析过程的对话式理解，最终我们能够借助对话沉淀出一个仪表盘，实际上这是将分析过程进行聚合的一种方式，其中的优点在于它能够降低我们自定义BI能力的成本，并引导用户去思考，带着数据分析的思路前行。

同时我们还提供了一些关键指标的分析，这个功能在我们公司内部使用得非常广泛。我们将很多管理的目标进行数字化，然后通过目标指标的方式进行展现、计算和归纳，最后每周都会在各个部门生成报表。

从数据化管理的角度来看，AI 确实帮我们完成了大量的信息收集，包括它能够很好地处理一些较为复杂的指标，提取其中重要的信息，然后进行总结，并给出一些建议。当然这里面的一些建议可能是基于它本身的一些通用性的判断，并不一定比我们更了解业务，但它强大的归纳能力确实能帮助我们更好地聚焦在数据的一些特征点上。除此之外，还有一些归因分析的能力。实际上归因分析有两种情况，一种是基于数据的，类似于贡献度分析，我们当前所采用的就是这种类型。另外一种是基于指标之间的相关性。

这部分实际运用的是平台自身的能力，而非大模型。平台能将这些数据进行内部的分析，因为我们采用的是让用户使用工具的方式，但整个使用的过程是通过平台能力迭代完成的，这样也就降低了大数据的使用门槛。同时，我们也提供了一些集成能力，能够与第三方的一些资源，例如数据分析系统进行联动，以及下游也可以进行聊天功能的打通。

02 大模型底座的选型思路

2.1 大模型评测的标准和目的

接下来讲讲，我们如何在数据分析场景下，挑选企业内部真正适合的大模型。

事实上，当前的大模型数量依然在呈现上涨趋势，Hugging Face大模型社区已有超过2.9万种模型。目前国内开源的及可能存在的商业化的大模型日趋繁多，因此我们面临的挑战在于如何正确选择最优模型。然而，在我们实际使用这些模型时，往往会感到茫然无措，当前可以非常明确的一点是：GPT是当下综合各方面来看最好的选择。

但是，在一些私有化解决方案中，我们应怎样选择合适的大模型来作为我们新的基座呢？实际上，我们对大模型的功能需求主要集中在以下几个方面：

第一，具有理解准确性。大模型必须能够精准地理解语义信息，不能将用户的意图解读为完全不同的意思；

第二，具有结果可读性。同时，大模型还必须能够理解结果，具有数据敏感性，能够解释和借助用户的问题和信息知识进行行业的深度理解；

第三，基于洞察拓展性。大模型需要能够协助用户发现未知的问题，并引导用户探索更多前沿的研究方向。

2.2 评测结论

在测试方法方面，我们采用了统一的数据集进行评估，评估的“裁判”是目前业界公认性能最好的GPT4。我们使用的数据集是今年7月份的，其中也包括在线上收集的大量用户的使用情况，然后经过脱敏和清洗处理，最终形成了标准的测试数据集。我们对测试过程的各个环节进行了评分，最后给出结果以供大家参考。

我们评估了包括GPT4在内的许多国内主要投入使用的大模型，可能会有所遗漏，但大多数常用大模型都涵盖在其中。

目前的评估结果显示，GPT4的表现最优，这个结论无疑是无可争议的，其次是GPT3.5。同时我们还可以看到一些国内一线的大模型厂商，尽管他们在数据洞察和输出方面表现得相当优秀，但在计算方面可能会略微不足，可能是由于他们的训练逻辑还需要更加优化。此外，一些开源的大模型也有着不错的分数。

总体而言，参数越高，大模型的表现就很可能越优秀。当然，一些模型虽然参数较小，但可能是由于它所利用的训练语料是适用于相应分析场景的，因而分数也会有很大差异。

2.3 评测维度

接着，我们进行了多个方面的尝试以希望提升评分，事实上，这样的微调确实可以显著将评分提高。正是在这样的基础之上，我们也挑选出了具有较高潜在价值的模型，并经过调整后获得了较好的测评效果。

我们在此次测试中涉及到的维度有7个，包括报告撰写、洞察生成、推表推荐、意图识别、指标匹配、代码生成SQL和代码生成指标。

测试的模型中，国内的主要有智谱AI、MiniMax、百川、通义千问以及文心一言等在内，国外的Falcon和 LlaMA 也被列入了测试名单之中。我们也在不断测试新的模型，并根据垂直类别进行分类测试，例如不同的参数集与SaaS或私有化的对比。

总的来说，我们将这7个维度分为两个部分，数据计算和数据洞察。其中偏向于输出的我们称之为数据洞察，其主要功能在于将数据转化为用户易于理解的结论，同时提供一些更新的输出。

数据计算部分则更多地将用户意图理解为指令，或对该用户意图本身的适当判断。同时，还要选择适当的指标，以帮助用户了解如何使用数据进而得出结论。

从数据计算的角度来看，参数物料实际上直接决定了数据计算的能力，因此它们在专业语料方面的相关性可能较低。从理解的层面上来看，这些参数是非常重要的，但就逻辑推理、标准化代码输出的能力等方面而言，参数确实越大则效果越好，因为其复杂性较高。

从数据洞察的角度来看，我们原以为它会和参数息息相关，但实际的结果还是比较接近的。可以看到，数据洞察的输出和理解更依赖于语料，尤其是在我们这种特定的场景中，或是提供的语料涵盖了大量数据分析相关内容，特别是在测试中倾向于某些方面，例如零售或金融等行业的语料较多时，就能呈现出更好的性能。总的来看，这部分模型效果更与训练语料的质量紧密关联，反而和参数的关系没那么大。

同时，各个渠道可能会导致不同的研究结果，当平台变更导致了场景的差异，也会使最终结论有所不同，以上结果也仅代表在这个特定场景下的数据洞察结论。

事实上我们也在研究行业内的私有化方案，因此进行了许多本土大型模型的测评，同时也与众多厂商进行了深入交流。就目前而言，我们的主要思路是选择一个性价比高、能力优秀的模型，可能还会根据自身语料较为丰富的现状进行深度训练，最终形成一个符合我们场景的比较专业的垂类模型。客观而言，虽然通用大模型具备分析各式各样场景的能力，但可能并非每个方面都能达到优秀表现。

前面提到的数据计算与数据洞察，我们可以通过专项训练独立完成，并将洞察能力以另外一种形式或者采用不同的垂类模型来完成不同的任务。这其中也包括了对于用户的知识库的训练。我们会将这些逻辑进行分解，以便选择所需的不同能力加以运用，以免过度消耗资源。

以上是我们在数据分析场景下，企业大模型的一些选型建议。

03 热点问题解答

接下来针对大模型+数据分析话题下，一些企业和厂商提出的问题进行解答。

Q1：如何保证数据分析结果的准确性，避免大模型的幻觉问题？

A1：这个问题确实确实非常常见，主要是因为大模型确实存在幻觉问题，同时生成的查询结果不一定符合当时业务的场景。面对这类情形，我们有两点应对策略，第一是用户进行自查，第二是让模型介入审查。

具体来说，比如当用户遇到问题时，我们首先会创造指令，然后利用内部的某些机制进行调试，以确定其合法性和结果的有效性。如果出现错误情况，我们会对其进行修正。如果模型生成的结果与事实不符，我们也提供了可供使用者查看的查询要素展现，例如，基于何种条件，哪些维度被使用，以及排序方式和解读结论等等。在此过程中，用户可以进行干预和修改查询的选项，并对结果进行like或dislike的反馈。我们可以利用这些反馈来改善未来回答类似问题的策略，决定是采用类似的上下文回答，还是采取其他方式。

这个过程中确实无法完全保证数据分析结果正确性，但总体而言，这个过程能形成一个有益的闭环，用户可以通过不断的修正、训练来提高回答问题的准确性。随着用户反馈的增多，通过相关机制，模型就能够更好地理解并回答用户的问题。

Q2：如果用到的数据存在于多个表中，那么数据分析在进行多表和跨表时，如何保证识别和最终结果的准确率？

A2：现阶段我们的索引构建主要依赖指标平台，复杂的表关联以及结构表属性的定制化调整等工作，其实是借助指标进行抽象处理。但实际使用中不可避免地存在指标间的跨指标分析，潜在的问题或许来自于数据源。这实际涉及到前期提出来的问题，如何缩小数据范围。

这里的两个核心问题包括，第一，是否选定了正确的数据；第二，是否采用适当的SQL或分析方法关联这些指标，并依托这些关联结果进行高效的分析。此过程实际上回应了如何进行有针对性的审核，本质上并无不同，即我们构建的指标会引导用户进行确认，再进行审核。

由于我们有一套完善的数据权限控制系统，所以会适度考虑与权限相关的因素，以及用户使用该指标的频率，以便我们在进行各类模型的研发、选择以及推荐时，充分考虑这些因素，尽可能地从用户的实际应用场景中挖掘相关性较高的指标。尽管如此，我们仍不能完全保证能够发现所有的相关指标。因此，我们会通过用户可见的信息，引导用户进行确认、修正，以便我们能进一步地学习和提升。

目前普遍认为通过join操作，实现跨表数据的关联工作是很难实现的。当下市场上也有其他解决方案，主要是两类。

第一类方案，要完成多表或跨表操作，大多数情况下会选择借助小模型的帮助，因为这类表格的数据量通常不会过大，而且对速度要求更高。首先定位到数据所在的表，然后再基于单张表进行SQL的生成。

第二类方案，在数据模型的阶段就把多张表拼接成一个新的宽表，在宽表之上再进行相应的查询和生成工作。

Q3：如果企业本身已有私有化部署的大模型，是否还需要依据数据分析场景再部署垂类大模型？以及如何如何训练，能让不同大模型可以达到一致或者接近的效果？

A3：关于私有化部署大模型的主要思路，我们认为并不在于必须进行训练。训练的主要目的在于提高性价比和优化场景分析效果，但经过在众多平台上的测试，发现其中部分平台本身的模型参数较高，本身就可达到不错的效果。

如果有部分用户本身投入较大，他们训练出的模型基础优秀，那么就无需再行训练。但根据目前的用户接触经验来看，在初期很少有用户能够一开始就投入大量资源进行模型建立。如果存在这种情况，我们其实可以选择直接接入垂类大模型。

另一种思路是针对之前没有评估或接触过的模型，我们仍需要预先使用测试框架进行检验，这样的好处是避免过于盲目自信。最好在前期进行判断，发现如果有些能力欠缺，可以通过产品迭代、专项训练或者是引入企业自身模型的方式进行改善。

以上这些都是可选的解决方案，关键在于我们必须首先了解私有化大模型与产品本身是否兼容，然后再做进一步的判断。

Q4：向量知识库在数据分析场景有什么比较重要的用途吗？

A4：向量知识库在处理用户输入输出时，实际上都可视为一个参考信息，辅助AI来理解并输出适合业务知识的文本，这是最基础的应用场景之一。此外，向量知识库也可用于公司内部的流程分析沉淀，作为内部提示词演化的重要环节，这其中包括可能一些分析流程的一体化召回。在实际应用中，前者的份量会更为突出，因为一些公司工作重心主要集中在业务领域和场景业务上。

曾经有一个问题，如何让模型理解某些特别专业的词汇，其实知识库是一个不错的解决方法，即使模型在训练过程中可能并未接触到某类信息，但AI却可以通过知识库获得相应的答案。

Q5：大模型在归因分析方面有比较好的案例吗？例如借助大模型把知识库、外部因素（如天气、节日和政策）等融入到归因分析中。

A5：这个方面我们也曾考量过，假如近期出现波动或数据异常，究竟是由外部因素还是内部因素所引发。实际上，这可能需要综合考察外部数据，无论是舆论信息还是其他相关数据，都属于我们所定义的外部知识库。然而，其准确性取决于我们的分析策略，因为AI或许并不知晓这些因素之间的底层关联性。除非我们在数据中告知AI这些因素是具有相关性。

举个例子，如果我们只是说近期收入有所下滑，但却未告知最近天气转冷或附近道路正在施工等情况，AI便难以把握各种数据因素在其中的比重。因此，它需要我们提供一些分析策略，或者将所有数据都告知它，但它并不能明确揭示最为关键的因素，因为这确实需要人为的专业知识或是经验。

值得注意的是，目前GPT4只更新到了2023年4月的数据，所以对于最新数据的覆盖并不全面。因此，如何整合外部数据组件便显得尤为重要。否则，该大模型提供的结果可能存在较高的不可信度，对于时效性强的信息仍需进一步加强数据收集和分析。

Q6：哪些知识必须要微调到模型，哪些知识是通过Prompt提示词来去做传递的？

A6：我认为只要长度足够，其实Prompt能做的所有的事情都不一定要微调。微调的优势在于它能将一些固定的、常用的功能预先进行训练，例如一些常用的分析思路，以及生成的代码模式，其实都可以通过微调得到强化。不过，更重要的是通过结合当前用户的行为和一些可能的业务逻辑，进行灵活的调整来指导。当然，有些方法是值得推荐的，例如以前的Zero-Shot实际上是在告诉AI该如何回答。这个方案主要强调灵活性，可以通过提示词实现。然而有时候，由于在线服务的特性，微调可能会带来较高的成本。在此情况下，也可以选择只使用提示词而不必微调。

我认为，微调与提示词在某些方面的效果有各自的优劣，但提示词语可能更加侧重灵活性。此外，从实际案例来看，如果是一个规模较小的模型，如只有几十亿个到百亿级参数规模，有时候微调后反而可能会产生负面影响，会出现被称之为灾难性遗忘的现象；或者由于进行了微调，导致它失去了一些原本的能力。因此，我们有时会认为对于这类规模较小的模型，在企业或团队的AI技术或相关能力没有强大到可以驾驭时，甚至是不建议进行微调的。

总的来看，建议是优先考虑使用Prompt提示词的方案来解决问题，因为微调存在许多不确定性的风险。