。

本次分享主要围绕数据分析场景下大模型底座的选型思路#…来源/作者爱分析

随着大模型带来能力突破让AI与数据分析相互结合使分析结果更好支撑业务促进企业内部数据价值释放成为了当下企业用户尤为关注的话题。

本次分享主要围绕数据分析场景下大模型底座的选型思路以及当下热点问题解答展开。

分享嘉宾张逸凡

在AI诞生以后我们面临的变化主要在于其具备更加卓越的泛化能力。

这种能力使我们能够更为准确地理解用户需求将其转化为具体的指令乃至进一步完成数据层面的总结和文档的撰写。

此外AI也能够灵活运用工具例如通过AI

这些都是AI实现持续迭代后带给我们的重大变化且能明显感觉到这种变化的速度十分迅速。

像是GPT4最新版本只需简短的描述就能创建一个新的Agent如此一来许多用户甚至可以在没有任何专业知识的情况下创新性地开发自己的应用。

1.2

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

同时我们还提供了一些关键指标的分析这个功能在我们公司内部使用得非常广泛。

我们将很多管理的目标进行数字化然后通过目标指标的方式进行展现、计算和归纳最后每周都会在各个部门生成报表。

确实帮我们完成了大量的信息收集包括它能够很好地处理一些较为复杂的指标提取其中重要的信息然后进行总结并给出一些建议。

当然这里面的一些建议可能是基于它本身的一些通用性的判断并不一定比我们更了解业务但它强大的归纳能力确实能帮助我们更好地聚焦在数据的一些特征点上。

除此之外还有一些归因分析的能力。

实际上归因分析有两种情况一种是基于数据的类似于贡献度分析我们当前所采用的就是这种类型。

另外一种是基于指标之间的相关性。

这部分实际运用的是平台自身的能力而非大模型。

平台能将这些数据进行内部的分析因为我们采用的是让用户使用工具的方式但整个使用的过程是通过平台能力迭代完成的这样也就降低了大数据的使用门槛。

同时我们也提供了一些集成能力能够与第三方的一些资源例如数据分析系统进行联动以及下游也可以进行聊天功能的打通。

2.1

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

Face大模型社区已有超过2.9万种模型。

目前国内开源的及可能存在的商业化的大模型日趋繁多因此我们面临的挑战在于如何正确选择最优模型。

然而在我们实际使用这些模型时往往会感到茫然无措当前可以非常明确的一点是GPT是当下综合各方面来看最好的选择。

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

第一具有理解准确性。

大模型必须能够精准地理解语义信息不能将用户的意图解读为完全不同的意思

第二具有结果可读性。

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

第三基于洞察拓展性。

大模型需要能够协助用户发现未知的问题并引导用户探索更多前沿的研究方向。

2.2

在测试方法方面我们采用了统一的数据集进行评估评估的“裁判”是目前业界公认性能最好的GPT4。

我们使用的数据集是今年7月份的其中也包括在线上收集的大量用户的使用情况然后经过脱敏和清洗处理最终形成了标准的测试数据集。

我们对测试过程的各个环节进行了评分最后给出结果以供大家参考。

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

目前的评估结果显示GPT4的表现最优这个结论无疑是无可争议的其次是GPT3.5。

同时我们还可以看到一些国内一线的大模型厂商尽管他们在数据洞察和输出方面表现得相当优秀但在计算方面可能会略微不足可能是由于他们的训练逻辑还需要更加优化。

此外一些开源的大模型也有着不错的分数。

总体而言参数越高大模型的表现就很可能越优秀。

当然一些模型虽然参数较小但可能是由于它所利用的训练语料是适用于相应分析场景的因而分数也会有很大差异。

2.3

接着我们进行了多个方面的尝试以希望提升评分事实上这样的微调确实可以显著将评分提高。

正是在这样的基础之上我们也挑选出了具有较高潜在价值的模型并经过调整后获得了较好的测评效果。

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

测试的模型中国内的主要有智谱AI、MiniMax、百川、通义千问以及文心一言等在内国外的Falcon和

