共计 2485 个字符，预计需要花费 7 分钟才能阅读完成。
【导读】LLM是当下AIGC中最火热的领域。受限于其深度学习模型本身的token最大长度，市面上当前可用的LLM产品接口几乎都无法直接处理长文档（例如，中长篇小说）。本文介绍了工程上使用Embeding技术，引入外部存储，解决这一问题的一般思路，希望可以带来一些启发。
一、什么是Embedding？
在正式介绍技术路线时，有必要简单介绍一下Embedding。Embedding是一种多维向量数组，由一系列数字组成，可以代表任何事物，如文本、音乐、视频等，在这里我们将重点关注文本部分。
任何一段文本可以通过大语言模型，将其编码到特殊的，含有文本语义的空间R中，成为一个多维向量(即,embedding)，如下图所示：
Embedding让我们可以进行语义搜索（通常语义相近的文本在空间），也就是通过文本的含义进行相似性检索。
二、为什么Embedding在AI中如此重要？
受限于GPT系列模型的底层机制（自注意力机制），其计算复杂度随着token个数的增长，将呈现平方级别的增长。因此目前主流的LLMapi都将token最大长度限制在十万内，截至发文前，google的claude模型最长支持10wtoken数。由于Token数的限制，使得LLM没办法天然地去处理一些长文本。
此时我们的Embedding技术就登场了！Embedding在AI中的重要性在于，它可以帮助我们解决LLM的tokens长度限制问题。通过使用Embedding，可以在LLM模型之外，引入外部缓存（embeding到文档的索引）。这样，我们在与LLM交互时，仅在上下文窗口中包含相关的文本内容，从而不会超过tokens的长度限制。
三、如何使用Embedding，使LLM支持更长的上下文
3.1 步骤描述
1.文档切分
2.建立子文档embedding与索引表
3.将LLM任务与子文档embedding做相似度匹配
4.基于LLM产出最终结果
3.2 举例来说
【书籍问答任务】
假设我们有一本讲述人类历史的书籍，我们希望从中提取关于某个重要历史人物的信息，但不想阅读整个文件，因此我们希望通过LLM应用来完成这一任务。主要可以分为文档构建与内容匹配两个流程：
>>文档构建
1.将PDF文件的文本内容成若干子块。
2.使用Embedding模型将每个子文本块转换为向量数组。
3.将这些向量数组存储在向量数据库中，同时保存向量数组与文本块之间的关系。
>>内容匹配
当我们需要回答关于该PDF文件的问题时，例如：“作者对xxx人物的看法是什么？”产生结果的逻辑如下：
1.使用Embedding模型将问题转换为向量数组。
2.使用相似性度量函数，（如，在chatGPT中，推荐余弦相似度）将问题向量与PDF文件的向量进行比较，找到语义上最相关的若干个文本块。
3.将找到的最相关文本块与问题一起输入到LLM（如GPT-3）中，得到准确的回答。
3.3 小节
通过上面描述的基本流水线以及案例，我们可以将Embedding与LLM结合，实现特定的长文本任务。目前比较火的类chatPDF、以及文档问答产品都采用了与上述例子中类似的技术。
从某个角度来看，使用embedding为LLM建立外部的存储映射，像极了在计算机诞生之初，人们因为昂贵的内存与处理器资源，对代码进行了各种优化而做的妥协。随着硬件的发展，此类特定的工程优化也会逐渐成为时代的眼泪。
四、业界产品
4.1SupBase
开源fireBase解决方案商SupBase二月份时就推出了一款基于chatGPTAPI的，支持问答的文档系统
博客中也对这个文档系统的技术路径进行了相应的描述：
4.2 Langchain
LangChain是一个用于开发由LLM驱动的应用程序的框架。其主要特性为「将LLM模型与外部数据源进行连接」「允许与LLM模型进行交互」，已经在GitHub获得38KStar。
Langchain给出的诸多用例中自然也包括了“文档问答“，在官方给出的最佳实践中，也给出了与本文中描述类似的pipeline。
在Ingestion中，主要是构建原始文档的embeding索引与知识库，而后在generation的过程中通过与LLMapi的能力整合，最终输出符合用户要求的答案。
4.3 AnthropicClaude
实际上Claude的产品与本文提到的技术路径本身没有太大关系。之所以要提，是因为，claude在5月11日时宣布，支持最大100k的token数（相当于7.5万个字符），这意味着大部分页数在200页左右的电子文档可以直接被LLM的API处理（当然一些客户端上可能对输入的长度做了一些限制，需要使用合适的prompt才能解除封印）。
并且许多已经拿到使用资格的用户反馈，相比基于向量检索的方式及，其准确性要提高非常多。对比当前综合性能最好的GPT-4，最大支持的token数为3.2K，Claude无疑在泛用性这一赛道上又占据了上风。
总而言之，Claude在金主爸爸google的支持下，可以说是以一种非常暴力的方式，重新定义了中、短文档的LLM应用的技术逻辑。
这就好比，底层的基础设施足够强了，上层应用的开发者自然就不需要关心怎么使产品可用了。（钱到位就行）这应该也是LLM云厂商们提供的最有竞争力的解法，后继几个主要的LLMAPI提供商估计都会在这个特性上卷起来。
4.4 小节
从长远来看，未来最终的解决方案一定是云厂商在基础设施层逐步解决token数的限制，而上层应用的开发者不必去关心由于token长度限制而带来的复杂性。
当然，目前主流的，使用embedding，引入中间记忆存储的方式，在特定的时代背景下，也不失为一种优雅的工程解法。
