6 RAG / Agent 应用

2026-04-24 2026-04-24

6 RAG / Agent 应用

Agent 设计

1. 讲一下Agent中的短期记忆和长期记忆分别怎样存储？

短期记忆一般存当前会话上下文，长期记忆存跨会话可复用的信息。

短期记忆通常放在对话历史、scratchpad、当前任务状态里，常见实现是内存对象、Redis、会话态数据库
长期记忆通常放在向量库、关系库或知识库里，保存用户偏好、历史任务结论、结构化事实

设计上我会区分：

什么是“本轮临时状态”
什么是“跨轮仍有效的稳定信息”

否则很容易把噪声写进长期记忆，越记越乱。

2. 如何定义循环终止条件防止Agent陷入逻辑死循环？（你的安全护栏是关键词匹配，还是调了专门的模型？调用的什么模型？）

我一般不会只靠关键词匹配，而是做多层护栏。

常见终止条件：

最大思考步数 / 最大工具调用次数
同一工具或同一参数重复调用超过阈值
连续几轮状态没有新增信息
已经得到可回答结果或明确失败结论

护栏实现上通常是：

规则优先：步数、超时、重复调用检测、状态哈希
必要时再加一个轻量判别模型或主模型自检，用来判断“是否继续有价值”

也就是说，规则负责兜底，模型负责语义判断，不能只靠其中一种。

3. A2A 协议是什么？

A2A 一般指 Agent-to-Agent 协议，用来定义不同 Agent 之间如何发现能力、发送任务、交换状态和返回结果。

它解决的是：

多 Agent 怎么互相调用
任务状态如何传递
能力描述、鉴权、上下文和结果格式怎样统一

本质上它是多 Agent 协作的通信规范，和人写死的私有接口相比，更强调标准化和互操作。

4. 多 agent 工作流怎么搭建

先拆角色，再定拓扑，最后补观测和容错。

常见步骤：

明确哪些任务适合拆分，例如规划、检索、代码执行、审校。
给每个 Agent 定边界：输入、输出、工具权限、成功标准。
选择拓扑：主管理者调度，或固定流水线，或黑板式协作。
增加共享状态、消息总线、日志和超时重试机制。

经验上，多 Agent 不是把模型变多，而是把职责拆清。

5. 怎么优化 agent 的效果

我一般从四层看：

任务定义：提示词、目标函数、停止条件是否清楚
工具层：工具是否稳定、返回值是否结构化、错误是否可解释
记忆层：是否写入了有价值的记忆，是否及时清理脏记忆
调度层：是否让最合适的 Agent 做最合适的事

常见优化手段：

加强工具返回 schema
增加 plan / act / reflect 的中间状态
做失败样本回放和 prompt 迭代
引入 rerank、校验器或审稿 Agent 做结果过滤

6. MCP 是什么

MCP 是 Model Context Protocol，核心目的是让模型以统一方式接入外部工具、资源和上下文。

它的价值在于：

工具暴露方式标准化
客户端和工具服务端解耦
一个工具能力可以被多个支持 MCP 的客户端复用

所以它不是某一个工具，而是一套模型连接外部能力的协议层。

7. Agent 架构中具体有什么东西呢？分别是什么作用

一个比较完整的 Agent 架构通常包含：

Planner：拆任务、决定下一步
LLM：负责理解、推理和生成
Tool Executor：实际调用搜索、数据库、代码、API 等工具
Memory：保存短期状态和长期记忆
State / Orchestrator：维护流程状态，控制路由和终止
Guardrail / Evaluator：做安全、格式、质量校验
Observability：日志、trace、指标、回放

面试里可以概括成：大脑、手、记忆、调度和护栏。

8. 调用大模型的脚本主要需要设置什么字段呢？

核心字段通常有：

模型名
消息列表或 prompt
温度、top_p、max_tokens
是否流式返回
工具定义 / function schema
超时、重试、并发限制
鉴权信息，例如 API key、base URL

如果做生产脚本，我还会特别关注：

请求 ID 和 trace ID
日志脱敏
幂等和重试策略

9. Multi Agent 越多越好吗？端到端大模型和多个小模型协同各自有什么优缺点？有哪些拓扑结构？分别什么优缺点？

不是越多越好，Agent 数量增加会带来通信、延迟和错误传播成本。

端到端大模型的优点：

架构简单
延迟低
没有跨 Agent 协调开销

缺点是：

可解释性差
工具和流程控制不够细
某个环节错了不容易定位

多个小模型 / 多 Agent 的优点：

职责明确，方便替换和调优
可以针对不同子任务选不同模型
更容易插入规则和审计

缺点是：

系统复杂度高
延迟和成本可能更高
上下文传递不好会导致信息丢失

常见拓扑：

