反思机制与智能体评估框架

在课程评估与追踪链路中，本地 JSONL 文件用于保存测试输入、参考答案与授权资料 ID；自托管的 Langfuse 则通过 dataset items 和 experiments 对比不同版本表现，并记录脱敏后的运行追踪、用户反馈与错误日志。实验过程中，数据集的 input / expected_output、提示词整数版本号（version）与底层语料 hash 均需分别独立保存。

通过反思循环提高输出质量

反思循环（Reflection Loop）是一种让智能体在向用户返回最终答案前，先对初步生成结果进行自查、评估与修正的策略。它以额外的模型调用耗时为代价，换取更高的回答质量与准确性——在输出准确性优先级高于数秒延迟的生产场景中，这种取舍往往是值得的。

简单自我评价

最基础的做法是“先生成初稿，再追加一次自检调用”：在生成初步答案后，向同一个 LLM（或另一个模型实例）追加提示词（如“请检查上述答案是否正确、是否严格遵循了全部指令”），输出简单的“是/否”判定或具体问题清单。单纯的自我评价步骤本身不会自动修改答案，但能及时暴露明显错误，供系统记录日志或触发人工复核。在 LangGraph 中，只需在生成节点之后串联一个评价节点即可实现。

实现方式：增加一次模型调用即可。例如，第一次生成答案，第二次要求“评估上述答案的正确性及存在的错误”。发现问题后，可以记录或交给人工检查。LangGraph 中可以让生成节点连接评价节点。若要提高最终结果，还需要将反馈用于修改。

带重试的迭代反思

更进一步的做法是将评价反馈送回生成端重新作答，构成 生成（Generate）→ 反思（Reflect）→ 修改（Revise） 的闭环循环。智能体在检视初稿并指出缺陷后，在下一轮提示词中附带修改指令（如“根据上述反馈给出改进后的答案”），直至评估通过或达到最大迭代轮数上限 kkk。

以下示例使用 StateGraph 和 MessagesState 保存消息，另用 attempts 统计生成次数，最多生成三版答案。消息数与修改轮数不是同一口径。

from langchain_core.messages import AIMessage, HumanMessage
from langgraph.graph import StateGraph, MessagesState, START, END


class ReflectionState(MessagesState):
    attempts: int


def build_reflection_graph(generate_answer, review_answer, max_attempts=3):
    # 两个回调均接收消息列表、返回字符串；模型调用由应用提供。
    if max_attempts < 1:
        raise ValueError("max_attempts must be positive")

    def generate_node(state):
        answer = generate_answer(state["messages"])
        return {"messages": [AIMessage(content=answer)],
                "attempts": state.get("attempts", 0) + 1}

    def reflect_node(state):
        feedback = review_answer(state["messages"])
        return {"messages": [HumanMessage(content="请根据评价修改答案：" + feedback)]}

    def should_continue(state):
        return END if state["attempts"] >= max_attempts else "reflect"

    builder = StateGraph(ReflectionState)
    builder.add_node("generate", generate_node)
    builder.add_node("reflect", reflect_node)
    builder.add_edge(START, "generate")
    builder.add_conditional_edges("generate", should_continue)
    builder.add_edge("reflect", "generate")
    return builder.compile()

应用向 build_reflection_graph 传入生成和评价回调，两个回调均接收消息列表并返回文本。节点返回字典，MessagesState 的 reducer 负责合并消息。评价作为待处理反馈传给下一轮生成；最终返回最后一版生成结果。示例只演示有界循环，不证明反思必然提高答案质量。参见LangGraph 官方说明。

结合外部反馈的 Reflexion：标准的 Reflexion 模式在反思阶段进一步引入了外部工具与知识检索。当模型在自查时发现某项论断缺乏事实依据，可主动发起搜索工具调用，结合新检索到的外部证据与引用修正答案，或结合长期记忆与计算器验证结果，从而比纯内部自省更有效地消除事实错误。

3. 先评价再修改（Critique-Then-Revise）

Critique-Then-Revise 将“起草 → 评价 → 修改”固化为结构化的三步序列（既可通过单次结构化提示词完成，也可拆为固定调用链）：

例如，在 system 或 few-shot 提示词中规定：第一步，回答用户问题；第二步，识别草稿中的事实错误和不足；第三步，修正问题，只输出修改后的答案。过程中的草稿和问题列表用于生成最终结果。

这种自我修订方式具有以下优势：

改进目标明确：显式列出问题清单，减少修改时遗漏或重犯同一错误的概率。
降低过度自信：主动检查错误，有助于减少导致幻觉的不当确定性。
可闭环自包含运行：在无需外部人工干预的情况下即可在单次调用或短链条内完成自检。

同时需要考虑：

