Comet ML 10 条 提示词 提效技巧：Opik 评测接进 CI + DeepSeek 当 judge 实战

凌晨一点四十，CI 红了。我以为是 DeepSeek 的接口超时，打开日志一看，报错是这句：AssertionError: no spans were found in the last 200 traces。

不是模型挂了，不是我的代码挂了。是评测脚本自己把脚给砍了——那 200 条 trace 里，一条 LLM 调用都没记上。

那天我刚把一套 LLM 应用的观测从自研的 log 表切到 Comet 的 Opik。切之前我不知道 OpenTelemetry 这条路，我以为必须走 @opik.track 装饰器。而我的服务是 Java 写的，用的是 OpenTelemetry 的 Java agent 自动埋点。Opik 文档里说支持 OpenTelemetry endpoint，我就接上了，trace 有数据、能在界面上看到树状结构。我以为这就算通了。

结果评测跑起来是空的。

问题不在 Opik，在我自己：Opik 的 span 要么来自 SDK 装饰器，要么来自它自己的集成，OpenTelemetry 那条路接进来的数据默认落在 traces 里，而评测器读的是 spans。界面给你看的东西和评测器读的东西，不是同一张表。这个错不报错，日志干干净净，就一句「没找到 span」。

我当时的想法是：这不是个值得写文章的错误。

后来我把那 200 条 trace 里前后 5 条翻出来对了一遍，又把六种优化算法在同一个数据集上跑了两遍，才改主意——「Opik 是干什么的」和「Opik 的 span 从哪来」是两个问题，而第二个问题决定了前面那个问题有没有意义。这篇我就按这个顺序写：先分清两条产品线，再把「怎么把提示词接进评测闭环」拆成 10 条能落地的做法，中间把我踩的坑按报错原文贴出来。

说清楚口径，免得有人拿我的场景去套自己的：全文涉及的产品状态，均为我 2026 年 11 月 5 日当天从 comet.com 定价页、comet.com 官方对比页、GitHub 仓库、Opik 官方文档站和 DeepSeek 官方 API 文档查到的结果。官方页面和第三方评测口径不一致的地方我分开写，标注是谁说的；我自己没验证到的，标「这条我没验证到」。

一、先分清两条产品线，别的都是空谈

这是最容易买错的地方。Comet 官网首页挂的是「experiment management and LLM evaluation platform」，一句话里两个东西，但底下是两套完全独立的定价表、两套完全独立的 SDK、两个完全独立的 GitHub 仓库。

这张表里最反直觉的一行是价格那两行。Opik Pro 是 $19/月包整个账号，50 个人以内不再按人头收——官方对比页写得很明确：Note the unit on that Pro price: $19 per month, listed without a per-user multiplier. 而 Comet MLOps Pro 是 $19/用户/月。两个数长得一样，计费口径完全不一样。

我一开始按 MLOps 的思路去理解 Opik，觉得「$19 一个人一个月，那 50 个人一个月 950 美元」。这个理解是错的。你在 Opik 上开一个 Pro 账号，$19 覆盖 50 个成员、100,000 条 span。我把这点单独拎出来，是因为我自己在这上面算错过账。

官方对比页把 Langfuse 的 Core 档写成 $29/席/月，50,000 个 billable unit。Opik 是 $19 覆盖 100,000 个 span。Opik 的 span 和 Langfuse 的 billable unit 不是同一个口径，官方自己也提醒「units 口径要去 langfuse.com/pricing 确认后才能直接比」。我不替他们换算，只把两边官方原话摆出来。

二、10 条我实测下来能直接抄的做法

下面这 10 条不是产品功能列表，是我把提示词接进评测闭环这件事拆开之后的落地顺序。每条后面附的是我真踩到的坑。

