争夺“世界上最长的上下文窗口”背后：长上下文是否意味着 RAG 的终结？
前段时间，国内外包括 OpenAI、谷歌、月之暗面等一大批顶级大模型技术公司都以支持更大的上下文作为更新升级的重点。长文本的突破也让社区中有了一些争议，认为这可能意味着 RAG 可能会消亡。另外，最近国内一众大模型企业都开始宣布降价，那么低成本是否跟选择长上下文和 RAG 是否有关系？
在这期极客有约节目中，我们邀请到月之暗面唐飞虎、zilliz 合伙人栾小凡、英飞流创始人张颖峰三位重磅专家给大家解读“长文本和 RAG”方面的技术。
直播视频链接：https://www.infoq.cn/video/vZZIkkIt85rVRa61xsR8
InfoQ：前段时间，大模型企业都在宣传自己取得了上下文上的突破，那么更大上下文能让我们做些什么？唐飞虎：我认为可以将模型上下文长度类比为计算机内存。随着模型上下文长度的提高，应对较为复杂的逻辑推理或生成 repo level 的代码等问题的性能都有了提升。举例来说，使用谷歌 Gemini 对癌细胞进行影像学的诊断问题，是需要组合多模态和长文本才能完成，目前来说并没有较好的 RAG 解决方法。对多模态模型而言，更长的上下文不仅能帮助模型理解并读取更多文档，在模型的整体性能方面也有帮助。
栾小凡：对大模型来说，RAG 应用的构建时，更长的文本的确有利。这本质是一个输入输出窗口的问题，在具备捕捉信息和上下文能力的基础上，大文本输入的信息越多，输出也会越好。另一方面，我个人认为长文本只是大模型能力的其中之一，我是非常反对文本越长越智能的观点。
张颖峰：长文本对大模型来说是能力上的巨大提升，这种提升主要体现在其摘要能力的生成。结合我们过去的经验来说，去年在实施一些 RAG 项目时，我们遇到的最大痛点其实是来源于大模型本身，但在今年这些痛点就已经逐渐被消除或大大地改进了。长上下文也让模型的可控性得到了增强，我们在做 RAG 的过程中很多流程因此发生了变化，我们不会去追求特别复杂的检索策略，而是将结果检索到后将后续任务都交给了大模型来完成，这种实施也会相对较容易一些。
InfoQ：我们是不是必须要 200 万甚至无限长的上下文？张颖峰：长上下文很有意义，但无限长的上下文则是更偏向于是营销的宣传策略。上下文长度到达一定程度后，丢失的信息也会更多。毕竟上下文再大也只是内存，没有必要追求无限大的内存，再大的内存也还是需要硬盘的。
InfoQ：今年看到“长文本”我们可能就会想到“月之暗面”，之前月之暗面 Kimi 将上下文扩展到了 200 万，那么 Kimi 是如何实现的这个突破的？唐飞虎：我们从 20 万字到 200 万字的扩展并没有采取常规的渐进式提升路线，而我们在技术攻关中遇到的难度也是呈指数级增加。为了达到更好的长窗口无损压缩的性能，我们团队从模型的预训练到对齐再到推理环节，均进行了重新的设计和开发，并且没有走滑动窗口、降采样等常规技术捷径，而是攻克了很多底层的技术难点。但是长上下文也不是无限长更好，我认为对现阶段的开发者而言这是一个 trade-off 的过程，上下文长度的增加对推理成本和时间都有一个平方几倍的增加。很多技术也是类似，都是遵循从 paper 到实验室，再从实验室到工程，最后再到产品这样一个循序渐进的过程，在现在的研究阶段，我们要将成本做到最低，长文本效果做到最好，这才是更重要的事情。
InfoQ：Kimi 也直接在国内带来了比拼上下文长度的热潮，各厂商瞬间就突破了 500 万、1000 万的处理能力，那这种效果属于算法还是算力上的突破？唐飞虎：各个厂商目前还没有公开自己的 technical report，所以这方面开发者还是更有话语权，他们会实地使用、体验各家不同的产品。上下文的性能可以参考一些常规的 Benchmark，比如大海捞针和腾讯的数星星，最近还有更加复杂的评测，比如在长文本中添加代码、逻辑片段。如何在长文本上下文长度边长的同时还要保质保量，这是一个非常有挑战性的技术难题。
栾小凡：我人认为以目前的 Transformer 架构来讲，算法的提升空间还是相对有限，再想将上下文提升到下一个数量级，这条路已经很难走得通了。我最近做的一些测试来看，不说几十万、几百万 token 的上下文，光是上百 KB 的上下文在各家的线上测试都有几秒甚至是几十秒的延迟。所以在真正落地的生产环境中，上下文的长度还是应该控制在数十 K 的范围内。
张颖峰：从实现的角度来说，我会将其分为两派，一派是使用了 RAG，一派是没用 RAG。在目前提供公共大模型服务的厂商里，我认为这两派都有，且比例都不低。站在技术的角度来说，我在某些方面上还是更倾向于纯模型派。
InfoQ：增加上下文窗口大小且不影响模型性能，会存在哪些挑战以及有什么应对方法？唐飞虎：这个其实关系到我们 Transformer 模型的它的底层架构，就如果你去看它的那个计算的方法，然后再做一些相关的评测的话，就是有一些长文本性能上的一些常规上的瓶颈，那基本上说出目前分析下来的话是长文本的并发性能，它会随着你上下文长度的长度增加而反比下降。然后预填充的延迟会随着你上下文长度的增长而平方级别的增长，然后解码延迟和上下文切换的开销也会随着你上下文长度的增加而线性的增加啊。这几个参数里面对整个推理性能影响比较明显的是并发性能和预填充的延迟，也是现在各个厂商，包括一些学者专家，大家在研究和攻坚的这个难题。
栾小凡：飞虎老师提到的 Transformer O(n^2) 的问题，我比较期待的是最近 LSTM 的卷土重来。我认为是需要对模型架构进行调整，才可能到达下一个阶段的。
InfoQ：在处理大上下文长度时，原始 Transformer 架构的主要限制是什么？目前有哪些优化技术可以加速 Transformer 并将上下文长度增加到更大？唐飞虎：主要的瓶颈就在于前面提到的矩阵计算导致预填充延迟和并发性能随上下文长度的增长而显著增加。目前这方面的优化角度主要还是硬件、机器学习工程和模型架构这三方面。硬件现在有 A100 memory 的 hierarchy 设计；机器学习工程有 VLLM 和较为主流的 Flash Attention 等技术；模型架构有前段时间流行的 MoE（多专家模型），也有最近对 Transformer 架构底层的颠覆，比如 Mamba 等等。但有些优化技术目前还没有较为完善的支持，导致其在工程上的实现并不可行。举例来说，键盘 QWERTY 的布局对人类而言并不是最优的，但大家都已经用了很久也非常习惯了，除非有更加优秀、能带来颠覆性结果的设计，大家才能更好地 follow。因此，如果只是从某一层面上带来效率的提升，那还要关注优化是否能再工程上有更好的结合。最近的一些论文有提到从 layer、head、hidden layer 等层面上做优化。大家可以在 ICIP 这些网站上搜索“推理优化”相关的论文结果。
栾小凡：如果大家对降低成本方面感兴趣的话，DeepSeek 的 MLA（Multi-latent Attention）和多专家模型是他们能将价格压下来的最底层的技术。从硬件层面来说，最早有去年很火的 Grok，今年也有越来越多的硬件厂商从推理方向加入这个赛道，比如美国的 SambaNova、英特尔等公司，这方面在我看来会比训练更容易得出成果，模型架构本身相对简单，硬件定制优化更容易得到很好的吞吐。
唐飞虎：旗舰店的另一个好处是不会出现前面提到的技术选型方向不兼容的问题。
张颖峰：模型成本方面最近降价很猛，我认为这和长上下文确实是有一些关系的。在目前的架构下， 主要瓶颈都在于对 KV cache 的低利用率。DeepSeek 本身的 ML 架构其实也是对 KV cache 做 low-rank 压缩。其实无论是推理加速还是长上下文，这些都是围绕着 KV cache 的利用率，要怎么将 cache 里的 attention 量化、提升和压缩。
InfoQ：有论文声称能赋予 LLM 处理无限长度文本的能力，那工程上是否可实现，或大概多久后能达到无限上下文长度？栾小凡：这个问题还是要回到第一原理上，如果说 AI 最终的目标是替代人做事，那么我们首先要问的一个问题是，人有什么样的能力？每个人的记忆都不是无限的，我们有短期也有长期的记忆，所以这其实是一个伪命题。再说什么才是真正的智能，我认为这是个伪命题，长文本不代表智能，长文本只是一种手段。能记住更多东西的人不一定更聪明。OpenAI 最近一年内的演进方向来看，更好地使用工具才是用大模型解决问题的一个关键点。记忆短有记忆短的处理办法，但记忆变长就一定意味着密度更小，以现在的 Transformer 机制来说，随着上下文的边长，模型一定会遗忘一些东西。举例来说，让大模型找到一百个数字中唯一的乱序数字，现有的模型都可以轻松完成，但换成一万个数字，那么基本上所有的模型都会犯错，因为它已经找不到重点了，甚至已经忘记了自己的任务是去找乱序的数字。
InfoQ：Jeff Dean 的 twitter 提到，百万 Token 上下文，精度还能达到 99.7%（千万 99.2%），那么在这种情况下的大模型解决了 RAG 技术方案下所存在哪些痛点？但也还存在哪些问题待解决？张颖峰：RAG 的痛点基本来源于这几个方面，一是在用户意图很强的情况下，召回可能不够精确。在实际的企业内部数据集或者用户的个人数据中进行检索，因为答案不再一个语义空间内，所以很可能搜索不到想要的东西。其次也是我们在公司创业到现在做各种 RAG 项目时遇到的问题，检索查询时数据本身非常杂乱。这些问题部分可以用上下文进行缓解，比如在长上下文的语义空间中包含检索需要的答案，这样大模型也能对问题进行回答。不过这种方案还不能完全解决这种问题，我认为还是需要提高 RAG 自身的能力。以今年春节为分割线，春节之前最大的瓶颈是大模型本身，春节之后在大家对大模型能力要求的情况下，我认为整套体系最大的瓶颈已经落到 RAG 上了。如果未来大家对模型期待提到，希望能引入更多的逻辑推理，那么痛点可能又会转移到大模型上去，这个问题总是在不断变化的。
唐飞虎：这个我可以举的例子是上个月我们的联合线下黑客马拉松，有一个场景是需要基于百大行业分析的研报文档知识库，生成相关数据的图表。当时在现场无论怎么组织 prompt，RAG 都没有办法得到想要的结果，于是我们直接将其换成长文本。因为 prompt 的上限导致还是无法不支持，所以我们采用了自定义插件将文档全部输入进去，结果的图表很效果很好。这样类似的例子其实有很多，需要的上下文信息分散在整个文章文档且有一定的上下文逻辑关系时，长文本目前的确比 RAG 更好。
栾小凡：我个人认为，无论是 RAG 还是长文本，和之前的数据处理没有什么本质区别。长文本是对所有数据的实时处理，RAG 则是对数据的离线处理。在没有理解用户意图的情况下，离线的数据处理可能结果出错。所以我认为现在的各种小技巧无非都是建立更加普遍适用的关系，猜测用户的意图。从本质来讲，如果大模型对一个问题没办法，那 RAG 也很难回答。所以我认为从模型最终的智能角度来说，一定是先有大模型智能再有 RAG。至于说 RAG 是否是不必要，人可以把所有书都读一遍来找到自己想要的答案，但搜索引擎却可以为我们节省时间。我认为 RAG 存在的一个核心价值是能帮助我们在大模型预处理数据之后更快速地完成重复工作。
观众提问：这种场景一般要求准确性会比较高，长文本替换 RAG 的解决方案不会出现模型幻觉吗？唐飞虎：如果只是将数据提取出来，那么出现幻觉的概率还是相对较低的。重灾区一是体现在一些较长的复杂逻辑上，数学证明题可能就在中间某个步骤就乱了，现在的模型也没有办法去很好地验证结果的正确；二是一些比较冷门的知识点，模型完全不知道结果；还有一种是数据本身 bias 导致的幻觉。这些都是我们目前需要攻克的问题，之前提到的场景，如果只是生成一个图表，那么模型出现的幻觉相对较低，即使生成了幻觉也能很容易地去验证，然后再重新调整 prompt。
InfoQ：Gemini 1.5 出来后，社区认为百万 Token 的上下文意味着 RAG 可能会消亡，老师们怎么看待这个观点？张颖峰：我个人认为这种观点大部分正确，在海外媒体比如推特上这方面的讨论很多，基本是对 RAG 在成本、性能方面优势进行赞同，但在其他方面则持反对意见。我认为在 C 端个人知识库这类简单的场景下，大模型足矣。不论成本、性能和数据安全，只谈能力的情况下，B 端的 RAG 应用场景非常多，而随着上下文长度的增加，查询率也会降低。所谓的大海捞针也只是不会错过最近的针，更靠前的还是会有遗漏的可能。在这些场景下，我们不能只依赖大模型，还要将 RAG、大模型以及内部系统进行整合。这样一来又会带来更多问题，比如 RAG 检索出的结果虽然语义相似但答案却不是很相关，这种情况反而会降低模型回答的质量。
唐飞虎：上下文长度决定了模型的基础能力，RAG 则是决定了开发者对应用开发的上限。和模型微调类似，在大模型能力还不够的时候，我们很多的业务场景都是靠微调实现的，现在我们直接用长文本或 RAG 替代，不过还是会存在一些场景需要靠微调解决。RAG 也是一样，目前的一些 RAG 场景可能在未来用长文本会更快速、更方便，但 RAG 本身也会进步扩展，也会开发出新的场景。开发者还是需要同时掌握这两门技术的。
栾小凡：我不太认同 RAG 是 ToB 的观点，实际上我们目前的应用中有很多 ToC 场景，其中多租户就是一个非常有挑战性的问题。在应用有十万甚至百万的活跃用户时，怎样在所有的数据中精确搜索到某个租户的数据，这其实是 RAG 或向量数据库中非常重要的一个问题。OpenAI，包括 ChatGPT 中的许多能力也是围绕 RAG 和向量数据库构建的。RAG 解决的核心问题是准确帮助大模型找到所需的信息，它的本质是 retrieval。模型的能力需要提升，搜索的质量也要有提升。至于大家现在说到的分 chunk 等各种 trick，很可能会随着上下文和模型能力的提升而变得不再重要。
张颖峰：我也认同目前的一些 trick 可能在未来不再需要。我们目前这些杂乱无章的非结构化数据可能会随着未来多模态模型的能力提升，模型自己就能进行解读，但在目前我们还是要依赖 RAG 来完成这些脏活。
观众提问：RAG 在 ToC 中的多租户难题是具体指什么？栾小凡：以现在陪伴类 APP 为例，每个用户和大模型聊天时都会有上下文，用户在隔天登录时会需要对上下文的回顾，我们可以将这些聊天记录全部作为 context 输入到模型中去，但首先过多信息的输入会对大模型产生干扰，其次是成本的问题，随着聊天深入，上下文长度增长，整体的成本也会快速增加。我们需要在有限的长聊天记录中摘取出与当前对话相关的内容。对一个用户来说这点非常简单，但在数百万用户的情况下我们就会有百亿甚至千亿级别的数据量，要如何在这其中找到某个用户的数据，这其实是业界面临的一个较大挑战。
InfoQ：模型幻觉有什么常用的解决办法吗？要如何避免幻觉的出现？唐飞虎：一个方法是 function calling，引入一些外部工具验证模型的中间生成结果。在这方面 OpenAI 的 code interpreter 就做得很好。比如说在生成一道数学题的答案后，它会立即生一段相关代码进行结果的验算。这是一种思路，我们可以把这种方法推广到更多的场景中，通过引入外部工具解决模型幻觉问题。
栾小凡：复杂的 RAG 其实在本质上就是各种工具的混合使用，前面提到的在数列中寻找乱序数的例子，真正智能的解法我认为应该是让模型生成并运行代码，这样一来无论多长的上下文模型都能找到一个最终的答案。
InfoQ：现在大家最关注的就是“价格战”，比如有说百万 token 只要 1 元的，那么目前的一些大模型可能是通过哪些方式做到如此低的成本的？这其中，是否跟选择长上下文和 RAG 是否有关系？唐飞虎：推理优化方面的技术有很多，OpenAI 的 GPT 3.5 Turbo 在这方面就已经很好了。这一次大厂商所谓的价格战其实更多是对一些相对较小的模型（8k、32k 等）进行降价，但在实际的开发场景中，很多开发者已经需要 128K 甚至是更长的模型，8K 的模型用户可以直接用 GPT 3.5 Turbo 来实现。这次的价格战真正能帮到开发者多少，还是要实际使用才能知道。当然，技术方面也确实是有进步的，比如量化和推理性能的提高。可以预期在未来 Q3、Q4 模型的价格和推理的成本还会进一步降低，但目前更重要的还是让长文本模型也能以较低的价格给到开发者。
张颖峰：在我看来，这次的降价除了营销因素外，技术方面与提高 Transformer 所依赖的 KV cache 利用率有很大关系。压缩 KV cache 后，推理的 batch size 就会更大，从而在解码阶段可以将内存的限制转换为计算的限制，从而实现每个 token 的降价。
栾小凡：模型本身我可能不是专家，但我之前在朋友圈看到一个有趣的观点，叫“引进 token 成本”，也就是说大模型的 token 虽然相对较贵，但同样的任务所需的 token 数可能更少。大家可能都深有感触，在模型上下文较短的时候，我们需要采取大量压缩方式或预处理，消耗很多的 token，但如果能有更加智能的模型，则回节省很多预处理的时间成本。从这个角度来看，我们更需要期待模型变得更智能，而不是过早地打价格战。
InfoQ：长文本的不断突破对开发者意味着什么，更长的上下文是否会对开发人员应用程序的性能产生负面影响？唐飞虎：我认为目前对开发来说受益还是很明显的，类比 LMOS 来说，上下文就像是内存、RAG 就像是外部的硬盘，其他可能还有存储架构之类。在 DOS 时代的开发者可以用 256 KB 的内存开发出 WPS、永远的毁灭公爵这类非常厉害的应用，但如今 256 KB 可能连程序都无法启动。技术是在不断迭代的，在简单的场景和低廉的成本下，我们可以直接将上下文当作 prompt，让模型自己去判断。
栾小凡：RAG 面临的最大挑战其实是数据之间的关系。尤其是较长的文章中会存在许多代指和因果关系，这些是简单的 RAG 无法解决的问题。“他拿着一个苹果”，“然后他走出了教室”，那么苹果在哪里？如果 chunking 没有做好，将这两句话切分到了不同的段落中，这其实是超过了 RAG 能解决的范畴。随着上下文能力的提升，架构的相似性让未来的 embedding 模型上下文也会随着 generation 的模型提升。智源的 Landmark embedding 可以将很长的文章切割成多个 embedding 的同时又保持了一定的上下文关系，意味着有了长上下文之后，处理这类复杂的逻辑或代指关系就有了更多的工具。
InfoQ：zilliz 在增强检索技术上有什么打算？栾小凡：对我们来说有两件事是至关重要的，一是提高搜索性能，现在的 embedding 模型非常丰富，除了传统的 dense embedding，还有 sparse embedding、ColBERT embedding、Landmark embedding 等等，这些 embedding 其实都是在不同层面上提升搜索的质量，也可以将不同的 embedding 混合使用并结合 reranking 技术，大幅提高召回的效果和质量。这其实是 Milvus 或者说向量数据库在近一年内都在专注解决的问题。
另一件事则是成本，过去做 embedding，很多时候都是用一个 PDF 文件生成几百几千个 embedding。比如说曾经很火的 autoGPT，曾有次将 vectorDB 从他们的架构中移除了，人们问 Andrew G. 用什么 vectorDB 的时候，他说因为自己只有几千的向量，所以用的 numpy。但在今年，很多应用场景都发生了巨大变化，很多模型公司在用线下数据库做模型训练和微调时，ToB 或 ToC 的应用场景中出现了一亿甚至十亿级别的数据，这就让存储的成本成为了问题的核心。我在最近和美国的一家头部 AI 公司聊的时候，发现他们每年在线上数据库中花费的钱比 OpenAI 还要多，这个问题已经成为了很多头部 AI 应用公司的诉求。现在 binary embedding 的出现就是通过量化的技术降低存储的成本，再加上其他分存存储的技术和我们之前在做的 GPU index，都是降低成本的方向。
InfoQ：英飞流在增强检索技术上有什么打算？张颖峰：我们的规划有很多，对于前面提到的 RAG 的痛点，我们有些是在数据库层面解决，有些则是站在 RAG 全局的角度解决。在数据库层面，我们针对用户意图明确的情况下提供了丰富的多路召回能力。目前我们的多路召回只提供两路，但在一个月后的 release 中我们会提供更加丰富的在召回形式，包括用于精确召回的全文搜索、用于语义召回的向量搜索、以及稀疏向量等等。先前在四月 IBM 提出的 blended RAG 中提出同时采用这三路召回效果可能会更好。此外，我们还会提供基于张量 Tensor 的高级召回能力，将文章中的段落用张量表示，从而实现更高级的排序和重排序能力。
这些能力都是围绕用户意图非常明确的情况下，通过多样化的多路召回能力保证回答的精确、语义和性能。其次，在用户意图不明显的时候，我们计划会在今年夏天启动这方面工作，将外部知识图谱存放到数据库中，方便根据用户意图的不同来改写用户提问。这些都是站在数据库的层面来解决的问题。
在 RAG 层面，我们打算做的也有很多，比如目前我们是通过 一些小模型来解决数据本身杂乱的问题，但在未来这一定是通过多模态大模型来解决。此外还有 RAG 本身必备的排序模型。RAG 本质上是过去搜索引擎的增强，搜索引擎十年前的口号“relevance is revenue”，这直到今天也同样适用。
观众提问：多路召回是否会降低性能？张颖峰：会略微降低，毕竟在同时使用多种的搜索方式，再有就是 reranking 也就是融合排序，这会比单纯的搜索略慢。但在 RAG 系统中，瓶颈永远不会是 RAG 本身，大模型的并发是远低于 RAG 中使用的各种数据库的。即使多路召回存在性能开销，也不会成为整体系统的瓶颈。
观众提问：月之暗面什么时候可以开放 200 万字 token？唐飞虎：目前我们也在积极扩展用户的体验资格，前段时间 Kimi 也推出了打赏的功能，一些的打赏用户也已经提前拿到功能体验了，但具体什么时候能够全量放出，还是要依据具体的研发进度判断。
观众提问：关于提示词有两种观点，一种认为很重要，一种认为随着 AI 的发展提示词将会越来越无关紧要。嘉宾们对此的怎么看？唐飞虎：找个问题要要看分析的角度，从发展的角度来看，提示词二代重要性肯定会下降，但目前阶段提示词还是很重要的，在测试 benchmark 时提示词不对结果都会不准。如果我们再将目光放得长远些，如果我们将 AI 想象成智能体或人类，我们与其交流时需要学会提问的艺术，之前 HackerNews 上一篇很值得看的文章有提到 prompt 的艺术。随着时间的发展，模型越发智能，即使提示词表达不好模型也有会理解你的意图。我们的一些用户在反馈模型回答不准确时，我们发现这些问题就算是人类也没办法很好地回答，也需要对细节进行二次询问、
我们的 Kimi 大模型中有一些场景，比如在调用外部工具时如果缺失 required 的 prompt 参数，模型会反问用户这个参数是什么。这只是一个例子，未来的大模型可能会更加智能。就像是乔布斯从来不做用户调研而是为产品创造用户，因为他更深刻地理解了用户背后的需求。未来大模型这方面的能力也会提升，从一个不完整或有缺陷的 prompt 中理解用户背后的真实意图。
栾小凡：我认为 prompt 还是非常重要的，大模型的本质是 next token prediction，如果上下文都比较模糊那么后续的结果也大概率会出现问题，从更长期的角度来说，prompt 的重要性会下降，但就目前所有的模型来看，提示词还是设计给专家来使用的。大家在写代码时大模型虽然可以有所帮助，但对于一个完全不懂代码的人来说他一定会遇到各种问题，也没办法解释任何一个报错。但如果是一个代码专家，我们能够看懂模型生成代码的模式，稍加调整就能得到还算不错的结果。在未来随着模型输入手段的多元化，这种门槛可能会下降，我们可以通过图片、声音或者更多的输入方式将信息直接传递给大模型， 甚至在未来大模型也可能具备获取信息的能力。
观众提问：有哪些可以有效提高 RAG 召回率和准确率的方法吗？张颖峰：在我看来，提高 RAG 召回率和准确率的方法有两种，一是前面提到的多路召回，也就是通过多种方法将结果取回后进行统一的融合排序，从而提高 RAG 的召回率。另一种方式则相对较为前沿，例如采用 ColBERT 这种基于张量的召回方式会有相对来说较好的结果，但这种方式时需要有对应的模型可以产生相应的张量。这两种方式也有相互融合的可能，站在 Infrastructure 的角度来说，我们有必要同时提供这些能力。
栾小凡：我认为是可以从两方面回答的，一是数据层面，大家提到 RAG 的第一反应都是向量数据库，但其实也有很多别的方式，比如关键词检索和图数据库的使用。在意图相对较为明确的时候，数据的组织结构是和意图和应用场景对齐。二则是复杂的 RAG 或 agent 中一些流程，比如基于问题生成答案进行搜索、ranking 、chain of thought、trail of thought，甚至是基于图等复杂构造的流程。这些都可能会在不同的场景中有所帮助，我自己在做 RAG application 的时候一般会先基于 LangChain 或 LLamx 系统做 profiling，尝试应用场景中不同组合的效果。当然，构建自己的 evaluation dataset 其实是关键，只有知道要怎样评价模型或系统，我们才能进行各种的尝试。
观众提问：向量数据库的未来是纯向量化还是混合型？RAG 要如何选择合适的向量数据库呢？栾小凡： 在我看来万物皆可向量化。但向量不代表 dense embedding。Dense embedding 很多会关注上下文，但却在关键词方面有所欠缺，因此需要用 hybrid search 进行弥补。当然也有专门针对关键词的 embedding，比如将 dense embedding 和 sparse embedding 相结合，这个我们在 Milvus 的最新版本中进行了支持。但无论怎么说，我认为搜索的未来一定是基于模型上限的提高，而不是传统的统计信息。因此，知识图谱的构建等场景也一定是通过大模型自动化来构建，而非是通过业务的规则，搜索也是一样，只有在见过更多语料后搜索的质量才会提升。所以在我看来，最终很多都会变成向量，只不过不一定是 dense embedding 而已。
观众提问：数据分析趋势会是 RAG 的一个场景吗？张颖峰：数据分析我认为严格来说不能算是 RAG，当前的数据分析更多是依靠 text-to-SQL 的方式完成，是由大模型将自然语言转换为一条查询 SQL 语句，再用这条 SQL 去查询数仓返回结果。换句话说，我们从数据库中拿到的数据并没有经过大模型的加工。因此，我认知至少在当下，数据分析不算是 RAG。至于未来，这种可能性是存在的。如果我们在拿到数据图表和分析的结果后，希望结合其他数据源获得一些更深层次的洞见 insight，那么这种未来的用例是可以归纳到 RAG 中的。
观众提问：多模态大模型的 RAG 未来的路要怎么走？世界大模型能带来哪些 RAG 和向量数据库的变化？栾小凡：最近在 GPT-4o 发布后确实出现了较多的多模态应用场景。其中我认为比较重要的一个趋势是类似之前的 AI native 和 cloud native 的多模态 native。过去大家在训练多模态模型时，往往采取对齐的手段，将 image mode 和文本 model 通过对比学习或其他方式对齐到同一语义空间之中。但随着新的模型的出现，文本 token 和图像 token 天生就是在同一个语义空间中训练。因此，这类模型的性能相较其他会更好，语义理解能力也会更强，从而诞生出很多的应用场景。其中比较有意思的是一个无人驾驶的训练场景，过去大家在做动态搜索的时候往往是以图搜图或文字搜图的形式，但这种方式其中缺乏了很重要的意图理解：针对同一个图片，用户可以询问的问题有很多，生成的 embedding 或搜索结果也会不同。然而随着多模态 embedding 的发展，这种想法逐渐变得越发现实。结合多模态的生成能力，无论是视频领域还是 GPT4 演示的语音助手领域，我认为都会有更多新场景演化出来。
张颖峰：说到多模态大模型 RAG，我认为在 RAG 本身部分可能变化没有很大，但要是想让这条链路在未来成为爆款，有更大的普及，那么瓶颈还是在模型本身。就目前来说，不说视频，光看文和图之间的生成，就已经有很多的选择了，但要是想要达到商用标准，在模型的可控性上还有很长的路要走，基于多模态的 RAG 在图像生成方面其实是非常薛定谔的，我们没有办法精准控制生成的结果。这其实是阻止我们将多模态 RAG 大规模使用的主要瓶颈，但我相信这个瓶颈的突破应该不会花太长时间。
观众提问：哪些 embedding model 可以同时支持多语言呢？唐飞虎：现在支持多语言的模型有很多，大家熟悉的 OpenAI embedding 目前来看效果相对来说很不错。国内包括智源和 GenAI 在内也有很多跨语言的 embedding model，如果大家对 embedding model 的效果和能力感兴趣的话，可以关注 HuggingFace 上的 MTEB 榜单，里面也有一些多语言的 benchmark。
观众提问：开发基于大模型的应用生产环境是应该考虑用 Python 还是其他的语言呢？唐飞虎：这个问题主要取决于开发应用的量级和它依赖的生态。就我们所观察到的情况来说，开发者社群内使用的语言从 Python、Java、GoLang 到 Rust 都有，在我们的 GitHub repo 里也是 Python、NodeJS、Go、Java、C# 等等，能想要的语言应有尽有。从编程语言来说并不会对开发者有很大的限制，哪怕是只会一种语言也是可以和我们的模型有很好的交互。主要的问题在于其他的生态，对 bot 来说，Node 或 Python 更加合适，但要是想和企业内已有的服务打通，那么 Java 可能会是更好的选择。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐剥离几百万行代码，复制核心算法去美国？TikTok 最新回应来了
开源独角兽 GitLab 走上“卖身”路！前工程师拆台：赚钱的业务不好好运营，开发了一堆没用的功能