Token 消耗与延迟翻倍：多步输出（含初稿与长篇评审意见）通常会使 token 消耗量增加到原来的两倍以上，显著拉长延迟并增加 API 费用。
受限于既有知识边界：如果上下文中本来就缺失关键事实，模型单靠自我评价最多只能意识到“信息不足”，却无法凭空变出正确事实——此时必须配合外部检索或工具调用。

用户只需看到整理后的结果。这种方法适用于问答、解释生成，以及初次代码中存在模型能够通过检查发现的问题的任务。

排查幻觉与提高可靠性

幻觉指模型以肯定语气输出事实错误或没有意义的内容，是 LLM 智能体的重要问题。反思可以鼓励自查，本节进一步讨论如何结合内部策略与外部工具，系统发现、诊断并减少幻觉。即使设计良好，模型仍可能产生错误，因此需要持续识别这些失败，建立可信系统。

幻觉是什么，为什么出现？

幻觉（Hallucination）是指模型以笃定的语气输出与客观事实或所给材料不符、乃至完全凭空捏造的内容（例如当用户询问一份并未放入上下文的文档时，模型却编造出一段看似有模有样的摘要）。由于 LLM 本质上是在根据预训练习得的统计语言模式预测高概率 token，当遇到训练语料缺失或过时、提示词指令含糊、上下文窗口过长导致中间关键事实被忽略，或者模型在缺乏把握时仍强行作答，就会产生幻觉。在生产环境中，幻觉会严重侵蚀用户信任，因此发现、诊断并抑制幻觉是 LLMOps 的核心工作。

生产环境中的幻觉会损害信任，关键信息错误还可能造成伤害。因此，幻觉排查是 LLMOps 的重要任务，需要既能发现单次错误，也能降低总体发生率。

1. 如何发现幻觉

第一步是判断输出是否存在幻觉。开放任务没有现成标准答案时尤其困难。下面回顾 RAG 评估中涉及的方法：

有参考答案的评估：在具备标准答案的离线测试集上，除使用 BLEU、ROUGE 衡量字面重合度外，还可采用 RAGAS 的 Answer Correctness 等指标——将模型回答拆解为独立事实陈述，对照标准答案计算事实级的精确率与召回率。

无参考答案的上下文忠实度评估：在线上生产环境中通常没有预置标准答案，但若系统基于检索文档作答，即可检查回答对检索上下文的忠实度（Faithfulness）与上下文利用率（Context Utilization）。通过另一个模型或程序将回答拆解为事实陈述并逐条回溯检索原文，凡是无法从参考资料中找到依据或合理推导出的陈述，均标记为疑似幻觉。

LLM 事实检查：没有参考答案或上下文时，也可以让另一模型或同一模型判断正确性。例如，向评判模型提供用户问题与助手回答，要求检查是否真实、指出问题。同一模型同时回答和评判时，可能遗漏自己的错误，也可能把正确内容误判为错误，但仍可作为一个信号。更可靠或专门化的评判模型可能有所帮助。

人工反馈：用户或内部评审可以指出错误，是发现细微或高影响幻觉的重要来源。人工无法逐条检查所有结果，但反馈按钮、评分和抽样评估，可以补充自动方法，帮助了解幻觉发生频率及形式。

运行轨迹与启发式规则监控：分析 Trace 轨迹常能直接抓出异常——例如检索工具明明返回了空结果或报错，模型随后却给出了言之凿凿的详细回答；或者模型在回答中声称“根据某资料”，但工具调用记录里根本没有读取过该资料。通过启发式规则监控这类状态矛盾，可实时拦截明显幻觉。

生产系统通常结合多种方法，例如每个答案使用 LLM 评估，收集用户反馈，并每天对有标准答案的测试集进行离线评估。

2. 根因分析与状态检查

定位到幻觉样本后，需结合详细日志与状态 Trace 排查根因：

审查提示词与对话输入：用户提问是否过于含糊、缺失必要背景？系统提示词是否未明确禁止猜测？若启用了反思循环，反思节点是否识别出了问题、生成节点是否真正采纳了修改建议？
审查工具调用与检索结果：智能体是否漏调了工具，或者在工具返回“未找到结果”时未触发查询改写与拒答逻辑，反而自行编造答案？
检查可用的中间过程：若应用能够取得模型的显式中间步骤，可以检查是否早期做出错误假设，或已知道信息缺失却继续猜测，再调整指令与流程。并非所有模型都提供内部推理内容。
归纳跨案例共性模式：例如，当系统提示词强制要求“每次回答必须附带引用来源”，但当前问题并未挂载检索工具或检索为空时，就会逼迫模型捏造虚假引用；此外还需检查多步状态传递与历史摘要压缩过程中是否掺入了错误事实。
将失败样本对应的状态快照、工具参数、权限判断与评价结果关联到同一次运行，区分检索失败、调用失败和答案事实错误。

