面试题 · Prompt
搜索「RAG 检索增强生成」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请阐述ReAct（Reasoning + Acting）框架的核心思想，并分析其在复杂任务（如问答、决策）中为何优于传统的纯提示（prompt-only）方法。
ReAct = Reasoning（推理）+ Acting（行动），核心是将内部思维链与外部工具交互交织进行：
循环：Thought → Action → Observation → Thought → ...区别于纯提示方法，ReAct不是一次性生成答案，而是通过多轮迭代，让模型主动决定何时思考、何时行动、何时终止。
| 维度 | 纯提示/Prompt-only | ReAct |
|---|---|---|
| 事实准确性 | 依赖参数记忆，易幻觉 |
学习内容与项目面试，在同一条路上。
| 通过工具（搜索、数据库）获取实时信息 |
| 推理可解释性 | 黑盒输出 | 显式展示思考过程，便于调试和审计 |
| 动态适应性 | 静态响应 | 根据环境反馈调整策略 |
| 复杂任务拆解 | 一次性生成，易遗漏 | 分步执行，每步验证 |
典型场景对比：
建议系统学习该知识点
场景切入
假设你在做一个智能客服，用户问‘我的订单到哪了’，你直接调API查物流。但如果用户接着问‘那退款流程呢？’——你是让模型直接回答，还是先查一下退款政策再回答？能不能让模型像人一样，一边想一边查，最后再给答案？
层层追问
你觉得纯prompt的方式做复杂问答，比如‘比较GPT-4和Claude的推理能力’，模型直接回答会有什么问题？……那如果让它先搜索再推理呢？……具体怎么把搜索和推理串起来？每一步做什么？
直球架构
请阐述ReAct框架的核心思想，并解释为什么它在复杂任务中比纯prompt方法好。关键讲清楚它怎么处理事实准确性、可解释性和动态适应性这些点。
这道题其实问的是，当模型面对复杂任务时，光靠内部参数记忆为什么不够，以及我们怎么让它主动借助外部工具来补齐短板。[[ReAct]]的核心就是推理和行动交替进行，形成一个Thought→Action→Observation→Thought的循环。你可以把它想象成模型自己当项目经理，先想下一步要干嘛，然后调用一个工具，比如查数据库或搜网页，看到结果再接着想，直到任务完成。
那它为什么比纯提示好呢？纯提示就是一次性把答案吐出来，依赖模型内部参数，容易产生 [[Hallucination]]，特别是涉及实时信息或需要多步推理的时候。比如你问“今天北京飞上海的航班有哪些”，纯提示可能编造一个不存在的航班。而ReAct会先去查实时航班数据，拿到结果再组织回答。
但这里有个边界划分的问题。不是所有任务都需要ReAct。纯提示对于简单的事实问答、常识推理，其实更快更省成本。比如“苹果和橘子哪个更甜”，这种纯提示就能搞定。真正落地的时候，往往是ReAct和纯提示混着用，或者ReAct跟 [[RAG]] 结合。比如客服退款场景，用户说“我买的东西降价了，能退差价吗”，纯提示只能给个通用话术，但ReAct可以拆成几步：先查订单状态，再查当前价格，然后算差价，最后看是否符合满减政策。每一步都调用不同的工具，比如订单系统、价格库、规则引擎，最后给出准确答复。
再说落地风险。ReAct看起来很美好，但前提是工具描述要足够清晰。如果Action空间里工具的定义模棱两可，模型可能选错工具，比如该查订单号却去查了用户ID。还有一个常见失败场景是缺乏错误恢复，比如外部系统挂了，Observation返回异常，模型可能就卡住了。所以上线时我会特别关注终止条件和重试机制，比如设置最大步数，或者当Observation包含错误信息时，让模型重新规划而不是硬撑。
还有一个延伸点，就是ReAct的推理轨迹本身其实可以作为 [[Few-shot]] 示例，帮模型更快学会怎么拆解任务。但这也要求轨迹质量高且覆盖典型错误，否则模型会学到错误模式，反而降低效果。
所以我会把ReAct看作一个可编排的循环，核心是让模型学会什么时候该想、什么时候该动、什么时候该停。它不是银弹，而是在需要多步推理和实时信息时，比纯提示更可靠的方案。