Apple 用神经网络加速 RAG 检索

Faster Retrieval for Better, More Efficient RAG

▲ 153zerop28 HN 评论区

在检索增强生成（RAG）场景中，查询向量与文档向量的分布差异常导致传统几何检索方法失效。Apple 团队提出利用神经网络学习支持函数，通过 SupportNet 优化聚类路由，或利用 KeyNet 直接预测最佳匹配键。实验表明，在 Natural Questions 数据集上，该方案在保持高召回率的同时，将检索延迟降低了近 8 倍。这种方法不再依赖粗糙的质心距离，而是通过学习查询分布特征，实现了更精准高效的向量检索。

为可能出现的输入源打造最佳方法，而非追求在所有可能输入上的良好表现，是现代机器学习的核心原则。
阅读原文 →HN 评论区RSS

HN 评论区

28
  1. armcat

    就在昨天，我看了 Spotify 的一场演讲，他们展示了自家的快速检索机制“Parallel Fusion Router” [1]。这也属于“learned retrieval”（学习式检索）范式——在他们那里，是用一个教师 LLM 来训练一个更小的路由 LLM 如何进行检索，奖励函数基于 LLM-as-a-judge（LLM 作为裁判）。

    就我个人的经验而言，Apple、Spotify 等公司的这些学习方法，只适用于超大规模场景——也就是当你需要处理数亿甚至更多条目，且要求前 5 个结果的关联度极高时。对于其他所有用例（条目数在几百万以内），我发现构建一个 BM25 索引，给 LLM 一个 BM25“搜索工具”，然后“撒大网”去搜，每次都能完胜那些学习方法（尽管后者在 recsys 和 icml 上更容易发表论文）。

  2. comandillos

    我觉得，无论你的排序机制有多好，检索方法最终都会让 LLM 偏向于那些基于启发式规则、对领域理解差得多的系统所给出的结论。我想这算是速度和质量之间的权衡吧，但根据我个人的经验，让 LLM 在没有偏见（bias）的情况下自由探索，通常能为最终输出带来更好的质量。

  3. mickeyp

    我还不太买账；这倒不是说我不能被说服，但我花了很多时间构建那种“一刀切”的 RAG 方案来应对代码库，我并不相信嵌入模型（embedding models）或各种各样的 BERT 实现效果好到能胜过 grep。

    大多数嵌入/BERT 模型都太小了，当 AI 向它们提问时，根本无法真正抓住问题的核心（grasp the nettles）；如果你把 AI 限制为只搜索一些非常基础的东西，那么……你基本上又回到了 grep + regex。

    你需要剪除各种可能干扰匹配的无用残渣，比如测试文件、文档和语义重叠的 sidecars，否则你匹配到的全是测试代码。如果你是在为企业构建文档库，这没问题；但如果你想要一个针对代码库的“一劳永逸”的解决方案，这通常远远不够。

    而且，如果你真的使用一个非常大的嵌入模型（这意味着必须在云端运行，因为大多数公司的电脑都跑不动），那么……嗯，你不如直接用语言模型作为一个子代理（subagent）为你先行侦察，从一开始就省去嵌入模型。

同日更多故事

2026-11-11