考虑业务与大模型结合时，优先选择PromptOnly和Embedding，找业务与大模型的结合点，先用起来以后再考虑做大模型微调。
总结目前对大模型的使用模型，从轻度到重度有如下三种：
- 纯提示词模式（PromptOnly）：直接使用提示词结合千帆Prompt模版调用大模型 API，这是目前最容易上手、也是效果最明显的方式；
- 嵌入向量模式（Embedding）：将知识预处理存入向量数据库，在提问时通过向量相似度查询找到关联知识，然后跟Prompt模版 + 关联知识 + 问题一起加入提示词，再调用大模型 API进行推理；
- 微调模型模式（Fine-tune）：将知识通过 SFT、Prompt Tuning、LoRA等微调训练方式存入大模型，然后使用时再进行 Prompt 进行调用。
一、纯提示词模式（PromptOnly）
调用文心大模型通用API能力进行推理，不需要做模型微调，如果QPS要求不高（<5），也不需要做模型托管，通过合理使用Prompt提示工程技巧（few shot、CoT等），能够胜任内容生成、推理、通用知识问答等大多数场景。这是大模型应用的首选模式，当考虑客户业务与大模型结合时，首先要考虑的就是这种模式。能用Prompt解决的问题，都不是真正的问题，如果不能，再想想是否Prompt没写对。
二、嵌入向量模式（Embedding），即知识库
涉及到专业知识问答， 通用大模型就无法胜任了，这时候有两种选择： 嵌入向量模式、精调模型模式。
嵌入向量模式是先将知识文档分片，然后将分片后的知识片段通过调用大模型 API 获取其对应的向量，这个向量也就是我们所说的Embedding。随后将上述调用后得到的向量值存入向量数据库。
在用户提问后，应用层先将用户问题调用大模型 API 获得对应的向量（Embedding），然后通过此向量到向量数据库中查询相似度最相似的 TopK 知识片段。
组合Prompt模版 + 知识片段 + 问题三部分形成最终的提示词，最后调用大模型推理API获得最终答复。
2.1 嵌入向量模式优点如下：
- 不需要对大模型做微调，使用的仍然是大模型的PromptOnly推理能力，所以成本较低；
- 客户完全控制向量数据库，可以非常方便对向量数据库中的数据进行增删改查，更加灵活；
- 能够在多个大模型之间进行切换， 应用层无需改动，支持多个大模型；
能够解决大模型输入限制问题；
嵌入向量模式的问题是没有CoT思维链能力，由于引用的是知识片段，无法根据完整知识做推理。
对于大模型的输入限制问题， 目前文心API的输入限制是2K字符， 那么将来输入限制更大以后，是否可以直接使用PromptOnly代替Embedding了呢？ 答案是不可以。
主要是考虑成本和延时问题。大模型的计费模式是按照输入输出的token总数计算， Prompt里内容越多成本越高。另外是延时问题，如果Prompt里内容过多，增加了大模型单次处理API调用的工作量，延时也会更高。
大模型支持的上下文在相当长时间内最大也只会到 MB 级别，而向量数据库大小则可轻松突破 GB 级别。
三、微调模型模式（Fine-tune）
微调模式是将外部知识内化到大模型之中，有SFT、RLHF、Prompt tuning、LoRA等方式。
SFT是全量参数微调， 需要的数据量较大(>1w），少量数据有将大模型调“傻”的风险。客户如果只有几十、几百条数据，不建议做SFT。
微调使用的数据除了有数量要求，还要求能覆盖到客户业务的方方面面，还不能包含敏感数据。数据质量将直接影响大模型微调效果，数据准备与预处理，将会是微调模式的主要工作。
除此之外，微调模式的优缺点基本上与嵌入向量模式对应。 微调模式的优点对应嵌入向量模式的缺点， 微调模式的缺点对应了嵌入向量模式的优点。
总结
考虑业务与大模型结合时，优先选择PromptOnly和Embedding，找业务与大模型的结合点，先用起来以后再考虑做大模型微调。1`3
