百度大模型应用面试：知识问答、上下文与记忆

可以设计成多源接入与治理、统一检索、证据问答、持续更新与评测四部分。接入内部Wiki、PDF、共享文档和工单时保留来源、版本及访问权限；解析清洗后建立关键词和语义索引；用户提问时先确定身份与问题范围，检索可访问的有效证据，再生成带出处的回答。

重点不是把所有文件转成向量，而是让跨来源的信息保持结构、及时更新且可核查。资料少时可以先做简单检索与问答，不必一开始就上知识图谱、多Agent和所有检索策略。

RAG（检索增强生成）通过检索外部知识，为大模型提供相关上下文，辅助生成有依据的回答。 以向量检索为例，完整流程分为两个阶段：

1. 索引阶段（离线）：加载、清洗文档，切分为适合检索的片段，通过 Embedding 模型进行向量化，建立索引，并关联保存片段原文、来源等元数据。
2. 检索生成阶段（在线）：将用户问题向量化，检索 Top-K 相关片段，按需过滤和重排，再将片段原文、原始问题和回答要求组织成 Prompt，由大模型生成答案。

例如，员工问“出差怎么报销”，系统先检索报销流程、凭证要求等制度条款，再据此组织回答。向量用于查找资料，片段原文才是模型生成答案的主要依据。

评估时，需要分别检查检索的相关性与覆盖度，以及答案的正确性和忠实性。其中，忠实性关注结论是否得到所用资料支持。资料不足时说明缺口，知识发生变化后同步更新索引及关联内容。

RAG 文档切分要在“检索能定位”和“片段足以回答”之间取舍。 常见策略有四类：

1. 固定长度切分：按字符数或 Token 数分块，适合快速建立基线。
2. 递归切分：优先按段落、句子等边界切分，超长部分再继续细分。
3. 结构化切分：依据标题、条款、函数或表格等文档结构组织片段。
4. 语义切分：根据相邻内容的语义变化确定边界，同时限制块的最小和最大长度。

确定块大小时，先明确长度单位与 Embedding 输入上限，再看问题需要多大的证据单元。块太小，容易拆开前提和结论；块太大，会混入多个主题，增加检索噪声与生成成本。通常先保留自然边界，超长部分递归细分，再用同一批业务问题比较块大小和重叠量，检查证据召回、答案质量、延迟与成本。

例如运维手册中的适用版本、触发条件和恢复步骤应能一起取回。需要“小块定位、大段阅读”时，可以用父子块，把写入索引的子块与交给模型阅读的父段落分开。

Agent 的上下文，是当前这次模型调用能够看到、用于判断下一步的信息。它通常有五类：

1. 指令与当前任务：角色、行为边界、输出要求，以及用户本次要完成的目标和已确认条件。
2. 相关对话历史：必要的用户消息、助手回复和工具交互，帮助理解指代、修改和连续任务。
3. 工具与输出契约：当前可用工具的名称、用途、参数 Schema，以及需要时的结构化输出格式和示例。
4. 外部证据：检索片段、文件内容、工具结果等，附上必要的来源、版本或时间。
5. 记忆与任务状态：与本轮有关的偏好、已确认事实、计划、已完成步骤和待解决问题。

组织时先按当前任务筛选，再按来源和职责分块，保持消息角色及工具调用与结果的关联。注入时由宿主把这些内容适配成模型支持的消息、工具定义和输出格式；数据库里保存过的信息不一定全部进入本轮上下文。每轮调用前还要检查 Token 预算，为回答和后续工具反馈留出空间。

控制上下文要区分完整历史的存储和本轮模型的输入。历史保存在 Redis 或检查点里，不代表模型会自动读到；本轮不发送旧消息，也不必删除原始记录。调用前应统计指令、工具定义、历史和工具结果的 token 占用，按模型窗口预留输出空间，在超限前处理长输入。

再按信息的后续用途选择策略：

• 保留原文：近期讨论、最新更正，以及需要精确引用的内容。
• 直接裁剪：已经结束、与当前任务无关的过程。
• 抽取或摘要：把当前目标、仍生效的约束、已确认进度和待核验事项整理成简短状态。
• 外置并按需取回：长网页、报告和旧材料放在外部存储，需要时再读取相关原文。

例如报告范围从“上半年”改成“第二季度”，摘要要保留新范围和原有的来源要求。取舍是否合理，要用多轮任务检查约束、更正和关键事实有没有丢；质量达标后，再比较 token、耗时与成本。

下面用一个 32,000 token 的预算例子，把“保留、裁剪、摘要、外置”四种处理方式放在一起比较。报告范围发生更正时，也要把新约束带入下一轮。

Agent 的记忆要围绕写入、使用和维护管理。先区分当前会话的短期状态与跨会话保留的长期信息：前者保存任务进度、消息和工具结果，后者选择性保存以后仍有价值的用户偏好、事实或经验。