Manager-Worker：中心调度强，适合复杂任务
Pipeline：流程清晰，但灵活性一般
Blackboard：共享状态强，适合协作，但一致性更难
Peer-to-Peer：更去中心化，但控制更难

10. 多 Agent 系统里的 query 改写怎么做？如果要训练 query rewrite 模块，如何挑选训练 query，并在上线前后设计离线和线上评估指标？

query 改写的目标是把用户问题变成更利于检索或分发的表达，而不是单纯换个说法。

常见改写方向：

实体补全
歧义消解
多查询扩展
把口语问题改成更结构化的检索表达

训练数据会优先挑：

真实线上 query
召回差、歧义强、缩写多的样本
覆盖不同领域、长度和意图的 query

离线指标常看：

改写后 Recall@k、MRR、NDCG
是否提升 gold evidence 命中率
改写前后语义偏移率

线上指标常看：

首答命中率
追问率
人工转接率
用户满意度

核心是既看“是否更好召回”，也看“是否把原意改坏了”。

11. 工具调用（tool calling / function calling）一般怎么实现？

本质是“把工具描述成结构化接口，让模型输出参数，再由程序执行”。

一般流程：

预先注册工具名、参数 schema、用途说明。
把这些工具描述随请求一起发给模型。
模型判断是否需要调用工具，并返回结构化参数。
程序端校验参数、实际执行工具。
把工具结果再喂回模型，由模型生成最终回答。

工程上关键是：

参数校验
超时和重试
权限控制
对工具结果做结构化封装，而不是返回一大段随意文本

12. MCP 协议相较于 Function Call 的优势是什么？在工具注册、上下文管理、跨客户端复用和工程解耦上分别体现在哪里？

Function Call 更像“模型厂商接口里的工具调用能力”，而 MCP 更像“独立于具体模型接口的标准化连接层”。

优势可以分四点说：

工具注册：Function Call 往往要在每个客户端里手工注册 schema；MCP 可以把工具和资源统一暴露出来，注册方式更标准
上下文管理：MCP 不只支持工具，还能提供资源、文件、状态等上下文对象，能力范围更广
跨客户端复用：同一个 MCP server 可以被多个支持 MCP 的客户端使用，不用每个应用重写一遍
工程解耦：工具提供方和 Agent / 客户端分离，便于独立演进、权限控制和运维

所以如果只是单应用、少量函数，Function Call 足够；如果希望多工具、多客户端、长期演进，MCP 的工程价值更明显。

RAG

1. 介绍一下 RAG，它的作用是什么，为什么大模型会出现幻觉，RAG 能缓解哪些问题、不能解决哪些问题？

RAG 是 Retrieval-Augmented Generation，先检索外部知识，再把相关内容连同问题一起送给大模型生成答案。

大模型会出现幻觉，核心原因是：

训练目标是“预测下一个 token”，不是“保证事实为真”
参数记忆有时效性，知识可能过期
问题超出训练覆盖时，模型也倾向给出看起来合理的回答

RAG 能缓解：

知识过期
私域知识问答
需要可追溯证据的回答
降低纯参数记忆带来的事实性错误

RAG 不能根治：

检索没召回到正确证据
召回内容本身就是错的或过期的
多跳推理、复杂计算、强逻辑规划
模型读懂了证据但仍然总结错

一句话：RAG 是“给模型补上下文”，不是“自动保证正确”。

2. 对于RAG，既然向量检索已经计算了相似度，为什么还要用引入交叉编码器进行重排？

因为向量检索通常是“双塔”近似匹配，适合大规模召回，但对 query 和 document 的细粒度交互建模不够强。

向量召回追求的是快，通常先把 query 和文档各自编码后做 ANN 检索
Cross-Encoder 会把 query 和候选文档一起输入模型，能显式建模词级 / 句级交互
所以它更适合做小规模候选集合上的精排，而不是全库检索

常见流程是：

粗召回 -> TopN 候选 -> Rerank -> TopK 送给 LLM

它的价值是提高最终送入生成模型的证据质量。

3. 向量数据库检索出来的历史信息，如果语义相关但时间太久，能直接用吗？

一般不能直接用，要做时效性判断。

对政策、价格、配置、版本、业务规则这类强时效信息，旧文档可能比没有文档更危险
语义相关只说明“讲的是同一件事”，不代表“当前仍然有效”

常见做法：

检索打分里加入时间衰减
元数据过滤，例如只取最近半年 / 最近一个版本
让 rerank 模型同时看语义相关性和时效标签
生成时要求模型标注文档时间，并在证据冲突时优先最新版本

所以是否能用，不只看语义，还要看业务时效窗口。

4. Rerank的Top-k数量怎么确定？

