Agent 与 RAG：核心概念与高频问题

Agent 面试的题目翻来覆去就那几个：和工作流的区别、ReAct 怎么跑、Function Call 底层做什么、RAG 检索不到怎么办。这篇把它们按问题组织，而不是按名词。

1. Agent开发核心概念与技术栈

概念

Agent是一种具备感知，决策与执行能力的软件实体，能够基于环境信息自主完成目标导向的任务，

Agent应用开发不是简单效用大模型API，也不是只做一个聊天机器人，而是围绕大模型构建一个可以理解目标，拆解任务，调用攻击胡，观察结果，持续修正并最终完成任务的系统

现代Agent开发融合了大语言模型（LLM）、工具调用（ToolCalling）、记忆机制（Memory）、规划能力（Planning）以及多Agent协作等关键技术。

经典架构包括：

1. 感知层（输入解析与上下文理解）
2. 推理层（任务分解、规划与决策）
3. 执行层（工具调用、API交互、代码生成）
4. 记忆层（短期对话历史与长期知识存储）

一个完整的 Agent 一般包括：

Agent = LLM 决策核心 + Context 上下文 + Planner 任务规划 + Tools 工具执行 + RAG 知识补充 + Memory 状态记忆 + Permission 权限控制 + Evaluation 评测优化。

关键实现要素

工具集成：

Agent需要通过结构化函数（通常是Josn文件）描述注册外部能力，例如检索、计算、数据库查询或者WebAPI调用。工具调用过程通常由LLM生成符合规范的参数并交由运行时执行

记忆管理：

短期记忆常以对话里是（message history）形式注入提示词；长期记忆则依赖向量数据库（如Chroma、Pinecone）实现语义检索增强（RAG），提升知识复用能力。

规划与反思机制：

高级Agent支持子目标分解（如使用Tree-of-Thoughts或Chain-of-Thought prompting）、失败回溯、以及动态重规划。例如，当某工具调用返回异常结果时，Agent可触发反思提示重新评估策略。

安全与可控性：

生产级Agent必须引入输出验证（output validation）、沙箱执行（sandboxed tool execution）、权限控制（RBAC）及人工审核通道（human-in-the-loop），防止越权操作或有害内容生成。

名词解释：

RAG语义检索增强（Retrieval- Augmented Generation）

大模型先去外部的知识库检索相关的资料，再把检索结果联通用户问题一起交给大模型生成答案

2. Agent汇总：ReAct、Function Calling、MCP、RAG高频问题

LLM 的四大天花板

这四条，面试的时候一定要能展开说，不能只背关键词：

① 只会说不会做——它能告诉你"你可以去天气 App 查一下"，但它自己不会去查。

② 没有记忆——上下文窗口一满就"失忆"，跨会话什么都没留下。

③ 知识截止——训练数据有截止日期，昨天发生的事它不知道。

④ 不会规划——你让它"做一份竞品分析"，它只会线性回答，不会自己拆解成"先搜集资料、再逐个分析、再对比价格"这样的步骤。

Agent 是什么？

一句话：Agent = LLM + 工具 + 记忆 + 规划，在循环中自主完成目标。

2. Agent 和 Workflow 有什么区别？

Workflow 详解

Workflow 就是把流程提前写死在代码里，LLM 只是其中某些节点的处理器。

拿退款处理举例：接收申请 → LLM 提取信息 → 查询订单数据库 → LLM 判断是否符合政策 → 是则执行退款、否则生成拒绝邮件 → 发送通知。每个 if/else 分支、每个步骤的顺序，都是开发者预先定义的。 LLM 只是流程中的一个"智能节点"，它不决定下一步做什么。

Agent 详解

Agent 接收到目标，自主规划执行路径。

同样拿退款举例：用户说"处理这个退款"，Agent 自己思考——“我需要先了解申请内容”，于是调用 read_ticket()；“发现是高价值订单，需要查特殊政策”，于是调用 search_policy_doc()；“政策允许，但需要主管审批”，于是调用 create_approval_request()。

