一文探秘LLM应用开发(2)

1.问题定义与基本思路

  对于大模型应用来讲，核心工作围绕这个问题展开：

如何让大模型能够完成具体领域场景的实际工作，并且能够提升和干预效果？

从影响大模型的能力和效果的两个因素入手：

1）模型（内在）

可以将模型理解为知识和能力的混合体，经过微调的模型包含了学到的知识，逻辑，也包含执行具体某个任务的能力。但它有个缺点就是比较重量级，训练和更新需要大量的时间和成本，这也就导致模型知识不够及时，变更困难，黑盒难控制，能力扩展难度高等问题。

2）提示词(prompt)（外在）

可以将其理解为知识和指令的混合体，类比于AI 1.0的判别模型，提示词相当于特征输入，因此AI2.0将特征工程（feature enginering）晋级为提示词工程（prompt enginnering），特征工程决定了模型的上限，从这个角度侧面可见用好提示词的重要性。prompt可以给大模型直接表达需求（zero-shot），也可以给它示例（few-shot）解释需求，也可以一步步教它思考（chain of thought）一起完成需求，还可以给它一些背景信息（context），帮助它理解问题和回顾历史。因此，prompt有很好的灵活性和透明性，能够轻量级地完成一些看似神奇的工作。但prompt也有它的约束，受限于大模型性能和成本考虑，prompt的大小有限，加之每次请求都需要携带大量信息来维持状态，在性能上也有一定缺陷。

那么，针对于这两个因素，我们分别可以做些什么干预模型呢？

1）针对于模型本身的优化为：fine-tune

图@jerryjliu0

对于fine-tune来讲，影响的是模型的权重。

2）针对于输入的优化为：in-context learning，即prompt learning

图@jerryjliu0

两者比较：

可以看出，提示词具有相当大的应用优势，具备很明显的成本和灵活性优势，使用门槛也比较低，随着token数量的不断增长及prompt压缩方案的提出，prompt层面的工作将是工程化方案的最重要的内容。

工程改进：

如上面分析，目前提示词中需要包含需求，背景，例子，历史等很多内容，就拿常见的检索场景，如何让大模型在海量的文章里总结回答，这不仅受限token的大小，还会导致响应的时间过长，不能满足用户的需要，那么在不能提高token数量，及提升大模型推理的条件下，如何解决这一问题呢？

图@jerryjliu0

那就是对于prompt进行压缩提炼，一个常见做法是外部引入一个检索流程，增加一步粗筛召回的逻辑，减少候选范围，便能明显缓解这一问题。而这一过程，还有一个明显的好处，给了大模型一个发挥的范围，使得大模型能够在更可靠的知识内容基础上总结推理，一定程度上可以避免模型黑盒条件下的自说自话，提高了输出的可信度。另一方面，对于提升模型返回角度考虑，增加检索流程，可以对提示词进行检索增强（retrieval augmentation），比如对接知识图谱，业务知识库等，能够提高输出的质量。

检索方式选择向量检索的原因

目前业内主流做法是采用向量检索的方式来做检索增强。很多同学有疑问为什么要用向量数据库，原来传统的ElasticSearch这样的文本检索的方案是否可以？

实际上，结合上面的分析来看，也不是不可以，本质上是大模型外围需要一个检索和存储的组件来完成检索过程，只要能满足这样的要求，均可以采纳。那么为什么大家不约而同选择了向量检索？

这样的选择本质上是为了获得更好的检索效果，提高相关性。万物皆可embedding，通过embedding可以将一个维度的问题映射到另外一个维度，在新的维度里能够更准确的表达它们之间的关系。这一过程类似于我们曾经学习的信号处理的知识，将时域的信号通过傅立叶变换转到频域中处理，可以极大地减少复杂度。

从上图可以看到，向量搜索和普通搜索的差异，它基于内容embedding，在编码时就考虑到了内容的相关性，在检索时不必简单文本匹配，基于语义的检索，自然召回的效果更好。

从这个意义上讲，选择向量检索并不是大模型的要求，而是对召回效果不断提升加之向量检索性能取得不断提升的自然演进，因此，可以看出未来搜索服务面向语义检索发展也是必然趋势。

小结：

在实际的LLM开发中，也会先从简单入手，只有当简单无法完成需求时才会转而更复杂的方式去干预实现。

本节介绍了目前主流的检索增强的LLM应用的产生原因和基本实现思路，可以帮助构建整体宏观的概念，在下一节中，对LLM应用开发过程中涉及到的技术展开讨论。

包含:

1. embedding & tokenization

2. vectordb

3. fine-tune

4. prompt

5. deploy&inference

6. 编排集成

7. 预训练