腾讯混元大模型面试真题解析(上):9道RAG与Agent工程落地高频题

前言

近期腾讯混元大模型技术岗的面试题在技术圈引发广泛讨论，区别于传统算法岗的纯理论考察，这些题目全部瞄准生产环境落地的真实痛点：RAG检索效果差、文档更新不及时、高并发流式连接不稳、Agent执行重复与安全风险……

本文整理了9道高频工程类面试题，给出贴合大厂生产实践的完整解答，不管是备战面试还是优化线上RAG/Agent系统，都能直接参考落地。

1. RAG为什么要同时用稀疏检索和稠密检索？生产环境怎么调权重？

问题本质：考察对两路检索优劣势的理解，以及生产环境的调优方法论。

为什么必须两路结合

• 稀疏检索（BM25/倒排）：强项是精准关键词、专有名词、实体字面匹配，对专业术语、产品名、代码关键字召回极准；短板是完全不理解语义，同义词、改写问句、口语化提问很容易漏召回。
• 稠密检索（向量Embedding）：强项是语义匹配，能理解同义表达、长文本的语义关联，适配用户模糊提问；短板是容易丢失字面强特征，引入语义相近但事实无关的噪声。
• 融合价值：两路召回形成互补，同时保障召回率和精准率，解决单一检索方式的边界问题，是工业界RAG的标准配置。

生产环境权重调优方案

1. 基础加权融合：将两路得分做归一化后线性加权 总得分 = α × 稠密得分 + (1-α) × 稀疏得分，初始值通常设 α=0.5~0.6。
2. 动态自适应权重：
• 短query、含大量专业术语：调低稠密权重，提升稀疏检索优先级；
• 长问句、口语化、模糊意图：调高稠密权重，优先语义匹配。
3. 分层召回+重排：两路各自召回TopK，合并后用Rerank模型做二次精排，弱化人工权重的主观影响。
4. 数据驱动调参：通过线上A/B实验，以问答准确率、幻觉率为核心指标，迭代最优权重组合。

2. 文档频繁更新时，RAG如何做增量索引，避免全量切片向量化？

问题本质：考察RAG系统的可维护性与更新性能，是生产环境的核心痛点。

核心思路：变更驱动、增量处理、版本隔离，只处理发生变化的文档片段。

1. 变更监听与标记 给每个文档分配唯一DocID+版本号，通过消息队列监听文档新增/修改/删除事件，区分三类变更操作，避免全量扫描。
2. 差异化切片处理
• 新增文档：仅对当前文档做分块、向量化，写入向量库；
• 修改文档：对比新旧文本差异，仅重建发生变更的段落切片；若文档整体重写则全块重建；
• 删除文档：向量库做软删除标记，后台定时任务清理物理数据。
3. 向量库增量写入 利用Milvus、PGVector、Elasticsearch的增量写入能力，不重建全量索引；高频更新文档放在热分区，历史文档沉降到冷分区。
4. 版本元数据联动 每个文本切片绑定父文档版本号，检索时自动过滤过期版本的切片，避免新旧内容混杂。

3. RAG检索结果更新不及时，用户搜到旧内容，怎么定位和解决？

问题本质：考察排查问题的系统思维，以及生产环境的兜底方案。

定位排查四步走

1. 数据源层：检查变更消息是否丢消息、消费堆积，同步链路是否有延迟；
2. 处理层：增量切片、向量化任务是否执行失败，重试机制是否失效，是否存在资源限流阻塞；
3. 存储层：向量库软删除是否生效，索引是否未刷新，新旧向量是否共存；
4. 缓存层：前端/检索层是否命中旧缓存，缓存TTL是否设置过长。

落地解决方案

1. 同步可靠性保障：变更消息增加死信队列，失败任务定时重试，配置消费延迟告警；
2. 检索时效过滤：检索请求强制携带时间阈值，自动过滤早于阈值的过期切片；
3. 缓存主动失效：检索结果缓存设置短TTL（30s~5min），文档更新时主动触发对应缓存清理；
4. 兜底强制刷新：提供「强制刷新检索」接口，支持绕过缓存拉取最新知识库内容。

4. 如何评估RAG系统效果？检索和生成环节分别看哪些指标？

问题本质：考察对RAG全链路的度量能力，判断是否能体系化优化系统。

检索环节核心指标

• 效果指标：Recall@K、Precision@K、F1@K、NDCG@K（衡量相关文档的排序质量）；
• 工程指标：检索平均耗时、QPS承载能力、两路召回重合度、重复切片占比。

生成环节核心指标

• 质量指标：事实准确率、幻觉率、答案完整度、答案与检索文档的一致性；
• 用户指标：问答通过率、人工满意度、重复提问率；
• 成本指标：单问答Token消耗、重排调用成本、知识库检索命中率。

评估体系搭建

离线自动化评测 + 线上抽样人工标注 + 用户负反馈埋点，三者结合形成闭环优化。

5. QPS 1000+场景下，SSE流式连接怎么做心跳检测、超时释放和资源复用？

