一、 技术架构
目前，大模型应用开发的技术架构主要有四种。
1.1 纯Prompt模式
不同的提示词能够让大模型给出差异巨大的答案。
不断雕琢提示词，使大模型能给出最理想的答案，这个过程就叫做提示词工程（Prompt Engineering）。
很多简单的AI应用，仅仅靠一段足够好的提示词就能实现了，这就是纯Prompt模式。
其流程如图：
1.2 FunctionCalling
大模型虽然可以理解自然语言，更清晰弄懂用户意图，但是确无法直接操作数据库、执行严格的业务规则。这个时候我们就可以整合传统应用于大模型的能力了。
简单来说，可以分为以下步骤：
1.我们可以把传统应用中的部分功能封装成一个个函数（Function）。
2.然后在提示词中描述用户的需求，并且描述清楚每个函数的作用，要求AI理解用户意图，判断什么时候需要调用哪个函数，并且将任务拆解为多个步骤（Agent）。
3.当AI执行到某一步，需要调用某个函数时，会返回要调用的函数名称、函数需要的参数信息。
4.传统应用接收到这些数据以后，就可以调用本地函数。再把函数执行结果封装为提示词，再次发送给AI。
5.以此类推，逐步执行，直到达成最终结果。
流程如图：
注意：
并不是所有大模型都支持Function Calling，比如DeepSeek-R1模型就不支持。
1.3 RAG
RAG（Retrieval**-Augmented Generation）叫做检索增强生成。简单来说就是把信息检索技术和大模型**结合的方案。
大模型从知识角度存在很多限制：
时效性差：大模型训练比较耗时，其训练数据都是旧数据，无法实时更新。
缺少专业领域知识：大模型训练数据都是采集的通用数据，缺少专业数据。
可能有同学会说， 简单啊，我把最新的数据或者专业文档都拼接到提示词，一起发给大模型，不就可以了。
同学，你想的太简单了，现在的大模型都是基于Transformer神经网络，Transformer的强项就是所谓的注意力机制。它可以根据上下文来分析文本含义，所以理解人类意图更加准确。
但是，这里上下文的大小是有限制的，GPT3刚刚出来的时候，仅支持2000个token的上下文。现在领先一点的模型支持的上下文数量也不超过 200K token，所以海量知识库数据是无法直接写入提示词的。
怎么办呢？
RAG技术正是来解决这一问题的。
RAG就是利用信息检索技术来拓展大模型的知识库，解决大模型的知识限制。整体来说RAG分为两个模块：
检索模块（Retrieval）：负责存储和检索拓展的知识库
文本拆分：将文本按照某种规则拆分为很多片段
文本嵌入（Embedding)：根据文本片段内容，将文本片段归类存储
文本检索：根据用户提问的问题，找出最相关的文本片段
生成模块（Generation）：
组合提示词：将检索到的片段与用户提问组织成提示词，形成更丰富的上下文信息
生成结果：调用生成式模型（例如DeepSeek）根据提示词，生成更准确的回答
由于每次都是从向量库中找出与用户问题相关的数据，而不是整个知识库，所以上下文就不会超过大模型的限制，同时又保证了大模型回答问题是基于知识库中的内容，完美！
流程如图：
1.4 Fine-tuning
Fine-tuning就是模型微调，就是在预训练大模型（比如DeepSeek、Qwen）的基础上，通过企业自己的数据做进一步的训练，使大模型的回答更符合自己企业的业务需求。这个过程通常需要在模型的参数上进行细微的修改，以达到最佳的性能表现。
在进行微调时，通常会保留模型的大部分结构和参数，只对其中的一小部分进行调整。这样做的好处是可以利用预训练模型已经学习到的知识，同时减少了训练时间和计算资源的消耗。微调的过程包括以下几个关键步骤：
选择合适的预训练模型：根据任务的需求，选择一个已经在大量数据上进行过预训练的模型，如Qwen-2.5。
准备特定领域的数据集：收集和准备与任务相关的数据集，这些数据将用于微调模型。
设置超参数：调整学习率、批次大小、训练轮次等超参数，以确保模型能够有效学习新任务的特征。
训练和优化：使用特定任务的数据对模型进行训练，通过前向传播、损失计算、反向传播和权重更新等步骤，不断优化模型的性能。
模型微调虽然更加灵活、强大，但是也存在一些问题：
需要大量的计算资源
调参复杂性高
过拟合风险
总之，Fine-tuning成本较高，难度较大，并不适合大多数企业。而且前面三种技术方案已经能够解决常见问题了。
那么，问题来了，我们该如何选择技术架构呢？
二、 技术选型
从开发成本由低到高来看，四种方案排序如下：
Prompt < Function Calling < RAG < Fine-tuning
所以我们在选择技术时通常也应该遵循"在达成目标效果的前提下，尽量降低开发成本"这一首要原则。然后可以参考以下流程来思考：
