百度 AI Agent开发一面

1.多轮对话中，如果不同轮次的记忆发生冲突，你如何处理？

这个问题本质上不是“删哪条、留哪条”，而是做记忆的版本管理。实际处理时一般会同时看三个维度：时间、来源、置信度。时间上通常新信息优先，但前提是它来自更可信的输入；来源上，用户当前轮明确表达、工具查询结果、系统写入，优先级通常高于模型从历史里自己总结出来的内容；置信度上，如果只是一次低置信抽取，不会直接覆盖长期稳定画像。

工程上我会把记忆拆成两层，一层是 event log，完整保留用户每次表达过什么；另一层是 materialized profile，也就是给模型使用的当前画像。冲突发生时，不是直接物理覆盖，而是先记事件，再按规则刷新画像。如果冲突很大，比如之前说“常驻北京”，现在说“长期在上海”，我会先标成待确认，优先在当前任务里使用最新信息，但不会马上把长期记忆彻底改掉。

2.chunk 切分时为什么要有重叠区域？比例一般怎么确定？

加重叠的原因很直接，很多语义不是刚好落在一个 chunk 里，而是跨边界分布的。如果硬切，前一个 chunk 可能只有定义，后一个 chunk 才有限制条件，单独看都不完整，召回时就容易漏。

比例没有统一答案，一般和文档类型、chunk 长度、信息密度有关。普通文本常见是 10% 到 20%，技术文档、规则文档、长句很多的材料，可能会放到 20% 到 30%。如果 chunk 本来就很短，重叠太大又会带来冗余，增加索引量和重复召回。实际做法通常是先按标题、段落、句子这些自然边界切，再加少量 overlap，而不是只按字符数机械滑窗。

def split_text(text, chunk_size=300, overlap=60):
    chunks = []
    start = 0
    while start < len(text):
        end = start + chunk_size
        chunks.append(text[start:end])
        start += chunk_size - overlap
    return chunks

3.是否做过关键词召回和向量召回的融合？具体怎么做的？

做过，这基本是线上检索比较常见的方案。因为关键词召回和向量召回各有短板，BM25 这类关键词召回对实体词、缩写、错误码、产品型号很敏感，但语义泛化差；向量召回擅长同义表达和自然语言问题，但在精确词匹配上不一定稳。融合之后效果通常比单路更均衡。

落地时一般是两路并行召回：一条走 BM25，一条走 dense retrieval，各自取 TopN，合并去重后做融合排序，再进入 rerank。融合方法可以是加权分数，也可以是 RRF 这种按排序做融合。进一步一点，还会先做 query 分类，如果判断是实体型 query，就提高关键词召回权重；如果是开放问答型 query，就提高向量召回权重。

def rrf_fusion(rank_lists, k=60):
    score = {}
    for rank_list in rank_lists:
        for rank, doc_id in enumerate(rank_list, start=1):
            score[doc_id] = score.get(doc_id, 0) + 1 / (k + rank)
    return sorted(score.items(), key=lambda x: x[1], reverse=True)

4.向量检索中 Top-K 设置过大或过小分别会带来什么问题？

Top-K 太小，最直接的问题就是召回不足。真正相关的 chunk 可能根本没进候选集，后面的 rerank 再强也救不回来。尤其是 query 本身比较模糊、文档切得很细、embedding 区分度一般的时候，K 太小会明显影响最终答案质量。

Top-K 太大也不是越多越好。候选一多，噪声会明显上升，rerank 成本更高，后面给大模型组上下文时也更容易把无关内容带进去，反而让生成变差。所以 Top-K 本质上是召回率、精确率、成本之间的平衡。线上一般不会写死一个值，而是根据 query 类型、召回置信度、文档域做动态调整。

5.rerank 之后的截断策略是怎么设计的？为什么选这个 K 值？

rerank 之后的截断不是简单“固定保留前 K 条”，而是同时看分数、token 预算和证据覆盖。因为有些问题只需要 2 到 3 个强证据，有些问题则需要多个片段拼起来才能答完整。

常见做法是先设一个最大 K，比如 5 或 8，再结合 rerank 分数阈值、相邻分差、去重情况做动态截断。如果前 3 条分数很高，后面明显掉档，那就没必要继续带；如果前几条各自只覆盖问题的一部分，就会多保留几条。为什么选这个 K，通常不是拍脑袋，而是通过离线评测看 answer accuracy、引用完整性、token 成本和时延，在效果和成本之间找平衡点。

6.HyDE 在 query 模糊时是如何提升召回效果的？

HyDE 的思路是先让模型根据用户 query 生成一段“假想答案”或者“伪文档”，再拿这段文本去做向量检索。因为很多 query 本身特别短，比如“权限怎么做”“发票规则呢”，这种表达语义太稀，直接 embedding 后检索空间里信息量不够。HyDE 会把潜在语义展开，比如补出角色、资源、策略、审批、范围这些相关概念，这样更容易召回到真正相关的文档。

但 HyDE 也不是一定更好。如果模型一开始就猜偏了，它生成的伪文档会把召回方向也带偏。所以线上一般不会只依赖 HyDE，而是保留原 query 召回，再把 HyDE 召回作为补充，最后做融合。

7.设计一个支持多轮对话 + 工具调用的 Agent，整体架构怎么拆？

这种 Agent 一般会拆成接入层、会话层、决策层、工具层、知识层和治理层。接入层负责 API、鉴权、流式输出；会话层维护 session、历史消息、当前状态和短期记忆；决策层负责意图识别、任务规划、工具选择和结束条件判断；工具层统一封装搜索、数据库、业务接口、代码执行这类能力；知识层负责 RAG、向量库、长期记忆和文档解析；治理层负责日志、监控、审计、限流和权限。

真正关键的是状态不能全靠模型“记住”，而要由系统显式维护。每一步都应该是读取状态、组装上下文、让模型决策、执行工具、写回状态、再进入下一步。这样工具调用、多轮记忆和流程控制才能稳定，不然一长链路就容易跑飞。