第 1 条：先确认你要的是 Opik 还是 MLOps，再动手装包。提示词评测、链路追踪、Agent 观测，全在 Opik 这条线上。MLOps 那条是训练实验追踪——记超参、存 artifact、模型注册表、漂移监控。你要接提示词评测，装错包后面全是白工。坑是：Comet MLOps 的核心 SDK 是闭源的，自托管要走 Enterprise 报价、还要 license token；Opik 这条 Apache-2.0 的路是免费的。这两条的差别不是「功能多少」，是「你能不能自己跑」。

第 2 条：装完先打一条 trace 验证链路，再往下做别的。两行起手：pip install opik 然后 opik configure（会提示填 API key、选云端还是本地，选本地就是 opik.configure(use_local=True)）。然后给函数挂装饰器：

import opik
from opik import track

@track
def my_llm_function(user_question: str) -> str:
    return "Hello"

就这一步。之后每次调用，Opik 自动记下输入、输出、耗时、错误，界面里拼成 trace / span 树。这棵树是后面所有事的地基——评测、优化、线上监控，全都从这棵树读数据。坑是装饰器挂的位置：@track 要挂在真正调 LLM 的那个函数上，不是挂在调用方上。我第一次挂在 HTTP handler 上，结果每次请求记一条 span，底下那次模型调用没被单独记下来，评测粒度整个是错的。

第 3 条：走 OpenTelemetry 接入的话，先确认评测器读的是 span 不是 trace。这就是我文章开头那个 CI 报错。OpenTelemetry 接进来的数据默认落在 trace 层，评测器读的是 span 层。界面能看见树，评测器却说没数据，这两件事不冲突——它们读的就是两张表。日志里干干净净，就一句 no spans were found in the last 200 traces。

顺带说一句：我这次是从自研 log 表迁过来的，迁之前我在自己的表里存的是「一次请求一行」。Opik 的 span 是「一个操作一条」——一次请求里模型调用、检索、工具调用各算一条。这个口径差，我是在账单上才反应过来的。

第 4 条：能用启发式指标就别上 judge。Opik 内置 21 个启发式指标和 22 个 LLM-as-a-Judge 指标，这两个数是官方对比页 2026-08-13 的口径。启发式那一组是 Equals、Contains、RegexMatch、IsJson、Levenshtein 这种；judge 那一组是 Hallucination、Moderation、AnswerRelevance、ContextRecall、ContextPrecision 这类。判「输出是不是合法 JSON」用启发式，判「有没有幻觉」才上 judge。理由是成本——judge 每次评分要额外调一次模型，20 条样本乘 5 个 judge 指标就是 100 次额外调用。

第 5 条：judge 模型自己也会错，先用人工标注校准一轮。我踩的就是这个坑。第一版指标函数我拿 20 条样本跑，judge 判「有幻觉」的那几条，我人工看下来全是对的——它把「引用了用户原话」判成了幻觉。judge 不是 ground truth，是又一个需要被评测的模型。

我的 judge 用的是 DeepSeek。Opik 的 AI Providers 配置里可以挂自定义模型，DeepSeek 的接口是 OpenAI 兼容的，接进去不用改我这边任何代码。这一条是我自己的接法，官方文档没把 DeepSeek 列进集成清单，所以我只敢保证「OpenAI 兼容的接口能接」，不敢保证所有指标在 DeepSeek 上表现和官方推荐模型一致。

选 DeepSeek 当 judge 的原因很直白：便宜，而且中文场景判定更靠谱。官方 API 文档的价格按百万 tokens 算人民币——deepseek-v4-flash 缓存命中 0.02 元、未命中 1 元、输出 2 元；deepseek-v4-pro 是 3 元、6 元。一次 judge 调用通常就是几百 tokens 输入加几十 tokens 输出，20 条样本跑 5 个 judge 指标，总共不到 0.1 块钱。这个数字小到可以忽略，也正因如此，我才更容易在量上来之后才发现它变成了账单上的一行。