LlaMA

也被列入了测试名单之中。

我们也在不断测试新的模型并根据垂直类别进行分类测试例如不同的参数集与SaaS或私有化的对比。

总的来说我们将这7个维度分为两个部分数据计算和数据洞察。

其中偏向于输出的我们称之为数据洞察其主要功能在于将数据转化为用户易于理解的结论同时提供一些更新的输出。

数据计算部分则更多地将用户意图理解为指令或对该用户意图本身的适当判断。

同时还要选择适当的指标以帮助用户了解如何使用数据进而得出结论。

从数据计算的角度来看参数物料实际上直接决定了数据计算的能力因此它们在专业语料方面的相关性可能较低。

从理解的层面上来看这些参数是非常重要的但就逻辑推理、标准化代码输出的能力等方面而言参数确实越大则效果越好因为其复杂性较高。

从数据洞察的角度来看我们原以为它会和参数息息相关但实际的结果还是比较接近的。

可以看到数据洞察的输出和理解更依赖于语料尤其是在我们这种特定的场景中或是提供的语料涵盖了大量数据分析相关内容特别是在测试中倾向于某些方面例如零售或金融等行业的语料较多时就能呈现出更好的性能。

总的来看这部分模型效果更与训练语料的质量紧密关联反而和参数的关系没那么大。

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

事实上我们也在研究行业内的私有化方案因此进行了许多本土大型模型的测评同时也与众多厂商进行了深入交流。

就目前而言我们的主要思路是选择一个性价比高、能力优秀的模型可能还会根据自身语料较为丰富的现状进行深度训练最终形成一个符合我们场景的比较专业的垂类模型。

客观而言虽然通用大模型具备分析各式各样场景的能力但可能并非每个方面都能达到优秀表现。

前面提到的数据计算与数据洞察我们可以通过专项训练独立完成并将洞察能力以另外一种形式或者采用不同的垂类模型来完成不同的任务。

这其中也包括了对于用户的知识库的训练。

我们会将这些逻辑进行分解以便选择所需的不同能力加以运用以免过度消耗资源。

热点问题解答

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

A1这个问题确实确实非常常见主要是因为大模型确实存在幻觉问题同时生成的查询结果不一定符合当时业务的场景。

面对这类情形我们有两点应对策略第一是用户进行自查第二是让模型介入审查。

具体来说比如当用户遇到问题时我们首先会创造指令然后利用内部的某些机制进行调试以确定其合法性和结果的有效性。

如果出现错误情况我们会对其进行修正。

如果模型生成的结果与事实不符我们也提供了可供使用者查看的查询要素展现例如基于何种条件哪些维度被使用以及排序方式和解读结论等等。

在此过程中用户可以进行干预和修改查询的选项并对结果进行like或dislike的反馈。

我们可以利用这些反馈来改善未来回答类似问题的策略决定是采用类似的上下文回答还是采取其他方式。

这个过程中确实无法完全保证数据分析结果正确性但总体而言这个过程能形成一个有益的闭环用户可以通过不断的修正、训练来提高回答问题的准确性。

随着用户反馈的增多通过相关机制模型就能够更好地理解并回答用户的问题。

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

A2现阶段我们的索引构建主要依赖指标平台复杂的表关联以及结构表属性的定制化调整等工作其实是借助指标进行抽象处理。

但实际使用中不可避免地存在指标间的跨指标分析潜在的问题或许来自于数据源。

这实际涉及到前期提出来的问题如何缩小数据范围。

这里的两个核心问题包括第一是否选定了正确的数据第二是否采用适当的SQL或分析方法关联这些指标并依托这些关联结果进行高效的分析。

此过程实际上回应了如何进行有针对性的审核本质上并无不同即我们构建的指标会引导用户进行确认再进行审核。

由于我们有一套完善的数据权限控制系统所以会适度考虑与权限相关的因素以及用户使用该指标的频率以便我们在进行各类模型的研发、选择以及推荐时充分考虑这些因素尽可能地从用户的实际应用场景中挖掘相关性较高的指标。

