手工 RAG 流水线 vs 智能体式上下文工程

Manual RAG Pipeline vs Agentic Context Engineering

设想你的数据分散在好几个不同的来源里（Gmail、Drive 等等）。

你要如何在这些数据之上，搭建一个统一的查询引擎？

开发者通常会把「上下文检索」当成一个周末就能搞定的小项目来对待。

……他们的做法通常是：「把数据 embedding 一下，存进向量数据库，然后做 RAG。」

对于静态数据源，这套做法效果拔群。

但问题在于，现实世界里根本不存在这么「干净」的工作流。

为了更好地理解这一点，不妨看看这样一个查询：

「芝加哥办公室项目现在卡在哪里了？下一次相关会议是什么时候？」

光是回答这一个查询，就需要跨多个来源搜索：Linear（查阻塞项）、Calendar（查会议）、Gmail（查邮件）、Slack（查讨论记录）。

任何朴素（naive）的 RAG 方案都搞不定这种问题！

要真正解决这个问题，你需要把它当作一套智能体式（Agentic）上下文检索系统来构建，其中包含三个关键层次：

• 接入层（Ingestion layer）：

  • 无需为身份验证问题头疼，就能接入各类应用。
  • 在做 embedding 之前，针对不同数据源（邮件 vs 代码 vs 日历）做好恰当的预处理。
  • 检测数据源是否发生更新，并刷新对应的 embedding（理想情况下无需全量刷新）。

• 检索层（Retrieval layer）：

  • 对模糊的查询进行扩展，推断出用户真正想要的东西。
  • 把查询导向正确的数据源。
  • 叠加多种检索策略，比如基于语义、基于关键词、基于图谱的检索。
  • 确保只检索出用户有权限查看的内容。
  • 权衡新旧检索结果的重要性（近期数据往往更重要，但旧的上下文依然有其价值）。

• 生成层（Generation layer）：

  • 给出带引用来源支撑的 LLM 回答。

在你的第一个查询真正跑通之前，这背后是数月的工程量。

这无疑是一个相当棘手的难题……

……但像 Google（在 Vertex AI Search 中）、微软（在 M365 系列产品中）、AWS（在 Amazon Q Business 中）这样的巨头，正是这样解决这个问题的。

如果你想看看实际落地效果，Airweave 就实现了这套思路——这是一个最近颇受关注的、100% 开源的框架，为 AI 智能体提供跨 30 多个应用和数据库的上下文检索层（截至 2025 年 12 月 3 日的数据）。

它实现了我们上面讨论过的所有要点，比如：

• 如何处理跨应用的身份验证。
• 如何处理不同的数据源。
• 如何从多个工具中汇集信息。
• 如何权衡新旧信息。
• 如何检测更新并进行实时同步。
• 如何生成类似 Perplexity 那种带引用支撑的回答，等等。

举例来说，要检测更新并触发重新同步，一种做法是比较时间戳。

但这种方法无法判断内容本身是否真的发生了变化（也许只是权限被修改了），结果你可能还是要把所有内容不必要地重新做一遍 embedding。

Airweave 针对这个问题，为不同数据源分别实现了对应的哈希（hashing）技术，比如实体级哈希、文件内容哈希、基于游标（cursor）的同步等等。

你可以在 GitHub 上查看完整实现，亲自试一试。

但无论你用哪个框架，其中的核心洞察都是通用的：

面向智能体的上下文检索，本质上是一个基础设施问题，而不是一个 embedding 问题。

从第一天起，你就需要为持续同步、智能分块（chunking）和混合检索（hybrid search）而设计架构。