我要投稿

BISHENG视角|跟上百家企业聊完大模型应用，大家关心的：应用场景、困难、解法

发布日期：2024-05-28 10:57:02 浏览次数： 3703 来源：毕昇 BISHENG

毕昇BISHENG 是一款开源 LLM应用开发平台，主攻企业场景，已有大量行业头部企业组织在使用。我们秉持专业、创新、实干、不炫技的精神，为帮助企业实现LLM应用落地，全力以赴！

BISHENG的视角系列文章说明：

该文档将以在线文档形式持续更新，点击文末“阅读原文”访问。
仅代表我们的视角（偏见），不代表市场整体观点和共识。
本系列文章假定读者是了解基本概念的业内人士，不对概念做科普。

本文分为三部分：企业应用场景、企业落地应用遇到的困难与挑战、我们尝试提出的解法与思路

一、典型应用场景

按应用/交互形态分类，见下图。

详细场景列表1.0版本，见下图。

场景列表同样将在BISHENG在线文档（doc.bisheng.ai）持续更新，我们也非常乐意跟大家一起探讨和贡献各自的落地实践。

以下场景配图均使用Dreamina生成

对话助手

对话助手是最基础也是场景数量最多的应用形态，从实现原理上我们分成了两小类：

“对话助手-基于文档库”，即常说的RAG。
“对话助手-基于Function Call”，即对话过程中需要调用内外部系统获取信息。

实践过程中，也有许多场景会融合这两种能力。

出于准确率、合规两个方面的考虑，在大部分企业的应用中，都仅对内提供服务，提升员工工作效率。

由于理论上准确率不可能达到100%，实际上这类应用提供的价值更类似搜索，核心价值是高效信息传递，需要为最终用户提供便捷的答案确认的能力，如RAG的原文档溯源、Function Call的接口调用日志等。

同时，成熟度相对较高的应用基本都是即使答案错误也不会产生严重影响的场景，比如“产品使用手册问答”场景，对于大部分产品，并不会因为某个误操作导致严重后果，产品设计本身便会考虑误操作后的回退或者关键操作的重复确认。

报告生成

最容易对用户产生价值感的应用形态，刷刷刷自动生成一份几万字几十页的报告有直观的冲击力，这是大部分“打工人”直接的工作成果。

企业场景主要以有固定模板的报告为主，并且报告基本都是几十页到几百页的长篇幅内容，涉及大量专业逻辑，想要通过一次大模型请求完成这种任务几乎是不可能的。需要有类似BISHENG这样的平台将一个复杂的报告生成问题向下拆解成许多更简单的子问题，逐个解决，然后将子问题的结果逐个填充到预先定义好的报告模板中。同时，子问题也并不都适合使用大模型技术解决，需要融合不同类型大模型、小模型、专家规则系统、专业业务系统等能力解决。

这类应用同样无法提供100%准确的生成结果，需要为用户提供便捷的生成逻辑与依据溯源能力。当然，即使一份报告内，不同章节内容的准确性要求也是不一样，用户可以专注于一些重点章节与重点指标和要素的结果确认。整体来看，的确在许多场景可以帮助用户节省“码字”的时间。

其实从广义视角来看，这类应用可称之为“对生成逻辑有严格要求的内容生成”，比如会议纪要生成、各类审批建议生成等都属于这类。

审核

审核类场景往往与生成类场景相伴相生，所以各类“报告生成”场景都会有对应的审核场景。

除了文档类数据需要审核，结构化业务数据也可以用大模型辅助进行审核，如经营性贷款业务审核，这类场景主要借助大模型推理能力进行一些业务规则审核，如“抵押物是否属于房产”、“是否属于金融行业从业者”…

从业务阶段来看，审核包含“事中”业务的审批、审核，也包含“事后”的审计、监督与质检。

从审核内容来看，包含专业业务逻辑审核、合规性和合法性审核、通用纠错（错别字、歧义等）。

基于目前技术水平，审核同样只能是辅助性的，帮助审核者/提交者查漏补缺，比如在提交审批前先进行自动审核，提交者可以判断是否需要修改，提高提交质量，降低打回概率。

知识管理/非结构化数据治理

大模型技术火起来前这类场景需求在企业内就已很常见，只不过过去都需要专门训练小模型，而大模型降低了这类场景应用落地的门槛。

这类应用的本质是将非结构化数据向结构化/半结构化数据转换。

不过，有一些对实时性、准确性要求很高的信息结构化场景，大模型方案不一定优于专用模型。

数据分析

通用数据分析辅助（技术上相关概念是NL2SQL），主要是降低传统做数据分析的门槛。

目前基座模型如果不做微调优化，在特定业务场景下效果差，特别是企业内数据库中都有至少几十张表的情况，所以目前离业务可用较远。

