大模型可观测与评测闭环：Langfuse+LangSmith结合OTel，落地Prompt A/B评测24.8

一、前言

        现在我们做大模型应用，有个最基础、最直观的体会：写好Prompt、调通API只是项目的起点。本地测试效果看着很不错，一旦上线之后各种问题接踵而至。同样的输入，大模型时而回答精准，时而幻觉频发；不同Prompt版本效果好坏靠主观感觉判断，没有量化数据；线上用户真实问题无法回流，模型迭代全凭开发人员猜问题出在哪里；出现故障时，很难定位是Prompt问题、检索上下文问题、还是LLM本身输出不稳定。

        早期开发原型阶段，我们可以手动跑样例、肉眼看结果。但当业务走向生产环境，面向真实用户流量，就必须一套完整体系：可观测追踪、Prompt 实验能力、自动化评测、人工标注、线上反馈闭环。市面上LangSmith、Langfuse已经成为主流大模型追踪工具，OpenTelemetry提供通用可观测标准，Prompt A/B测试用来对比不同提示词版本优劣，自动化评测集保证迭代不退化，人工标注和用户反馈补齐自动化评测覆盖不到的场景。

        如果没有完整的体系概念和思路，很容易会把这些组件当成独立工具使用：只拿LangSmith打日志，只单独写评测脚本，各个模块互相割裂，无法形成闭环。真正工程化落地，不是简单堆砌工具，而是把追踪、实验、评测、标注、线上反馈串联起来，形成完整迭代链路。

二、大模型可观测基础

1. LLM可观测介绍

        传统软件可观测包含日志、指标、链路追踪三大支柱。但大模型应用属于生成式 AI，它和普通接口服务有本质区别。普通接口输入固定，输出确定性强；大模型同样输入，输出具备随机性。传统监控只能看到接口报错、耗时、QPS，看不到Prompt完整内容、模型返回文本、中间思考步骤、RAG 检索出来的文档、工具调用参数、幻觉现象。

大模型场景下的可观测，核心要回答这几类问题：

• 每一次用户请求完整链路是什么样？用户输入、Prompt模板、检索上下文、大模型输出全部留存。
• 性能指标：Token消耗、链路耗时、各个子步骤耗时分布。
• 质量指标：回答是否幻觉、是否答非所问、用户是否满意。
• 故障定位：输出异常的时候，到底是输入Prompt、检索数据、还是LLM模型本身导致。

大模型可观测分为两大路线，两者不是互斥关系，可以互相配合使用：

• 一类是大模型专用追踪工具，代表为LangSmith、Langfuse；
• 另一类是通用可观测标准OpenTelemetry。

        在没深入深入了解前，很容易混淆彼此，LangSmith、Langfuse不是简单日志打印工具。它们专门针对LLM调用链做抽象，会区分不同Span类型：LLM调用、Retrieval检索、Tool工具调用、Prompt模板渲染、Agent 思考步骤，把大模型应用复杂执行过程完整还原。

        传统日志库只能打印字符串文本，无法结构化保存Prompt变量、输入输出、token消耗、嵌套 Agent调用层级。如果我们自己手写日志，要处理大量结构化字段，工作量巨大，还很容易遗漏关键字段。这就是专用LLM追踪工具存在的价值。

2. LangSmith与Langfuse对比

        LangSmith是LangChain官方配套产品，Langfuse是开源可观测平台，二者能力高度重合，但设计定位有差异。

LangSmith 核心特点

• 和LangChain生态深度原生集成，一行开关即可开启追踪；非LangChain代码也支持SDK埋点。
• 开箱即用评测数据集、评测器，原生支持跑自动化评测，UI交互偏向开发者调试。
• SaaS版本开箱即用，也支持自托管；适合重度使用LangChain技术栈团队。

Langfuse核心特点

• 完全开源，可完整私有化部署，数据完全掌握在自己内部，对数据敏感业务更友好。
• 设计更偏向产品闭环：原生内置用户反馈打分、Prompt管理、Prompt A/B测试、标注工作台。
• SDK 支持 Python、JS/TS，不绑定LangChain，任意大模型应用都可以接入，兼容OpenAI原生调用、自定义Agent。

