百度 AI Agent 工程师 - 面试题 & 面经
Q: 搜索场景下的 Agent 和传统搜索引擎的技术路线差异是什么？如何融合？
💡 思考逻辑： 百度核心业务是搜索，面试官考察你对搜索 + Agent 融合的理解，不能把搜索简单理解为 RAG。
参考答案： 传统搜索是 query → index → rank → display 的检索范式，搜索 Agent 是 query → understand → plan → search+synthesize → generate 的生成范式。关键差异：1）意图理解深度——传统搜索做关键词匹配和 query 改写，Agent 做深层意图推理（'周末去哪玩'→分析偏好、天气、距离等多维度）；2）结果呈现——传统搜索返回 10 条链接，Agent 返回综合性答案；3）多步推理——Agent 可以 chain 多次搜索（先搜目的地→再搜天气→再搜交通），传统搜索是单次；4）融合方案——用 Agent 做意图层和编排层，底层仍复用搜索引擎的倒排索引和排序能力作为 Tool。百度的'AI 搜索'就是这个路线，文心一言做上层推理，搜索引擎做底层检索。
Q: 自动驾驶场景中 LLM Agent 可以扮演什么角色？有哪些技术可行性和限制？
💡 思考逻辑： 百度有 Apollo 自动驾驶业务，面试官考察你对 LLM 在安全关键系统中的限制是否有清醒认识。
参考答案： LLM Agent 在自动驾驶中的角色：1）场景理解与决策辅助——用 VLM（视觉语言模型）理解复杂路况（'前方有施工，右侧有行人准备过马路'），辅助规划模块做决策；2）人车交互——乘客用自然语言与车辆交互（'找个安静的咖啡厅'），Agent 编排导航 + POI搜索 + 路线规划；3）异常场景处理——遇到规则引擎覆盖不到的 corner case，用 LLM 做推理兜底。限制：1）延迟——自动驾驶要求毫秒级决策，LLM 推理太慢，只能做非实时决策层；2）确定性——自动驾驶需要行为可预测，LLM 的随机性不可接受，必须加确定性校验层；3）责任归属——LLM 决策出错时的法律责任不明确。百度 Apollo 的方案是 LLM 做高层规划 + 传统算法做底层控制。
Q: 文心一言的插件（Plugin）系统和 OpenAI 的 Function Calling 在设计理念上有何异同？
💡 思考逻辑： 面试官考察你对不同生态技术方案的横向对比能力，不是只会用一家的 API。
参考答案： 相同点：都是让 LLM 调用外部工具扩展能力，都需要工具描述 + 参数解析 + 结果注入。差异：1）接入标准——OpenAI 用 JSON Schema 描述函数签名，文心一言插件用类似 OpenAPI 的描述格式，更重视 HTTP API 直接接入；2）生态策略——OpenAI 侧重开放生态（GPT Store），百度侧重与自有生态整合（百度地图、百度网盘、小度设备）；3）安全模型——文心一言对插件的安全审核更严格（符合国内监管要求），涉及内容安全、数据安全双重审核；4）执行模式——OpenAI 是 LLM 生成 function call JSON → 客户端执行 → 结果返回；文心一言支持服务端直接执行插件，减少一次往返；5）多工具编排——文心一言原生支持多插件串联调用的 plan-and-execute 模式。
Q: 如何优化 RAG 系统中的 Query 改写和多路召回策略？
💡 思考逻辑： 百度有搜索基因，面试官考察你对检索技术的深入理解，RAG 不只是'切分+embedding+检索'。
参考答案： Query 改写策略：1）意图澄清改写——用 LLM 将模糊 query 改写为精确 query（'那个手机'→'iPhone 16 Pro Max 256GB'）；2）多角度改写——生成 3-5 个不同表述的 query 扩大召回范围；3）Hypothetical Document Embeddings (HyDE)——让 LLM 先生成一个假设性答案文档，用这个文档的 embedding 做检索，效果往往优于原始 query。多路召回策略：1）向量检索——语义匹配，用 BGE/M3E 等中文 embedding 模型；2）关键词检索——BM25/TF-IDF，擅长精确匹配专有名词；3）知识图谱检索——实体关系查询，适合结构化知识；4）融合排序——用 Cross-Encoder Reranker（如 bge-reranker）对多路结果统一打分排序。百度搜索天然有海量 query log，可以做 query 改写的监督微调。
Q: 如何设计 Agent 的幻觉检测和抑制机制？
💡 思考逻辑： 搜索场景对准确性要求极高，面试官考察你对幻觉问题的系统化解决方案。
参考答案： 幻觉检测和抑制多层方案：1）生成时抑制——设置较低的 temperature（0.1-0.3），使用 Constrained Decoding 限制输出格式；在 system prompt 中强调'只基于提供的信息回答，不确定时说不知道'；2）生成后检测——事实核查模块：将 Agent 输出拆解为原子事实声明（atomic claims），每个声明与检索到的源文档做 NLI（自然语言推理）判断是否矛盾；3）自我一致性检测——让模型对同一问题多次生成，如果答案不一致则标记为可能幻觉；4）引用追溯——要求 Agent 在回答中标注信息来源，无法标注来源的内容大概率是幻觉；5）人工反馈闭环——用户标记的幻觉案例积累成负样本，用于 DPO/RLHF 持续优化。
Q: Scaling Laws 对 Agent 系统设计有什么指导意义？如何平衡模型规模和推理成本？
💡 思考逻辑： 面试官考察你对模型选型的理性思考，不盲目追求大模型，要会算成本账。
参考答案： Scaling Laws 揭示：模型性能随参数量、数据量、计算量按幂律增长，但增长速率递减。对 Agent 设计的指导：1）模型选择——不是越大越好，要找性价比拐点，7B-13B 模型经过充分训练可以在特定任务上接近 70B 效果；2）路由策略——简单任务用小模型（成本低、速度快），复杂任务用大模型，用 Intent Classifier 做路由，整体成本可降 60-80%；3）专业化微调——在特定领域数据上 SFT 微调的 7B 模型可以超过通用 70B 模型，因为 Scaling Law 中数据质量是关键变量；4）推理优化——大模型部署用 TensorRT-LLM + Continuous Batching + Speculative Decoding 组合拳。百度的方案是多尺寸模型矩阵（文心 ERNIE Speed/Lite/Tiny）覆盖不同场景。