回答错了先看检索到了什么，Phoenix 可以把召回片段导成表

知识库助手回答错了，直接换模型未必解决问题。资料压根没有被找出来，和资料已经到手却没有用好，是两种不同故障。Phoenix 的数据导出能力，可以把检索阶段的记录整理成逐条片段表，让排错有更具体的起点。

前提是应用已经接入追踪，并且记录了检索问题与返回文档。表格来自实际trace，工具不会替缺失的日志补造证据。

先把一条回答拆到检索记录

Phoenix可本地或自托管运行，接收应用的trace。官方导出指南提供SpanQuery：按span_kind等于RETRIEVER筛选，再把input.value选成input列。

这一步得到的是检索器当时收到的问题。它可能与用户原问题不同，例如应用先做了查询改写；因此不能一概把它当成原始提问。

随后，对retrieval.documents使用explode，将列表里的每份文档展开。官方示例把document.content命名为context，形成“检索输入—第几个文档—片段内容”的对应表。

一次检索多份资料，每份都能单独看

展开后的索引包含span身份和从零开始的document_position。需要看排序或比较相似度时，还可增加document.score列；但这个值来自检索器自身，不是平台自动给出的事实正确率。

教学情境中，用户询问退款期限，表里若全是物流片段，优先检查查询、索引或过滤条件；若已经召回包含期限的正确段落，再看后续上下文组装和生成。这是借助记录提出排查方向，不是仅凭一张表就自动定位全部根因。

表格也便于人工标记相关与不相关片段，或准备后续检索评测。判断仍需读原文，不能把“排名靠前”直接等同“能够支撑答案”。

导出范围和使用许可，关系到怎样落地

查询可以指定项目及起止时间。未设置时间范围时会查询所选项目中的可用记录；项目默认来自默认项目或PHOENIX_PROJECT_NAME设置。因此排查某次改动时，应明确项目与时间范围，免得把不同版本材料混成一张表。

Phoenix服务端当前LICENSE采用Elastic License 2.0，允许范围与MIT、Apache不同，尤其限制向第三方提供包含实质功能的托管或管理服务。内部自托管分析和将它包装成对外商业平台，不能按同一种许可理解。

这项能力最有用的成果，是一张能回到检索现场的明细表。它把“模型好像答错了”变成“这一问到底找回了哪些材料”，给后续调整检索或生成链路提供可读、可核对的依据。