Kimi K3 的 1M 令牌上下文窗口与 RAG:成本、延迟和应答质量

对相同 12 个问题、相同系统提示和相同模型的前 5 个 RAG 管道和完整的 127,000 个令牌提示进行受控比较。对正确性、完整性和接地性进行盲评分。Kimi K3 的 1M 令牌上下文窗口与 RAG:成本、延迟和答案质量一文首先出现在 Towards Data Science 上。

来源:走向数据科学

对于一百万个令牌的上下文窗口,我问自己很多人可能会问的同样的问题:我现在可以跳过 RAG 吗?

数学看起来很诱人。一切 我在过去两年中发布的精选内容总计达 127,068 个代币。这是窗口的百分之十二。因此,我可以简单地将所有内容转储到提示中,而不是构建块、计算嵌入并担心检索质量。

但“它适合”和“它效果更好”是两件不同的事情。

这正是我想在一个小实验中测量的。在本文中,我将向您展示当通过 RAG 设置一次回答相同的 12 个问题并通过上下文窗口中的完整语料库回答一次(我在这里称之为 long_context 设置)时,会发生什么。我还向您展示了整个过程中出了什么问题,事实证明这几乎比实验本身更具启发性。

这是我使用的设置:

  • 相同的提示:两条路径得到完全相同的系统指令。唯一不同的是它之前的内容。对于 RAG 设置,它是 5 个选定的文本段落,对于 long_context 设置,它是全部 32 篇文章。
  • 相同型号:两条路径都在具有相同生成设置的 Kimi K3 上运行。温度是唯一我无法自由选择的设置,因此固定为温度 = 1。
  • 最后的盲目评估:我将每个问题的两个答案打乱,并将它们作为“X”和“Y”放在我面前的 Excel 文件中,没有提示哪条路径产生了哪条路径。密钥位于一个单独的文件中,我仅在完成评分后才打开该文件。
  • 这样我就可以确保 RAG 和完整语料库(long_context 设置)的条件相同,并且盲目评分可以防止我影响自己。

    → 🤓在 GitHub Repo 中找到完整代码🤓 ←

    目录 1 – 为什么问题现在看起来不同了 1 – 为什么问题现在看起来不同了 2 – 设置:一个语料库,两条路径 2 – 设置:一个语料库,两条路径 3 – 三个难度级别的十二个问题 6 – 结果