每一步都是 LLM 自己决定的，不在代码里写死。 这意味着同一个 Agent，面对不同的退款申请，可能会走完全不同的路径。

实际生产中：混合架构最常见

别把 Workflow 和 Agent 对立起来。大多数生产系统是 Workflow + Agent 的混合架构——Workflow 提供稳定骨架，Agent 负责处理异常和复杂情况。

比如智能客服系统：简单问题走 Workflow 直接回答，复杂问题启动 Agent 自主分析决策，投诉工单直接升级人工。这样既保证了基础场景的稳定可控，又能在复杂场景发挥 Agent 的灵活性。

面试答法：先说清楚 Workflow 和 Agent 的区别，再强调混合架构才是生产落地的正确姿势。能说出这个，面试官就知道你做过实际项目。

3. Agent 有哪些工作模式？

模式一：ReAct（推理 + 行动）

最经典的 Agent 工作模式，几乎所有主流框架（LangChain、LangGraph）的默认选择。

ReAct 的核心是一个三步循环：Thought（思考）→ Action（行动）→ Observation（观察）→ 回到 Thought 继续思考，直到任务完成。

实际跑起来长这样：

1
2
3
4
5
6
7

Thought: 用户想查北京明天天气，我需要调用天气工具
Action: get_weather(city="北京", date="明天")
Observation: {"city":"北京","date":"2025-04-11","weather":"中雨","temp":"14-20°C"}

Thought: 天气查到了，是中雨。用户还没说要不要取消日程，我应该告诉他结果
Action: 结束，生成最终回答
Final Answer: 明天北京有中雨，气温14-20°C，建议带伞。

优点：透明可审计（每步思考看得见）、灵活适应（观察结果后可调整）、通用性强。

缺点：Token 消耗大（每步都要完整推理）、可能死循环（工具反复失败时卡住）、延迟高（每次 Action 都要等 LLM 响应）。

ReAct 本质是个 Prompt 范式，循环的是文本。这些缺点放到生产环境会被放大，怎么把"循环"这件事单独工程化（上下文、状态、预算、工具、终止五类治理），单独展开见 从 ReAct 到 Loop Engineering：Agent 到底在循环什么。

如何防止 ReAct 死循环：

1. 最大步数限制——通常设 15 步，超过就强制终止
2. 重复动作检测——连续 3 次调用同一个工具且参数相同，直接退出循环
3. 超时控制——整个任务设置最大执行时间

模式二：Plan-and-Execute（先规划再执行）

ReAct 的问题是每一步都要重新思考全局，Token 消耗太大。Plan-and-Execute 的思路是：先把计划想清楚，再按计划逐步执行，省去每步的重复推理。

两阶段工作：第一阶段，Planner LLM 一次性生成完整计划（比如"搜集竞品列表 → 逐个分析功能 → 对比价格策略 → 分析用户评价 → 生成对比报告"）；第二阶段，Executor 按计划逐步执行，每步只需完成当前任务，不用重新思考全局。

Token 消耗对比：ReAct 每步都思考全局，消耗 100%；Plan-and-Execute 规划一次执行省力，消耗约 20%。

但有个问题：执行过程中发现计划不合理怎么办？比如计划了 5 个竞品，结果搜出来 50 个。解决方案是加入重新规划检查点——执行完某步后检查，如果发现和预期偏差大，触发重新规划，更新后续步骤

模式三：Reflection（自我反思）

Reflection 的思路是：让一个 Agent 生成，另一个 Agent 审查，循环迭代直到质量达标。

用代码 Review 类比最容易理解：Writer Agent 生成代码 → Reviewer Agent 发现问题（安全漏洞、性能问题）→ Writer Agent 修改 → Reviewer Agent 确认通过 → 最终输出。

适用场景：代码生成、法律文书、学术论文、创意写作——这些场景对输出质量要求高，值得多花 Token 反复打磨。