而微调需要从零开始针对性准备大量微调数据（上千条），是否具有性价比大家可以根据具体场景评估，目前真正落地的数量是少的。我认为等基座模型无需微调即可达到90%以上准确率时，这类场景才会真正意义上解锁。

智能仪表盘/看板（BI）类场景当前的成熟度更高一些，因为做BI展示的数据库往往是被针对性治理过的，并且查询的频次也相对较低。

企业系统统一导航/交互

大部分企业内都至少有上百个系统，统一导航/交互指的是为员工提供统一入口，用户通过自然语言表达意图，直达操作对象。

这类场景目前落地案例少，因为并非痛点场景，特别是从管理者视角来看。

长期来看，这种应用形态可能重构整个企业应用交互形态，对于各种长尾需求或不同企业之间的定制化需求，可以通过这种更自由的交互形式得到满足。

技术角度，基座模型通过Function Call或类似能力对企业内部系统进行操作方面的能力如何有待验证。

代码

一种是编程过程中的各种辅助，类似于写作辅助，另一种是程序开发自动化，类似于“报告生成”，直接生成一个完整的项目，然后由人进行调试验收。

这个方向不是最典型的企业落地场景，且属于相对较独立的一类，不作为本文介绍重点。

二、落地应用的困难与挑战

真正做过大模型应用落地项目的朋友应该对以下四个问题不陌生：

1.应用落地效果不及预期

虽说列举了四项困难，但究其本质，第一项困难才是最最核心的。

大概到2023年底，企业落地的先行者们开始感受到从技术发展曲线的希望之巅跌入失望之谷的坠落过程。

一方面大模型技术从原理上存在的天然缺陷导致它就是不可靠的，作为一个概率系统，大模型输出的结果不可控且不可解释，这对于大部分企业严肃业务场景来说是无法接受的。最终能产生有限价值的只能是一些无关痛痒的边缘场景。

另一方面，相较C端应用，B端的应用场景要复杂得多，业务逻辑非常专业且复杂，这导致直接依靠大模型本身的能力或简单做个RAG根本无法解决问题。通常情况下，大模型只是在某些特定环节提供了增量价值，而整个过程仍是复杂的长流程，这无疑提高了大模型应用落地的探索代价。

2.缺乏高质量数据

包括两个方面：

一方面是缺乏高质量的知识库数据，大部分企业的结构化与非结构化数据治理还在起步或进行过程中。

另一方面是缺乏应用场景相关数据，且不说场景优化的微调训练数据，连用于评测的真实数据也没有。因为大模型应用基本都是新场景，所以并不存在历史数据，比如NL2SQL场景，它的目标用户是技术小白，但以前都是专业人员做数据分析，并不存在小白用户通过自然语言方式表达的数据分析需求。

碰到这种情况，最常见的做法是技术团队先根据自己的理解“造”一些数据出来进行效果测试与效果优化，但问题是，当优化完提供给最终用户使用时才发现他们完全不按我们预想的方式使用。

另一种做法是让最终用户来帮忙造数据，先不说最终用户“造”的数据还是会跟真实使用时有差异的问题，跨部门的资源协调也往往是企业内项目推进一大难题。

最好的方式当然是尽早将应用提供给最终用户试用，收集真实数据。但效果差的时候就提供给用户使用必定会遭到吐槽进而损害用户对技术团队的信任。所以这是一个先有鸡还是先有蛋的困境。

3.基座模型选择困难

许多企业还并没有深入试用过各家模型，更没有在自家企业内具体任务上对比过不同模型的效果。

而市面上模型相关的宣传信息眼花缭乱，企业缺乏一个清晰、权威、客观的方式来选择模型，包括选择开源模型还是闭源模型，如果选择开源/闭源应该选择哪家。

4.效果难以评估

相较传统软件系统，以大模型为中心或者有大模型参与的系统，不确定性大大提升了。因为即使是相同的输入，大模型的每次输出也都是不固定的，这为系统整体的评测带来了新的挑战。

三、我们尝试提出的解法与思路

不得不承认，大模型在企业内的应用落地仍处在早期阶段，我们提出的解法与思路也只是阶段性的一家之言，欢迎有实践经验的朋友们联系我们一起探讨进步。

首先应从大方向和思路上想清楚，然后才是具体实操，所以我们分为“建设思路”与“应用平台相关能力要求”两部分进行说明。

建设思路

对于大模型技术的发展，我认为应当谨慎乐观——不过分夸大的同时对未来充满期待。

建设规划建议大致分四个阶段：探索与勇气、建立认知、寻找并扩大价值、组织重塑。

阶段1、探索与勇气

做大模型应用很容易因为惯性思维走到上一代做小模型AI项目的老路上——过分关注准确率。

