RAG、知识库问答、搜索、Agent 的边界分别是什么

5 RAG、知识库问答、搜索、Agent 的边界分别是什么

P2 · rag

🏷 标签：rag, agent, knowledge-base, search, boundary

1️⃣ 考察意图

面试官想看你能否清晰界定这四个易混淆的概念，而不是模糊地混为一谈。这是典型的“概念辨析+系统设计”题，刁钻点在于：很多人能背定义，但说不清它们在真实系统中的层级关系和调用逻辑。答好了能展示你对 AI 系统架构的全局理解，知道什么时候该用 RAG 增强知识、什么时候该让 Agent 自主决策、什么时候搜索就够了。核心是考察你是否能画出“组件 vs 应用 vs 功能 vs 范式”的边界图。

2️⃣ 标准答

这个问题从四个概念的本质定义、核心输出、典型用例和层级关系来拆解边界。

1. RAG（检索增强生成）—— 组件

本质：一个技术框架，将检索模块（如 BM25、DPR、ColBERT）与生成模块（LLM）耦合，解决 LLM 的知识截止和幻觉问题。
核心输出：一个生成式答案，基于检索到的文档片段。
典型用例：客服问答中，先检索知识库文档，再让 LLM 生成回答。
边界：RAG 是组件，不是独立应用。它需要被嵌入到更大的系统中。实际落地的坑：检索质量直接决定生成质量，如果检索 Top-K 文档全是噪声，LLM 会“被迫”生成错误答案。解法：引入 Reranker（如 Cohere Rerank 3）对检索结果重排序，或设置置信度阈值，低于阈值时直接返回“无法回答”。

2. 知识库问答（KBQA）—— 应用

本质：一个应用场景，用户对结构化（如 SQL 数据库）或非结构化（如文档库）知识库提问，系统返回答案。它不一定涉及生成。
核心输出：一个精确答案（如“张三的年龄是 28 岁”）或文档片段。
典型用例：企业内部的 FAQ 系统，直接匹配预定义问答对；或基于知识图谱的问答。
边界：KBQA 是应用，RAG 是实现 KBQA 的一种技术手段。传统 KBQA 可能只做精确匹配（如 Elasticsearch 的 term query），而 RAG 让 KBQA 能处理开放域问题。工程取舍：精确匹配快但覆盖率低，RAG 覆盖率高但延迟高（检索+生成通常 2-5 秒）。选哪个取决于业务对实时性的要求。

3. 搜索（Search）—— 功能

本质：一个功能，从海量文档中返回相关文档列表，不生成答案。
核心输出：一个文档列表（如 Google 的 10 条蓝色链接）。
典型用例：搜索引擎、企业内部文档检索。
边界：搜索是功能，RAG 可以调用搜索作为检索模块。搜索的终极目标是“召回”，RAG 的终极目标是“生成”。实际落地的坑：搜索的排序指标（如 NDCG）和 RAG 的生成质量（如 BLEU）不一定正相关。一个高 NDCG 的搜索结果，LLM 可能因为文档冗余而生成重复内容。解法：在 RAG 中，对检索结果做去重（如基于 MinHash 的近似去重）和摘要压缩。

4. Agent（智能体）—— 范式

本质：一个系统范式，能自主决策、多步推理、调用工具（如代码执行、API 调用、RAG 组件）。它包含一个“思考-行动-观察”循环（ReAct 框架）。
核心输出：一个动作序列（如“先搜索天气，再调用日历 API 创建提醒”）。
典型用例：AutoGPT 完成旅行规划，先搜索航班、再查酒店、最后生成行程表。
边界：Agent 是范式，RAG 是 Agent 的一个子模块。Agent 可以调用 RAG 获取知识，也可以调用搜索 API 获取实时信息。工程取舍：Agent 的自主性越高，越容易陷入死循环或产生不可控行为。解法：设置最大步数（如 10 步）、引入人类反馈（Human-in-the-loop）、使用结构化输出（如 JSON 格式的 Action）来约束。

总结边界图：

