Pinecone 工程副总裁 Jörg Schad 在 11 月 4 日的一场网络研讨会上，完整梳理了检索技术从关键词搜索到 RAG 的演进路径，并重点讨论了当 AI 代理而不是人类来消费检索结果时，整个系统需要补上哪一层能力。这场分享由 Pinecone 官方博客整理成文，以下为核心内容的重述。
研讨会上给出的第一个例子颇具代表性：让代理预测第四季度移动业务的增长，代理生成 SQL、执行查询，然后返回 +16% 的结果。问题在于，9 月 8 日当天有一次仅持续一天的合作伙伴促销活动，代理把这个流量尖峰当成了真实需求。如果按正确口径处理——把促销从预测中剔除、但仍保留在已报告的总量里——同样的趋势得到的结论是 +6%。数据本身都在，SQL 也完全合法，错的只是判断。
Schad 用这个案例说明，检索的每一代技术都在修补上一代的短板，但每一代也都有自己的天花板。关键词搜索依赖倒排索引，用 IDF（可追溯到 1972 年）和 BM25（1994 年）等相关性指标排序，能够在大规模数据上实现精确匹配，可它永远匹配不到“取消”和“终止订阅”之间的语义联系。语义搜索借助 word2vec（2013 年）、用于近似最近邻搜索的 HNSW（2016 年）以及 BERT（2018 年），跨越词汇差异找到语义相关的内容，其局限则变成了“设计文档问题”：两篇文档可能都与查询高度相似，但只有一篇描述的是今天真正运行的代码，而相似度分数无法告诉你哪一篇才算数。
2020 年 Lewis 等人提出的 RAG，让模型可以在查询时把答案锚定在知识库上，此后几乎每一个聊天演示都离不开它。但 Schad 强调，这种锚定是不受校验的：模型拿到检索返回的一切，却没有任何步骤去检查它是不是正确结果，也没有人去核对模型是否真的使用了它。
检索质量通常用 Recall@K 衡量，例如 Recall@10 表示相关文档出现在前十条结果中的比例。它是一个衡量“信息在不在”的好指标，却无法衡量“信息对不对”。假设某条政策已被新版本取代，检索会把两个版本都返回，召回率把两条都算作相关；一个基于旧版本做出的、看似合理的回答，实际得分是零，而 Recall@K 依然好看。同样的问题也出现在权限上：某份文档与查询高度相关，但调用方根本没有权限查看它，召回率不会因此扣分。
那么，如何让语义搜索更准确？Schad 的答案是：很多时候搜索本身已经完成了它的工作，缺的是搜索之外的信息。他举了一个并购场景：两家公司合并后，一家财年从 1 月到 12 月，另一家从 2 月到次年 1 月，同一个“季度”在两侧对应着不同的月份。对于任何跨越两家公司的问题，语义搜索都能找到全部相关文档，却无法说明这些文档该如何组合。再调检索器也无济于事，因为没有任何相似度分数能承载“两套财年日历如何对齐”这样的规则。
研讨会上用一组对比表格把问题讲得很清楚：预测第四季度增长时，检索返回了包含 9 月 8 日尖峰的完整数据，真正做决定的是“那天是一次性促销、应从预测中剔除”这条规则；询问某个功能如何工作时，检索同时返回三年前的设计文档和当天早晨的代码扫描结果，决定答案的是“哪份材料描述的是当前运行的代码”；并购后的跨公司数字，需要“1 月至 12 月如何对齐 2 月至 1 月”的规则；而“政策允许什么”，则取决于新旧两个版本中哪一个正在生效。换句话说，检索按 Recall@K 评分，上下文则按基于它做出的决策来评分。
当答案由人阅读时，这种缺失尚可弥补：一个人看到明显偏高的预测，或者在不应下滑时出现下滑，会皱起眉头重新核对。但当自主代理来读答案时，它可能直接把结果发出去，而且代理调用检索的规模是任何人类搜索都无法比拟的。高并发下的代理未必能察觉结果不合理或已过期，也未必会主动为答案寻找依据——它缺的正是能告诉它这些的上下文。
那么为什么不干脆把全部信息都交给模型，让它自己判断相关性？Schad 引用了 Chroma 的“上下文衰减”报告：该研究评估了 18 个大语言模型，发现在输入长度增加时，模型表现会越来越不可靠，即便任务被刻意设计得很简单。在 LongMemEval 上，平均约 300 个 token 的聚焦提示优于平均约 113,000 个 token 的完整提示。对代理同样如此：把与任务无关的信息灌进去，结果只会更差。于是问题从“正确的文档有没有被召回”变成了“代理还需要知道哪些内容是有效、可信、被允许且适合当前任务的”。
在架构上，Pinecone 的做法是把检索保留下来，并在其上叠加一层“决策层”。检索侧，Pinecone 在同一个索引中同时提供稠密向量、稀疏向量和基于 BM25 排序的全文检索，三种能力都内建于数据库而无需外挂。Schad 表示，不同任务需要不同的检索工具，很多任务需要不止一种，而关键词搜索在需要精确匹配的场景中依然不可替代。
决策层为每个任务维护一份“任务上下文”，其中包含摘要、实体、策略与规则，以及在查询到来之前就在后台整理好的知识制品。上下文负责判断哪些制品与当前任务相关，再根据需要向索引发起词法、向量或混合查询。回到并购的例子：搜索已经找齐了所有文档，缺失的是“一套财年日历如何映射到另一套”这种语义信息，它被放在任务上下文中，与策略和规则并列。被取代的政策、以及数据机器人遇到的一次性促销，处理方式如出一辙——索引提供数据，上下文中的规则决定如何对待它。
这也是 Pinecone Nexus（面向代理的知识引擎）的定位。Nexus 的整理流程会维护一份已处理来源的账本，以内容哈希追踪，因此一次运行只触碰发生变化的内容。答案会附带引用，标明每个结论背后的文件、页码和原文片段。优先级同样被明确写下来：上下文的默认指令相当于针对该上下文每次查询的系统提示，可以规定模型如何处理相互冲突的来源，例如哪一版政策胜出。
Schad 也坦率地划出了边界：Nexus 并非适合所有工作负载。如果检索模式简单、你有把握前十条结果里就有答案、没有复杂的规则或政策来决定哪个来源胜出，并且你愿意自己负责锚定环节，那么 RAG 已经够用。像大型在线商店里每一笔购买这样每秒都在变化的运营数据，更适合实时动态视图，全天被就地编辑的实时流和记录目前也不适合 Nexus；它最适合数据变化节奏较慢的场景，例如合同和研究资料。
他给出的最后建议是：在花一个迭代周期去调嵌入或重排之前，先检查检索是否其实已经找到了文档。如果答案是肯定的，那么真正需要修补的，是那个负责做决定的上层。完整回放已发布在 YouTube 上，想动手搭建这一层的读者可以从 Nexus 文档或申请试用开始。