当 LLM 应用从实验阶段走向生产环境团队关注的东西会发生明显变化。在实验阶段大家更关心“这个提示词能不能跑通”“这个模型回答得准不准”而到了生产环境问题会变成每天有多少请求延迟有没有变高成本是不是在可控范围内用户对回答的满意度是上升还是下降这些问题如果只靠人工翻日志几乎不可能及时回答。Opik 的生产环境监控能力就是为这种场景准备的。Opik 从设计之初就考虑到了高容量 traces 的支持这使得它非常适合用来监控生产环境中的 LLM 应用。所谓高容量意味着即使你的应用每天产生成千上万条 traceOpik 也能稳定地接收、存储和展示这些数据。对于生产系统来说这一点很关键因为监控工具本身不能成为瓶颈。在 Opik 里你可以通过任意项目中的Insights标签查看反馈分数、trace 数量、延迟和成本随时间的变化。内置的 Project Overview 提供了一个一目了然的健康检查里面有统计卡片和时间序列图表。如果你之前用过其他监控系统可以把它理解成一个专门为 LLM 应用定制的仪表盘左边是关键指标卡片右边是趋势图不需要自己拼凑。除了看时间趋势你还可以在 traces 表格里查看项目中所有 trace 的平均反馈分数。这个功能看起来简单但在实际使用中非常实用。比如当你怀疑最近一轮提示词改动导致质量下降时直接看平均反馈分数的变化比逐条检查 trace 快得多。记录反馈分数生产监控的基石要监控 LLM 应用的表现首先得有“表现”的量化指标。Opik 把这部分称为 feedback scores也就是反馈分数。你可以通过 Python SDK 和 UI 来记录这些分数。反馈分数的来源可以很多样用户点赞点踩、人工标注、自动评估模型甚至是业务侧的转化数据。关键是要把它们和具体的 trace 关联起来。定义在线评估指标在生产环境中最省力的方式之一是让 LLM 自己当裁判。Opik 平台支持定义 LLM as a Judge 指标这些指标会自动为所有或部分生产 traces 打分。你可以在 Online evaluation 部分找到如何定义这些指标的详细信息。一旦规则定义好Opik 就会对项目中的 traces 进行评分并允许你跟踪这些反馈分数随时间的变化。这里有个很实用的点你不需要对所有 trace 都打分。比如你可以只对包含特定标签的 trace 评分或者只对某个用户群体的请求评分。这样既能控制成本又能把注意力放在最需要关注的数据上。Opik 还提到除了 LLM as a Judge 指标未来很快会支持定义 Python 指标给用户更多控制权。对于有自定义评估逻辑的团队来说这是一个值得期待的功能。手动记录反馈分数当然不是所有反馈都能自动获得。很多时候你需要手动记录。Opik 允许你在记录 traces 的同时把反馈分数一起写进去。下面是一个典型的代码示例fromopikimporttrack,opik_contexttrackdefllm_chain(input_text):# LLM chain code# ...# Update the traceopik_context.update_current_trace(feedback_scores[{name:user_feedback,value:1.0,reason:The response was helpful and accurate.}])这段代码的意思是在llm_chain函数执行过程中除了记录 trace 的基本信息还通过opik_context.update_current_trace更新了当前 trace 的反馈分数。反馈分数的名字叫user_feedback值是 1.0理由是这个回答有帮助且准确。你可以根据实际情况定义多个反馈分数比如relevance、accuracy、toxicity等。这种方式的优点是实时性高数据一旦产生就立刻关联到 trace 上。缺点是需要在业务代码里嵌入监控逻辑可能会让代码稍微复杂一点。不过对于生产系统来说这种嵌入往往是值得的因为它能保证反馈数据不丢失。更新已有 traces 的反馈分数有时候反馈分数不是在 trace 产生时就能获得的。比如用户可能在几个小时甚至几天后才提交评价或者人工标注团队需要离线处理一批 trace。这时候你就需要先获取这些 trace然后再更新它们的反馈分数。使用搜索 API 获取 tracesOpik 提供了Opik.search_traces方法用来获取你想要标注的 traces。代码很简单importopik opik_clientopik.Opik()tracesopik_client.search_traces(project_nameDefault Project)search_traces方法允许你根据任何 trace 属性来筛选 traces。比如你可以只搜索某个时间范围内的 trace或者只搜索带有特定标签的 trace。这种灵活性让批量标注变得很容易。更新反馈分数拿到 traces 之后就可以用Opik.log_traces_feedback_scores方法来更新反馈分数了fortraceintraces:opik_client.log_traces_feedback_scores(scores[{id:trace.id,name:user_feedback,value:1.0,reason:The response was helpful and accurate.,project_name:Default Project}],)这段代码会遍历所有获取到的 trace为每个 trace 添加一个名为user_feedback的反馈分数。更新完成后你就可以在 Opik dashboard 中看到这些反馈分数并跟踪它们随时间的变化。这里有一个细节值得注意log_traces_feedback_scores方法接受一个 scores 列表这意味着你可以一次性为同一个 trace 添加多个反馈分数。比如同时添加user_feedback和auto_eval_score。这在需要多维度评估时非常方便。更新 trace 内容除了反馈分数有时候你还需要更新 trace 本身的内容。比如你发现某条 trace 的输出有误想要修正或者你想给某条 trace 添加额外的元数据。Opik 也支持这些操作。获取 trace 内容要更新 trace首先得知道它的内容。你可以使用Opik.get_trace_content(id: str)来查看 trace 的内容通过 ID 查找。trace ID 可以通过Opik.search_traces()方法找到也可以在 Projects ‘My-project’ 视图的 ID 列中看到。fromopikimportOpik TRACE_IDEXAMPLE-ID# UUIDv7 Identifieropik_clientOpik()trace_contentopik_client.get_trace_content(idTRACE_ID)这会返回一个TracePublic对象这是一个 pydantic 模型对象包含了与找到的 trace 相关的所有数据。你可以把它理解成一个结构化的字典里面有你需要的所有字段。按 ID 更新 trace拿到 trace ID 之后你可以先重新实例化这个 trace然后更新它的任意属性fromopikimportOpik TRACE_IDEXAMPLE-ID# UUIDv7 Identifieropik_clientOpik()traceopik_client.trace(idTRACE_ID)trace.update(outputupdated_output)Trace.update()方法支持更新以下属性end_timetrace 的结束时间。metadata与 trace 关联的额外元数据。inputtrace 的输入数据。outputtrace 的输出数据。tags与 trace 关联的标签列表。error_info包含错误信息的字典通常在 trace 函数失败时使用。thread_id用于将多个 trace 分组到一个 thread 中。这个标识符是用户定义的并且在每个项目中必须唯一。这些属性覆盖了 trace 生命周期中可能需要修改的大部分内容。比如你可以在 trace 结束后补充end_time或者给一个失败的 trace 添加error_info方便后续排查。为什么生产监控值得投入很多团队在 LLM 应用上线初期会把注意力放在功能实现上监控往往是事后才补的。但实际情况是LLM 应用的行为比传统软件更难预测。同一个提示词在不同时间、不同用户输入下可能产生完全不同的结果。如果没有持续的监控你很难知道系统是在变好还是变坏。Opik 的生产监控能力本质上是在帮你建立一套反馈闭环。通过记录反馈分数你可以把主观感受变成可量化的指标通过 Insights 标签和 Project Overview你可以把这些指标可视化通过搜索和更新 API你可以对历史数据进行追溯和修正。这套组合拳打下来团队就能从“凭感觉”转向“看数据”。更重要的是Opik 的设计考虑到了生产环境的规模。高容量 traces 的支持意味着你不需要担心数据量大了之后系统变慢。自动评分和手动记录的结合则让你可以根据实际情况选择最合适的评估方式。对于刚开始做生产监控的团队建议先从内置的 Project Overview 看起了解哪些指标最重要然后逐步定义自己的 LLM as a Judge 规则把重复性的评估自动化最后再根据业务需要手动补充一些关键反馈。这样循序渐进既不会一下子负担太重也能持续积累对系统的理解。生产环境监控不是一次性任务而是一个持续的过程。Opik 提供的这些工具目的就是让这个过程尽可能顺畅。当你能够随时看到反馈分数的变化、trace 数量的波动、延迟和成本的趋势时你就有了做出正确决策的基础。无论是调整提示词、切换模型还是优化系统架构数据都会告诉你方向。