专注LLM深度应用，关注我不迷路
大语言模型（LLM）的出现，使基于自然语言处理的人工智能技术实现了飞跃式的发展，彻底开启了AI2.0的时代。随着大模型的不断迭代与升级，周边生态的培育与成熟，其在B端企业级场景的落地应用也逐渐拉开序幕。本文将对大模型在企业应用中的落地场景、典型架构与产品选择等做较深入的探讨与分析。由于内容较长，本文将分为上下两篇做完整阐述。
LLM在企业应用的落地场景
当然，我们说的企业应用场景不是指的企业内个人使用的桌面AI助手或问答机器人；而是指的借助这些工具背后的大语言模型（LLM）的智能理解与生成能力，来改造或升级传统的企业信息系统，进而改进用户体验，提升业务效能。
那么大语言模型在企业场景应用的能力源泉来自于哪里？可以认为这来自于其强大的自然语言处理能力，这主要体现在两个方面：
- 输入侧：极高的自然语言理解能力
这种理解能力超越了以往所有的自然语言处理(NLP)技术。表现在对人类输入的高度理解与遵从，以及对输入内容的语义理解的准确性。这带来一种全新的交互界面的可能性。
参与过传统AI项目的人应该都知道，自然语言处理（NLP）一直是难以克服的核心难点，语义表示、歧义消除、上下文联系等都是语义理解的头疼问题，也是之前很多人工智能被称作“人工智障”的罪魁祸首，LLL的出现改变了这一现状。
而从集成角度，在LLM出现之前，我们构建一个基于自然语言交互的AI应用，可能面临繁琐的配置与训练过程，而最后的效果却不如人意，以训练一个简单的天气查询机器人来说，其流程可能是这样的：
而现在，我们可以利用大模型轻松构建自然语言的交互界面。
- 输出侧：强大的自然语言生成能力
大语言模型则在语义理解的基础上，具备了强大的自然语言推理、决策与生成能力，具体表现在文本内容的总结、归纳、整理、对比、摘要、转换、创作、分析等能力与行为。这源自于大语言模型学习算法的改进及海量训练数据的输入与“投喂”，千亿甚至万亿级参数的大模型不断出现，这让大模型具备了某种意义上的“思考”能力。
简单的说，大模型具备了相当程度类似人类的“理解”与“思考”能力。因此可以很自然的想到把这样的智慧“大脑“与现有的企业应用展开协作，从而实现企业应用的智能化程度的跨越式升级。
大语言模型在企业应用的一些典型落地场景如：
- 构建以自然语言为交互界面的应用，结合成熟的语音/图像识别、语音合成等技术，在市场营销、客户服务等领域提升客户体验。比如：智能客户咨询、智能呼叫中心、智能销售助理等
- 借助大语言模型的文本抽取与分析能力，分析呼叫中心对话记录，完成质量检查、客户情绪分析归类、热点问题提取、销售线索发现
- 构建基于自然语言的企业内容搜索引擎与门户。相对传统的搜索解决方案，大模型可以在语义理解的基础上帮助更好的优化与总结搜索结果，提升搜索体验。并可与其他企业应用做进一步融合，比如，在一个典型的营销过程中，可以根据客户对话自动搜索产品介绍并发送给到客户。
- 一个更具有通用性的应用场景：根据设定目标/任务，由大语言模型驱动自动化的企业应用流程，自动分解任务，自动思考“下一步动作“并调度执行，自动根据结果迭代与调整任务，并能够与外部应用完成协作，最终完成任务输出结果。
借助AI大模型的自动化任务概念图
LLM在企业应用中的复杂性
通用大语言模型在C端的应用逻辑非常简单：一种是直接与大语言模型对话，获得输出，用于咨询或者创作；另外一种是大语言模型给C端软件赋能，比如WPS AI，或者代码Copilot。
但大语言模型到了企业应用端则没有那么简单：如上文所述，大语言模型在企业的应用场景通常不是直接简单的对话输出，而是作为背后的“大脑”参与到现有的企业应用，成为流程的一部分：
由于大型的企业信息系统的数据、流程、架构的复杂性都是惊人的。而大语言模型自身对外接口又是极其简单的（prompt->结果），本身并不具备访问外部应用、数据、任务调度等能力，这就带来了一些集成上的复杂工程问题，包括：
1. 私域知识与数据的链接问题。通用大模型能够解决通用性问题，但是在企业应用中，你需要大模型接入你的私有数据，比如你的产品、订单、服务记录等。如何把私域知识与大语言模型链接应用，是首先要解决的问题。
链接私域数据与LLM
方案一：训练或者微调私有大语言模型。这种方案可能对大部分企业门槛过高，算力成本高昂，且训练出来的模型存在一定不确定性。最主要的是灵活性受到限制，比如你的服务记录，随时都在变化，但你无法随时训练进入大模型。
方案二：通过提示工程做私有数据输入。将领域知识临时输入大语言模型，再由大模型理解并推理形成输出结果。这是一种更实用灵活的方案，但需要借助于向量数据库技术实现领域知识的存储与搜索：因为你不可能每次都把所有的领域知识临时输入大模型。典型的连接架构如下：、
2. 提示词的构建与管理问题。企业应用场景中，与大模型“对话”的很多时候不是自然人，而是企业应用系统，而这些系统通常无法用自然语言交互。因此，需要借助于提示词工程（Prompt Engineering）优化大语言模型的输入输出。
比如，要求大模型“，你可能需要动态的构建类似这样的Prompt提示：
请按照给定的格式思考并回答问题。你有下面这些工具可以使用：
Tool1: 当需要查询公司产品信息时使用
Tool2: 当需要登记发送邮件使用
Tool3: 当需要网络搜索时使用
回答时请遵循以下========内的格式：
===========
Question: 我需要回答的问题
Thought: 回答该问题我需要做什么
Action: 【以上的一个工具名字】
Action Input: 【该工具的输入内容】
Observation: 【该工具上次的调用结果】
...（以上的思考/行动/输入/观察可以重复迭代N次）
Thought: 我现在知道最终答案
Final Answer: 最终输出答案
============
{对话历史}
现在开始回答，记得按照指定格式进行一步一步的推理。 参考大模型框架Langchain内置提示工程
此外，在任务过程中，你可能还需要构建其他的prompt来完成其中的子任务，比如对产品信息进行对比并做表格化输出。可以看到，这样的提示词与个人AI工具使用的提示是完全不一样的设计。
3. 与各种企业应用、遗留系统、外部工具的对接问题。在企业应用场景中，除去自己可以直接完成的文本内容输出外，大模型很多时候是输出“指令”，而指令的执行则需要借助外部应用或工具来协助完成企业级任务，例如：
- 借助工具搜索内部产品知识然后让大模型“销售代表“回答客户问题；
- 大模型理解客户服务意图后需要借助CRM系统登记销售线索；
- 大模型将自然语言转换为数据库查询语言(SQL)并获得查询结果；
由于这些外部应用/工具通常具有不同的接口协议与类型要求，因此需要消解复杂性，使得其易于管理与扩展。
4. 任务的上下文记忆问题。大模型是一种无状态的服务，本身不具备记忆能力。而在一个复杂的AI任务完成过程中，需要自行记忆决策与行动过程，进而形成大模型的上下文，以增加大模型输出的确定性。
5. AI任务的自身管理。当大模型变得无处不在，基于大模型的AI任务运行也就需要管理，特别在调试阶段，这些任务的执行过程需要做细粒度的跟踪，以用于优化提示词与流程设计，进而影响大模型的任务决策与执行过程。
以上是大语言模型在企业应用与集成中可能面临的复杂问题，当然，在实际实施中，通常会借助于一些第三方的开源或者商业框架来降低这种集成上的复杂性。但是理解这些复杂性背后的原因，有助于更好的使用这些工具。
在【下篇】中我们将会分析一个典型场景下的企业应用与大语言模型的协作架构与工作流程。
END
私信“交流”
一起探讨AI大模型的应用实践