面试加分：Reflection 也可以用于自我校正幻觉。当 Agent 发现自己给出的事实存疑时，可以触发"验证反思"，调用搜索工具去核实，而不是盲目输出。这个点说出来，面试官会觉得你理解得比较深。

模式四：Multi-Agent（多智能体协作）

多个专业 Agent 协作完成复杂任务：Orchestrator（协调 Agent）负责理解需求、分配任务、汇总结果，下面挂 Research Agent（搜集资料、分析数据）、Coder Agent（写代码、跑测试）、Reviewer Agent（代码审查、安全检查）等。

主流框架对比：

Anthropic 的提醒，面试时要提到：不要过早引入 Multi-Agent。一个强大的单 Agent 往往比多个简单 Agent 协作更稳定、更省钱。只有任务明确需要并行处理或专业分工时，才引入多 Agent。盲目上多 Agent，调试地狱等着你。

4. Function Call 是什么？底层怎么实现？

Function Call 是什么？

Function Call 是让 LLM 输出结构化的工具调用指令，而非普通文本，再由应用程序实际执行。

关键认知：LLM 自己并不执行函数！ 它只告诉你"我想调用什么函数、传什么参数"，真正执行的是你的代码。

Function Call 四步流程

Step 1：定义工具——告诉 LLM 有哪些工具可用

Step 2：LLM 判断并生成调用指令——LLM 的输出不是文本，是结构化 JSON

Step 3：你的代码解析执行

Step 4：把结果传回 LLM，生成最终回答

5. MCP 是什么协议？解决什么问题？

MCP 解决的根本问题：N × M 爆炸

没有 MCP 之前，每个 AI 应用要跟每个外部服务单独写一套集成代码。3 个应用 × 3 个工具 = 9 套代码，10 个应用 × 20 个工具 = 200 套代码，维护成本爆炸。

MCP 把这个问题变成了 N + M：每个应用只需接入 MCP 协议，每个工具只需实现一个 MCP Server，总共 3 + 3 = 6 套代码。

**

MCP 架构详解

MCP 由三个角色组成：

• MCP Host：你使用的 AI 应用（Claude Desktop / Cursor / 你自己的 Agent）
• MCP Client：住在 Host 里，负责和 Server 通信的"翻译官"
• MCP Server：对外暴露具体工具能力的服务端，每个第三方服务各自实现一个

MCP 提供了哪些能力？

MCP Server 可以暴露三类资源：

MCP 的工具发现机制

这是 MCP 最强大的特性之一：Agent 启动时，扫描配置的 MCP Server 列表，向每个 Server 发送 tools/list 请求，接收工具列表和描述，将所有工具注入 LLM 的上下文。运行时，用户说"帮我在 GitHub 创建一个 Issue"，LLM 发现有 github_create_issue 工具，通过 MCP Client 发送调用请求到 GitHub MCP Server，Server 调用 GitHub API 返回结果。

这意味着 Agent 可以在运行时动态发现新能力，不需要重新部署代码。 今天加一个 Slack MCP Server，明天 Agent 就能用 Slack 的能力了。

MCP 安全性设计

三层安全机制：

第一层——能力声明：Server 明确声明自己提供哪些工具，Agent 只能调用声明的工具，无法越权。

第二层——授权控制：敏感操作可以要求人工确认，MCP Host 负责管理 Server 的授权范围。

第三层——审计追踪：所有工具调用都有日志，可追溯每次 Agent 行为。

MCP 底层协议

面试可能会追问 MCP 基于什么协议实现的：

• 本地通信：stdio（标准输入输出，最简单）
• 远程通信：HTTP + SSE（Server-Sent Events，支持流式）
• 消息格式：基于 JSON-RPC 2.0 规范

6. Skills 是什么？和 Prompt 有什么区别？

面试官会问：“Skills 和 System Prompt 有什么区别？你会怎么设计一个 Skill？”

Skills 解决什么问题？