两者共同能力：

• 链路追踪：记录完整 trace，包含每一步输入输出、token用量、耗时、错误堆栈。
• Prompt 管理：保存Prompt 模板，支持版本管理。
• 数据集管理：保存样例，用于后续评测。
• 人工打分：对Trace做质量标记。

简单总结选型参考：

• 如果项目重度依赖LangChain，快速做原型评测，优先LangSmith。
• 如果需要私有化部署、数据不能出内网、需要原生Prompt A/B、线上用户反馈收集，优先Langfuse。

3. OpenTelemetry适配LLM

        OpenTelemetry是一套通用可观测标准，简称OTel，不属于大模型专属工具。它定义统一 Trace、Metrics、Logs数据格式，可以把链路数据输出到Jaeger、Zipkin、Prometheus、Elasticsearch各类后端。

        为什么大模型项目需要OTel？ LangSmith、Langfuse有自己的数据存储与UI。企业内部往往已经有一套成熟监控体系。直接把所有可观测数据全部丢给第三方SaaS平台，存在数据合规、数据出境、权限管控问题。OTel可以作为中间标准层：把 LLM 调用链路输出标准OTel Span，一份数据，既可以推送到Langfuse做AI业务分析，同时推送到企业内部现有监控平台做运维监控。

        目前社区已经有LLM语义约定，在OTel Span中约定LLM相关属性：模型名称、prompt内容、completion输出、token输入输出数量、temperature参数等。

示例：Python OpenAI + Langfuse OpenTelemetry桥接片段

from openai import OpenAI
from langfuse.openai import langfuse_context
import opentelemetry

client = OpenAI()

# 开启追踪，Langfuse同时支持输出OTel标准span
langfuse_context.configure(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="http://localhost:3000",
    otel_exporter_enabled=True
)

completion = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role":"user","content":"解释什么是大模型可观测"}]
)
print(completion.choices[0].message.content)

上面示例执行完成后，一次大模型调用会生成两份数据：

• 一份存入 Langfuse，用于Prompt调试、评测、查看用户反馈；
• 一份输出标准OpenTelemetry Trace，可以被Jaeger采集，用于运维层面监控耗时、错误率、token指标。

4. 可观测落地注意事项

可观测上线最容易出现的问题，这里做几点实践提醒：

• 敏感数据处理：用户输入会包含手机号、身份证等隐私信息。生产环境必须配置脱敏规则，不要原样存储敏感文本。Langfuse、LangSmith都支持回调钩子，在数据入库之前做内容脱敏。
• 采样策略：线上流量很大，100%全量存储所有Trace成本很高。生产环境配置采样，比如100%采样异常请求，10%采样正常流量；关键业务链路100%保存。
• 区分开发 / 测试 / 生产环境：设置environment标签，把dev、staging、prod链路数据隔离，不要混在一起，否则UI查询时数据混乱。
• Trace 附加业务属性：每条Trace带上用户ID、会话ID、业务场景标签。后续筛选、做用户反馈闭环，这些字段至关重要。

三、Prompt A/B 测试实践

1. Prompt 迭代的痛点

开发大模型应用，Prompt是核心资产。同样业务需求，可以写出多版Prompt。

• v1：简单直白指令；
• v2：增加角色设定，增加输出格式约束；
• v3：增加Few-shot示例；
• v4：增加约束规避幻觉。

        在多版Prompt情况下，我们该如何确定哪一个 Prompt 版本线上效果更好？通常我们的做法，通过本地跑10几个样例，主观感觉v3效果不错，直接上线。这种方式风险很高，本地少量样例不代表真实用户分布。部分Prompt在测试样例表现优秀，遇到真实用户五花八门输入就翻车。

        Prompt A/B测试，就是解决这个问题：线上流量做分流，一部分流量走Prompt A版本，一部分流量走Prompt B版本，基于真实业务数据，量化对比两个版本各项指标，用数据决定哪个版本上线，而不是靠开发者主观感受。

        Prompt A/B不等同于简单离线对比。离线评测使用固定评测集；A/B测试使用真实线上用户流量，能够捕捉到离线测试覆盖不到的真实输入分布。