第三方评测里有句话说得很准：Once traffic grows that becomes a line item somebody asks about, though at low volume you will never feel it. 低流量时你感觉不到 judge 成本，量一上来它就摆在那儿了。

第 6 条：指标函数必须返回带 reason 的 ScoreResult，reason 不能是空字符串。这条是 HRPO 的硬前提，不是建议。它整个机制就是靠分析失败原因的文本来定位根因，你只返回一个浮点数，它就没东西可分析。坑在于它不报错——优化器照跑，输出一个结果，但优化效果接近于零。我第一版就是 return score，当时还以为是自己数据集太小。

第 7 条：断言用自然语言写，让 pass/fail 直接进 CI。这是我认为 Opik 最值钱、也最容易被当成「又一个评测平台」略过的一块。Test Suites 支持直接写人话：

suite = opik.TestSuite("crm-agent-v2")
suite.add_assertion("The response must include specific deal details, not just a count")
suite.add_assertion("The response must never reveal unauthorized information")
suite.run_tests()

底层转成 LLM-as-a-Judge 检查，但输出给你的是 pass / fail 这种能当门禁的东西，不是两个要人读的分数。配合它的 PyTest 集成，每次 commit 都能跑，分数掉了就卡合并。

我把它挂在 CI 的一个 stage 上之后，改提示词的习惯就变了：以前改完直接推，现在改完先在本地跑一遍 30 条样本的红绿，看到结果才敢推。官方文档里那句话是我认同的：test suites should grow organically from real production failures rather than from a separate test-writing phase——评测集应该从真实的线上故障里长出来，不是另起一个阶段专门写测试。

第 8 条：六种优化算法按瓶颈选，不要默认挑分数最高的那个。Opik 的 Agent Optimizer 提供六种算法，都在同一个 optimize_prompt() API 底下：GEPA、Evolutionary、Few-Shot Bayesian、MetaPrompt、HRPO、Parameter Optimization。官方对比页特别标了一句：这些在 Langfuse 的公开文档里是 Not documented。

官方基准跑在四个学术数据集上，评测模型用的 GPT-5-nano：

横着看比竖着看有意思：Arc 上 HRPO 拿 92.70%，GSM8K 上就掉到 28.00%，还不如 Few-Shot Bayesian 的 59.26%。RagBench 上反过来，Evolutionary 92.00% 最高。没有万能算法，只有最适合的。指令措辞不行就 MetaPrompt 或 HRPO，few-shot 例句选不好就 Few-Shot Bayesian，参数要微调就用 Parameter 收尾。

GEPA 有两个限制对你可能是硬伤：只支持单轮任务（一个用户输入对一个模型回复），多步 Agent 工作流它跑不了；反思机制需要至少 reflection_minibatch_size 个不同候选才会触发，否则直接跳过反思进进化搜索。它在 Arc 上只有 6.55%，这个数字配上「只支持单轮」两条，说明它对我这种多步场景基本没用。

第 9 条：只留一个算法，别把六个都挂进日常流程。我最后选了 HRPO，理由是它给我 reason——优化完我去看每个候选为什么得这个分，而不是只看一个总分数字。这个差别在调提示词的时候比分数高低重要。HRPO 排第一也确实是因为它在 Arc 这种任务上碾压，而 Arc 恰好是我这类结构化输出任务最像的。

成本差异也是真的。官方自己标了：HRPO 要批量分析失败案例再加综合，token 消耗最高；Evolutionary 是种群 × 代数 × 数据集，也重。默认参数是 MetaPrompt 每轮 4 个候选、最多 10 轮试验，Evolutionary 种群 30、跑 15 代、交叉率 0.8、变异率 0.2、精英保留 3 个。同样的预算下，HRPO 和 Evolutionary 的账单不是一个量级。我的用法是 MetaPrompt 改措辞、Parameter 调参数这种链式收尾，平时只开 HRPO 一个。

