Dify 应用上线后的 LLMOps：该看哪些日志和指标

Dify 应用上线不是项目终点，而是开始接触真实表达、真实资料和真实故障。只看调用次数与平均耗时，会漏掉最重要的问题：用户是否完成任务、引用是否支持答案、工具是否产生正确业务结果。LLMOps 要把一次请求从入口关联到检索、模型、工作流、工具和人工处理，并用业务可理解的方式决定继续观察、修正还是回退。

判断这个场景是否适合

几乎所有生产应用都需要基本观测，但深度应与风险匹配。内部低风险问答可关注可用性、引用与反馈；会写入系统、面向外部或处理敏感数据的应用，还需动作审计、权限异常、人工审批和数据泄露告警。先列出应用失败会造成什么影响，再选择指标，避免收集大量数据却无法支持决策。

可观测的前提是定义成功。知识问答可以用找到有效证据、回答被采纳、转人工原因来衡量；字段抽取关注字段正确、格式合法与人工改动；工单助手关注草稿通过、驳回原因和最终是否成功提交。用户点赞不能单独代表准确，低反馈也不必然说明失败。每个指标要有负责人、统计口径、查看频率和触发动作。

还要确定允许记录什么。原始提示、检索片段和工具参数有助排障，却可能包含个人信息、商业材料和密钥。日志方案应先做数据分级，默认保存标识、版本、耗时、状态和必要摘要，正文按授权采样、脱敏并限制保留。没有访问审计和删除机制时，不应为了调试把所有内容长期落盘。

实施时怎么拆

首层是业务与质量。记录任务类型、是否完成、是否转人工、用户纠错及审核结论。抽样评审要使用明确准则：事实有无证据、引用是否有效、是否遗漏关键限制、格式是否符合下游要求。争议样本由业务负责人裁定并进入回归集，不能让模型自动评分成为单一结论。

第二层是检索和模型。检索记录数据集版本、过滤条件、候选与最终引用，观察无结果、引用失效和目标证据排名。模型侧记录供应商、模型标识、应用与提示版本、输入输出规模、首字延迟、总耗时、错误和重试。质量下降时先区分知识变化、检索失败还是生成误读，再选择重建索引、调整流程或回退模型。

第三层是工作流与工具。节点级耗时和错误能发现瓶颈，运行标识要贯穿外部调用。写工具记录幂等键、审批和业务结果，区分请求超时与实际未执行。队列积压、重复调用、循环次数和人工待办时长都应有告警。告警通知包含应用、版本、影响、开始时间和排查入口，不能只发送一条无上下文错误码。

成本与容量按一次业务任务归集，包含检索、多个模型节点、重试和工具调用。分别观察高频正常请求、异常长输入和循环造成的消耗，并设置预算预警。发布前记录基线，新版本通过小流量比较质量、延迟、错误和消耗。任何关键指标恶化时都能关闭新版本或特定节点，回滚后确认正在运行的旧任务和新任务没有混用配置。

不要忽略的限制

指标会被平均值掩盖，必须按应用、任务、用户群、模型和版本分组，并关注高延迟和严重失败。自动评测只能作为筛查，特别是合规、合同和医疗等高后果内容需要具备资格的人复核。线上反馈存在偏差，沉默用户和失败后离开的用户不会主动留下评价，因此要结合任务完成与人工抽样。

监控本身也可能失败。应测试日志中断、告警渠道不可用、时钟偏差和存储达到上限，并保留最小运行探针。复盘不只调整提示词，还要记录根因、影响范围、临时处置、长期修正和验证证据。若问题涉及错误写入，先停用相关工具并人工对账；模型版本回滚不能撤销外部结果。成熟的 LLMOps 不是一张大屏，而是每个异常都有明确判断和处置流程。

参考资料

• Dify 官方文档