Prompt + Eval

在 LLM 应用中，prompt 往往承担了大量业务逻辑：角色定义、输出格式、检索上下文的使用方式、工具调用约束、拒答策略和风格要求。如果 prompt 只散落在代码、配置文件或表格里，团队很快会遇到三个问题：不知道线上用了哪个版本，不知道一次效果变化来自模型还是 prompt，不知道回滚到哪里。

Langfuse Prompt Management 的定位，就是把 prompt 变成可创建、可版本化、可协作编辑、可按 label 部署的软件资产。官方文档支持通过 UI、Python SDK、JS/TS SDK 和 API 创建 prompt，并通过 label 将版本发布到 production 等环境。#Langfuse Prompt Management, 2026

langfuse.create_prompt(
    name="movie-critic",
    type="text",
    prompt="As a {{criticlevel}} movie critic, do you like {{movie}}?",
    labels=["production"],
)

Langfuse 的 Evaluation 覆盖线上和线下两类场景：线上对 production traces 进行打分和监控，线下用 datasets 和 experiments 比较 prompt、模型或代码变体。官方文档强调，evals 的价值是用可重复检查替代猜测，在发布前发现回归，并在生产中持续监控质量。#Langfuse Evaluation, 2026

最值得建立的流程是：线上 trace 中发现失败样本，将其沉淀为 dataset item；随后在 experiment 中比较不同 prompt、模型或代码版本；最后用 score 判断新版本是否更好。这样，线上事故不只是一次排查记录，而会变成未来发布前的回归测试样本。#Langfuse Evaluation, 2026

flowchart LR
    BadTrace[线上失败 Trace] --> Dataset[加入 Dataset]
    Dataset --> VariantA[Prompt A / Model A]
    Dataset --> VariantB[Prompt B / Model B]
    VariantA --> Scores[Scores]
    VariantB --> Scores
    Scores --> Decision[发布 / 回滚 / 继续实验]

Prompt 管理的关键不只是"把 prompt 放到 Langfuse"，而是让 prompt 有稳定的资产边界。一个好的 prompt name 应该对应一个业务能力；变量应该少而清晰；label 应该表达部署环境；版本说明应该写清楚改变了什么。

LLM 应用质量通常不是单一维度。一个客服回答可能要同时满足事实正确、引用充分、语气合适、不过度承诺、符合安全策略。只给一个 overall score 会掩盖失败原因，因此更推荐拆成多个 score config。

如果把 Langfuse 用成工程流程，而不仅是调试工具，可以制定一条简单规则：任何 production prompt、模型或检索策略的变更，都必须关联一次 experiment 或人工评审记录。对于核心链路，还可以将 code evaluator 或 experiment 结果接入 CI/CD，阻止明显回归进入生产。