生成式语言模型工作流中检索的沉痛教训 - Mikko Lehtimäki | 向量空间讲座
Demetrios Brinkmann
·2024 年 1 月 29 日
“如果你还没听过“沉痛教训”，它实际上是一个定理。它基于 Ricard Sutton 的一篇博文，其基本观点是，根据我们在过去几十年机器学习和人工智能系统发展中汲取的经验教训，那些能够利用数据和计算的方法，往往或最终会超越那些由人类设计或手工打造的方法。”
—— Mikko Lehtimäki
Mikko Lehtimäki 博士是一位数据科学家、研究员和软件工程师。他交付了一系列数据驱动的解决方案，从循环经济中用于机器人的机器视觉，到新闻业中的生成式 AI。Mikko 是 Softlandia 的联合创始人，这是一家创新的 AI 解决方案提供商。在该公司，他领导 YOKOTAI 的开发，这是一个基于 LLM 的效率助推器，可以连接到企业数据。
最近，Mikko 为 Llama-index 和 Guardrails-AI 这两个 LLM 领域领先的开源项目贡献了软件。他在计算神经科学和机器学习的交叉领域完成了博士学位，这为他提供了设计和实现 AI 系统的独特视角。在 Softlandia，Mikko 还主持轻松的混合形式数据科学聚会，欢迎所有人参加。
您可以在 Spotify、Apple Podcast、Podcast addicts、Castbox 上收听本集。您也可以在 YouTube 上观看本集。
主要收获
您不好奇“沉痛教训”是什么以及它在生成式语言模型工作流中如何体现吗？
来看看 Mikko 如何深入探讨检索增强生成的复杂世界，讨论 Yokot AI 如何管理大量多样化的数据输入，以及如何通过专注于重排序大幅提升 LLM 工作流和输出质量。
从本集中您将获得的 5 个关键收获
- Yokot AI 的发展： Mikko 详细解读了 Softlandia 的内部技术栈如何改变语言模型应用的现状。
- 解读检索增强生成： 了解 Yokot AI 的 LLM 如何通过上传文档和抓取网页来获取宝贵洞察的背后技术。
- “沉痛教训”理论： 深入探讨这个正在动摇 AI 基础的定理，它表明数据和计算的优越性胜过人类设计。
- 高质量内容生成： 了解该系统如何处理海量数据输入，从而将内容质量提升到极高的水平。
- 通过重排序实现未来保障： 了解为何改进重排序组件可能类似于在我们的 AI 领域中发现一个新宇宙。
趣味事实：Yokot AI 整合了检索增强生成机制，以方便检索相关信息，这使得用户可以上传和利用自己的文档或从网络上抓取数据。
节目笔记
00:00 关于语言模型检索和 Yokot AI 平台的讨论。
06:24 各种语言的数据灵活性促进发展。
10:45 用户输入文档，系统转换为向量。
13:40 提升数据质量，减少重复，简化处理。
19:20 通过专注于重排序器来降低复杂性。
21:13 检索过程提升语言模型效率。
24:25 信息检索方法演进，利用数据、计算。
28:11 在本地硬件上实现快速运行是最佳的。
Mikko 的更多引言
“我们过去常常基于手动设计的这类特征来构建图像分析……而现在，我们只需将大量图像馈送给 Transformer，就能获得漂亮的边界框和语义分割输出，而无需在系统中构建规则。”
—— Mikko Lehtimäki
“我们不能简单地忽视它，并希望未来很快就能出现一个不需要我们以如此复杂的方式为其抓取数据的语言模型。重排序器是一个可以高效利用数据和计算的组件，并且它也不需要太多手动工艺。”
—— Mikko Lehtimäki
“我们可以增强我们存储的数据，例如，通过使用多种分块策略或从用户的文档中生成问答对，然后我们将这些内容嵌入并用于处理查询。”
—— Mikko Lehtimäki 关于提升 RAG 技术栈中数据质量的观点
文字记录
Demetrios：大家好吗？很高兴和大家一起参加又一次向量空间讲座。今天我很荣幸邀请到 Mikko，他是 Softlandia 的联合创始人，也是首席数据科学家。在他的职业生涯中，他做过各种出色的软件工程和数据科学工作，目前他领导着 Yokot AI 的开发，我刚刚学会了它的发音，他将为大家详细介绍。我先来总结一下：它是一个基于 LLM 的效率助推器，可以连接到您的数据。Mikko，你好吗，兄弟？
Mikko Lehtimäki：嘿，谢谢。很高兴来到这里。是的。
Demetrios：所以，我必须说，虽然我在录制前或直播前说过，但我还是要再说一遍。这个演讲标题非常到位。您的演讲标题是：生成式语言模型工作流中检索的沉痛教训。
Mikko Lehtimäki：没错。
Demetrios：所以我猜您一定经历了很多困难，希望您能和我们分享，这样我们就不必犯同样的错误了。我们可以在自己犯错之前就变得聪明，从您的错误中学习，对吧？好的。这是一个很好的开场，您可以开始了，哥们。我知道您有话要讲，我知道您有一些幻灯片要分享，请随时将它们显示在屏幕上。各位正在观看的朋友，请随时在聊天中提出问题。我会监控聊天，这样如果您有任何问题，我就可以介入，确保 Mikko 在继续下一张幻灯片之前回答它们。好的，Mikko，我看到您的屏幕了，兄弟。
Demetrios：这很不错。
Mikko Lehtimäki：好的。那我们开始吧？好的。我叫 Mikko，是 Softlandia 的首席数据科学家。我去年夏天完成了博士学位，至今已在 Softlandia 工作两年了。我还是 Llama index 和 Guardrails AI 等一些开源 AI LLM 库的贡献者。所以如果您从未看过它们，请务必去看看。在 Softlandia，我们主要是一家专注于端到端 AI 解决方案的 AI 咨询公司，但我们也开发了自己的用于大型语言模型应用的内部技术栈，这就是我今天将要讨论的内容。
Mikko Lehtimäki：所以这次演讲的主题可能有点引人深思。也许是关于大型语言模型检索的一个沉痛教训，它确实源于我们在构建可投入生产的检索增强生成解决方案中的经验。我只想说，这并不是一场讲座，我不会告诉您该做什么不该做什么。我只是想带您了解我们在开发 RAG 解决方案时所适应的思维过程，看看是否能引起您的共鸣。我们的 LLM 解决方案叫做 Yokot AI。它实际上是一个平台，企业可以在上面上传自己的文档，并从中获得基于语言模型的洞察。典型的例子是文档问答，但我们做得更多。例如，用户可以利用自己的数据生成长篇文档，而无需担心在使用 LLM 输出内容时通常遇到的 token 限制。
Mikko Lehtimäki：这里您看到的是我们构建的数据管理视图的一个截图。用户可以导入自己的文档或抓取网页数据，然后立即使用 LLMs 访问这些数据。这是文档生成输出。它比您通常看到的要长，并且每个部分都可以基于不同的数据源。我们有不同的生成流程，我们称之为生成流，因此您可以使用 LLMs 修改文档的风格。当然，还有典型的聊天视图，它实际上是执行这些工作流的入口点。当您从数据中提问时，您可以看到语言模型使用的来源。而这一切都得益于检索增强生成。
Mikko Lehtimäki：这都是在幕后发生的。所以当我们要求 LLM 执行一个任务时，我们首先从上传的数据中获取信息，然后一切都由此展开。我们会决定获取哪些数据，如何使用，如何生成输出，以及如何将其呈现给用户，以便他们可以继续与数据互动或将其导出为所需的格式等等。但这类系统的主要挑战在于它非常开放。我们对用户可以上传什么类型的数据或数据是什么语言没有设置限制。例如，我们公司位于芬兰。我们的大多数客户都在北欧地区。他们讲芬兰语、瑞典语。
Mikko Lehtimäki：他们的大部分数据都是英文的，为什么不呢？他们可以随心所欲地使用系统。所以我们不想限制任何这方面的事情。另一件事是聊天视图作为界面，它确实没有设置太多限制。所以用户可以自由地使用系统选择他们想做的任务。因此，我们要准备应对的可能性非常广泛。这就是我们正在构建的东西。现在，如果您没听说过“沉痛教训”，它实际上是一个定理。它基于 Ricard Sutton 的一篇博文，其基本观点是，根据我们在过去几十年机器学习和人工智能系统发展中汲取的经验教训，那些能够利用数据和计算的方法，往往或最终会超越那些由人类设计或手工打造的方法。
Mikko Lehtimäki：举个例子，我在这里有一个图示展示了这一点是如何体现在图像分析中的。左侧显示的是从图像中提取梯度的操作输出。我们过去常常基于手动设计的这类特征来构建图像分析。我们会进行边缘提取、计数角点、计算边缘距离，并手工设计特征来处理图像数据。而现在，我们只需将大量图像馈送给 Transformer，就能获得漂亮的边界框和语义分割输出，而无需在系统中构建规则。这是“沉痛教训”的一个主要应用示例。现在，如果我们将这一点放在 RAG 或检索增强生成的背景下，我们首先来看看简单的 RAG 架构。我们为什么首先要做这件事呢？原因在于语言模型本身没有最新的数据，因为它们是在一段时间前训练的。
Mikko Lehtimäki：您甚至不知道是什么时候。所以我们需要让它们访问最新的数据，我们需要一种方法来做到这一点。另一件事是幻觉等问题。我们发现，如果您只是问模型一个训练数据中的问题，结果不总是可靠的。但如果您能用数据为模型的回答加冕（补充），您将获得更真实的结果。这也是 RAG 可以做到的。最后一点是，我们无法一次性将一本书给语言模型，因为即使理论上它可以一次性读取输入，如果您一次性输入太多数据，从语言模型获得的结果质量也会下降。这就是我们设计检索增强生成架构的原因。
Mikko Lehtimäki：如果我们看看底部的这个系统，您会看到典型的数据摄取过程。用户提供一个文档，我们将其切分成小块（chunks），并使用向量嵌入（vector embeddings）计算数值表示，然后将其存储在向量数据库（vector database）中。为什么使用向量数据库？因为它在接收到用户查询时，从其中检索向量非常高效。因此，查询也会被嵌入，并用于在数据库中高效地直接查找之前上传的数据中的相关来源，然后我们可以将结果文本输入到语言模型中，合成答案。这就是 RAG 最基本的工作方式。现在您可以看到，如果您只处理一个文档，如果想解决的问题集非常受限，那这样做是很好的，但您能为系统带来更多数据，就可以基于这些数据构建更多的工作流。例如，如果您能访问一整本书或多本书，显然您可以从这些数据生成更高质量的内容。所以这种架构必须能够利用更大量的数据。
Mikko Lehtimäki：总之，当您第一次实现这个系统时，感觉就像魔法一样。它通常工作得相当好，但很快您就会注意到它不适用于所有类型的任务。比如您有时会看到，例如，列表。如果您检索列表，它们可能会损坏。如果您询问文档比较的问题，结果可能不完整。如果您运行总结任务时不加思考，那么很可能会得到不理想的结果。所以我们需要对架构进行相当多的扩展，以考虑用户上传的更大批量数据所要实现的所有用例。而这可能就是经过几次设计迭代后的样子。
Mikko Lehtimäki：那么，我们可以在 RAG 技术栈中添加哪些步骤来提高结果质量呢？如果我们再次从底部开始看，可以看到我们尝试通过在数据摄取管道中添加步骤来提高上传数据的质量。我们可以增强我们存储的数据，例如，通过使用多种分块策略或从用户的文档中生成问答对，然后我们将这些内容嵌入并用于处理查询。同时，我们可以减少上传的数据量，确保没有重复。我们想清理低质量的内容，比如 HTML 残留物，并且可能还会添加一些元数据，以便某些数据（例如参考文献）可以在搜索结果中排除，如果它们对于我们想执行的任务不是必需的。顺便说一下，我们将其建模为一个流处理管道。我们正在使用 Bytewax，这是另一个非常好的开源框架。插播一个小广告，我们将在 2 月 16 日与 Bytewax 合作举办关于 RAG 的研讨会，请大家关注。在中心部分，我添加了不同的数据库和不同的检索方法。
Mikko Lehtimäki：例如，我们可以添加基于关键词的检索和元数据过滤器。好消息是，如果您愿意，可以使用 Qdrant 完成所有这些操作。因此，Qdrant 可以成为您文档数据的一站式解决方案。但有些用户可能希望尝试不同的数据库，比如图数据库或 NoSQL 数据库，以及普通的 SQL 数据库。它们确实可以实现不同类型的用例。所以哪个对您真正有用取决于您的服务。如果我们再往左看，我们有一个叫做查询规划器（query planner）和一些查询路由器（query routers）的组件。这真正决定了响应策略。
Mikko Lehtimäki：所以当您收到用户的查询时，例如，您可能需要采取不同的步骤来回答。例如，您可能希望将查询分解成可以单独回答的小问题，而每个小问题可能采取不同的路径。因此，您可能希望基于元数据进行查询，例如文档的第五页和第六页。或者您可能希望基于关键词查找包含特定词语的整页或块。这里真的有海量的选择。另一个例子是根据查询生成假设文档并将其嵌入，而不是嵌入查询本身。这在某些情况下会带来更高质量的检索结果。但现在，所有这些都引向了查询路径的右侧。
Mikko Lehtimäki：所以这里我们有一个重排序器（re-ranker）。如果我们实现所有这些，我们最终会检索到大量数据。通常我们检索到的数据量会超过一次调用中输入给语言模型更有意义的数量。因此，我们可以在这里添加一个重排序步骤，它首先会过滤掉低质量的检索内容，其次会将高质量的内容放在检索文档的顶部。现在，当您将这些重新排序后的内容传递给语言模型时，它应该能够更好地关注查询中真正重要的细节。这应该能让您更好地管理需要由最终响应生成器（LLM）处理的数据量。它还应该使响应生成器更快一些，因为您一次输入的数据会稍微少一些。构建重排序器最简单的方法可能是直接要求一个大型语言模型在将检索到的内容输入给语言模型之前进行重新排序或总结。
Mikko Lehtimäki：这是一种方法。所以是的，这非常复杂，老实说，我们目前在 Yokot AI 中也没有完全做到所有这些。我们在不同的范围尝试过所有这些，但这确实需要维护大量逻辑。对我来说，这简直就是“沉痛教训”的体现，因为我们在系统中构建了太多步骤、太多逻辑、太多规则，而所有这些仅仅是因为目前的语言模型不够可信，或者无法使用现有架构可靠地训练，或者无法使用现有方法进行实时训练。因此，在我看来，这张图中有一点比其他部分更有希望利用数据和计算，这应该会在长期主导解决方案的质量。如果我们只专注于这一点，或者说不是只专注于，而是大力专注于流程的这一部分，我们就应该能够消除其他地方的一些复杂性。所以如果您正在观看录播，可以暂停思考一下这个组件可能是什么。但在我看来，它是末端的重排序器。
Mikko Lehtimäki：为什么呢？当然，您可以争辩说语言模型本身就是一个，但鉴于我们目前的架构，我认为我们需要检索过程。我们不能简单地放弃它，并希望将来很快就会有一个语言模型，不需要我们以如此复杂的方式为其获取数据。重排序器是一个可以相当高效地利用数据和计算的组件，并且它也不需要太多手工工艺。它对样本进行处理并输出样本，并且与我们现在拥有的高效向量搜索（如 Qdrant 是一个典型例子）配合得非常好。向量搜索是初步的过滤步骤，然后重排序器是确保我们将尽可能高质量的数据提供给最终 LLM 的次要步骤。重排序器效率高，确实是因为它不必是一个成熟的生成式语言模型——虽然它通常是一个语言模型，但它不需要具备生成 GPT-4 级别内容的能力。它只需要理解，甚至可能以一种非常固定的方式，传达您提供给它的输入的重要性。
Mikko Lehtimäki：所以通常的输入是用户的查询和检索到的数据。就像我之前提到的，使用重排序器最简单的方法可能是要求大型语言模型对您检索到的块或句子进行重新排序。但也有专门为此训练的模型，Colbert 模型就是一个主要例子，我们还必须记住重排序器已经存在很长时间了。它们在传统的搜索引擎中已经使用了很久。我们现在只是对它们的要求更高一些，因为在重排序运行后，没有用户再检查搜索结果并决定哪些是相关的。我们需要相信重排序器的输出是高质量的，并且可以直接提供给语言模型。所以您也可以从文献中获得很多想法。但最简单的方法无疑是在一个简单的 API 后面使用 LLM。
Mikko Lehtimäki：这并不是说您应该忽略其他部分，比如查询规划器当然是一个有用的组件，不同的检索方法对于不同类型的用户查询仍然相关。所以，这就是我认为“沉痛教训”在这些 RAG 架构中体现的方式。我在这里收集了一些我认为最近或比较有趣的方法。但就像我说的，信息检索研究中有很多现有信息很可能在不久的将来被重新发现。所以如果我们总结一下我们正在亲身体验或已经体验到的“沉痛教训”，它表明利用数据和计算的方法将胜过手工打造的方法。如果我们专注于 RAG 中的重排序组件，我们将能够消除过程中其他地方的一些复杂性。并且要记住，我们当然一直在等待大型语言模型技术的进步。但这些进步也很可能使重排序器组件受益。因此，当您发现新的、有趣的研究时，请记住这一点。
Mikko Lehtimäki：好的。这就是我最后的论点了。我希望有人觉得这很有趣。
Demetrios：非常棒。这种感觉是像一杯黑咖啡一样苦涩，还是像黑巧克力一样醇厚？我非常喜欢您分享的这些经验教训，感谢您的分享。我知道重排序以及检索评估方面的问题是目前很多人关注的焦点，我也知道 Qdrant 的一些人正在积极思考这个问题，以及如何使其更简单。所以很高兴您经历过这些，感受过痛苦，也能够分享对您有帮助的东西。对此我表示感谢。如果大家有任何问题，现在是提问的时间。否则我们将线下交流，大家可以在领英上联系您，我会在聊天中分享您的领英个人资料，方便大家联系，因为这真的很棒，哥们。
Demetrios：这非常酷，我对此表示感谢。
Mikko Lehtimäki：谢谢。希望对某些人有用。
Demetrios：非常好。如果这就是全部内容了，我想我还有一个问题。尽管我们时间有点紧，所以这个问题就像是“闪电”问题。您提到您展示了一个非常详尽的图表，上面包含了所有内容，这有点像您追求的理想状态或理想结果。接下来是什么？您打算从那个图表中构建出哪些您还没有的东西？
Mikko Lehtimäki：如果您想要“闪电”回答，那么能在本地硬件上完全运行这个系统会非常棒。我知道这可能不是算法层面的事情，也未必完全在 Yokot AI 的范围之内，但如果我们能以这种形式在物理设备上运行它，那将是太棒了。
Demetrios：我喜欢。我喜欢。好的。Mikko，谢谢您以及所有在座的朋友们。各位向量空间宇航员们。祝大家有美好的一天。早上好，晚上好，无论您身处世界的哪个角落或太空中。我们下次再见。
Demetrios：谢谢。
Mikko Lehtimäki：再见。