写入时判断信息是否值得长期保留，并记录来源、时间和适用范围；使用时先按用户、项目等范围筛选，再检索与当前任务相关的记忆，控制进入上下文的内容；维护时处理纠错、冲突、过期、去重和删除。最后用多轮任务验证能否记对、用对、改对、忘掉，而不只检查“数据是否存进了向量库”。

例如用户平时要求中文报告，这可以成为长期偏好；本次临时要求英文，应覆盖当前任务的输出语言，但不应直接改掉长期偏好。

我会先判断冲突是不是发生在同一主体、同一字段、同一适用范围和时间，再决定当前使用哪条信息，最后单独决定是否更新长期记忆。不能简单按“长期记忆更稳定”或“最后一句话永远优先”处理。

• 当前任务偏好：用户这次明确要求详细解释，就按这次要求回答；这不自动把“平时偏好简短”改成永久详细。
• 明确事实变化：用户确认已经从北京搬到上海，就把上海设为当前居住地，并保留北京曾在何时有效的历史。
• 客观状态或高风险信息：要核对来源与有效时间；冲突尚未消解时，保留待核实状态，必要时澄清，不能让一句模糊表述覆盖业务记录或重要限制。

例如“一个月前喜欢吃辣，一周前不能吃辣”，偏好和当前限制本来就是两个字段。系统应尊重仍有效的限制，必要时确认其适用时间，不能根据旧偏好推断用户现在可以吃辣。

设计多 Agent 系统，先确定谁负责什么、谁决定下一步、交付什么结果、失败后怎样继续，再选择框架和 Agent 数量。每个角色要能独立完成一个可验收的子目标，单纯把提示词换成几个角色名，不能解决协作问题。

以研搜系统为例，我会采用“主智能体协调、专家取证、统一汇总”的结构：网络、数据库和内部知识库专家分别获取不同来源的信息，主智能体理解目标、派发任务、检查信息是否齐全并组织最终答案。具体把协作落到五件事上：

1. 职责与任务契约：给每个专家明确目标、输入、可用工具、输出格式和完成条件，避免重复检索或遗漏问题。
2. 控制流与依赖：固定步骤由代码编排，不确定的搜索方向交给模型；输入齐备且互不依赖的任务才并行，有依赖的任务按顺序执行。
3. 通信与上下文：传必要背景、结论和证据引用，各自保留局部上下文，不把所有原始对话广播给每个 Agent。
4. 状态与恢复：编排器记录任务状态和产物，约定并行结果如何合并，对超时、重试、总预算和停止条件做硬限制；涉及外部写操作时保证幂等。
5. 汇总与验证：统一检查来源、缺失项和冲突，必要时补查；用任务成功率、事实与引用准确性、延迟和费用评估，确认多 Agent 的收益覆盖协调成本。

模型负责在子目标内探索，编排层负责约束执行和推进状态。这样既能利用专业分工，也能在部分任务失败或意见不一致时有明确处理路径。

动态模型选择可以分两步：先筛出能够且允许处理本次请求的候选，再在满足业务效果要求的候选中权衡成本、时延与当前可用性。任务类型、输入模态、上下文长度、工具调用需求和数据边界决定候选范围；业务评测、剩余时间、预算、配额和服务状态决定本次选择。

第一版通常用配置化规则就能落地：为不同场景维护候选集合和默认策略，每次请求结合输入特征与实时状态做选择。任务分类复杂、请求分布较稳定且已有足够评测数据时，再引入轻量分类器或学习型路由。低成本模型先试、校验失败再升级也是一种方案，但它会增加调用与等待，只有存在可靠校验且允许额外延迟时才适合。

路由效果最终看整个任务的成功率、端到端时延和总成本，而不是只看某次模型调用便宜了多少。模型更贵、参数更多或某个公开榜单更高，都不能代替它在当前任务上的效果依据。

Harness 要把模型的动作建议交给可信的授权与执行层检查，再在受限环境中执行。核心是明确“谁能对什么资源做什么”，并让约束在模型判断错误时仍然生效。

• 身份与最小权限：从认证会话取得用户、租户和授权范围，按任务开放必要工具；每次执行前校验参数、资源归属和业务状态，不能接受模型自行声明的身份或批准标记。
• 执行隔离：文件、命令和网络访问分别设边界。限制可读写目录、进程权限、网络出口和资源预算，子进程也要受相同约束；提示词中的目录要求不能替代实际隔离。
• 按风险处理授权：已获授权且在范围内的操作可以自动执行；超出范围或需要额外确认的动作，先展示具体目标和影响。授权要绑定工具、资源、参数和有效期，拒绝后不能换个工具绕过。
• 数据与记录：网页、文档和工具结果作为不可信数据；凭据留在执行层，返回和日志做必要脱敏。记录允许、拒绝、授权与实际执行结果，并验证越权、注入和重复执行等场景。

例如 Coding Agent 可以在获准工作区内读代码、修改文件并运行测试；读取其他用户文件、访问凭据目录或向新地址上传内容，应由资源与出口策略决定是否允许，不能因模型说“任务需要”就自动放行。