要知道，大模型令人震惊的能力在于涌现、泛化、通识与通用推理。它并不擅长把某个垂类任务做到极致——这是小模型的特长——即使通过训练大模型真的把某些垂类能力顶到极致，它整体的性价比也是差的，无论是训练的代价还是推理的代价。

在探索阶段，不应只拿2~3个场景做立项，而是应该先拿200~300个场景做尝试，可以组织一些全公司参与的内部黑客松活动或是组织虚拟小组让部分有兴趣的业务人员参与进来。

每个场景应该借助一些比较成熟的脚手架工具花非常短的时间（小时级别）进行快速敏捷验证，要有勇气做尽量多的尝试，不要担心失败，成功不是规划出来的，大模型应用的落地更是如此。

大模型不是万能的，要有勇气承认失败。

以发展的眼光看问题，对于一些大模型暂时解锁不了的场景，我们也不必硬上，可以过几个月等新一代模型发布后再进行验证。

阶段2、建立认知

整个探索的过程便是建立和积累认知的过程，相比市场上的各种宣传，亲手验证一些场景效果的经验比谁的说法都更值得信任。

可以为每个场景建立简单的档案，就像上文中我们提供的场景列表一样，对每个场景进行成熟度评定（成熟、有希望、不确定、不靠谱），并且记录当前主要困难的点在哪里。持续积累验证过程中产生的真实用户测试数据，这些便是未来验证新技术能力珍贵的数据集。

在探索与建立认知的阶段，建议先快速使用最好的开源模型和开源中间件框架把验证迭代的流程运转起来（而不是花好几个月论证该买哪家），建立了基本的认知与感觉，自然能更科学地看待各家的优劣势。

认知的建立不应局限于技术团队内，最好能邀请业务人员代表、领导也一同参与，大家诚恳交流、对齐认知。

阶段3、寻找并扩大价值

通过前两个阶段的积累，我们将从大量场景中筛选出一些成熟度较高且业务价值较大的，通过这种方式做出的选择就不再是拍脑袋或者人云亦云。对于这些场景，可以开始进行必要的针对性优化，以达到真正的业务可用。

注意，这里的优化并不一定是模型，并且应当最后才去考虑动模型。有两方面原因：

1、整个应用端到端效果受多方面因素影响，如数据治理情况、任务拆解与Workflow编排的情况、其他相关小模型的效果、大模型效果，从我们落地过程中做错例分析的经验来看，占比大的错误反而不在大模型，所以优化应当先从那些代价低、性价高的方向入手；

2、大模型本身能力的发展还在高速变化，很可能当下辛苦训练调优了一个模型，优化的能力几个月后就被新的基座模型给抹平了（当然，有些能力的确是通用基座模型很难提升的，这个后续再专门讨论）。

大模型及相关技术领域太新，全市场相关的人才都是稀缺的（即使是过去从事NLP算法工作的人也基本是从头开始），通过实践培养组织内的人才可能是最可靠的方法，毕竟大部分企业需要的也不是尖端训练模型的人才，而是懂大模型的特性与能力边界，能把大模型的能力用好的人。

随着技术演进和人才队伍的建设，将不断解锁更多新的应用场景，不仅能够赋能组织内部，更有走在前面的企业已经开始向外输出能力（比如正在参与BISHENG开源代码贡献的中核八所，以及其他许多BISHENG在组织内的开发者）。

阶段4、组织重塑

这是更远的未来，AI员工的加入必将改变未来组织的形态和组织流程。

届时，如果管理AI员工将是一个新的话题。

应用平台相关能力要求

思想上有了准备，那么探索和构建大模型应用的平台工具又应当具备哪些特性呢？

1.低门槛构建应用的能力

若想让企业内非技术人员/业务人员仅用几小时（甚至几分钟）就能完成应用开发，“低门槛”非常重要。OpenAI的GPTs 提供了这方面的最佳实践，仅需一段几十字的需求描述即可自动生成应用。[BISHENG Ready]
要实现这样的功能，核心依赖两方面能力：一方面是常说的大模型Function Call能力，包含了理解、推理、规划、外部工具调用与多轮交互能力；另一方面是足够丰富的外部工具接入，包含一些企业内部通用工具的预置以及对自定义工具接入能力的支持。[BISHENG Ready]
当前效果最好的开源模型，如Command R plus（104B），基于我们内部的测试数据集，经过优化后，在Function Call 方面的能力，已经能达到GPT-4约90%的效果，未来可期。[BISHENG Ready]

2.复杂业务逻辑表达与控制的能力