层级：RAG（组件）⊂ 知识库问答（应用）⊂ 搜索（功能）⊂ Agent（范式）。
调用关系：Agent 可以调用搜索功能，搜索功能可以集成 RAG 组件，RAG 组件可以用于知识库问答应用。
一句话：RAG 是“怎么答”，知识库问答是“答什么”，搜索是“找什么”，Agent 是“做什么”。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从四个概念的本质定义、核心输出和层级关系来回答。RAG 是组件，输出生成式答案；知识库问答是应用，输出精确答案或片段；搜索是功能，输出文档列表；Agent 是范式，输出动作序列。边界在于：RAG 是 Agent 的子模块，搜索是 RAG 的检索手段，知识库问答是 RAG 的应用场景。总结一句：RAG 解决‘怎么答’，搜索解决‘找什么’，Agent 解决‘做什么’。”

4️⃣ 高频追问 & 应对

追问 1：那在实际系统中，你怎么决定用 RAG 还是用 Agent？

应对策略：看任务是否需要多步推理。如果用户问“今天北京天气怎么样”，一个 RAG 系统直接检索天气文档生成答案就行。但如果用户问“帮我规划一个北京三日游，预算 5000 元”，就需要 Agent 先搜索景点、再查酒店价格、然后计算总花费、最后生成行程。取舍点：RAG 延迟低（1-3 秒），适合单轮问答；Agent 延迟高（10-30 秒），适合复杂任务。如果业务对实时性要求高，优先用 RAG；如果任务需要工具调用，必须用 Agent。

追问 2：知识库问答和搜索的边界在哪里？如果用户问“张三的邮箱是什么”，用哪个？

应对策略：看数据结构和答案形式。如果知识库是结构化的（如 SQL 表），用知识库问答直接查表返回“zhangsan@xxx.com”，精确且快。如果知识库是非结构化的文档，用搜索返回包含“张三邮箱”的文档列表，用户自己找。工程取舍：知识库问答需要提前构建 schema 和查询逻辑，开发成本高但准确率高；搜索开发成本低但需要用户二次筛选。对于“张三的邮箱”这种精确查询，优先用知识库问答（如基于 SQL 的 Text-to-SQL 系统）。

追问 3：Agent 调用 RAG 时，怎么避免 RAG 的幻觉污染 Agent 的决策？

应对策略：引入置信度机制。在 RAG 模块中，对检索到的文档计算相关性分数（如 BM25 的 TF-IDF 分数），低于阈值（如 0.5）时，RAG 返回“无法找到相关信息”，而不是强行生成。Agent 收到这个信号后，可以切换策略（如调用搜索 API 获取实时数据）。实际落地的坑：阈值设得太高，Agent 会频繁切换策略，增加延迟；设得太低，幻觉污染决策。解法：通过 A/B 测试动态调整阈值，或使用多轮对话中的用户反馈来校准。

5️⃣ 避坑 · 常见错误答法

❌ “RAG 就是知识库问答，搜索就是 Agent。” → ✅ “RAG 是组件，知识库问答是应用，搜索是功能，Agent 是范式。它们有层级关系，不能等同。”
❌ “Agent 比 RAG 高级，所以 Agent 可以替代 RAG。” → ✅ “Agent 可以调用 RAG 作为子模块，但 RAG 的检索+生成能力是 Agent 无法替代的。Agent 解决的是‘做什么’，RAG 解决的是‘怎么答’。”
❌ “搜索和 RAG 一样，都是返回答案。” → ✅ “搜索返回文档列表，RAG 返回生成式答案。搜索是 RAG 的检索手段之一，但 RAG 多了生成步骤。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“RAG 作为 Agent 子模块”切入，讲你如何在项目中用 RAG 增强 Agent 的知识获取能力，并解决检索噪声问题（如引入 Reranker）。
如果你只做过传统搜索：用“搜索是功能，RAG 是组件”类比，讲你如何从搜索的排序指标（NDCG）迁移到 RAG 的生成质量评估（如 ROUGE），并分享你如何用 BM25 作为 RAG 的检索基线。
如果你是校招无项目：聚焦“概念辨析”本身，用论文（如《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》）中的定义来支撑你的边界划分，并展示你对 ReAct 框架的理解。
《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）
《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao et al., 2022）
《Search-Augmented Generation: A Survey》（2024）
《Knowledge Base Question Answering: A Survey》（2023）
《Building Agentic RAG Systems with LangGraph》（LangChain 官方博客）

—— 本场面试完 ——