2. A/B测试核心要素

一套完整 Prompt A/B 测试体系，必须包含下面几个组件：

• Prompt 版本管理：所有Prompt模板统一存储，版本化，不能散落在代码硬编码字符串。支持在线修改Prompt，不需要发布服务代码。Langfuse原生提供Prompt管理仓库；LangSmith也有Prompt Hub。
• 流量分流器：请求进来，根据分流策略分配不同Prompt版本。支持按百分比切分流量，支持按用户ID哈希做稳定分流，同一个用户始终使用同一个Prompt版本，避免同一个用户来回切换版本造成体验混乱。
• 链路埋点关联：每一条Trace必须标记当前使用的Prompt版本ID。后续统计指标，能够按Prompt版本做分组聚合。
• 效果指标体系
  • 客观指标：平均耗时、总token 消耗、错误率。
  • 用户侧指标：用户点赞/点踩反馈率。
  • 评测指标：自动化评测打分平均分。
• 结果判定与回滚：对比两个版本指标，判断新版本是否优于旧版本；新版本指标恶化，支持快速切回旧 Prompt 版本。

示例：Prompt 分流逻辑

        以下示例实现稳定分流，30%用户流量走到v2新版本Prompt，70%继续使用基线v1。每条Trace绑定prompt_id，后续平台就可以按prompt版本分组统计用户反馈、自动化评测分数。

import hashlib

def get_prompt_version(user_id: str, traffic_ratio_b: float=0.3):
    # 根据user_id哈希稳定分流
    hash_val = int(hashlib.md5(user_id.encode()).hexdigest(),16) % 100
    if hash_val < traffic_ratio_b * 100:
        # B组：新版本Prompt
        return {
            "prompt_id":"prompt_summary_v2",
            "template":"你是专业摘要助手，输出精简摘要，控制在100字以内：{input_text}"
        }
    else:
        # A组：基线旧版本
        return {
            "prompt_id":"prompt_summary_v1",
            "template":"对下面文本做摘要：{input_text}"
        }

# 业务调用
user_id = "user_123456"
prompt_info = get_prompt_version(user_id, traffic_ratio_b=0.3)
# trace记录prompt_id，用于后续统计
langfuse_context.update_current_trace(
    prompt_id=prompt_info["prompt_id"],
    user_id=user_id
)

3. A/B测试常见误区

• 样本量不足就下结论：只跑几十条请求就判定新版本更好。大模型输出存在随机性，需要足够样本量，指标差异才具备统计意义。
• 没有基线版本：直接两个新Prompt互相对比。一定要保留线上当前正在使用版本作为A组基线。
• 流量不稳定分流：使用随机数，同一用户一会A一会B，用户体验波动，统计结果失真。优先使用用户ID哈希分流。
• 只看主观效果忽略成本：新版本回答质量提升，但是token用量翻倍，成本大幅上涨，综合业务收益不一定正向。A/B测试同时要观测token消耗指标。
• Prompt 硬编码写死代码，没有版本ID埋点。就算做了流量切分，后续无法回溯哪条Trace使用哪个Prompt版本，无法统计对比。

4. 离线预实验与线上A/B结合

不建议直接把未经离线验证的Prompt直接丢线上A/B测试。正确流程：

• 1. 离线：使用自动化评测集，候选Prompt全部跑一遍评测，淘汰明显变差版本。
• 2. 筛选出离线评测表现不错的候选版本，再放到线上做A/B分流实验。
• 3. A/B实验结束之后，把线上真实Trace中高质量样例回流补充到自动化评测集。

离线评测过滤掉明显劣化版本，线上A/B验证真实用户场景表现，两者互相补充。

四、自动化评测集构建