问题本质：考察高并发场景下流式服务的稳定性设计，是大厂C端产品的必考点。

1. 心跳检测机制 服务端每15s下发一次心跳空消息，客户端30s未收到心跳则主动断开；客户端上报心跳ACK，连接存活状态存入Redis统一管理。
2. 超时释放策略
• 闲置超时：单连接60s无用户交互，自动关闭SSE连接，释放推理资源；
• 推理超时：单轮流式输出设置30s上限，强制中断任务回收算力，防止异常请求占满资源。
3. 资源复用方案
• 连接池化：HTTP长连接池复用底层连接，减少频繁握手开销；
• 推理池化：模型推理实例池化调度，流式任务排队执行，不重复创建模型进程；
• 会话缓存：用户上下文存入Redis，连接断开重连可恢复会话，无需重新发起推理。
4. 限流隔离：限制单用户最大并发SSE连接数，避免单用户占用过多服务资源。

6. 流式输出适配小程序/APP/PC，怎么解决Markdown兼容、乱序和渲染卡顿？

问题本质：考察多端适配的工程经验，以及流式场景的前端体验优化。

1. Markdown兼容治理 后端输出标准化的轻量化MD子集，剔除各端不兼容的复杂语法（嵌套HTML、复杂表格、特殊公式）；新增语法转换中间层，根据客户端类型自动适配对应格式。
2. 内容乱序根治 每个流式分片携带自增序号seq，前端按seq重排后渲染；异常分片先缓存，补齐序号后再展示；服务端单会话串行输出分片，避免并发下发导致乱序。
3. 渲染卡顿优化
• 后端批量打包分片（200ms一批）下发，减少前端DOM刷新频率；
• 长对话启用虚拟滚动，仅渲染可视区域内容；
• 前端采用增量追加渲染，避免每次分片都全量重绘DOM。

7. 多用户同时触发同一个Agent任务，怎么设计幂等机制避免重复执行？

问题本质：考察分布式系统的幂等设计能力，以及Agent任务的状态管理。

1. 全局唯一幂等标识 每个任务生成全局唯一TaskID（用户ID+请求特征+时间戳），前端每次请求携带，作为幂等主键。
2. 分布式锁抢占 基于Redis实现分布式锁，锁过期时间大于任务最大执行时长；抢占失败直接返回「任务执行中」，不重复触发流程。
3. 任务状态持久化 数据库存储任务全生命周期状态：待执行/执行中/成功/失败；执行前先查询状态，已完成任务直接返回缓存结果。
4. 子步骤幂等兜底 Agent的每一次工具调用、数据库操作，都携带子步骤幂等Key，底层操作增加唯一约束，避免重复执行副作用。

8. Agent生成SQL、代码、Shell命令时，怎么设计安全校验与确认机制？

问题本质：考察Agent的安全风控设计，是生产落地的红线问题。

采用四层安全防护体系：

1. 前置语法拦截：语法解析器自动识别高危指令（SQL全表删除、Shell rm -rf、系统权限修改），直接拦截拒绝执行。
2. 沙箱隔离执行
• SQL：只读库访问，限制查询行数，禁止DDL语句，敏感数据自动脱敏；
• Shell/代码：容器沙箱内执行，限制CPU/内存/执行时长，禁止访问宿主机与内网核心服务。
3. 分级人工确认
• 低风险（单表查询、简单计算）：自动执行；
• 中风险（少量数据修改、文件读写）：弹窗展示内容，用户确认后执行；
• 高风险（批量删除、系统变更）：强制人工复核，管理员二次审批。
4. 全量审计溯源：所有执行语句完整落库，记录操作者、时间、执行结果，支持全链路安全审计。

9. Agent执行过程如何实现全链路追踪？怎么记录调用状态？

问题本质：考察Agent系统的可观测性设计，是排查问题、迭代优化的基础。

1. 全局TraceID串联 单会话分配唯一TraceID，所有日志、请求、存储统一携带该ID，串联起完整执行链路。
2. 分层全量记录
• 会话层：完整对话历史、系统Prompt、动态改写后的Prompt；
• RAG层：召回的文档ID、切片内容、检索得分、重排结果；
• 调度层：规划器输出的任务步骤、工具调用顺序与决策依据；
• 工具层：每个工具的入参、返回结果、执行耗时、异常报错；
• 模型层：模型版本、输入输出Token数、推理耗时、采样参数。
3. 存储与可视化 实时日志接入ELK用于检索排查，完整链路数据归档到对象存储；搭建排查平台，输入TraceID即可展示时序执行链路，快速定位异常节点。

写在最后

这9道题全部围绕「生产落地」展开，也是当前大模型应用开发岗位的核心考察方向——不再只懂算法原理，更要能解决高并发、高可用、低成本的工程问题。

下篇我们会继续拆解剩下的9道架构与商业化题目，覆盖0到1平台设计、多模型路由、企业级Agent体系、产品价值评估等内容。

如果本文对你有帮助，欢迎点赞、在看、转发给身边正在准备大模型面试的朋友。