给 Agent 一堆工具（MCP）还不够，它还需要知道：遇到代码审查，该用什么标准？写 SQL 查询时，DBA 的最佳实践是什么？回复客户时，品牌的语气要求是什么？

这些领域专家经验，就是 Skills 要编码的东西。

Skills vs System Prompt

一个完整的 Skill 文件示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

---
name: Senior_Code_Reviewer
description: 当用户要求进行代码审查时激活此技能
triggers:
  - "帮我 review 代码"
  - "code review"
  - "检查这段代码"
allowed-tools:
  - read_file
  - search_codebase
  - run_linter
---

# 角色定位
你是有 10 年经验的资深后端架构师，对代码质量有极高要求。

# 审查维度（必须全部覆盖）

## 1. 安全性（最高优先级）
- SQL 注入风险
- 越权访问漏洞
- 敏感信息硬编码（密码/密钥）
- 反序列化安全

## 2. 性能
- N+1 查询问题（for 循环里查数据库）
- 未释放的资源（IO流/数据库连接）
- 不必要的重复计算
- 缓存策略是否合理

## 3. 代码质量
- 单一职责原则
- 方法长度不超过 50 行
- 命名是否准确表意
- 注释是否必要且准确

# 输出格式
必须输出 Markdown 格式报告，包含：
1. 总体评分（1-10分）
2. 严重问题（必须修复）
3. 建议优化（非强制）
4. 每个问题必须附代码示例（原始代码 vs 修复后代码）

# 语气要求
专业、直接，不废话。发现问题就直说，别用"可能""也许"这类模糊表达。

注意这个 Skill 文件的结构：身份定位 + 工作流程 + 注意事项 + 输出规范。这比简单给几个 Few-shot 示例强得多——Few-shot 教的是格式，Skills 教的是方法论。

Skills 的激活机制

用户输入 → Agent 扫描所有可用 Skills → 匹配 triggers 关键词 / 语义相似度超过阈值 → 匹配到则将 Skill 内容注入上下文，按 Skill 指导执行；没匹配到则使用通用能力

Skills 决定「怎么想」→ MCP 决定「用什么」→ Function Call 决定「怎么调」。

三者协作的完整流程

用户说"帮我审查 agent.py 这个文件"，完整流程是这样的：

1. Skills 匹配：检测到"审查"关键词 → 加载 Code_Review Skill → “好，我知道审查要关注安全/性能/质量三个维度”
2. Agent 规划（受 Skill 指导）：“我需要先读文件，再用 linter 检查”
3. MCP 工具发现：发现有 filesystem MCP Server 和 linter MCP Server
4. Function Call 执行：生成调用指令 read_file("agent.py") → MCP Client 转发给 filesystem Server → 获取文件内容
5. 再次 Function Call：run_linter("agent.py") → 获取 lint 结果
6. LLM 综合分析（按 Skill 规范）：输出标准格式的代码审查报告

8. A2A 协议是什么？和 MCP 的关系？

MCP 解决了 Agent ↔ 工具的连接，但没有解决 Agent ↔ Agent 的连接。

Agent A 想请求 Agent B 帮忙完成一个子任务，面临的问题：不知道 Agent B 有什么能力、不知道怎么给 Agent B 发任务、不知道 Agent B 完成没有、Agent B 是 LangGraph 做的而我是 CrewAI 做的，怎么通信？

这些问题 MCP 没有设计解决，因为 MCP 的设计目标是工具，不是 Agent。

A2A 核心概念

① Agent Card（智能体名片）——每个 Agent 发布一个 JSON 描述文件，包含名称、能力描述、端点地址、认证方式等。其他 Agent 读取名片，决定要不要委托任务。

② Task（任务）——标准化的任务对象，有完整生命周期：CREATED → PROCESSING → COMPLETED / FAILED。

③ Message & Artifact——过程中沟通用 Message，最终成果用 Artifact（可以是文档/代码/数据）。

A2A 通信流程