1. 自动化评测基础

        Prompt迭代、模型版本升级、RAG检索逻辑改动，每次修改之后，如何确认没有把原有能力改坏？如果全部靠人工一条条审核，成本极高，迭代速度会被严重拖慢。自动化评测集的价值，就是充当回归测试用例。每次代码、Prompt改动，自动批量跑一遍评测集，输出量化分数，快速发现能力退化。

        首先消除一个对评测存在的误解：自动化评测不是用来100%替代人工。自动化擅长大规模回归、快速筛明显问题；复杂、高风险业务场景仍然需要人工标注兜底。自动化评测集核心组成：评测样本数据集 + 评测器。

• 数据集：一条条测试样例，包含输入，期望输出/评估标准。
• 评测器：输入用户 query、模型实际输出，给出分数或者判定结果。

2. 评测数据集来源

评测数据集有4个主要来源，实际项目一般混合使用：

1. 人工编写样例：针对业务核心场景，人工构造边界 case、典型 case。优点样本质量可控；缺点人力成本高，数量有限。
2. 线上真实 Trace 抽样：从生产环境真实用户请求采样，过滤敏感信息，人工清洗之后加入评测集。这是最高价值来源，覆盖真实用户五花八门提问。
3. 大模型生成合成样本：使用 LLM 批量生成测试 query。适合快速扩充数据集，缺点会生成很多不贴合真实业务的虚构问题，需要人工过滤。
4. A/B 测试回流样本：A/B 实验过程中线上 Trace，用户给出点赞 / 点踩反馈，把高价值样本沉淀进评测集。

数据集需要分类管理，划分不同场景：通用问答、摘要、RAG 问答、工具 Agent 等。同时数据集要持续迭代，不是一次性建好就永久不变。随着业务变化，持续新增样本，淘汰过时样本。

3. 主流自动化评测器类型

3.1 基于规则评测器

简单字符串匹配，关键词检测。

• 适用场景：输出格式校验、禁止输出敏感词、必须包含特定关键词。
• 优点是速度快，零token消耗，结果确定。
• 缺点是只能处理简单规则，无法评估语义好坏。

3.2 LLM-as-Judge 大模型充当裁判评测器

        把query、模型输出、参考标准答案交给另一个能力更强LLM，让裁判模型打分，输出1‑5分或者布尔判断（是否幻觉、是否回答准确）。 这是现在工业界最主流评测手段。 常用评判维度：

• 事实准确性：回答是否符合参考事实，是否幻觉。
• 有用性：回答是否解决用户问题。
• 完整性：有没有遗漏关键信息。
• 无害性：输出内容是否违规。

LLM as Judge 简单示例：

        LLM‑as‑Judge存在固有偏差，裁判模型本身也会犯错。实践技巧：temperature设置为0；prompt写清楚评判标准；高风险场景可以多个裁判投票。

def llm_judge(query:str, model_output:str, reference_answer:str):
    judge_prompt = f"""
你是评测专家，请评判模型回答质量。
用户问题：{query}
参考标准答案：{reference_answer}
模型输出：{model_output}

请输出JSON，包含两个字段：
score：1‑5分，5分最好，1分最差；
reason：简短打分理由。
"""
    resp = client.chat.completions.create(
        model="gpt‑4o‑mini",
        messages=[{"role":"user","content":judge_prompt}],
        temperature=0
    )
    return resp.choices[0].message.content

3.3 嵌入相似度评测

计算模型输出文本和标准答案向量相似度。

• 适合摘要类任务；
• 缺点：语义相近但是文字完全不一样的时候效果差；无法识别幻觉，文本相似度高但是内容事实错误也会给出高分。

3.4 专用指标

• RAG场景特有评测指标：上下文相关性、答案忠实度（Faithfulness，是否基于检索文档生成，禁止编造不存在事实）。
• LangSmith、Langfuse内置现成忠实度评测器。

4. 评测执行流程

完整自动化评测工作流：

• 1. 维护版本化评测数据集。
• 2. Prompt/代码变更触发评测任务，可以CI流水线触发，也可以手动执行。
• 3. 批量跑全部测试样本，调用各个评测器得到每条样本分数。
• 4. 输出汇总报告：平均分、各个维度得分、失败样例明细。
• 5. 重点关注退化case，分析原因，修复Prompt或者业务逻辑，更新数据集。

实践中碰到的问题记录总结：