Top-k 不是越大越好，要在效果、延迟和上下文成本之间平衡。

一般这样定：

先看召回阶段的 TopN 是否已经覆盖足够高的正确文档
再看 rerank 后送给 LLM 的 Top-k 增大时，回答质量是否继续提升
一旦质量收益开始变小，而 token 成本和噪声继续上升，就该停

经验上：

FAQ / 短文档常见 Top-k=3~5
长文档、多证据问题可能到 5~10
再大通常会引入无关上下文，反而降低生成稳定性

最终还是通过离线指标和线上 A/B 一起定。

5. 长文档切片的粒度你一般怎么选择？

原则是“一个 chunk 要有完整语义，又不能长到稀释检索信号”。

我通常同时看三件事：

文档结构：标题、段落、表格、代码块能否自然切分
检索模型的有效输入长度
下游问题粒度，是问局部事实还是问整段总结

常见经验：

说明文、知识库文档：200~500 tokens 一段
技术文档或强结构文本：按标题层级切，再配少量 overlap
代码 / 表格 / FAQ：更适合结构化切片，不宜纯按字数硬切

overlap 不是必须很大，通常保留 10%~20% 过渡信息就够。

6. 如何评估Rerank的有效性？有什么指标吗？

可以看两层指标：排序指标和最终问答指标。

排序层常用：

MRR
NDCG@k
Recall@k
Hit@k

如果有人工标注的 query-doc 相关性，排序指标最直接。

问答层还要看：

最终答案正确率
引用证据覆盖率
是否减少幻觉
平均 token 成本和延迟

因为 rerank 的目标不是单独“排得好看”，而是提升最终回答质量。

7. BM25和向量检索融合你是如何设置权重的？

我一般不会先拍脑袋定死，而是先做归一化，再用验证集调权重。

常见原因是：

BM25 擅长关键词精确匹配、实体名、缩写、版本号
向量检索擅长语义泛化和同义改写

一个常见做法是：

score = \alpha \cdot score_{bm25} + (1-\alpha) \cdot score_{dense}

实践里会注意：

两路分数要先归一化，不然量纲不同
先从 0.3/0.7、0.5/0.5 这类权重开始网格搜索
如果业务更依赖精确术语，可适当提高 BM25 权重
如果 query 表达很口语化，dense 权重通常更重要

有时也会直接用 Reciprocal Rank Fusion，比线性加权更稳一些。

8. 讲一下Ragas评测？

RAGAS 是面向 RAG 系统的一套评测框架，重点不是只看生成文本像不像，而是同时评估检索和回答质量。

常见维度包括：

Context Precision：召回上下文里有多少是真的相关证据
Context Recall：需要的证据有没有被召回
Faithfulness：回答是否忠于给定上下文
Answer Relevancy：回答是否真正回应用户问题

它的价值在于：

不一定要求每条样本都有人手标注标准答案
可以较系统地拆分“是检索差，还是生成差”

但要注意：

评测结果本身也常依赖 LLM judge
不同 judge、prompt 和语言环境会影响稳定性

所以更适合做相对比较，不适合当绝对真值。

9. RAG 用什么数据库？如果召回不准怎么办

常见选择有：

向量库：Milvus、Qdrant、Weaviate、pgvector、FAISS
关系库或搜索引擎配合：Postgres、Elasticsearch / OpenSearch

选型看：

数据规模
是否需要过滤查询和元数据检索
写入频率
运维复杂度

如果召回不准，我会按链路排查：

query 是否要改写、补实体、做多路检索。
切片是否过粗或过碎。
embedding 模型是否适合当前领域。
ANN 索引参数是否过于激进，导致召回损失。
是否缺少 BM25 / 规则召回这类补充通道。
rerank 是否把好结果排掉了。
知识库是否脏、旧、缺关键文档。

10. 讲一下 embedding 过程

在 RAG 里，embedding 过程就是把文本编码成稠密向量，便于做语义相似度检索。

基本流程：

文本清洗和切片。
用 embedding 模型把每个 chunk 编成向量。
把向量和原文、标题、时间、来源等元数据一起写入索引。
用户 query 进来后也编码成向量。
通过余弦相似度或内积做近邻检索。

关键点：

文档和 query 最好用同一套或对齐好的 embedding 模型
需要保留元数据，方便过滤和后续 rerank
更新知识库时要考虑增量编码和索引重建成本

11. 讲一下 rank 的过程

rank 一般指在召回候选上做排序，决定哪些证据真正进入生成阶段。

常见流程：

多路召回拿到候选文档。
对候选做去重、合并和基础过滤。
用 BM25 分数、向量相似度、业务规则、时间特征等做粗排。
再用 rerank 模型做精排。
取最终 Top-k 作为 LLM 上下文。

