1. 为什么 LLM 应用比传统 Web 服务更需要可观测性我第一次在生产环境上线一个基于 LLM 的客服摘要系统时客户反馈“有时返回空结果有时格式错乱有时干脆卡住不动”而日志里只有一行INFO: Request completed in 428ms。没有错误堆栈没有中间状态没有 token 消耗记录甚至不知道模型到底有没有被调用——它就像把请求扔进一个黑箱然后等一个不确定的回音。这根本不是“服务不可用”而是“服务不可理解”。传统 Web 应用出问题你查 Nginx 日志看 502、查数据库慢查询看 SQL 执行时间、查 JVM 线程 dump 看死锁但 LLM 应用的问题90% 不在代码里而在 prompt 的微小扰动、temperature 的漂移、外部工具调用的超时重试策略、甚至 API 响应中一个未被校验的换行符。这些都不是 HTTP 状态码能表达的。可观测性Observability这个词在 LLM 场景下必须重新定义它不是“我能查到系统是否在运行”而是“我能还原出模型决策的完整上下文链路”。比如用户问“帮我对比 iPhone 15 和 Pixel 8 的夜景拍照能力”系统可能走了一条路径先调用搜索插件查参数 → 再调用知识库查评测原文 → 最后让 LLM 综合生成结论。如果最终输出漏掉了 Pixel 8 的数据问题可能出在搜索插件返回了空结果但 HTTP 状态是 200也可能出在知识库检索时 embedding 相似度阈值设得过高导致没召回关键段落还可能是 LLM 在生成时被截断了后半句。这些环节彼此嵌套、状态不透明、失败无明确报错靠传统 metricsQPS、延迟和 logs单行文本完全无法定位。Opik 正是为解决这个本质矛盾而生的——它不试图去“监控”LLM 的内部权重而是专注捕获和结构化 LLM 应用的执行轨迹trace。每一个 trace 就是一次用户请求的完整生命线里面包含多个span一个 span 可能是“调用 OpenAI API”另一个 span 是“执行 RAG 检索”再一个 span 是“解析 JSON 输出”。每个 span 带着输入 prompt、实际输出、token 计数、耗时、错误信息哪怕只是{error: invalid_json}、甚至自定义的 metadata比如当前用户的 VIP 等级、本次请求的业务场景标签。这不是日志聚合而是把一次对话变成一张可钻取、可关联、可统计的因果图。我后来用 Opik 追踪到一个稳定复现的问题当用户 query 包含 emoji 时RAG 检索模块的 embedding 模型会静默降维导致召回率暴跌 60%但所有上游服务都显示“成功”。这种问题没有 trace 级别的上下文串联根本不可能发现。提示可观测性不是给运维看的是给产品、算法、开发三方共用的“真相源”。产品经理靠它验证 prompt 效果是否随版本下降算法工程师靠它分析 bad case 的 token 分布特征开发靠它确认工具调用链路是否符合预期。Opik 的价值首先体现在它让这三个角色第一次能在同一份数据上对齐认知。2. Opik 的核心设计哲学不做代理只做记录者很多团队一听说“LLM 可观测性”第一反应是找一个中间件代理所有 LLM 请求——比如在应用和 OpenAI 之间加一层网关由网关统一打点、记录、转发。这条路看似直接实则埋了三个深坑第一网关本身成了单点故障LLM 请求本就高延迟再加一层网络跳转P99 延迟直接翻倍第二网关无法感知应用层的语义逻辑它只知道“发了一个 POST /v1/chat/completions”但不知道这次调用是为了生成邮件草稿还是执行 SQL 查询metadata 严重缺失第三也是最致命的它完全无法覆盖本地模型如 llama.cpp、自研推理服务、甚至非 HTTP 的模型调用比如通过 Python subprocess 调用 Ollama。Opik 的选择非常清醒它不碰网络层不改请求路径不引入任何额外延迟。它的核心是一个轻量级 SDK以instrumentation插桩方式嵌入你的应用代码。你不需要改一行 HTTP 客户端代码只需要在初始化 LLM 客户端时加一个 wrapperfrom opik import track from openai import OpenAI # 原始 client client OpenAI(api_keysk-...) # Opik 包装后的 client —— 零延迟零网络跳转 opik_client track(client, nameopenai-wrapper)这个track函数干了什么它利用 Python 的functools.wraps和inspect.signature动态劫持了client.chat.completions.create方法的调用入口和出口在函数执行前自动创建一个 span记录下所有传入参数model、messages、temperature 等在函数返回后自动捕获响应体、计算耗时、提取 token 数并将整个 span 关联到当前 trace。整个过程发生在应用进程内存内毫秒级开销且完全兼容异步async def和同步调用。更关键的是Opik 的插桩是语义感知的。它不只是记录“调用了哪个 API”而是理解“这次调用在业务流程中扮演什么角色”。比如你在写一个 Agent 编排逻辑track(nameagent-step-execute-tool) def execute_tool(tool_name: str, input: dict) - dict: # 实际调用工具的逻辑 result tools[tool_name](input) return {tool: tool_name, result: result} # 在 agent 主循环中 for step in plan: if step.type tool_call: # 这个 span 会自动带上 step.id, step.type 等业务上下文 execute_tool(step.tool_name, step.input)Opik 会自动将execute_tool的 span 标记为agent-step-execute-tool并注入step.id作为 custom attribute。这意味着你后续在 UI 上筛选 trace 时可以直接按step.type tool_call过滤而不是在海量日志里 grep “tool_call”。这种设计哲学决定了 Opik 的适用边界它不替代 Prometheus指标、不替代 ELK日志、不替代 Jaeger分布式追踪而是成为 LLM 应用专属的“语义追踪层”补全传统可观测性栈在 AI 场景下的最后一块拼图。注意Opik SDK 的侵入性极低。它不要求你重构整个应用架构也不强制使用其 client。你可以只对最关键的几个 LLM 调用点比如主 prompt 生成、RAG 检索、tool call进行track其他部分保持原样。这种渐进式接入是它能在真实业务中快速落地的关键。3. 从零搭建 Opik 服务Docker Compose 三分钟部署与配置要点Opik 提供两种部署模式SaaS 托管版opik.ai和开源自托管版。对于重视数据主权、有定制化需求或需对接内部认证体系的团队自托管是唯一选择。官方推荐的部署方式是 Docker Compose但直接docker-compose up很容易踩坑——因为默认配置针对演示场景生产环境必须调整四个关键参数。首先拉取最新镜像并创建docker-compose.ymlmkdir opik-deploy cd opik-deploy curl -O https://raw.githubusercontent.com/epiclabs-io/opik/main/docker-compose.yaml默认的docker-compose.yaml启动的是 SQLite 数据库这仅适用于单机测试。生产环境必须切换为 PostgreSQL。修改services.opik-db部分opik-db: image: postgres:15-alpine environment: POSTGRES_DB: opik POSTGRES_USER: opik POSTGRES_PASSWORD: your_strong_password_here # 必须修改 volumes: - ./pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U opik -d opik] interval: 30s timeout: 10s retries: 3接着修改services.opik的环境变量这是最容易被忽略的致命点opik: # ... 其他配置 environment: OPIC_DATABASE_URL: postgresql://opik:your_strong_password_hereopik-db:5432/opik OPIC_JWT_SECRET: generate_a_32_byte_random_string_here # 必须用于 session 加密 OPIC_ADMIN_EMAIL: adminyourcompany.com # 用于首次登录 OPIC_ADMIN_PASSWORD: your_admin_password # 首次登录密码 OPIC_DISABLE_AUTH: false # 生产环境务必设为 false提示OPIC_JWT_SECRET必须是 32 字节的随机字符串。我见过太多团队用secret123导致 session 被伪造。生成命令openssl rand -hex 32。这个 secret 一旦设定就不能轻易更改否则所有现有用户 session 失效。启动服务docker-compose up -d # 等待数据库初始化完成约 30 秒 docker-compose logs -f opik | grep Server started服务启动后访问http://localhost:8000用OPIC_ADMIN_EMAIL和OPIC_ADMIN_PASSWORD登录。首次登录后系统会引导你创建第一个 Project。Project 是 Opik 的数据隔离单元建议按业务线划分customer-support-llm、internal-analytics-agent、marketing-content-generator。每个 Project 有独立的 API Key前端 SDK 或后端服务通过OPIK_PROJECT_NAME和OPIK_API_KEY环境变量关联。一个常被忽视的配置是trace 采样率。Opik 默认全量采集这对高 QPS 业务不现实。在opik服务的环境变量中添加environment: # ... 其他变量 OPIC_TRACE_SAMPLING_RATE: 0.1 # 仅采集 10% 的 trace采样不是随机丢弃而是基于 trace_id 的哈希值做确定性采样确保同一个用户会话trace_id 相同要么全采要么全不采避免会话断裂。我们线上将客服场景设为 100% 采样因需 100% 追踪 bad case而内容生成场景设为 5%平衡了数据价值与存储成本。4. SDK 集成实战从单点记录到全链路追踪的四层演进Opik SDK 的集成不是一蹴而就的“加个装饰器”而是一个渐进式的价值释放过程。我把它拆解为四个清晰的演进层级每层解决一类典型问题也对应着团队对 LLM 应用理解的深化。4.1 第一层基础 Span 记录解决“谁调用了谁”这是入门级用法目标是让每一次 LLM 调用都留下可查证的痕迹。以 FastAPI 应用为例from fastapi import FastAPI, HTTPException from opik import track from openai import OpenAI app FastAPI() client track(OpenAI(api_keysk-...), nameopenai-client) app.post(/summarize) async def summarize(text: str): try: response client.chat.completions.create( modelgpt-4-turbo, messages[{role: user, content: f请用 3 句话总结以下内容{text}}], temperature0.3 ) return {summary: response.choices[0].message.content} except Exception as e: raise HTTPException(status_code500, detailstr(e))部署后每次/summarize请求都会在 Opik UI 中生成一个 trace包含一个名为openai-client.chat.completions.create的 span。你能看到输入 prompt 的完整文本自动截断过长内容输出的 content、finish_reason、usageprompt_tokens、completion_tokens耗时end_to_end_latency_ms错误堆栈如果调用失败这一层的价值在于当用户投诉“总结不准”你不再需要翻日志猜而是直接在 Opik 中搜索该用户 ID 或时间范围找到对应 trace一眼看清模型实际收到了什么 prompt、返回了什么 content、token 消耗是否异常。4.2 第二层手动 Span 创建解决“业务逻辑在哪里断了”基础记录只能看到 LLM 调用但看不到业务编排。比如一个 RAG 流程query → embedding → vector search → rerank → LLM generate。你需要明确知道哪一步出了问题。这时用opik.tracer.start_span()手动创建 spanfrom opik import tracer app.post(/rag-answer) async def rag_answer(query: str): # Step 1: Embedding with tracer.start_span(nameembedding, input{query: query}) as span: embedding embedder.encode(query) span.end(output{embedding_dim: len(embedding)}) # Step 2: Vector Search with tracer.start_span(namevector-search, input{embedding: embedding.tolist()[:5]}) as span: results vector_db.search(embedding, top_k5) span.end(output{matched_docs_count: len(results)}) # Step 3: LLM Generation with tracer.start_span(namellm-generate, input{context: [r.text for r in results[:3]]}) as span: response client.chat.completions.create( modelgpt-4-turbo, messages[{role: user, content: f基于以下资料回答{query}\n\n资料{results}}] ) span.end(output{answer: response.choices[0].message.content})现在一个/rag-answer请求会生成一个 trace里面包含三个嵌套 span。你可以直观看到embedding 耗时 12msvector search 返回了 5 个结果但 LLM 生成时只用了前 3 个——如果答案质量差优先检查vector-searchspan 的matched_docs_count是否为 0而不是盲目调优 LLM。4.3 第三层Trace 关联与上下文传递解决“跨服务调用怎么串起来”真实系统中LLM 服务往往只是链条一环。比如用户在前端发起请求 → API 网关 → 认证服务 → LLM 服务 → 工具调用服务。Opik 支持通过trace_id透传实现跨服务 trace 关联。关键是在服务间传递X-Opik-Trace-IDHTTP header# 在网关服务中收到请求时生成 trace_id 并透传 import uuid from opik import tracer app.middleware(http) async def add_trace_id(request: Request, call_next): trace_id str(uuid.uuid4()) request.state.trace_id trace_id response await call_next(request) response.headers[X-Opik-Trace-ID] trace_id return response # 在 LLM 服务中从 header 读取并关联 app.post(/llm-call) async def llm_call(request: Request): trace_id request.headers.get(X-Opik-Trace-ID) if trace_id: tracer.set_trace_id(trace_id) # 强制关联到上游 trace # ... 后续 LLM 调用这样前端、网关、LLM 服务、工具服务的所有 span 都会出现在同一个 trace 下。当你发现某个 LLM 输出异常可以一键跳转到上游网关的 trace查看原始用户请求体、认证服务返回的用户权限信息彻底打通全链路。4.4 第四层自定义评估与自动化告警解决“好坏怎么量化”Opik 最强大的能力是把 trace 数据变成可计算的信号。比如你定义“bad answer”为LLM 输出包含抱歉、我不清楚、无法回答等关键词且 token 使用率低于 30%说明 prompt 没被充分消化。你可以写一个评估函数from opik.evaluation import evaluate from opik.evaluation.metrics import Contains, TokenUsageRatio def is_bad_answer(trace): llm_span trace.spans[-1] # 假设最后一个 span 是 LLM 调用 output llm_span.output.get(content, ) usage llm_span.output.get(usage, {}) prompt_tokens usage.get(prompt_tokens, 0) completion_tokens usage.get(completion_tokens, 0) return ( Contains([抱歉, 我不清楚, 无法回答]).score(output) 1.0 and TokenUsageRatio().score({prompt_tokens: prompt_tokens, completion_tokens: completion_tokens}) 0.3 ) # 批量评估最近 1000 个 trace results evaluate( datasetcustomer-support-traces, evaluators[is_bad_answer], limit1000 ) # 输出 bad rate bad_rate sum(r.score for r in results) / len(results) print(fBad answer rate: {bad_rate:.2%})这个bad_rate可以接入 Prometheus设置告警规则当opik_bad_answer_rate{projectcustomer-support} 0.05时触发企业微信告警。从此“LLM 服务质量”不再是主观评价而是可监控、可告警、可归因的 SLO 指标。5. 高阶技巧与避坑指南那些文档里不会写的实战经验Opik 的文档清晰易懂但真实落地时有五个关键细节几乎每个团队都会踩坑而它们恰恰决定了可观测性能否真正驱动业务改进。5.1 Prompt 版本管理别让 trace 变成“考古现场”我们曾遇到一个棘手问题某天客服摘要的准确率突然下降 15%但 Opik 显示所有 trace 的 prompt 文本都一样。排查三天后才发现prompt 里引用了一个外部知识库 URLhttps://docs.yourcompany.com/v2/faq.json而该 URL 的内容被运营同事悄悄更新了——Opik 记录的是运行时实际 fetch 到的内容但 UI 上只显示静态的 prompt 模板字符串。解决方案是在 prompt 中显式注入版本号并作为 span attribute 记录# 错误动态内容不显式标记 prompt f请基于 {FAQ_URL} 的 FAQ 回答用户问题 # 正确绑定版本号 FAQ_VERSION 2024-Q3 # 从配置中心或 git tag 获取 with tracer.start_span( namellm-summarize, input{prompt_template: faq_summarize_v1, faq_version: FAQ_VERSION} ) as span: full_prompt f请基于 {FAQ_URL}?v{FAQ_VERSION} 的 FAQ 回答... # ... 调用 LLM这样在 Opik UI 中筛选faq_version 2024-Q2就能精准对比两个版本的效果差异。我们后来建立了规范所有动态 prompt 元素URL、模板名、变量值都必须作为input的 key-value 对显式传入禁止在 prompt 字符串里硬编码。5.2 Token 计数陷阱不同 SDK 的差异必须统一OpenAI Python SDK 的response.usage返回的是精确 token 数但 Anthropic 的response.usage.input_tokens和output_tokens是估算值而本地 llama.cpp 的 token 计数依赖于 tokenizer 实现。如果你用 Opik 同时追踪多个模型直接比较completion_tokens会得出错误结论。我们的解决方案是在 span 结束前用统一 tokenizer 重算一次from transformers import AutoTokenizer # 全局初始化统一 tokenizer选一个通用的如 gpt2 tokenizer AutoTokenizer.from_pretrained(gpt2) def calculate_tokens(text: str) - int: return len(tokenizer.encode(text, truncationFalse, add_special_tokensFalse)) # 在 LLM 调用后 response client.chat.completions.create(...) actual_completion_tokens calculate_tokens(response.choices[0].message.content) span.end( output{ content: response.choices[0].message.content, actual_completion_tokens: actual_completion_tokens, # 用这个字段做统计 reported_completion_tokens: response.usage.completion_tokens # 保留原始值用于 debug } )我们在 Opik 的 dashboard 中所有“token 成本分析”图表都基于actual_completion_tokens字段确保跨模型比较的公平性。这个细节让我们的 LLM 成本优化项目节省了 23% 的 token 开销。5.3 敏感信息过滤不是删日志而是建白名单LLM 应用天然处理大量 PII个人身份信息用户姓名、手机号、订单号、地址。Opik 默认会记录所有input和output直接暴露在 UI 上风险极高。Opik 提供filter_inputs_outputs参数但简单地replace或mask会破坏调试价值——你无法判断是模型没理解 masked 的地址还是地址本身格式就有问题。我们的实践是建立字段级白名单只记录必要字段# 定义白名单哪些字段可以明文记录 SAFE_INPUT_FIELDS {query, topic, language} SAFE_OUTPUT_FIELDS {summary, sentiment_score} def safe_input_filter(input_dict: dict) - dict: return {k: v for k, v in input_dict.items() if k in SAFE_INPUT_FIELDS} def safe_output_filter(output_dict: dict) - dict: return {k: v for k, v in output_dict.items() if k in SAFE_OUTPUT_FIELDS} # 在 track 时启用 client track( OpenAI(...), namesafe-openai, filter_inputs_outputsTrue, input_filtersafe_input_filter, output_filtersafe_output_filter )这样input中只有query和topic会显示output中只有summary和sentiment_score可见其他字段如user_phone,order_id在 Opik UI 中完全不可见但仍在应用内存中参与逻辑不影响功能。审计时我们只需证明白名单字段不包含 PII 即可。5.4 Trace 生命周期管理避免磁盘被撑爆Opik 默认不清理历史 trace而 LLM 应用 trace 数据量极大一个 trace 平均 50KBQPS 100 就是每天 432GB。我们线上采用三级 TTL 策略热数据7天保留在 PostgreSQL支持实时查询和 dashboard。温数据90天每日凌晨导出为 Parquet 文件存入对象存储S3 兼容供离线分析。冷数据90天自动删除。实现方式是在docker-compose.yml中增加一个 cron 服务opik-cleanup: image: postgres:15-alpine depends_on: - opik-db command: sh -c sleep 300 psql -h opik-db -U opik -d opik -c \ DELETE FROM traces WHERE created_at NOW() - INTERVAL 7 days; DELETE FROM spans WHERE trace_id IN (SELECT id FROM traces WHERE created_at NOW() - INTERVAL 7 days); \ restart: always environment: PGPASSWORD: your_strong_password_here这个脚本每天执行确保数据库体积可控。更重要的是它让我们敢于开启 100% 采样——因为知道数据不会无限堆积。5.5 与现有监控栈的融合让 Opik 成为“AI 仪表盘”的心脏Opik 不是孤立的工具它必须融入公司已有的监控体系。我们将其与 Grafana 深度集成在 PostgreSQL 中创建物化视图预计算bad_answer_rate、avg_latency_per_model、token_cost_per_user_segment在 Grafana 中添加 Opik 数据源用这些物化视图构建 dashboard关键指标如opik_bad_answer_rate同时推送到 Prometheus与其他服务指标API 延迟、DB 连接数放在同一面板。最实用的一个联动是当 Opik 的bad_answer_rate告警触发时Grafana 自动跳转到关联的 trace 列表并在右侧 panel 显示同一时段的 CPU 使用率、内存占用、PostgreSQL 连接数。我们因此发现了一个隐藏问题当服务器内存使用率超过 85% 时llama.cpp 的 tokenizer 会静默降级导致 prompt 解析错误——这原本属于基础设施问题但只有通过 Opik 的业务指标才能触发根因分析。我的经验是Opik 的价值不在于它自己有多炫的 UI而在于它能把 LLM 的“黑箱行为”翻译成其他系统能理解的信号。当你能在 Grafana 里看到“LLM 准确率下降”和“GPU 显存泄漏”两条曲线高度相关时可观测性才真正完成了它的使命。6. 性能压测与稳定性验证Opik 在万级 QPS 下的真实表现技术选型最怕纸上谈兵。我们花了两周时间对 Opik 进行了全链路压测模拟真实生产环境的极限压力。测试环境3 台 16C32G 云服务器PostgreSQL 15SSDOpik 服务2 实例压测工具 Locust。6.1 基准测试单实例吞吐与延迟首先测试单个 Opik 实例的极限。我们固定 LLM 调用 QPS 为 1000持续 30 分钟观察 Opik 的表现指标数值说明Opik 实例 CPU 使用率峰值 62%未达瓶颈仍有余量Opik 实例内存占用稳定在 1.8GBGC 正常无内存泄漏平均 trace 写入延迟8.2ms从 span 创建到 DB commitP99 trace 写入延迟24ms可接受LLM 本身延迟常为 500msPostgreSQL WAL 写入速率12MB/s低于 SSD 顺序写入上限200MB/s结论单实例 Opik 完全能支撑 1000 QPS 的 LLM 应用且延迟开销在业务可容忍范围内5% 总延迟。6.2 水平扩展测试多实例 连接池当 QPS 提升到 5000 时单实例 PostgreSQL 成为瓶颈连接数打满WAL 写入饱和。我们启用 Opik 的多实例部署Opik 服务扩容至 4 实例负载均衡PostgreSQL 启用连接池PgBouncer最大连接数 2000所有 Opik 实例共享同一个 PgBouncer endpoint结果QPSOpik 实例数PostgreSQL 连接数P99 写入延迟系统稳定性1000112024ms✅3000238031ms✅5000482042ms✅800041980128ms⚠️开始抖动当连接数接近 2000 时P99 延迟陡增。解决方案不是继续加实例而是优化 span 写入批处理。Opik 支持batch_size和batch_interval参数# 在 Opik 初始化时 opik.configure( batch_size100, # 每 100 个 span 批量写入 batch_interval1000, # 或每 1000ms 强制 flush )开启批处理后8000 QPS 下 P99 延迟降至 58msPostgreSQL 连接数稳定在 420。这证明 Opik 的水平扩展能力足够应对绝大多数企业级场景。6.3 故障注入测试验证韧性我们模拟了三种典型故障PostgreSQL 宕机 30 秒Opik SDK 自动启用内存缓冲in-memory buffer30 秒内 span 数据暂存内存恢复后批量重发。trace 无丢失但 UI 实时性延迟 30 秒。Opik 实例 50% 掉线负载均衡自动剔除剩余实例承接全部流量P99 延迟上升 15%无请求失败。网络分区Opik 与 DB 间丢包SDK 持续重试指数退避buffer 满后自动丢弃最老 span可配置策略保障主线程不阻塞。实测下来Opik 的韧性设计非常务实它不追求“永远不丢数据”而是保证“绝不影响业务请求”。对于 LLM 应用延迟敏感度远高于 trace 完整性——用户宁可接受 1% 的 trace 丢失也不愿看到响应延迟从 800ms 变成 5s。Opik 的设计哲学在此刻体现得淋漓尽致。7. 未来演进Opik 如何支撑 LLM 应用的下一阶段挑战Opik 当前版本v1.12已很好地解决了 LLM 应用的 trace 可视化问题但随着 LLM 应用走向更深的工程化还有三个方向值得期待也是我们团队正在与 Opik 团队共建的领域。7.1 实时流式评估从“事后分析”到“事中干预”现在的评估都是 batch 模式滞后数小时。但对于金融客服、医疗咨询等强实时场景需要在 LLM 输出流式 token 的过程中就判断质量。比如当模型生成第 3 个 token 就出现根据我的知识这种模糊表述时就应该中断生成并 fallback。Opik 正在开发streaming_evaluator接口允许你在on_token回调中注入评估逻辑def real_time_guardian(token: str, context: dict) - bool: # context 包含已生成的 tokens、原始 prompt、当前 span id if 根据我的知识 in context[generated_text_so_far]: return False # 中断生成 return True # 注册到 Opik opik.register_streaming_evaluator(guardian, real_time_guardian)这将 Opik 从可观测性工具升级为“质量控制网关”。7.2 多模态 trace不止于文本当前 Opik 的 trace 主要围绕 text-in/text-out。但越来越多的应用涉及图像、音频、视频。比如一个视觉问答系统用户上传图片 → OCR 提取文字 → LLM 理解图文 → 生成答案。Opik 需要支持image_url、audio_duration_ms、video_fps等新字段并在 UI 中提供图片缩略图预览、音频波形图。我们已提交 PR为Span添加media字段支持 base64 编码的二进制数据或 CDN URL。7.3 LLM-native APM从“记录”到“优化建议”终极形态的 Opik应该能基于海量 trace 数据主动给出工程优化建议。例如检测到temperature0.8的请求中finish_reasonlength的比例高达 40%提示你“考虑增加 max_tokens 或优化 prompt 截断逻辑”发现rerankspan 的耗时标准差是均值的 5 倍提示你“检查 rerank 模型的 batch size 配置”统计到tool_callspan 的error_codetimeout集中在下午 2-4 点关联到数据库慢查询日志提示你“该时段有定时任务占满 CPU”。这不再是简单的数据展示而是把 Opik 变成一个懂 LLM 工程的“虚拟 SRE”。我们相信当可观测性开始驱动自动化优化时LLM 应用的成熟度才算真正迈入新阶段。我在实际使用中发现Opik 最大的价值不是它提供了多少炫酷功能而是它强迫团队建立起一种新的工程习惯每一次 prompt 修改、每一次模型升级、每一次工具集成都必须伴随着可观测性的同步更新。这种习惯让 LLM 应用从“艺术创作”走向“可验证的工程实践”。