• 评测集不要泄露给业务模型训练。Judge裁判模型和业务推理模型建议做模型隔离。
• 不要迷信单一分数，分数只是参考，重点看低分样例明细。
• 数据集要划分测试集，不要把测试样本拿来做Prompt调优，造成过拟合。
• 自动化评测有成本，大量样本运行会消耗token，合理控制数据集规模。

五、人工标注与线上反馈闭环

1. 人工标注的价值体现

自动化评测强大，但存在天花板：

• 第一，LLM‑as‑Judge裁判模型本身会出错，复杂主观业务，机器很难精准判断好坏。
• 第二，很多真实用户意图非常模糊，没有标准答案，机器很难客观评估。
• 第三，自动化评测集样本有限，无法覆盖线上源源不断新用户问题。

        所以我们需要两条输入：用户线上原始反馈 + 人工标注工作台，形成闭环：线上真实 Trace 收集用户反馈 → 人工审核标注 → 优质/坏样例沉淀到评测数据集 → 使用评测集迭代 Prompt、业务逻辑 → 上线之后继续收集线上Trace与反馈。这个循环就是大模型迭代飞轮。

2. 用户线上反馈收集

        线上反馈是第一手原始信号。产品侧在应用界面增加简单反馈按钮：满意/不满意，还可以允许用户填写简短反馈文本。

        关键工程点： 用户反馈事件，必须和后端的Trace ID做关联。前端点击点赞/点踩，上报 trace_id，后端调用Langfuse/LangSmith接口，把用户打分附着在对应Trace记录上。

示例：接收前端用户反馈

# 接收前端上报：trace_id、用户评分、用户反馈文本
def user_feedback_callback(trace_id:str, user_score:int, user_comment:str=None):
    from langfuse import Langfuse
    lf = Langfuse()
    lf.score(
        trace_id=trace_id,
        name="user_feedback",
        value=user_score, # 1差评，5好评
        comment=user_comment
    )
    lf.flush()

这样在Langfuse平台，我们就可以筛选所有用户打低分Trace，集中查看哪些场景用户不满意。

3. 人工标注工作台使用

        收集完海量Trace，需要人工介入标注工作。Langfuse内置标注工作台，可以筛选出：用户差评Trace、自动化评测低分Trace、高优先级业务Trace，推给标注人员。

人工标注可以自定义标签体系，举例RAG问答业务标签：

• 标签 1：回答准确
• 标签 2：幻觉编造事实
• 标签 3：检索文档正确，但 Prompt 没有用好文档
• 标签 4：检索文档错误导致回答错误
• 标签 5：用户问题超出业务范围

标注完成之后，可以一键把这条Trace的query、理想修正答案导出，新增到自动化评测数据集。做到线上真实问题回流进评测集。

4. 完整闭环执行流程

        完整闭环全链路，整个流程构建了“采集→标注→评测→迭代→灰度→上线”的完整闭环：线上Trace与用户反馈经人工标注后沉淀为评测数据集，CI自动评测保障迭代不退化，候选版本经离线过滤与A/B灰度验证后全量上线，并持续采集反馈进入下一轮，形成数据驱动的持续优化飞轮。

流程细节说明：

• 1. 用户发起请求，服务执行大模型业务逻辑；通过Langfuse/LangSmith记录完整Trace，携带 user_id、prompt_version_id，同时输出OTel指标给运维监控。
• 2. 前端收集用户点赞/点踩反馈，关联trace_id回写到追踪平台。
• 3. 平台筛选：差评样本、自动化评测低分样本，进入人工标注队列。
• 4. 标注人员人工审核，打业务标签，编写期望正确回答。
• 5. 将标注完成样本，加入自动化评测数据集。
• 6. 开发修改Prompt、RAG逻辑、Agent逻辑；在CI环节运行自动化评测集，观察各项指标，确认没有退化。
• 7. 候选版本先做离线评测过滤，再进入Prompt A/B测试，小流量线上验证。
• 8. A/B测试指标达标，全量上线新版本Prompt。上线继续收集Trace和用户反馈，进入下一轮循环。

        这样最需要的注意的是，很多场景如果只做到第一步记录Trace，后面2‑8步没有打通，工具就沦为单纯日志工具，无法产生迭代价值。闭环的核心不是工具，是数据流转流程，让线上真实问题持续回流到开发评测环节。