尽管如此我们仍不能完全保证能够发现所有的相关指标。

因此我们会通过用户可见的信息引导用户进行确认、修正以便我们能进一步地学习和提升。

目前普遍认为通过join操作实现跨表数据的关联工作是很难实现的。

当下市场上也有其他解决方案主要是两类。

第一类方案要完成多表或跨表操作大多数情况下会选择借助小模型的帮助因为这类表格的数据量通常不会过大而且对速度要求更高。

首先定位到数据所在的表然后再基于单张表进行SQL的生成。

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

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

A3关于私有化部署大模型的主要思路我们认为并不在于必须进行训练。

训练的主要目的在于提高性价比和优化场景分析效果但经过在众多平台上的测试发现其中部分平台本身的模型参数较高本身就可达到不错的效果。

如果有部分用户本身投入较大他们训练出的模型基础优秀那么就无需再行训练。

但根据目前的用户接触经验来看在初期很少有用户能够一开始就投入大量资源进行模型建立。

如果存在这种情况我们其实可以选择直接接入垂类大模型。

另一种思路是针对之前没有评估或接触过的模型我们仍需要预先使用测试框架进行检验这样的好处是避免过于盲目自信。

最好在前期进行判断发现如果有些能力欠缺可以通过产品迭代、专项训练或者是引入企业自身模型的方式进行改善。

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

A4向量知识库在处理用户输入输出时实际上都可视为一个参考信息辅助AI来理解并输出适合业务知识的文本这是最基础的应用场景之一。

此外向量知识库也可用于公司内部的流程分析沉淀作为内部提示词演化的重要环节这其中包括可能一些分析流程的一体化召回。

在实际应用中前者的份量会更为突出因为一些公司工作重心主要集中在业务领域和场景业务上。

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

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

A5这个方面我们也曾考量过假如近期出现波动或数据异常究竟是由外部因素还是内部因素所引发。

实际上这可能需要综合考察外部数据无论是舆论信息还是其他相关数据都属于我们所定义的外部知识库。

然而其准确性取决于我们的分析策略因为AI或许并不知晓这些因素之间的底层关联性。

除非我们在数据中告知AI这些因素是具有相关性。

举个例子如果我们只是说近期收入有所下滑但却未告知最近天气转冷或附近道路正在施工等情况AI便难以把握各种数据因素在其中的比重。

因此它需要我们提供一些分析策略或者将所有数据都告知它但它并不能明确揭示最为关键的因素因为这确实需要人为的专业知识或是经验。

值得注意的是目前GPT4只更新到了2023年4月的数据所以对于最新数据的覆盖并不全面。

因此如何整合外部数据组件便显得尤为重要。

否则该大模型提供的结果可能存在较高的不可信度对于时效性强的信息仍需进一步加强数据收集和分析。

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

A6我认为只要长度足够其实Prompt能做的所有的事情都不一定要微调。

微调的优势在于它能将一些固定的、常用的功能预先进行训练例如一些常用的分析思路以及生成的代码模式其实都可以通过微调得到强化。

不过更重要的是通过结合当前用户的行为和一些可能的业务逻辑进行灵活的调整来指导。

当然有些方法是值得推荐的例如以前的Zero-Shot实际上是在告诉AI该如何回答。

这个方案主要强调灵活性可以通过提示词实现。

然而有时候由于在线服务的特性微调可能会带来较高的成本。

在此情况下也可以选择只使用提示词而不必微调。

我认为微调与提示词在某些方面的效果有各自的优劣但提示词语可能更加侧重灵活性。

此外从实际案例来看如果是一个规模较小的模型如只有几十亿个到百亿级参数规模有时候微调后反而可能会产生负面影响会出现被称之为灾难性遗忘的现象或者由于进行了微调导致它失去了一些原本的能力。

因此我们有时会认为对于这类规模较小的模型在企业或团队的AI技术或相关能力没有强大到可以驾驭时甚至是不建议进行微调的。

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