所以 rank 不是单一步，而是“多信号融合 + 分层排序”。

12. 多路召回策略下，如何分别评估各召回通道返回文档的质量？如何判断某一路召回是在补充覆盖、制造噪声，还是和其他通道高度重叠？

我会把每一路召回拆开做通道级评估，而不是只看融合后的总效果。

重点看：

单通道 Recall@k、Hit@k、MRR
与其他通道的重叠率、唯一贡献率
被该通道独立召回的文档里，有多少最终进入答案证据

判断逻辑：

如果单通道召回不强，但能稳定补到其他通道没覆盖的正确文档，它是在补覆盖
如果返回大量最终不会被 rerank 选中的文档，而且拖高延迟，就是在制造噪声
如果和其他通道高度重复，说明它的边际价值有限

所以多路召回要看“新增有效覆盖”，不是只看“多了一路”。

13. 是否有成熟的评价体系衡量召回质量？离线和在线分别看哪些指标，怎样把召回质量和最终回答质量关联起来？

有，但通常是“离线检索指标 + 在线业务指标 + 端到端问答指标”组合起来看。

离线常看：

Recall@k
Precision@k
MRR
NDCG
chunk / doc 级命中率

在线常看：

首次命中率
用户追问率
人工纠错率
点击引用率
满意度、解决率

关联方式通常有两种：

建立 query 到 gold evidence 再到 final answer 的标注链路
分桶分析：召回命中和未命中的样本，最终回答正确率差多少

如果召回指标提升了，但回答质量没提升，通常说明问题在 rerank、上下文组织或生成阶段。

14. 如果召回出来的答案不是想要的，应该从 query 改写、切片策略、embedding、索引召回、融合策略、rerank 和知识库时效性等哪些环节排查？

我会按“从前到后”的链路排查。

query：用户问题是否过短、歧义大，是否需要 query rewrite、多查询扩展、实体补全。
切片：chunk 是否丢失关键信息，是否标题和正文被切散。
embedding：模型是否不适合当前领域或语言。
索引召回：ANN 参数、过滤条件、向量写入是否正确。
融合策略：BM25 和 dense 是否失衡，多路召回是否互相污染。
rerank：是否把正确结果排低了，Top-k 是否过大或过小。
知识库：文档是否缺失、重复、过期、版本冲突。
生成阶段：prompt 是否要求“只基于证据回答”，是否把无关上下文一起塞给模型。

这样排查的好处是能区分“没找到”还是“找到了但没用好”。

推理 / Prompt

1. 了解ToT或者GoT吗，什么区别？

了解。

ToT 是 Tree of Thoughts，把中间推理步骤当成树节点，允许模型先生成多个候选思路，再评估、回溯和扩展
GoT 是 Graph of Thoughts，把推理状态组织成图，不要求严格树结构，允许多个分支合并、复用中间结论
ToT 更像“搜索 + 打分”，实现相对直接；GoT 更强调状态复用和复杂依赖表达，但工程复杂度更高

面试里可以补一句：二者本质都是把“一次性直出”改成“显式搜索 / 规划”，提高复杂任务的稳定性。

2. 如何设计 prompt？你认为好的 prompt 范式是什么？

我一般按“角色、任务、约束、上下文、输出格式、失败处理”来设计 prompt。

好的 prompt 范式通常包含：

任务目标：要解决什么问题，成功标准是什么
上下文输入：用户信息、检索结果、工具返回、历史对话
约束条件：不能编造、证据不足时要显式说明、优先使用哪些来源
输出格式：是否要求 JSON、分点、表格、字段名
边界处理：缺信息、冲突信息、工具失败时如何回复

一个实用模板可以写成：

你是{角色}。
你的任务是：{任务目标}。
可用上下文：{context}。
请遵守：
1. 只基于提供的信息回答；
2. 信息不足时明确说明；
3. 输出格式必须为{format}。

核心原则不是把 prompt 写很长，而是把目标、约束和输出契约写清楚。

3. 如果工具调用超时或返回空值，你如何设计Prompt让Agent反馈用户？

关键是不要让模型把“工具失败”误判成“答案不存在”。

我会在 prompt 里明确写：

如果工具超时，先告知用户“本次查询失败 / 超时”，不要伪造结果
如果工具返回空值，区分“没有查到”和“工具异常”这两种情况
优先给出下一步动作，例如重试、缩小查询范围、换一个工具或让用户补充条件
如果有部分结果，可先返回当前已确认的信息，再说明剩余部分未完成

例如可以加一条规则：

当工具调用失败、超时或返回空结果时，不得编造结论。
需要向用户明确说明失败类型、已完成的步骤、当前不确定点，并给出下一步建议。

这样 Agent 的行为会更可控，也更符合生产环境的可观测性要求。