可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载多轮对话Multi-Turn Conversation是客服、AI 助教、Agent 等场景最常见的交互形态但其失败模式与单轮问答截然不同——上下文丢失、目标漂移、偏好遗忘等错误只存在于回合与回合之间单看任何一轮都可能一切正常。本文基于 Phoenix 官方技能文档 error-analysis-multi-turn.md 展开结合 phoenix-error-analysis 技能、Phoenix 客户端会话 API 与仓库内会话级评估示例系统讲解一套从端到端观察到首因定位再到N-1 隔离的多轮错误分析方法论。读完本文你将掌握如何在海量 trace 中快速锁定多轮会话的真正根因并把结论沉淀为可复用的评估维度。为什么多轮会话的错误分析与众不同Phoenix 的错误分析流程error-analysis.md以采样 → 开放编码 → 轴向编码 → 量化 → 排序为主线默认的分析单元是单个 trace 或 span。但多轮对话引入了轨迹性trajectory失败上下文跨轮丢失、目标漂移、忘记用户偏好这些失败只存在于跨 trace 的序列中单看任意一轮 trace 都无法发现。因此在开始分析之前必须先选定分析单元unit of analysis。phoenix-error-analysis 技能 给出了三条决策信号信号观察方式判定用户表述对话agent 忘了跨轮漂移用 session 级会话接线检查根 span 的attributes.session.id属性空串表示缺失统计约 200 条 trace 中非空 session id 的比例、去重 id 数、每会话中位 trace 数中位数 ≥ 2 → session 级合理回合结构打开根 span 的input.value单条用户消息是一次性任务消息数组[{role: user}, {role: assistant}, ...]则是多轮对话的一轮消息数组 → session 级选定单元后再开始逐条记录问题笔记单元可以随证据转移——如果 trace 级笔记反复出现agent 从不记得前面的回合下一批样本就该转向 session 级。四步分析法从端到端结果回溯到根因多轮错误分析的核心思路可以浓缩为四个步骤这也是原文档 error-analysis-multi-turn.md 给出的骨架端到端优先End-to-end first——先问这场对话最终达成目标了吗找到第一个失败点Find first failure——沿着轨迹向前回溯定位根因而不是盯着最终症状。先简化Simplify——在深入多轮调试之前先用单轮复现一次。N-1 测试——把前 N-1 轮作为上下文单独测试第 N 轮隔离上下文问题与能力问题。这套方法的合理性在于多轮会话的错误会沿轨迹传播下游的每个坏结果都可能是上游某个错误回合的连锁反应。只有端到端判断 向前回溯才能避免在症状上修修补补。找到第一个上游失败不要在第 6 轮上浪费精力原文档给出了一个非常典型的机票查询示例Turn 1: User asks about flights ✓ Turn 2: Assistant asks for dates ✓ Turn 3: User provides dates ✓ Turn 4: Assistant searches WRONG dates ← 第一个失败 Turn 5: Shows wrong flights (后果) Turn 6: User frustrated (后果)分析焦点应当放在Turn 4而不是 Turn 6。Turn 5、Turn 6 都是 Turn 4 的连带后果即使你在 Turn 5 或 Turn 6 上打补丁只要 Turn 4 仍在用错误日期查询下一场对话还会以同样的方式失败。这与 phoenix-error-analysis 技能 中的标签第一个失败原则完全一致下游症状只有在具有独立成因时才需要单独记录笔记。例如检索到了错误的文档和基于错误文档给出了幻觉答案是两条独立的失败应当分别标注而搜索了错误日期导致的展示了错误航班则是一条只需标注前者。实践提示在 Phoenix 中不要只按 span 的status_code ERROR采样——OTel 的 ERROR 状态仅在埋点捕获到抛出的异常时才翻转幻觉、语气不当、检索落空、工具选错都会以OK或UNSET干净地结束。多轮会话里最隐蔽的失败恰恰是那些成功状态下的错误行为。先简化用单轮测试划分问题域在投入多轮调试之前先用单轮请求做一次快速二分# 如果单轮也失败 → 问题是检索/知识/能力层面 # 如果单轮通过 → 问题是会话上下文层面 response chat(Whats the return policy for electronics?)这一小步的价值在于把问题空间一分为二单轮也失败根因很可能与对话历史无关问题出在检索召回、知识库覆盖、工具调用参数或模型本身。此时应回到 error-analysis.md 的单轮/span 级分析流程。单轮通过说明模型在该任务上的基础能力是够的失败源于多轮上下文——例如历史消息没有正确注入、用户偏好被覆盖、目标在回合间发生漂移。从仓库的会话级评估文档 session-level-evaluation.mdx 可以看到这种单轮全对、整场失败并非假设其受控示例中四个手写会话逐轮正确率均为 100%但会话级 judge 仍能识别出逻辑矛盾incoherent目标未完成goal not met用户挫败frustrated三类整体性失败。先做单轮二分能让你带着明确假设进入多轮调试。N-1 测试隔离上下文问题与能力问题N-1 测试是定位多轮根因的关键实验把前 N-1 轮作为上下文喂给模型单独测试第 N 轮然后与实际第 N 轮的回答做对比。context conversation[:n-1] response chat_with_context(context, user_message_n) # 与实际第 N 轮回答对比对比结果有四种典型解释实验结果结论用前 N-1 轮上下文时第 N 轮回答正确实际第 N 轮错误生产中上下文注入链路出了问题历史丢失、顺序错乱、截断用前 N-1 轮上下文时第 N 轮仍然错误模型在该轮任务上的基础能力不足与上下文无关只给前 N-1 轮的一部分如只给前 N-2 轮就正确问题精确锚定在第 N-1 轮引入的信息如某个错误的事实、被覆盖的偏好截断到最近的 K 轮后正确上下文窗口过长导致注意力稀释或中间遗忘lost in the middle在实际工程中第 N 轮的上下文往往由多轮历史 检索结果拼装而成。为了把上下文问题再细拆为历史问题和检索问题可以进一步做受控实验固定历史上下文、替换检索内容反之亦然。这种逐步缩小的做法与错误分析技能中的先取样 → 再展开 → 最后深入单点的流程一脉相承。实战在 Phoenix 中拉取会话轨迹并重建多轮现场前面四步方法论需要真实的会话数据支撑。在 Phoenix 中多轮会话的每个回合是一条独立的 trace共享同一个session.id存储在根 span 的attributes.session.id属性中。分析时先按会话聚合再按开始时间排序重建轨迹。采样与会话聚合参照 error-analysis.md 的采样模式先用 Python 客户端拉取 spans 并按attributes.session.id分组from phoenix.client import Client # Client() 连接本地 Phoenix回退到环境变量或 localhost:6006 # 远程/云环境Client(base_urlhttps://..., api_key...) client Client() spans_df client.spans.get_spans_dataframe(project_identifiermy-app) # 只保留带会话归属的 span按会话分组、按开始时间排序 sessions ( spans_df[spans_df[attributes.session.id].notna()] .sort_values(start_time) .groupby(attributes.session.id) )会话聚合后每个会话变成一条按时间排序的、带有user:/assistant:角色标记的转录文本。仓库中的 session-level-evaluation.mdx 提供了完整的prepare_sessions实现它读取每个 LLM span 的attributes.llm.input_messages/attributes.llm.output_messages而非原始请求 JSON取每条请求中最后一个 user 消息作为该轮的新输入更早的历史是重放并为长会话设置max_chars_per_session截断保护默认 600,000 字符保留最近上下文。按会话查询与深入单场对话如果你已经锁定了具体会话例如用户反馈的某次糟糕体验可以直接用 Phoenix 客户端的 Sessions 资源按 id 拉取整场对话。在 sessions 资源源码 中可以看到get与list两个核心接口需要 Phoenix server ≥ 13.5.0# 按用户提供的 session_id 或 GlobalID 获取单场会话 session client.sessions.get(session_idsession-abc-123) # 返回 SessionDatasession_id、trace 列表等 # 或按项目列出会话支持过滤表达式 sessions client.sessions.list( project_namemy-app, limit100, # filtersession_annotations[note].identifier coding-run:chatbot-2026-05-06, )拿到单场会话的 trace 序列后回到四步法先看端到端是否达成目标再沿start_time顺序逐轮检查输入/输出/工具调用找到第一个失败的回合最后用 N-1 实验验证假设。记录分析笔记找到问题回合后立刻把观察记录成具体笔记而不是在聊天里口头总结。Phoenix 技能规范强调记录的笔记就是交付物client.spans.add_span_note( span_idspan-of-turn-4, notesearched flights for March 10 but user said March 12 - wrong date carried from turn 3, )好笔记应当精确到事实层Response says ships in 2 days but policy is 5-7 days优于Response is bad。建议笔记归入如下类别事实性错误日期、价格、信息缺失、语气问题、工具问题工具选错、参数错、检索问题文档不符、缺相关文档。从错误笔记到评估维度把多轮失败沉淀为标注多轮错误分析的终点不是一份诊断报告而是可复用的评估维度。沿 phoenix-error-analysis 技能 的轴向编码流程将笔记按它们回答的是同一个问题聚类为每个维度定义一个小标签集2~4 个标签外加一个通过值例如context_tracking: [kept, ignored_preference, goal_drift] task_completion: [completed, partial, abandoned] answer_faithfulness: [grounded, invented_fact, invented_citation] tool_selection: [correct, wrong_tool, hallucinated_tool, unnecessary_call]其中context_tracking就是典型的多轮专属维度——是否跨轮追踪上下文在单轮 trace 上根本不存在只有以 session 为单位才能标注。这类 session 级标注可以写回 Phoenixclient.sessions.log_session_annotations_dataframe( dataframesession_annotations_df, annotator_kindLLM, )在 sessions 资源源码 中log_session_annotations_dataframe将长格式标注每 session × 每评估维度一行含name/label/score/explanation写入服务端随后即可在 Phoenix 的Sessions标签页按标注筛选、聚合、审计。如果需要用 LLM-as-a-judge 批量打分仓库的 session-level-evaluation.mdx 展示了完整范式用ClassificationEvaluator定义维度如coherence、goal_completion、frustration、correctness每个 judge 读取整段会话转录、只评判自己的维度并通过suppress_tracing()避免 judge 自身的 LLM 调用污染项目from phoenix.evals import LLM, ClassificationEvaluator, async_evaluate_dataframe from phoenix.trace import suppress_tracing judge LLM(provideranthropic, modelclaude-sonnet-4-6) coherence_evaluator ClassificationEvaluator( namecoherence, llmjudge, prompt_templateSESSION_COHERENCE_PROMPT, # 只评判跨轮一致性不评判事实正确性 choices{coherent: 1.0, incoherent: 0.0}, ) with suppress_tracing(): results_df await async_evaluate_dataframe( dataframesessions_df, evaluators[coherence_evaluator], concurrency10, )多轮错误分析检查清单完成一场多轮会话的排查后用原文档 error-analysis-multi-turn.md 的清单做最终确认端到端这场对话达成目标了吗先做整体判断首个失败回合从哪一轮开始第一次出错把分析焦点放在它上面而非下游症状。单轮复现能用单轮请求复现吗二分检索/知识问题 vs 上下文问题N-1 隔离错误来自上下文还是基础能力用前 N-1 轮作为上下文单独测试第 N 轮结语多轮对话的错误是轨迹级的它跨越多个 trace 存在只在会话这个分析单元上可见。Phoenix 提供的四步分析法端到端优先 → 找第一个失败 → 先简化 → N-1 测试给出了一条从整体现象回溯到具体回合、从具体回合再隔离到上下文/能力两域的完整路径。结合 error-analysis.md 的采样与笔记规范、axial-coding.md 的维度沉淀以及 Phoenix 客户端的 Sessions API 与会话级评估范式你可以把一次性的多轮 bug 排查转变成可复用、可量化、可回归的会话级评估体系——让上下文丢失这类最隐蔽的 Agent 失败成为团队可观测、可追踪、可修复的工程问题。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐kotaemon对话管理多轮会话上下文维护kotaemon对话管理多轮会话上下文维护 痛点为什么需要专业的对话上下文管理 在RAGRetrieval Augmented Generation检人工智能大模型RAG向量数据库后端CANN Runtime 多 Device 场景下 aclrtMemcpyAsync 错误 Stream 下发失败错误码 107003的定位与解决CANN Runtime 多 Device 场景下 aclrtMemcpyAsync 错误 Stream 下发失败错误码 107003的定位与解决 本篇文章CANNAscend人工智能性能剖析系统编程OpenAI Agents SDK 会话记忆Sessions完整指南多轮对话上下文持久化的内置方案与自定义实现OpenAI Agents SDK 会话记忆Sessions完整指南多轮对话上下文持久化的内置方案与自定义实现 会话Sessions是 OpenAI人工智能AI AgentAgent 框架多智能体工具调用MCP Clients创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考