编排 Agent 收到"写一份关于 AI Agent 技术的竞品分析报告"的需求后：

1. 查询 Agent Registry，找到 Research Agent 和 Writer Agent
2. 读取各 Agent 的 Agent Card，了解能力
3. 通过 A2A 委托 Research Agent：Task{搜集主流 Agent 框架信息}，Research Agent 内部用 MCP 调工具完成，返回 Artifact（调研报告）
4. 通过 A2A 委托 Writer Agent：Task{基于调研报告写分析报告}，Writer Agent 生成最终报告

MCP vs A2A：互补而非替代

• MCP 解决纵向问题：Agent ↔ 工具（一个 Agent 连接多个外部服务）
• A2A 解决横向问题：Agent ↔ Agent（多个 Agent 之间协作）

两者互补，不互相替代。Agent 内部用 MCP 调工具，Agent 之间用 A2A 协作。

Agent 的记忆系统怎么设计？

面试官会问：“Agent 怎么实现跨会话记忆？“以及"RAG 是 Agent 记忆的一部分吗？“还有"记忆太多放不下上下文窗口怎么办？”

记忆的两种层次

Agent 的记忆分为两大层：

上下文窗口（In-Context Memory）——速度最快的短期记忆，存当前对话、任务状态、加载的 Skill、工具调用历史、检索到的长期记忆。但容量有限（通常 128K tokens），超出窗口需压缩或归档。

外部记忆（External Memory）——分三类：

记忆压缩策略

上下文快满的时候怎么办？三种策略：

1. 滑动窗口——丢弃最旧的消息，保留最近 N 条
2. 摘要压缩——用 LLM 把旧对话总结成一段话，大幅缩减 Token
3. 重要性过滤——只保留关键信息（用户指令、重要结论），丢弃过程细节

压缩后归档到外部记忆，下次需要时再检索回来。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class AgentMemory:

    def __init__(self):
        self.working_memory = []      # 当前上下文
        self.vector_store = VectorDB()  # 长期语义记忆
        self.kv_store = Redis()          # 结构化状态

    def add_message(self, message):
        self.working_memory.append(message)

        if self.token_count() > MAX_TOKENS * 0.8:
            self._compress()

    def _compress(self):
        old_messages = self.working_memory[:-20]
        summary = llm.summarize(old_messages)

        self.vector_store.add(summary)
        self.working_memory = [summary_msg] + self.working_memory[-20:]

    def recall(self, query):
        relevant = self.vector_store.search(query, top_k=5)
        return relevant

记忆的读写时机

写入记忆：任务完成后保存结果和关键发现、用户提供个人信息时保存偏好、发现新知识时更新知识库、出错了保存失败原因避免重蹈覆辙。

读取记忆：任务开始时加载用户偏好和历史背景、遇到陌生问题时检索相关历史经验、需要事实核查时检索已知信息。

10. Agent 的安全与可靠性如何保障？

Agent 面临四大安全威胁：

核心防御：最小权限 + Human in the Loop

最小权限原则：读任务只给 SELECT 权限，不给 DELETE；MCP Server 声明工具时限制操作范围；不同环境（生产/测试）使用不同凭证。

Human in the Loop（人类审批）：高风险操作暂停，请求人类确认。

1
2
3
4
5
6

def execute_action(action):
    if action.risk_level == "HIGH":
        approval = request_human_approval(action)
        if not approval:
            return "操作已取消"
    return action.execute()

必须人工审批的操作：删除数据、发送外部邮件、修改权限配置、超过阈值的资金操作。

Prompt Injection 防御

这是面试高频考点，防御手段要说得具体：

1. 数据/指令分离——外部内容放在明确的数据区域，和系统指令区分开
2. 输入过滤——检测并标记可疑内容（如包含"忽略之前指令"等关键词）
3. Prompt 模板隔离——用户输入不直接拼入系统提示词，用结构化格式包裹
4. 上下文标记——在对话中明确标记哪些是外部数据、哪些是系统指令

可靠性设计