5. 落地过程现实约束

工程落地会遇到现实约束，需要权衡取舍：

• 标注人力有限，不可能标注全部Trace。做抽样策略，优先标注用户差评、自动化评测低分、高价值业务会话，过滤大量普通正常样本。
• 数据安全：人工标注人员访问Trace，要做好权限隔离，Trace中用户敏感信息提前脱敏处理。
• 闭环不要追求一步到位。可以分阶段建设：
  • 第一阶段实现Trace追踪 + 用户反馈采集；
  • 第二阶段搭建自动化评测集；
  • 第三阶段上线 Prompt A/B；
  • 第四阶段完善人工标注完整闭环。

六、综合工程实践总结

1. 各组件定位总览

我们把全部技术点做一次汇总梳理，理清各自职责边界，避免混淆：

• LangSmith/Langfuse：LLM专用追踪平台。存储Trace，管理Prompt版本，数据集管理，提供标注工作台，采集用户反馈。面向AI开发者，聚焦业务质量。
• OpenTelemetry：通用可观测标准。打通企业现有运维监控体系，处理耗时、错误率、QPS 运维指标，不负责AI质量评测。
• Prompt A/B Test：实验手段。利用真实线上流量对比不同Prompt版本效果，避免纯主观决策。
• 自动化评测集：回归测试套件。每次迭代自动验证，快速发现能力退化；样本来源包含人工编写、线上Trace回流。
• 人工标注 & 线上反馈闭环：获取真实用户痛点，补齐自动化评测盲区，持续扩充评测数据集，驱动迭代飞轮。

它们不是相互替代关系，是一套互补组合。缺少任意一环，整个迭代链条就会断裂。

2. 分阶段落地建议

不要期望一次性搭建完整庞大体系，可以分阶段实施：

阶段一（最小可用）：

• 接入Langfuse或者LangSmith，把全链路Trace跑通；
• 产品增加简单用户点赞点踩反馈，关联TraceID。
• 目标：线上出问题可以回溯完整请求链路，拿到用户真实负反馈。

阶段二（自动化回归）

• 构建基础自动化评测数据集，实现CI流水线自动跑评测，修改Prompt、代码自动输出评测报告。杜绝修改之后凭感觉上线。

阶段三（Prompt 实验）

• 接入Prompt版本管理，实现基础Prompt A/B分流。
• 候选Prompt先离线评测筛选，再小流量线上实验。

阶段四（完整闭环）

• 使用平台标注工作台，把线上差评Trace人工标注，沉淀回评测集。
• 完整跑通：线上流量→反馈→标注→评测集→离线评测→A/B 测试→全量上线完整飞轮。

七、总结

        大模型应用开发，原型调试只是起点，真正难点在于上线之后持续迭代优化。传统软件依靠单元测试、线上监控保障质量；大模型应用因为生成结果存在不确定性，我们需要一套全新质量保障体系。LangSmith、Langfuse负责记录每一次大模型运行完整过程；OpenTelemetry对接企业运维体系；Prompt A/B测试用真实流量客观对比提示词版本好坏；自动化评测集充当回归测试，防止迭代过程能力退化；人工标注和线上用户反馈闭环把真实用户遇到的问题源源不断回流到开发环节。

        整套体系核心思想就是减少主观判断，用数据驱动Prompt与业务逻辑迭代。不再靠开发人员感觉判断Prompt好不好，而是结合Trace记录、用户反馈、自动化评测分数、A/B实验指标综合决策。

        对于应用实践来说，不必追求一步做到完美完备。可以按照分阶段路径，从小版本逐步搭建。先把Trace追踪和用户反馈落地，再补齐自动化评测，之后逐步完善A/B测试与标注闭环。当真正运转起来之后，大模型应用就可以持续吸收真实业务输入，稳步迭代质量，而不是停留在一次性调 Prompt 的原型阶段。