企业内应用场景的逻辑大部分是相对比较复杂的，除了面向非技术人员的低门槛构建能力，平台还需要具备复杂长流程编排的能力。[BISHENG Ready]
企业的应用形态与个人用户需求也存在差异，比如个人用户生成内容的场景多是“小红书文案生成”、“视频脚本生成”等短小的文案，而企业内则是“企业尽调报告生成”、“招标文件生成”等复杂长文档的生成，并且企业场景对于结果的可控程度要高很多，包括了版式与章节结构的可控、内容准确性的可控，这就要求平台需要有相关功能做支撑。[BISHENG Ready]

3.自定义能力

即使是同类场景，不同企业间也会存在差异，所以需要平台拥有足够强的开放性与灵活性，各层面参数都需要支持自定义设置。[BISHENG Ready]
除了平台已有能力，企业应用开发的过程中经常需要纯定制化的特殊逻辑或内部专业系统能力的接入，系统应当支持低代码或全代码的定制。[BISHENG Ready]

4.多模型的接入能力

因为目前大模型能力的增长曲线仍然陡峭，所以最新发布的模型（特别是开源模型）在实验环境中应该能够尽快进行使用，平台需要支持一键切换或接入所有主流大模型（开源或闭源）[BISHENG Ready]

从模型选择思路角度，我们建议缩短决策路径，优先选择最好的开源模型进行场景验证。

5.便捷的开发调试

大模型应用的开发与传统软件开发最大的区别在于不确定性，相同的输入每次得到的输出是变化的，所以需要为大模型应用的开发过程提供便捷的调试对比能力。涉及的主要对比项包括但不限于：不同大模型、Prompt、知识库不同召回策略、知识库文档解析策略、Workflow的编排逻辑等。[BISHENG Ready]

在调试比对的基础上，支持对应用进行完善的版本管理，可选择或切换当前上线的版本。[BISHENG Ready]

6.自动化效果评估

应用开发中的调试是比较轻量级的，一般只基于几个测试case；而应用开发完成后，需要更加完备科学的效果评估。这跟上一代AI系统的诉求是类似的，所以需要支持基于某个较大的数据集（几十或几百条case）进行自动化的端到端的效果评估。[BISHENG Planning]

与上一代AI系统不同的是，大模型解决的任务类型更广、输出的不确定性更高，抽象下来任务类型可以分为选择题（有精确答案）任务、阅读理解任务、作文任务，相应的评估方法是多样的，包括：模型方法（相似度、大模型评分）、规则方法、模型规则混合方法、人工标注方法等。评估结束后输出相应评估指标，并支持对不同版本或者不同应用之间的指标对比。[BISHENG Planning]

7.数据层能力

分为两个方面

一方面是通用文档解析能力，该能力对于大模型应用落地的效果影响显著，但容易被忽视。常举的例子是，构建RAG类场景时，若一张表格跨页了没有被拼接起来，召回的内容很可能就是残缺的，导致模型即使再强也无法给出正确答案。好的文档解析需要包含的能力：高精度文字检测与识别（包含手写体检测与识别）、高精度表格识别（有线、少线、无线、异形表）、版式识别（标题、分栏、段落、页眉页脚、附注等）、印章及公式识别能力等。[BISHENG Ready]
除通用解析外，我们在构建某些类型RAG场景时，业务元数据（如合同的甲方、乙方、合同金额…）索引能够有效提升搜索召回准确性与应用效果，这便需要对非结构化数据进行治理（非结构化转结构化）。[BISHENG Ready]

另一方面是场景相关数据的获取与积累，说白话就是，真实情况下业务人员会怎么问问题以及希望获得怎样的答案，这些数据目前是最难获取、最独特且最宝贵的。在前文提到过，最科学的方法肯定是让真实用户参与进来，产生最真实的交互数据，筛选、沉淀这些数据，然后需要技术团队能使用这些数据敏捷迭代应用效果，否则用户迟迟见不到改善容易失去信心。所以这里一方面需要大模型应用开发平台有很强的综合能力，另一方面需要有对用户使用过程数据进行自动化分析与管理的能力。[BISHENG Planning]
当然，也有一些冷启动的方法，比如基于业务文档直接生成QA对，然后人工进行质检。但这是退而求其次的方法，因为这只适用于特定类型的场景，并且生成的结果仍然依赖人工检查。[BISHENG Ready]

8.微调

首先，微调模型并非必要，前面提到过，大模型最被寄予众望的是其泛化与通用推理能力，否则如果每个场景都需要专门微调一下，那跟每个场景训练一个小模型就没有本质差别了。当然也有一些需要微调的情况，比如需要控制“你是谁”这类自我认知问题的回答时，比如某个场景价值很大，投入产出比能算过来时。
如果确认要进行微调，注意一定是面向问题的，所以这里跟上面提到的“场景相关数据的获取与积累”是紧密关联的，基于用户使用问题分析定位出模型问题后再谈微调。
常见的微调方式有全参、Freeze、Lora三种。[BISHENG Ready]（目前还很少看到企业内跑起来RLHF框架做微调的）