3. 减少与预防幻觉的工程措施

诊断后，需要修改系统并验证是否减少后续错误。

收紧提示词与拒答边界：在系统指令中明确要求“依据不足时直接说明限制或请求用户澄清，严禁猜测编造”，并配合 Few-shot 示例展示标准的拒答话术；对复杂推理任务采用分步拆解提示。
强化检索增强（RAG）：接入权威知识库或网页搜索，并通过评估确保模型确实使用了检索到的上下文。
前置输出护栏检查：在草稿返回给用户前，串联第二个校验模型或规则检查器；一旦发现无依据陈述，立即打回重改或替换为安全兜底说明。
优化工具路由与反思条件：针对跳过工具或误用工具的案例修正路由逻辑（例如强制规定所有涉及库存的数据查询必须先经过检索工具）。
要求外部证据：让答案提供引用或依据，便于审查。引用并不消除幻觉，但可以检查来源是否真的支持主张；无法找到来源时，应进一步核实。评估时也可以考察各项主张是否有提供资料支持。
利用线上错题持续学习：收集真实对话中的“提示词 + 错误回答 + 修正后正确回答”构建偏好数据集，用于后续微调或強化学习奖励建模（这是较复杂的长期演进路径，目前在实际工程中尚未见到广泛采用）。

幻觉排查是持续循环：发现问题，通过轨迹与反思分析原因，应用修改，再评估是否有效，以及是否引入其他问题。

Agent系统的评估与改进循环 — Agent的追踪记录与人工反馈进入评估流程，未通过的案例推动系统和应用继续改进。

智能体评估的主要组成

在课程评估体系中，本地 JSONL 保存输入、参考答案和授权资料 ID；自托管 Langfuse 使用 dataset items 和 experiments 对比版本，并记录脱敏追踪、反馈与错误，分别保存数据集 input / expected_output、提示词整数 version 和语料 hash。完整的智能体评估框架通常包含以下四个要素：

评估指标与多维标准：

正确性（Correctness）：最终回答是否准确无误？
相关性（Relevancy）：是否紧扣主题并完整回应了用户需求？
幻觉率（Hallucination Rate）：是否夹带无法核实或凭空捏造的信息？
工具使用正确性（Tool Use Accuracy）：是否按预期调用了正确的工具及参数（可通过比对工具调用轨迹评估，如需要查库时是否真实调用了数据库工具）？
稳健性（Robustness）：当用户提问方式略微改写时，输出质量是否保持稳定？
安全性与合规性（Harmfulness & Policy Compliance）：是否生成有害内容或违反业务准则？
效率：需要多少步骤和时间？

自动化评估器（Automated Evaluators）：尽可能将上述指标转化为自动化测试——既可以使用 LLM-as-a-Judge 按评分细则打分，也可以在确定性测试环境中用 Python 函数直接断言工具调用序列是否匹配预期，从而快速跑完成百上千条回归用例。

人工评估（Human Evaluation）：针对语气风格、实际帮助程度等难以完全靠公式量化的维度，保持定期人工盲测或抽检（如每周随机抽检 50 条线上交互），弥补自动化指标的盲区。

评估报告与基准对比（Reporting & Benchmarking）：汇总自动化与人工评估得分，按问题类型或难度分级展示趋势；每次升级智能体逻辑、提示词或底层模型时，均在基准测试集上重新运行评估，量化对比改进幅度或排查性能退化。

结合内部反思与外部评估

两者相互补充：

内部反思（运行时防御）：在单次请求执行期间实时检查并修正初稿，尽可能在结果展示给用户前拦截错误。
外部评估（离线与全局诊断）：从宏观视角持续监测系统整体表现，暴露单次内部反思无法自愈的系统性短板（例如即使内部反思成功拦截了 70% 的初稿瑕疵，剩余漏网的 30% 错误仍会在外部评估指标与线上日志中浮现，指导团队判断是否需要补充新工具或调整架构）。

在生产实践中，还可将内部反思节点的自评日志一并上报至外部评估流水线做联动分析——例如当统计发现每当反思节点输出“背景信息不足”时最终回答错误率极高，即可针对该信号增加自动补充检索分支，用外部评估洞察反哺内部决策循环。

复核答案、引用与拒答

在企业知识助手实践中，使用本地 JSONL 保存参考答案与来源 ID，配合自托管 Langfuse 保存实验结果与脱敏追踪。反思节点仅限于对照当前用户已获授权的检索材料核查事实，严禁在反思阶段越权扩大数据读取范围。 人工标注结果与 LLM Judge 评分需分别独立保存，明确界定评分规则，并定期统计人工与模型评分不一致的样本。

练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。