两年前 ChatGPT 出现后，每个人都纷纷加入。每个公司董事会/首席执行官都会询问他们的技术领导者“我们在人工智能方面正在做什么？”

我认为最初有两条路。根据您的数据微调您自己的LLM。这并不能真正扩展。微调LLM需要很长时间，而且价格昂贵。如果您需要 LLM 的实时更新，则无法执行此操作。

接下来，人们研究了 RAG，它获取数据片段，为它们创建一个 LLM 嵌入向量，并将向量存储在向量数据库中，例如带有 pg 向量扩展的 PostGres 或向量数据库（例如 pinecone）。

一旦片段出现，我们就可以查找与我们的提示最“相似”的片段，将其修剪为 10 个项目，然后提供这 10 个片段作为扩展提示并尝试回答我们的问题。

然后，我们建立一个数据管道，以在底层片段发生变化时保持矢量数据库最新。可以接近实时嵌入实时片段。

在我看来，这很快就会变得非常复杂。简单地获取单个数据库记录并为其生成嵌入不会给出好的结果。您可能需要对数据“块”进行非规范化。

事实记录（实际记录）和关联维度数据（记录周围的上下文）的混合。例如，员工记录可能需要用雇主、HCM 记录（如工作历史记录等）进行扩充。

所有这些都将转换为文本并为其生成嵌入。

如果所有维度数据都是特定事实（员工、员工历史记录），那么这还不算太糟糕。但是，如果维度数据在事实记录之间共享，那么当维度记录发生更改时，更新使用它的每个事实记录文本将变得昂贵。

您可以对其进行批处理等，或者只是在事实记录发生变化时重新生成，但是您的嵌入向量相对于实时数据来说是“过时的”。

当数据确实基于片段（彼此独立）时，这种方法有效，但当您希望 LLM 概括它时，基于我自己的实验则不起作用。

例如，根据我自己的经验，将复杂文档转换为片段，然后使用 RAG 询问有关文档的问题，这并不能提供良好的体验。

让我们以使用 RAG 培养编程专家为例。

我拿一些有关编程的书籍，将它们分成 500 字节的片段，为每个片段创建一个嵌入向量，然后如果我可以有 8k 上下文，那么我会获取前 10 个片段（大约 5k 上下文）并将其添加到提示中。

如果您的问题始终针对某个主题，那么您可能会得到很好的结果。如果你的问题不是特定于片段的，那么这根本不会起作用。我也在航海中尝试过这一点。

我将 10 个关于航海的 PDF 分块，将每个块/片段转换为嵌入向量，并询问有关航海的问题，这非常糟糕。

新世界，无限内容长度

Claude 3 和 Gemini 1.5 现在支持非常大的上下文长度。内容长度是最大提示大小。这些是 2 年前开始的，价格为 2k-8k。现在，我们已经达到一百万或更多，而且该提示中任何地方的数据调用实际上都是完美的。

旧的 LLMS 忘记或错误地回忆了隐藏在提示中的事实，但现在似乎已经解决了。

所以，现在我们实时处于以下位置LLMs。像 Claude3 这样的现成的LLM。收集您需要的所有实时数据并将其转换为文本。提供类似“根据以下信息，回答这个问题“什么是……”，然后回答数据文本”的提示。

根据我自己的经验，LLM 将提供一个非常好的答案，无需矢量数据库。您可能正在运行数据管道来获取数据并将其转换为对象存储或文档数据库（DynamoDB 或类似数据库）中的文本。

然后，应用程序将相关数据文本与提示一起获取，我们就得到了实时的LLM。

既然如何使用 LLMs 有效地处理非常大的上下文的秘密已经揭晓，那么到 2024 年夏天，我们将不可避免地拥有具有类似上下文实现的开源 LLMs。这将为许多应用提供非常具有成本效益的解决方案。

拉格完结了？不，混合的未来

那么，RAG完结了吗？我不这么认为。我的猜测是，当不可能拥有完整的知识时，我们将拥有一个混合解决方案。您可以想象从这样的实时文本数据库中获取的“基础”数据的组合。

所有这些文本都插入到每个提示中，即我们的基线数据。基于动态 RAG 的选项，还添加了与提示类似的前 N 个文本片段。因此，提示将是提示+基础数据+RAG类似数据。

我自己的个人人工智能助理项目目前使用 LLM 与我的自传（70K 代币）以及从播客播放列表/脚本、网络历史记录、日历/电子邮件等生成的矢量数据。静态数据+动态数据集。

这意味着有 2 个数据管道。一种使文本形式的基础数据保持最新，另一种为数据库或类似数据存储中的记录生成嵌入/数据片段。

这可能是该领域应用的中短期未来。一种兼具两全其美的混合解决方案。