1. 幂等性——同一个操作执行多次结果相同，避免 Agent 重试时重复提交
2. 回滚机制——重要操作前先备份，支持撤销（特别是文件修改、数据库写入）
3. 超时控制——每个工具调用设置超时，整体任务设置最大执行时间
4. 降级策略——工具失败时有备用方案，不能盲目重试，要有退出条件

RAG 是 Agent 工具箱里的"知识查询器”。 面试时说出这个关系，比单纯对比两者的区别要有深度得多。

Agentic RAG：进阶玩法

还有一种模式叫 Agentic RAG——把 RAG 本身做成一个 Agent。普通 RAG 是固定流程：检索一次就完事；Agentic RAG 是 Agent 自己判断检索策略：需要检索哪些数据源？检索结果够不够？不够就换个角度再检索。这种方式对复杂知识问答场景效果很好。

2. 大厂真实面试追问汇总

以下是各大厂在 Agent 方向的真实追问，整理汇总。

系统设计类

Q：设计一个企业级 Agent 系统，需要考虑哪些点？

必答五个要点：

1. 工具管理层——MCP Server 统一管理，工具权限分级（只读/读写/管理员），工具调用审计日志
2. 记忆与状态——短期对话上下文管理（滑动窗口/摘要压缩），长期向量数据库（用户偏好/历史经验），会话 Redis（任务状态/中间结果）
3. 可靠性保障——最大步数限制防死循环，工具调用超时控制，关键操作人工审批，失败重试 + 熔断机制
4. 可观测性——完整的 Trace（思考链 + 工具调用 + 结果），Token 消耗监控控制成本，错误分类统计
5. 安全——Prompt Injection 防御，最小权限原则，数据脱敏

Q：Agent 的 Token 消耗很大，怎么优化成本？

优化策略从易到难排：

1. 工具选择优化——只给 Agent 它真正需要的工具（减少工具描述 Token），按任务类型动态加载工具子集
2. 模式选择——简单任务用 Workflow 代替 Agent（节省4倍 Token），Plan-and-Execute 代替 ReAct（节省规划 Token）
3. 上下文压缩——摘要压缩历史对话，中间结果只保留关键信息
4. 模型路由——简单子任务用小模型（如 GPT-4o-mini），复杂推理才用大模型（如 GPT-4o / Claude 3.5）
5. 缓存——工具调用结果缓存（相同参数直接返回），Prompt 缓存（Anthropic 支持 Prompt Cache）

原理深挖类

Q：为什么说 Function Call 是 Agent 的基石？

因为没有 Function Call，Agent 只能生成文字，无法操作外部世界。Function Call 解决了两个核心问题：什么时候调用（LLM 自动判断，无需规则引擎）和传什么参数（从自然语言自动提取结构化参数）。Agent 的循环本质上是"Function Call 的循环编排”。

Q：MCP 基于什么协议实现的？

传输层：本地用 stdio（标准输入输出），远程用 HTTP + SSE（支持流式）。消息格式基于 JSON-RPC 2.0 规范。

Q：Skills 和 Few-shot 有什么区别？

Few-shot 教格式，Skills 教方法论。Few-shot 给 LLM 几个输入输出示例让它模仿格式，Skills 给 Agent 完整的工作流程、规范和标准。Skills 通常包含：身份定位 + 工作流程 + 注意事项 + 输出规范。

工程实践类

Q：你们生产环境的 Agent 踩过什么坑？

常见的五个坑：

1. 死循环：工具持续失败 Agent 反复重试 → 解法：最大步数 + 相同动作检测
2. 幻觉工具调用：LLM 调用了一个根本不存在的工具 → 解法：严格校验工具名，未知工具直接报错而非猜测
3. 上下文污染：历史对话影响当前判断 → 解法：合理截断上下文 + 任务重置机制
4. Token 爆炸：某个工具返回了超大数据（如整个数据库） → 解法：工具输出截断 + 分页策略
5. Prompt Injection：外部数据包含恶意指令 → 解法：数据/指令分离，外部内容放在明确的数据区域

