Opik vs Phoenix：RAG 评估平台的功能、部署和使用成本

RAG 刚做出来时，评估往往很简单：找一些常见问题，跑一遍，把答案交给业务同事看。问题不多、版本也少，这样做完全可以。

等到检索参数、Prompt 和模型开始频繁调整，事情就麻烦了。上周说这个问题已经修好，这周又答错；新模型的总分高了一点，却不知道究竟改善了哪些问题。工程师要翻脚本、找旧结果，还要问当时用的是哪一版知识库。评估平台首先要解决的，就是这部分反复整理和确认的工作。

Opik 和 Phoenix 都能管理 Trace、数据集和实验。我的取舍是：已有评估代码，主要想把检索过程和实验结果整理起来，可以从 Phoenix 开始；准备把生产请求持续纳入评分，又不想自行维护整套规则调度，Opik 更值得投入。

观测云｜2026-10-09 更新。依据官方资料比较，未进行双方性能测试。

Opik 和 Phoenix 的功能

有数据集、有实验，这些本身已经不足以区分两者。已有 Python 评估脚本的团队，最关心的是还能不能沿用原来的指标、样本结构和发布流程。没有这套积累的团队，则更关心把规则配置好后，生产数据能否持续进入评估。

Phoenix 的 SDK 与实验路径适合前一种工作习惯。Opik 的在线规则在后一种需求下更有用。不过 Phoenix 主平台采用 ELv2，Opik 仓库采用 Apache 2.0，部署和再分发的条件并不相同；商业 Arize AX 也是另外一个产品和采购范围。Phoenix 评估、Phoenix 许可、Opik 仓库。

检索没找到，还是模型没用好

以退货问答为例。材料里既有“签收后七天”，也有特殊商品的例外条款。如果检索结果里没有那条例外，模型再认真地总结，也只能给出不完整的答案。继续修改生成 Prompt，收益很有限。

延伸阅读AgentOps vs LangSmith：Agent 调试、评估和自托管怎么选→

如果例外条款已经被检索出来，模型却没有采用，才应该继续看上下文顺序、Prompt 和模型本身。两种情况在用户那里都是“答错了”，工程上却要改不同的地方。

所以评估数据不能只留下问题和最终答案。至少要能找回当次检索的文档、排序和实际送入模型的上下文。Phoenix 的检索评估可以结合相关性标注计算 Precision@K、NDCG；它们分别帮助观察返回内容是否相关、相关内容的位置是否合理。文档标注本身不可靠，算出来的数也就没有多少参考价值。Phoenix 标注与检索评估。

Opik 在线评估的一个具体工作是输入映射：评分规则从 Trace 的什么位置取得问题、答案和参考材料。应用换了埋点结构，映射也可能跟着失效。Judge 如果只拿到问题和答案，可以评估表达和部分相关性，却没有依据判断答案是否忠于这次检索结果。Opik 评估规则与输入。

这部分维护省不掉。团队已经把检索过程记录得很细，用 Phoenix 接续原来的排查和评估代码比较顺手；如果准备把评分交给 Opik 规则持续运行，就要把输入结构稳定下来。平台代替了搬运和执行，没有代替业务定义什么叫答对。

数据集版本

最初只有几十条样本时，直接维护一份文件没有问题。问题出现在多人同时补样本，又开始拿历史得分比较版本的时候。

假设旧版在两百道题里通过一百八十道。后来加了二十道困难题，新版通过一百九十道。通过数增加了，通过率却从 90% 降到约 86.36%。这并不能说明新版退步，题目已经不同了。两个版本在同一批问题上的结果，才有可比性。

Opik 的增删改会形成不可变的数据集快照，Phoenix 也提供数据集版本。两边都能把实验固定到一版样本上，这一项没有必要硬分高下。Opik 数据集、Phoenix 数据集。

更费心的是数据集之外的变化。题目没动，知识库重建了，检索结果就可能变；Prompt 没动，Judge 换了模型，分数也可能变。持续做回归时，知识库、检索参数、应用版本和评分规则都得跟着实验留下记录，否则平台只是把不可比的数字排在了一起。

Agent 的工具调用还多一层问题。调用真实库存或订单接口，外部状态会变化；固定工具返回，又只能评估那组条件下的执行。比较策略改动，可以固定响应；判断真实端到端效果，就保留当次工具结果。这样才知道一条失败是应用退步，还是外部条件不同。

线上评估

离线实验通常由工程师主动发起。线上评估需要持续取数，还要处理长对话、失败重试和模型调用限额。选择 Opik，一个实际理由就是它已经提供了这部分在线规则入口。

延伸阅读LiteLLM vs Portkey：AI 网关的路由、预算和部署成本→

Thread 评分默认在对话最后一次活动后等待十五分钟，再开始评估，等待时间可调整。因为一段对话还没结束，最后一轮的补充可能改变整段对话的判断。这样的设计适合事后质量检查，不适合承担“答案发给用户之前先拦一下”的职责。Opik Thread 评分。

Phoenix 同样可以对生产 Trace 做评估。如果走 SDK 路线，持续取数、定时运行、失败补跑和结果回写要安排进自己的运行流程。已有这套调度的团队，新增工作不一定多；从零开始的团队，则会多维护一项服务。需要商业 Arize AX 的持续监测能力时，费用和部署范围另算。

线上也没有必要把全部请求交给昂贵的 Judge。普通成功请求抽样，工具失败和用户负反馈单独进入复核，通常比同一个比例覆盖所有请求更有针对性。这些样本代表不同人群，最终的整体失败率还得按实际抽样方式计算。

模型评估的费用

免费部署一套平台，容易让人低估后面的模型消耗。

按一个假设规模计算：两百条样本、六个候选方案、每个重复三次，就是 3,600 次应用运行。每次用两个 Judge 评分，增加 7,200 次调用。每次 Judge 平均读六千个输入 Token，仅评分输入就有 4,320 万 Token，应用推理和评分输出还没算。

因此，开源平台之间的机器差价未必是大头。更有必要区分哪些问题需要模型判断：JSON 字段缺失、类型错误可以直接校验；是否遗漏限制条件、是否虚构引用，才值得消耗模型能力。Judge 还需要人工校准。它把明显错误判成高分，继续扩大评分量只会更快地产生无用结果。

我的建议是，先保留能解释失败的少量指标，再逐步增加。两套产品都能组织实验，能否把一个低分定位到检索、生成或工具步骤，比总分页面上多出几个维度更有用。

最后怎么选

Phoenix 更适合已经有评估代码、希望继续按工程脚本和实验推进的团队。主要投入在把 Trace、检索材料和样本版本接好，原有流程能够复用多少，决定了它有多省事。

Opik 更适合希望把离线实验和生产评分一起组织起来的团队。在线规则减少了自行搭建调度的工作，代价是要持续维护字段映射、评分规则和运行费用。只偶尔跑一轮离线评估，这部分优势就不明显。

还有一种情况：Agent 的生产数据已经在观测云。此时新增平台会带来另一份样本、权限和数据同步。观测云已有 Schema Eval、Prompt Eval、人工标注与数据集批量评估，常见的“找失败请求—人工复核—重新评分”可以在原有数据上完成，省去独立部署和搬运。观测云 Agent 评估。

如果确实需要多人标注任务的分配、领取和仲裁，当前观测云的共享标注队列还不覆盖这些流程。批量任务会固定当次样本，也不等于完整的数据集版本管理。需求就在这一层，专门的平台仍有价值；需求尚未到这一层，直接用已有能力往往更合算。