作者使用DALL-E制作，过程中有一些信息损失现象。
当我们把企业AI系统投入生产时，不应期待它们像搜索引擎那样的系统运行。是的，AI系统常常感觉像拥有与非向量文档数据库或搜索引擎相似的搜索功能，但内部工作方式却大不相同。如果我们试图将一个由向量存储和大规模语言模型（LLM）组成的AI系统当作数据结构化且查询结果精准来使用，可能会出现一些令人惊讶和失望的结果。
AI系统通常不会“记住”数据本身的内容。即使是保留主要文档集完整文本的RAG系统，也使用向量检索进行检索，这一过程虽然强大但并不完美且不够精确。几乎所有AI系统都会丢失一部分信息。
当然，这又引出了一个问题：我们该如何应对这种信息损失？简单来说，我们应该识别哪些使用场景能从保存特定类型的信息中受益，并有针对性地保存这些信息，尽可能做到这一点。通常，这意味着将确定性和结构化的非人工智能软件流程整合到我们的系统中，以确保在需要时保持结构和精确性。
在这篇文章里，我们讨论了问题的复杂性以及一些应对策略。有许多方法可以解决特定问题，例如建立知识图谱来构建主题和概念，将关键词搜索作为功能集成到向量数据库中，或者根据具体场景调整数据切分和加载。除此之外，正如我们在下文讨论的那样，将结构叠加到无结构文档的向量数据库中最灵活且易于访问的方法之一是通过结构化的元数据来导航知识库。文档链接和标签的向量图谱可以是一种强大、轻便、高效且易于实现的方法，以将有用的结构重新注入无结构化的数据中。
大多数AI系统结构松散，不太精确，并且带有模糊性。在围绕大量非结构化数据构建的系统中，信息丢失是无法避免的。诊断信息丢失在您的具体应用场景中的位置、方式和原因可以是一个有助于改进系统和提升应用性能的有益尝试。
在讨论人工智能系统中的信息保存和丢失时，需要注意的三个重要点是：
- 向量嵌入无法完全保留原始文本的所有信息。
- 大语言模型是非确定性的，这意味着文本生成包含一些随机性。
- 很难预测哪些信息会被保留，哪些会被丢失。
在文档进入向量存储的过程中，会丢失一些信息；在通过LLM检索的过程中，一些信息会被随机化和不准确；第三个情况是，我们可能不知道什么时候会遇到问题，也不知道问题的严重性。
以下，我们更深入地探讨上述第一点：向量嵌入本身是有损的。我们来探讨一下，这种嵌入损失通常是无法避免的，这种损失如何影响我们的应用，以及如何——与其试图通过大语言模型来恢复或避免这种损失——保持对信息丢失过程的认识，并在我们的AI系统中增加结构化的信息层次，以适应我们特定的应用需求，并建立在我们现有向量嵌入驱动的AI系统的强大功能之上。
接下来，我们更深入地研究一下信息丢失在向量嵌入中是如何发生的。
向量嵌入会有信息损失文本的向量表示——也就是LLM使用的嵌入——虽然包含大量信息，但这些信息总是近似的。当然，可以构建一个确定性的LLM模型，其向量表示的是可以精确生成的文本，在相同的初始向量下能够一模一样的重复生成。但是，这会非常受限且实用性不高。为了让LLM及其向量嵌入在我们今天使用的方式中发挥作用，嵌入过程需要捕捉语言细微之处，而不仅仅是精准的词汇。我们希望LLM能够理解，两个句子如果说的是同一件事，就代表相同的概念。例如，“我喜欢人工智能”和“AI很棒”实际上表达的是差不多的意思，向量和嵌入的主要作用是捕捉这样的信息，而不是单纯记忆词汇。
向量嵌入具备高维和精确的特点，将复杂的概念封装在一个巨大的概念空间里。这些维度的数量可以达到数百甚至数千，每个维度细微地编码了语言的不同方面——从语法和意义到语境和情感。这种高维度使得模型能够在广泛的概念范围内导航和表示，从而能够掌握文本中嵌入的复杂和抽象的概念。
尽管这些嵌入很精确，但从给定的向量生成文本仍然不是一个确定的过程。这主要是因为生成文本的模型具有概率性质。当LLM生成文本时，它基于向量中的信息计算序列中每个可能后续词的概率。这一过程包含了一定的随机性和上下文理解，这意味着即使使用相同的起始向量，每次生成的文本也可能不同。这种变化对于生成自然且适应各种上下文的语言至关重要，这也意味着文本的确切再现可能无法实现。
虽然向量能够捕捉文本意义的核心，但在向量嵌入过程中，具体的词汇和信息常常会丢失。这是因为嵌入是为了从文本中泛化，捕捉的是文本的整体意义而不是具体的措辞。因此，文本中的细节或不太突出的主题可能不会在向量空间中得到充分的表示。这种特性使得从大量文本中检索特定信息变得较为困难，由于系统更倾向于整体语义的相似性而不是精确的词汇匹配。
我们最常遇到的信息丢失问题有两种常见原因：
- 文本中的边缘细节在整体语义中被“忽略”或“埋没”。
- 具体关键词或短语的意义在嵌入到语义模型中的过程中被“丢失”。
这些情况中的第一种是因为嵌入效果不佳而导致文档（或片段）中实际存在的细节“丢失”。第二种情况主要涉及信息的具体措辞被丢失，而不仅仅是实际细节的丢失。当然，这两种类型的丢失各自都有可能带来严重且令人担忧的问题。
这篇文章通过测试几种流行的嵌入算法在较小文本片段中的搜索和检索效果，提供了许多有趣示例，展示了嵌入如何丢失或忽略细节。
接下来，让我们来看一些这两种损失类型是如何工作的实际例子，通过代码和数据进行展示。
AI产品页案例在这个案例研究中，我为一家名为Phrase AI的虚构公司的网站创建了一个产品页面的数据集。Phrase AI 构建大型语言模型并将其作为服务提供。它的前三款产品分别是Phrase Flow、Phrase Forge 和 Phrase Factory。Phrase Flow 是公司的旗舰产品，适用于通用场景，但在吸引和创造性的内容方面特别出色。其他两款产品是有各自优势和劣势的专业化大型语言模型。
该HTML文档数据集包含一个主首页phrase.ai（虚构的网站），每个LLM（共三个）一个产品页面，以及网站上的四个其他页面：公司宗旨，正在进行的工作，开始使用，和应用场景。非产品页面则主要围绕旗舰产品Phrase Flow，而每个产品页面则侧重于相应的LLM产品。文档中的大部分文本是标准的网页文案，由ChatGPT生成，但有一些特性对我们的研究来说非常重要。
最重要的的是，每个产品页面都包含关于旗舰产品Phrase Flow的重要信息。具体来说，每个专门的LLM产品页面都包含一个警告，不要将Phrase Flow模型用于特定目的。在Phrase Forge的产品页面底部包含以下文本：
特别擅长：
Phrase Forge 特别擅长创建完整的目录，相比之下，通用模型如 Phrase Flow 并不擅长这项工作。因此，不要用 Phrase Flow 来做目录。
并且，短语工厂的产品页面底部有如下文字：
特别擅长：Phrase Factory 在事实检验和防止错误生成方面更合适，远胜于像 Phrase Flow 这样更富有创造性的模型。对于需要准确性的文档，不要使用 Phrase Flow。当然，Phrase AI或许也应该在其Phrase Flow页面上加上这些警告，而不仅限于其他两个产品的页面。但是，我想我们都遇到过网站或文档中关键信息出现在不恰当位置的情况。我们仍然希望我们的RAG系统即使在文档集中某些信息位置不太理想时也能良好运行。
虽然这个数据集是编造的且规模很小，但我们设计它是为了清楚地展示在实际案例中可能相当常见的问题，这些问题在更大的数据集上诊断起来可能会比较棘手。接下来，我们再仔细看看这些问题。
次要的信息可能会在语境中被忽略。向量嵌入会丢失信息，正如我之前提到的，很难预测哪些信息会丢失。所有信息都可能丢失，但一些信息比其他信息更可能丢失。直接与文档主题相关的细节通常更有可能被捕获在嵌入中，而偏离主题的细节更可能丢失或难以通过向量搜索找到。
在上述案例中，我们提到了关于Phrase Flow产品在其他两个型号的产品页面上的两条重要信息。这两条警告非常强烈，用的是“不要使用Phrase Flow来……”，可能对于了解Phrase Flow模型的能力非常重要。但是，这些警告出现在不太直接涉及Phrase Flow的文档中，所以对于这些文件来说，它们更像是“边缘”信息。
为了看看一个典型的RAG系统如何处理这些文档，我们用LangChain的GraphVectorStore（知识图谱向量存储）和OpenAI API打造了一个RAG管道。代码在这个Colab笔记本里。
我们可以查询系统，了解Phrase Flow的不足之处，得到以下结果：
问题：
Phrase Flow有哪些弱点？
检索到的文档包括：
['https://phrase.ai/products/phraseflow',
'https://phrase.ai/usecases',
'https://phrase.ai/ongoingwork',
'https://phrase.ai/purpose']
LLM的回复：
提供的信息中没有提到Phrase Flow的任何具体弱点。注意，我们设置检索器获取前四份文档，这占总文档的一半。包含Phrase Flow警告的两个产品页面未出现在这些结果中，因此LLM的响应中没有任何关于Phrase Flow弱点的上下文。我们对其他措辞和其他询问“问题”或“问题”的查询也得到了类似的结果。更多示例请参阅笔记本。
如果我们不限制检索器只检索四个文档，我们将得到如下结果，包括所有八个文档的检索排序：
问题：
Phrase Flow 的一些弱点是什么？
获取的文档：
['https://phrase.ai/products/phraseflow',
'https://phrase.ai/usecases',
'https://phrase.ai/ongoingwork',
'https://phrase.ai/purpose',
'https://phrase.ai/gettingstarted',
'https://phrase.ai/products/phraseforge',
'https://phrase.ai/products/phrasefactory',
'https://phrase.ai']
大型语言模型响应：
Phrase Flow 不适合用来创建目录或需要高度准确性的文档。它可能不擅长生成详细、结构化的技术指南、报告或研究论文，因为这些任务更适合使用 Phrase Forge 来完成。此外，Phrase Flow 可能不是快速回答问题或实时检索信息的最佳工具，因为 Phrase Factory 特别为此类需求设计而成。值得注意的是，Phrase Forge 和 Phrase Factory 的产品页——这两个带有 Phrase Flow 警告的页面，在搜索结果中分别排在第六和第七位。大致来说，这两个警告不太容易被发现，因为它们已经被“隐藏”在主要捕获每页相关主题信息的向量嵌入中：或者是关于 Phrase Forge，或者是关于 Phrase Factory。
不过，如果我们重新表述查询，使查询的措辞更接近警告的措辞，“不要使用‘Phrase Flow’……”，就能得到我们期望的结果。
问题：
我在什么情况下不要使用Phrase Flow？
找到的相关文档：
['https://phrase.ai/products/phraseflow',
'https://phrase.ai/products/phraseforge',
'https://phrase.ai/products/phrasefactory',
'https://phrase.ai/usecases']
LLM 回答：
对于需要事实性内容创建的文档，例如技术指南、研究论文、白皮书或任何需要精确语言和详细结构的文本，不要使用Phrase Flow。对于这些类型的文档，使用Phrase Forge会更合适。此外，Phrase Flow 不适合用于创建目录。在这里，检索似乎对查询的具体措辞非常敏感，而短语“不使用Phrase Flow”提示我们更接近我们需要的那些文档，在语义空间里。但是，我们事先并不知道这一点，也不知道我们在找什么，我们依赖于我们的RAG栈来帮助找到它。
下面我们将讨论一些可能的解决方案，以解决由于损失性的语义向量而导致的这种类型的信息被埋藏的问题。但首先，让我们看看损失性向量如何在检索增强生成系统中引发另一种令人意外的现象。
向量检索并不是像搜索引擎那样的关键词搜索。向量检索不仅限于搜索引擎或关键词搜索。向量检索是专业术语，初次使用时可以简要解释。许多用户期望AI和RAG系统（检索增强生成系统）能够精确匹配名称、关键词和短语。我们已经习惯了用传统的搜索引擎，有一种明确的感觉认为AI如此强大，为什么不能找到我们想要的精准匹配呢？
如前所述，向量搜索与搜索引擎、文本搜索以及其他传统的数据查询方法有着根本的不同——所有这些方法都是基于精确匹配的搜索算法，仅具有有限的模糊搜索功能。虽然向量搜索可能会找到特定的单词和短语，但并不能保证。因为向量位于语义空间内，而将文本转换为向量的过程会有信息损失。
以下内容可能导致信息丢失，因为其中的词汇和短语的语义模糊。我们在研究的数据集中包含了一些这样的例子。具体来说，比如以下文本出现在我们虚构的公司名为Phrase AI的正在进行的工作部分的末尾：
即将上市：我们的最新型号 Flow Factory、Flow Forge 和 Factory Forge 已进入测试版阶段，并即将发布！这是数据集中唯一提及这些即将推出的模型的地方。不仅“Flow Factory”、“Flow Forge”和“Factory Forge”是这些名称在产品线中的令人混淆的组合，而且它们也是字典单词的简单组合。“Flow Factory”为例，它不仅是一个产品名称，还结合了“flow”和“factory”这两个词的常见含义，使其具有额外的语义。相比之下，像“FloFaktoree”这样的专有名称，几乎没有实际意义，可能会被AI系统以完全不同的方式处理——并且可能更容易被发现，因为它不会与其他任何术语混淆。
如果我们具体搜索或询问“Flow Forge”或“Factory Forge”，我们就能找到类似的结果：
问题：
什么是Flow Forge？
检索到的文档：
['https://phrase.ai/products/phraseforge',
'https://phrase.ai/usecases',
'https://phrase.ai/ongoingwork',
'https://phrase.ai/products/phraseflow']
LLM 回答：
Flow Forge 是一个新的专业化模型，目前处于测试版，并即将推出。所以系统成功检索到包含“Flow Forge”引用的唯一文档——关于“正在进行的工作”的那一页，但它却是排名第三的检索文档。但在语义空间中，有两份文档似乎更相关，尽管它们根本没提到“Flow Forge”。在大型数据集中，很容易想象到名称、术语、关键词和短语等会在难以诊断的方式中被埋没或“丢失”。
关于损失向量我们该怎么办？我们一直把“lossy”向量当作问题来讨论。确实，“lossy”向量带来了一些问题，但向量检索和AI系统依赖于将文档从文本转换为语义空间的向量嵌入过程，这个过程确实会丢失一些文本信息，但同时也带来了语义搜索的强大功能。“lossy”向量更像是一种特性而非缺陷。即使“lossy”向量不是缺陷，了解它们的优势、劣势和限制也有助于我们更好地掌握它们的功能，以及在什么情况下它们可能会表现出令人意想不到的行为。
如果上述任何问题与您的AI系统相符，您的AI系统中存在的问题与其描述相符，问题的根本原因不是向量搜索表现不佳。您可以尝试寻找更适合您的替代嵌入方式，但这通常是一个复杂且不透明的过程，通常有更好的简单解决办法。
根本原因是我们经常让向量搜索去做它原本不是为这些任务设计的事情。解决办法就是在你的技术堆栈中构建特定功能需求，在向量搜索的基础上，添加满足你具体需求的功能。
交替的分块和嵌入方法在处理文档分块以加载和使用嵌入方法时，有许多选择。我们可以通过选择合适的方法来减少嵌入过程中的信息损失，这些方法与我们的数据集和应用场景相匹配。这里有一些这样的选择。
优化的分块策略： 分块策略规定了文本如何被分割成片段进行处理和检索。优化分块不仅仅是基于大小或边界，还包括根据内容中的主题元素或逻辑划分来分割文本。这种方法确保每个片段代表一个完整的思想或主题，从而使嵌入更加连贯，并提高RAG系统的检索精度。
多向量嵌入技术 — 传统嵌入技术通常将一段文本简化为单一的向量表示，这可能无法全面捕捉文本的多面性。多向量嵌入技术通过使用模型从一段文本生成多个嵌入向量，每个向量对应不同的解释或问题，从而解决这一局限。这种方法增强了数据表示的维度丰富性，使数据更精细，从而在处理不同类型的查询时可以进行更精确的检索。
ColBERT：词级别嵌入技术 — ColBERT（BERT 上的上下文化晚期互动） 是一种嵌入实践，在这种精细的方法中，每个文本中的每个词都被分配有自己的嵌入。这种精细的方法允许每个词 — 特别是那些重要或独特的关键词 — 在检索中发挥更大的影响力，同时反映了关键词搜索的准确性，并利用现代 BERT 模型的上下文理解。尽管它计算需求较高，ColBERT 可以通过保留关键术语在嵌入中的重要性来提供更优的检索性能。这反映了关键词搜索的准确性。
Multi-Head RAG方法—— 借助变压器架构的能力，Multi-Head RAG 利用变压器的多个注意力头为每个查询或片段生成多个嵌入。每个头可以强调文本的不同特征或方面，从而产生一组多样化的嵌入，捕捉信息的不同维度。这种方法通过提供更丰富的语义线索，增强了系统处理复杂查询的能力，使模型在生成回复时有更多的选择余地。
给您的AI架构添加结构向量搜索和AI系统非常适合非结构化的知识和数据，但大多数应用场景可能从AI架构中的某些结构中获益更多。
一个非常清楚的例子是：如果你的使用场景和用户依赖关键词搜索和精确文本匹配的话，那么最好整合一个具有文本搜索功能的文档存储库。通常来说，整合传统的文本搜索比尝试让向量存储充当可靠的文本搜索工具更便宜、更稳健且更容易集成。
知识图谱也是一种很好的方法，可以将结构融入你的AI堆栈。如果你已经有了或者能够构建一个符合你的使用需求的高质量图谱，那么开发一些图谱功能，例如图谱RAG，可以提高你AI系统的整体效用。
在许多情况下，我们的原始数据集可能具有内在的结构，而我们没有在向量搜索中充分利用这些内在结构。在数据加载到向量存储库之前的预处理过程中，几乎所有文档的结构都会被剥离。HTML、PDF、Markdown和其他大多数文档类型都包含可以被利用来使我们的AI系统更加高效和可靠的结构元素。接下来，我们来看看这如何实现。
基于文档链接和标签增添一层结构回到上面的案例研究，我们可以利用HTML文档的结构使我们的向量搜索和RAG系统更强大更可靠。特别是，我们可以使用HTML文档中的超链接将相关实体和概念连接起来，以确保我们通过所有相关文档获取全面的理解。点击这里阅读更多以了解图形RAG中的文档链接。
需要特别注意的是，在我们的文档集中，所有产品名称都链接到产品页面。每次在页面中提到这三个产品中的任何一个时，产品名称都会链接到对应的产品页面。这些产品页面之间也相互链接。
我们可以利用这种链接结构通过向量图的遍历和 LangChain 中的 GraphVectorStore 实现。
此实现使我们能够根据文档之间的超链接轻松构建知识图，然后遍历此图以获取与给定文档直接链接的文档。实际上（并在幕后），我们首先通过向量搜索执行标准文档检索，然后我们遍历检索到的文档中的链接以获取更多连接的文档，无论它们是否在向量搜索中被视为相关。通过此实现，检索不仅获取了最语义相关的文档集合，还获取了直接链接的文档，这些文档可以为查询提供有价值的支持。
重新配置检索过程，从我们用例中的每次从每个文档开始，遍历链接图一步（depth=1），我们得到以下来自原始查询的结果。
问题：
Phrase Flow的弱点是什么？
检索到的文档：
['https://phrase.ai/products/phraseflow',
'https://phrase.ai/ongoingwork',
'https://phrase.ai/usecases',
'https://phrase.ai/purpose',
'https://phrase.ai/products/phrasefactory',
'https://phrase.ai/products/phraseforge']
LLM 回答：
Phrase Flow 不适合需要事实或完整目录表的文档。此外，对于需要较多思考或结构化的任务，它可能不是最佳选择，因为它更侧重于使语言生动流畅，而不是详细和条理分明。我们可以看到，在这个输出中，虽然我们仍然设置初始检索返回k=4个文档通过向量搜索，另外还检索到了这两个文档。这两份文档补充了原先查询结果中缺失的关键信息，即在仅使用向量搜索而未结合图谱时缺失的关于Phrase Flow的警告信息。包含这两份文档后，检索结果中包含了关于Phrase Flow的两个警告，LLM可以据此提供一个恰当的答案。
在这个使用向量图的RAG系统中，向量可能是有损压缩的，但超链接和由此产生的图边不是。它们提供了文档间的坚实且有意义的连接，可以用来以可靠和确定的方式丰富检索到的文档集，这可以作为解决这一问题的良方，对抗AI系统的有损和无结构性质。随着AI继续改变我们处理无结构数据的方式，我们的软件和数据堆栈继续从利用我们找到的结构中获益，特别是当这些结构是为适应我们当前的需求而设计时。
总结：我们都知道，向量嵌入在很多方面都会丢失信息。选择一个与您的数据集和使用场景相匹配的嵌入方案可以改善结果并减少信息丢失带来的负面影响，但还有其他有用的途径。
向量图可以利用文档数据集中的内在结构。从某种意义上讲，这就像让数据构建内在的知识图，将相关文本块相互连接起来——例如，通过文档中的超链接和其他引用来发现相关且相关的文档。
你可以自己尝试使用 这个 Colab 笔记本 中的代码进行链接和矢量图的操作。或者，如果你想更多了解文档链接，可以参考我的之前的文章 或者查看关于 通过消除边来扩展知识图 的更详细技术说明。
Brian Godsey, Ph.D. (LinkedIn )，一位数学家、数据科学家和工程师， 在DataStax 工作，专注于AI产品，著有_ Think Like a Data Scientist_
P.S. 好玩一下，这里还有几个为这篇文章生成封面图片的有趣尝试。😎
作者用DALL-E生成的。
这是作者用DALL-E生成的。