第 10 条：先算 span 用量，再决定要不要全量开。这一条我放在最后，但它决定了账单长什么样。Opik 的 span 是「一个操作一条」：一次 RAG 查询通常是 2 条（一次检索、一次生成），五到十步的 Agent 工作流就是五到十条。我那个服务一天大概 4,000 次调用，一次请求平均 3 个 span，一个月大概 36 万条 span——Free 档 25,000 根本不够，Pro 的 100,000 也不够。

但真正让我意外的不是总量，是我一开始把 span 当成「一次请求」算。按请求算是 12 万条，按操作算是 36 万条，差三倍。这个数直接决定了我要不要在生产全量开 tracing。我现在的做法是：全量请求都记 trace，但只对采样的一部分跑 judge 评测——观测要全，评分要省。

三、成本账，和它跟别家的差别

把账摊开。以下是我 2026 年 11 月 5 日查到的官方定价页口径。

Opik 侧：开源自托管 $0，无 span 上限，无按席位收费，机器成本你自己扛。云端 Free $0，25,000 spans/月，10 人，保留 60 天。Pro $19/月，100,000 spans/月，50 人，超出部分每 100,000 spans 加 $5，要延长保留到 400 天是每 100,000 spans 加 $29。Enterprise 定制，带 SSO、SOC 2、ISO 27001、ISO 9001、HIPAA、GDPR。

Comet MLOps 侧：Free $0，1 席位，100GB，公平使用策略。Pro $19/用户/月，最多 10 人，含 1,500 训练小时和 500GB，超出训练小时 $1/小时、超出存储每 100GB 加 $3/月。Enterprise 定制，无限成员和用量，含自托管或 VPC、SSO、服务账号、只读用户、生产监控和 SLA 支持。

这两个超费模型不一样，踩哪个容易心里没数。Opik 超的是 span，Comet MLOps 超的是训练小时和存储。

横向比一下同类，这是我在选型时实际拉的表：

星数是官方对比页 2026-08-13 的口径。Langfuse 星数比 Opik 多一万，社区更大是事实；但官方对比页自己的结论是，Langfuse 在「发现问题之后怎么修」这一层是手工的，Opik 有六种自动优化算法、Ollie 诊断、Test Suites。这句话是 Comet 自己写的，各位自己判断。

要提醒的是，我上周刚写过一篇站内对比 W&B Weave 的文章，那篇是从「改提示词靠不靠谱」的视角写的，结论是纯手调提示词的天花板在版本差分。那篇在这里。这篇是往下走一层，讲怎么把差分变成 CI 里能卡的门禁，两篇可以连着看。

还有一篇讲提示词模板本身的，7 条规则 30 个模板，跟这篇是上下游关系：那边解决「提示词怎么写」，这篇解决「提示词改了怎么知道是变好了」。LiteLLM 那篇讲多模型网关怎么接，在那边，你要先在网关层统一模型再谈评测，可以顺着看。另外我写过一篇把旧版模型名换掉的记录，400 报错那篇，里面提到过 deepseek-chat 这类老模型名在 2026 年 7 月 24 日就退役了，现在接 DeepSeek 只能用 deepseek-v4-flash 和 deepseek-v4-pro。

四、什么情况下我建议你别用它

这节比前面都重要，因为评测工具是那种「装上去容易、用起来才发现场景不对」的东西。

你只有一个提示词、一天改一次。那不用上。手工跑 20 条比搭一整套评测快得多。Opik 的价值在版本差分和回归拦截，你的版本数上不去，这个价值就是零。

你不能接受自托管的运维成本。自托管要 Docker Compose 起后端 API、ClickHouse 和 Web UI 三件套，官方建议 ClickHouse 开发环境至少 8GB 内存，生产 16GB 起步。ClickHouse 跑在你自己机器上，备份、升级、磁盘满了都得你自己扛。第三方评测里那条批评我认为是准的：You end up running the thing that watches the thing. 观测平台自己半夜挂了，你连告警从哪来都不知道。