这五个坑里，任务漂移和工具调用幻觉是最难缠的，单独展开见 Agent 漂移与幻觉怎么解 和 Agent 系统如何约束大模型幻觉。

约束 Agent 幻觉，不能只靠一层。

Prompt 要不要写？

当然要。

但 Prompt 只是第一层边界提醒，不是保险箱。

真正的工程防线至少有四层：

1. Prompt约束：告诉模型什么能做、什么不能做
2. 工具约束：限制它能调什么工具、参数能怎么填
3. 证据约束：要求回答必须有来源，没有证据就拒答
4. 输出校验：生成后再检查，不能让结果直接裸奔给用户

这四层解决的问题不一样。

Prompt 约束解决的是"模型知道边界"。

工具约束解决的是"模型不能乱行动"。

证据约束解决的是"模型不能空口编事实"。

输出校验解决的是"模型说完以后还要验收"。

高风险动作至少要加：

• 用户二次确认
• 权限校验
• 金额/范围阈值
• 人工审批
• 幂等和回滚机制

Agent 系统里，最怕的不是模型不知道，而是模型自信地执行错动作。

第四层：输出校验，生成完不是结束

很多系统把"模型生成回答"当成最后一步。

这不对。

在 Agent 系统里，生成之后还要验收。

1. 结构化输出校验

能用 JSON，就不要让模型自由发挥。

比如客服工单分类，输出应该是：

1
2
3
4
5
6

{
  "category": "refund",
  "confidence": 0.86,
  "need_human": false,
  "evidence_ids": ["doc_102", "doc_305"]
}

这样才能校验字段是否缺失、枚举值是否合法、置信度是否低于阈值。

自由文本看起来顺滑，但很难管。

2. 业务规则校验

模型说"可以退款"，系统还要检查：

• 订单是否存在
• 是否超过退款期限
• 金额是否异常
• 用户是否有权限
• 当前状态是否允许退款

这些不能交给模型自由判断。

应该由业务代码兜底。

确定性规则，别让概率模型拍脑袋。

3. RAG工作原理详解

全称：Retrieval Augmented Generation（检索增强生成）

1. 先从资料库里检索相关内容
2. 再基于这些内容来生成答案

总体介绍

使用场景

创建智能客服：

产品手册太长所带来的问题：

1. 模型无法读取所有内容
2. 模型的推理程碑太高
3. 模型推理速度慢

RAG的基本流程

数据准备部分（提问前）

分片（把文档分成多个片段）

索引

    1. 通过Embedding将片段文本转换为向量
        1. 向量：有大小和方向的量（在RAG中用到的向量维度通常都比较大，维度越大，每个向量包含的信息也就会越丰富）
        2. Embedding：把文本转化为向量的过程（含义相近的文本在Embedding之后对应的向量更相近）TODO：了解一下常见的Embedding模型
        3. 向量数据库：用于存储和查询向量的数据库,同时存储向量和原始文本，最终一同发给大模型的是原始文本
    2. 将片段文本和片段向量存入向量数据库中

回答部分（提问后）

召回（搜索与用户问题相关的片段，判断方法是向量相似度）成本低，耗时短，准确率低

    3. 用户问题发送给Embedding模型，生成对应的向量，返回最相似的几个向量，计算向量相似度（带入向量相似度公式）
        1. 向量相似度的计算方法
            1. 余弦相似度（主要是计算两个向量之间夹角的cos值，夹角越小相似度越高）
            2. 欧氏距离（主要计算两个向量之间的距离，距离越小相似度越高）
            3. 点积（一种代数的方式，乘积越大表示相似越高，方向相反为负的，垂直则为负的，可以通过点积的值判断是否在一个方向上努力）TODO：了解点积的过程
        2. 

重排（cross-encoder适合做精挑细选）成本高，准确率高

生成

本文由 3 篇笔记合并整理。