大模型企业端需求满足
面向企业的需求，大模型的需求似乎才刚刚起步。 首先，垂直领域就会有三种层面的需求：
-
垂直领域数据融合的基座大模型。
-
集成专业判断的对话式大模型。
-
基于大模型的企业应用改造。
对于第1种情况，一般是垂直领域数据供应商会大力投入， 会解决通用大模型的如下典型问题。
1.1. 术语理解
1.2. 领域知识联想
对于第2种情况，一般数据供应商，金融科技服务商都会大力投入， 一般会采用低资源（类似LoRA）的对话式大模型技术进行打磨。 会解决通用大模型的如下典型问题
2.1. 专业知识问答
2.2. 领域任务性能提升
2.3. 企业历史经验数据融合
2.3. 抑制幻觉问题（无中生有、事实冲突）
对于第3种情况，一般金融科技服务商、企业科技部门都会大力投入， 一般会采用CVP模式(ChatLLM-VectorDB-PromptEngineering)。会解决通用大模型的如下典型问题
3.1. 信息高效过滤
3.2. 抑制幻觉问题
3.3. 专业任务适配
3.4. 交互定制
因此对于需求企业，往往更重视第3与第2种落地模式的突破，围绕价值落地， 选择一个基础大模型， 会优先打造第3种能力。
因此，通用大模型，越来越像建设的解决方案，最终市场活下来的不超过5家的搜索巨头垄断了C端客户的需求。 然后基于开源的大模型解决方案，和基于开源或者部分开源的企业解决方案。
搜索引擎 - Google， Bing， Baidu
开源搜索框架 - Lucene, Solr
企业开源搜索框架 - ElasticSearch
日志领域定向企业搜索框架 - Splunk
相信未来通用大模型领域也会进入类似的解决方案。
大模型服务 - OpenAI，Google， Anthropic/Claude, NewBing, BaiduYiyan
开源大模型框架 - LLAMA2, BaiChuan2，ChatGLM
定向语法开源大模型 - SQLCoder， CodeLLAMA
定向应用集成：
- Chat2SQL: Chat2DB,DB-GPT
- Chat2VIS: Chat2Plot,VisGPT
- Chat2API: openai-java, Functionary,
openai-function-calling-tools
只是以上的所有改造的核心目标还是取代了3种低端人员。
-
低端文档整理工作人员
-
低端编码工程人员
-
低端数据分析人员
只是大模型爆发的原始阶段。 就好比以表数据为核心的， 企业服务软件经历了，早期的数据库大爆发。 再融入财务供应商等企业知识，进入ERP系统。再进一步融入工业细分领域知识，例如EDA系统一样。 一旦融入了财务，芯片设计等非常专业的知识。 自然形成了行业标杆联动，进而形成行业垄断优势。
Database --> ERP系统 --> EDA系统
而大模型，某种意义上开始走向表数据与文本数据的融合的时代产物， 相信对文本检索服务，数据库检索服务的再造会形成前所未有的改造！
但是，就目前而言大模型在表数据检索方向的能力融合还远未研究彻底， 值得学术界大力搞一下！
举个例子， 表数据一般用机器学习；非结构化数据一般使用深度神经网络。 深度神经网络也可以使用表数据呀。 那么， 那么多行业的表数据为何没有融合入大模型的网络呢？
基于大模型的应用改造
其实基于大模型的应用改造的核心是利用大模型的理解能力，形成强大的语言理解与调度能力。 其实这种能力在微服务领域就成为编码能力(Orchestration)。
编排能力的三大要素：
-
功能操作
-
基础设施
-
业务逻辑
功能操作
大模型的功能操作，其实目前主要是文本对话。但是文本对话的背后其实是所有的任务功能点的映射。 如何让大模型知道这些功能映射关系，相当于把树状的菜单导航彻底打平， 不代表菜单导航就不存在了。只是把困难进一步留给了系统， 而把傻瓜式交互留给了用户。
基础设施
大模型编排的基础设施就存在调度系统建设、向量数据库、用户权限管控、服务质量跟踪等一系列的基础设施建设。
尤其其中的编排框架，必然需要根据功能操作与集成的应用进行定制化开发。 目前开源的很多大模型功能编排的框架可以借鉴参考。
1. LangChain. - 工作流范式
LangChain早期围绕着功能编排(Chains)， 向量数据库（Memory）， 自动化代理(Agents)， 提示词工程(Prompts) 这4大能力打造。
但随着应用越来越多， 尤其是解决幻觉问题的Retrieval Augmented Generation based QA (RagQA)的需求大量增加。 因此， 细化了Documents系列， Retrieval系列， Language系列。
2. LLamaIndex - 查询范式
LLamaIndex其实是模仿了ElasticSearch的视角， 围绕着Query， 然后做回复集成的视角进行建设的。 如果企业内部想单一使用RagQA做个文本理解的垂直工具， 我建议优先测试一下它。
所以， 它提供了强大的文档内嵌的建设机制。非常适合只需要RagQA的应用建设。
3. Semantic Kernel - 插件范式
Semantic Kernel是最早探索与ChatGPT做应用集成的微软提出的开源框架。核心是把大模型打造成插件，内嵌到所有应用中去。 而微软规范插件主要为规划与执行的方式。 如果使用Azure云的很多功能，肯定是第一选择了。
插件：
-
规划 - 存储，工作流，语义建设（向量数据库）
-
执行 - 存储， 调度
4. Guidance - 提示工程范式
最早也是脱胎自微软的项目， 核心理念是要解决对于不同的大模型， 实现自适应的提示词工程适配。 所以未来，你想实现集成多家大模型来做应用适配， 可能非常值得试用一下。 看来早期微软已经想好了未来同时集成自家与openai等多家的模型提供服务了。
5. Haystack - 查询范式
Haystack也是走查询范式， 只是走的更直接， 就是要和ElaticSearch集成。 进而服务ES现有客户。
这里我们给出了一个基础设施的开源解决办法的大致示意图。
业务逻辑
编排的好，是需要业务逻辑的内嵌的。而目前大模型如何嵌入业务逻辑，还是一个带解决的问题。因为逻辑是高水平的知识， 需要实现推理能力。目前知识图谱， 最优化， 图神经网络都有推理的能力。但是， 业务逻辑推理应用，目前还没有非常成熟的方案。
企业应用建设
1. 数据资产盘点与分类
由此，首先需要盘点企业独家的数据！并且针对典型的适配场景做一个分类！
2. 清晰大模型企业应用的定位
前面提到， 大模型编排能力大致有4大范式。
-
工作流范式
-
查询范式
-
插件范式
-
提示词范式
企业应用大模型， 从大了来说，可以是大模型成为一切其他应用的新型入口。 本质上，就是把细分菜单的活通过交互式接口直接搞定。 很多企业把类似能力的接口应用成为数字员工。
1. 数字员工 - 工作流范式的编排能力
这种情况，需要把功能点进行分门别类， 同时让大模型学习业务工作流，需要强大的编排引擎。
但很多企业不想做的那么复杂， 毕竟大模型的编排能力还不成熟。较为成熟的，还是大模型的问答能力。 那么，就让大模型帮我实现智能问答， 实现对非结构化数据的语义问答。 尤其企业是因为领域非结构化数据过于庞大， 而且不定期处于变化中。
2. 智能问答 - 查询范式的编排能力
这种情况下的建设比较明确， 很大精力其实放在数据的清洗， 数据的组织。因为当前大模型的能力受限于输入长度， 输入历史， 幻觉等多种问题限制。 只有高质量的数据输入，才能让大模型变得更可靠。
但是有些企业，自己有非常多成熟的产品线， 并不愿意把大模型作为统一的入口。仅仅希望大模型赋能各个产品线。 这种情况的大模型就被当成了金山杀毒的小狮子， 适当的时候就跳出来帮你解决一些产品常识问题。
3. 大模型助手 - 插件范式
大模型助手其实算是介于数字员工与智能查询中间的一个状态。
3.1 每个插件都可以定制化开发， 不需要有很强的通用入口和强大的编排能力。
3.2 每个插件需要根据场景实现一定的规划能力，适配几个定向任务的触发。
3.3 每个插件面向的上下文数据可能不如智能问答的数量大。
这样应用的插件改造， 快速给现有应用带来智能化体验。
但是，千万要注意大模型的数据泄露问题。尤其原本闭环的信息通道， 不要因为大模型插件， 带来了新型的安全后门问题。
有些企业，希望自己基于众多细分的小模型，打造一个大模型中台。 一方面， 尤其是集团型企业， 因为大模型的资源需求， 大模型的更新换代都需要独门手艺。集中运营可能会有更好的效果。
4. 大模型中台 - 提示词范式
因此， 你不能指望大模型是一个静态的产物。
也不能指望一个大模型就搞定所有场景， 所有接口， 所有编程语言。
那么就需要很强的提示词适配能力， 适配不同版本， 不同平台。 进而保持大模型中台能力的稳定提升。
小结
大模型来了， OpenAI火了。 大模型应用服务来了， 微软火了。大模型企业服务来了， 供应商们的机会来了。 企业需要一套编排系统。而适配不同的企业大模型建设方向， 需要注意大模型编排能力的建设方向。
-
数字员工 - 新型交互式入口 + 智能工作流模式 - 工作流编排为主。
-
智能问答 - 大量动态非结构化数据解读 - 查询编排为主。
-
大模型助手 - 改造现有产品线，提升智能体验 - 插件编排为主。
-
大模型中台 - 集中全集团的大模型服务运营 - 提示词编排为主。