你要的只是「看 LLM 花了多少钱」。那是 token 追踪能做的事，别为了这个开一整套评测体系。

你在意自动诊断。Ollie 能读 trace、定位根因、提出代码修复建议，还能把失败的 trace 转成回归测试。但官方文档明确写了：Ollie is free to try on Opik Cloud, and self-hosting it means Enterprise. 自托管用户拿不到这一层。这就是「开源版是完整产品」这句话的边界——评测和追踪是完整的，自动诊断不在里面。另外 Diagnostics 扫描走的是 Ollie 的 token，免费试用之后按 token 计费，你把「扫全量 trace」做成定时任务，账单会长得很快。

你在意数据出境。Opik Cloud 的 Free 和 Pro 档数据存在美国区，Enterprise 才提供自定义数据区域；自托管则全部在你自己的机器上。

你的团队已经在某个平台里深度绑定了。LangChain 生态走 LangSmith 的集成更顺，模型平台全在一家走 Arize。你的选择不由「谁更强」决定，由「你已有的东西在哪」决定。

最后一条是我的盲区，得说明白：我只从后端这一面看这个工具——SDK 接入、trace 数据、CI 门禁、成本结构。前端和非技术同事怎么用它、界面顺不顺手，我没有认真验证过。官方对比页说 Langfuse 的「开发者 UX 受好评」，Opik 在这一项上是没拿到这个评价的。别的评测编辑写评测文章的时候容易把这层忽略掉，我觉得不该忽略。

还有一个迁移成本要提前知道：Comet MLOps 那条核心平台没有批量导出 API，第三方评测写得很直白——No bulk export API: leaving Comet means parallel logging, not a one-time migration. 想从 Comet MLOps 迁走，路径是在新工具里并行记两份 log，等你信得过了再切，不是一次性搬数据。不过这条只针对 MLOps 核心平台，Opik 自己的 trace、dataset、experiment、prompt 是能通过 opik import / opik export 在 Opik 项目之间搬的——但它搬的是 Opik 项目之间的，不是从别的平台搬过来。

五、我的结论

Opik 值不值得，取决于你手上的提示词有没有版本差分的痛点。有，就值；没有，别装。

我自己的结论是：我用它，但只用它的一半。trace 追踪 + 启发式评分 + Test Suites 挂 CI，这三样我全在用；六种优化算法我只留了 HRPO 一个，因为只有它给我 reason。Ollie 我没用，因为自托管拿不到。Guardrails 我留着没开——我的服务暂时没有 PII 相关的输入，先加一层推理开销不值得。

如果只让我推荐一件事，推荐第 7 条：自然语言断言加上 PyTest 集成。这是整个工具里唯一直接改变我工作方式的——以前改提示词是「我觉得好了」，现在是「CI 说是好了还是坏了」。

顺便提一句，Opik 仓库的 star 数在 2026 年 8 月到 9 月之间从 21,433 涨到 22,157，版本到 2.2.71 还在往前走。它的更新节奏快到文档经常追不上，你按官方对比页选型的话，记得去仓库 releases 看一眼当前版本再动手。

最后交代我没验证到的部分：Opik 官方文档说自托管是「true OSS，same codebase as the hosted versions」，但我没去逐个功能比对自托管版和云端版是不是完全一致。Ollie 那条我核了官方文档的明确表述，属于 Enterprise；别的功能有没有类似的口径差异，我只跑了追踪和评测这两块，没全测。DeepSeek 当 judge 这条是我自己的接法，官方集成清单里没有它。

你要复核这篇，三个地方就够：comet.com/site/pricing 看价格和额度，comet.com/site/products/opik/compare/langfuse-vs-opik 看官方对比表，GitHub 上 comet-ml/opik 的 releases 看版本。三处都是当天能查的，不需要信我。

—— 查不到那条日志