Trust scores and source provenance on traced generations

快速结论：这个 Issue 不是一个可复现的运行时报错，而是关于 Langfuse 是否应该把可信度（trust）与来源溯源（provenance）作为一等观测信号的功能讨论；如果你在排查“trace 里看不到 trust_score / 来源信息”或“无法按 trust 过滤告警”，根本原因是 Langfuse 目前没有原生 trust/provenance schema，只能把相关字段塞进 metadata 里。

适用环境：Issue 已确认的工具为 Langfuse（Python SDK 示例使用 langfuse.generation(...)）。Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息，不要补写。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的方向是：保持任意 metadata 兼容，同时约定一个文档化的 provenance envelope（如 trust_score、verification_status、source_tier、source_references，或更结构化的 provenance.sources / verification.verdict），让 dashboard / API 能索引、过滤和渲染。

注意事项：该 Issue 的 Labels 为 feature，是功能请求与设计讨论，并非已落地的产品行为；Issue 中描述的 schema、字段名、过滤能力都属于“可能方案 / 建议约定”，不能当作 Langfuse 现有 API 或配置项使用。隐私边界上，讨论中明确建议 trace 只存 source refs、hash、tier 和展示标签，不存原始私有来源内容。

问题场景

用户在用 Langfuse 追踪 LLM generations（prompts、completions、latency、tokens、costs）时发现：两个 latency 和 token 数完全相同的 generation，可信程度可能完全不同——一个来自已验证数据（high trust），一个来自未验证的推理（low trust）。但 Langfuse 当前只捕获性能元数据，不捕获 trust 元数据，因此团队无法在 dashboard 里按可信度过滤、告警，也无法在 RAG / agent 场景下直接看到某个生成用了哪些检索来源。

该 Issue 提出把 trust / provenance 作为观测信号，并给出了一个先用 metadata dict 承载的示例：trust_score、source_tier、sources、ai_generated、verified。核心诉求是：这些字段是否应被 Langfuse 提升为一等概念，从而可过滤、可告警。

报错原文

Trust scores and source provenance on traced generations

Two generations with identical latency and token counts can have very different trust levels:
- One sourced from verified data (high trust)
- One from unverified inference (low trust)

Currently, Langfuse captures performance metadata but not trust metadata.

说明：该 Issue 属于 feature 讨论，没有运行时报错堆栈或异常代码，以上为 Issue 标题与正文中的核心描述。

原因分析

可能原因：Langfuse 现有的 tracing 数据模型以性能观测为主（latency、token、cost 等），没有定义 trust 或 provenance 的原生字段与约定。用户虽然可以自行把 trust_score 等塞进 metadata，但任意 metadata 没有统一 schema，dashboard 和 API 无法稳定地索引、过滤或告警，这也是 Issue 中“fits in the metadata dict”但“the question is whether Langfuse should surface trust scores as a first-class concept”的分歧所在。

评论中的进一步分析认为，若要兼顾互操作性，又不让 Langfuse 变成 trust-score 权威，可以拆成三层：灵活的用户 metadata、文档化的 provenance envelope、可选的 verification events（由 evals 或外部 verifier 附加 verdict）。讨论还指出一个关键点：source_ref 是可寻址性而非身份，digest 只有在命名了 projection / profile 时才可互操作，例如 content_digest 配合 digest_profile: "retrieval-source/v1"。

环境排查

确认你使用的 Langfuse 版本，以及是否已包含 provenance / trust 相关的原生支持；本 Issue 关闭于 2026-09-16，期间并未给出具体落地版本号。
确认 Python SDK 调用方式是否为 langfuse.generation(...)，以及相关字段目前是写在 metadata 内还是作为顶层字段传递。
确认你的 observability 需求属于哪一类：只是想存 trust 信息，还是需要在 dashboard/API 中按 trust 阈值或 verification.verdict 过滤、告警。
确认数据隐私边界：trace 中是否需要存储原始来源文本；讨论建议仅存 source refs、hash、tier、展示标签，原始私有内容留在本地 adapter 或来源系统。
Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息，这些不作为排查项。

解决步骤

如果只是先把 trust / provenance 信息随 generation 一起记录下来，可继续利用现有 metadata，按 Issue 示例写入 trust_score、source_tier、sources、ai_generated、verified 等字段。这是 Issue 中明确提到“already fits in the metadata dict”的做法。
如果需要跨工具、跨应用的互操作性，可优先尝试评论中建议的文档化 provenance envelope：用结构化的 provenance.sources[]（含 source_ref、source_kind、retrieval_run_id、chunk_hash、score、role、freshness、access）和 provenance.claims[]（含 claim_id、output_span、source_refs、grounding）来描述来源与断言。
把验证结论与打分逻辑解耦：用可选的 verification 事件承载 verification.verdict（如 MATCH / DRIFT / UNVERIFIABLE / UNVERIFIED）、verifier、policy_hash、eval_run_id，由 evals 或外部 verifier 附加 verdict，而不是让 Langfuse 定义评分模型。
在 source 坐标中同时保留可寻址性和内容摘要，并明确 digest 的 projection / profile，例如 source_ref + content_digest + digest_profile + access，避免只存一个无法解释的 hash。
如果你期望的是 dashboard 原生过滤 / 告警，需要关注 Langfuse 是否采纳该 feature；Issue 本身没有给出“已实现”的结论，因此这一步只能等待官方实现或自行在应用侧处理。

验证方法

可按 Issue 评论中提到的验收测试思路自查：provenance envelope 是否能通过 generation ingestion 和 export 正确往返；dashboard / API 是否能在 verification.verdict 和 provenance coverage 上过滤、查询到缺失情况；渲染 provenance 时是否不需要重新检索、只依赖已附加在 generation 上的 metadata；原始来源文本是否为可选、不参与过滤；大 source 列表是否能在展示时截断但仍保留 sources_digest 以供审计；格式错误的 provenance metadata 是否降级为普通 metadata，而不是破坏 trace ingestion。

如果以上验证目前都做不到，说明你依赖的是 Issue 中提议的、尚未被 Langfuse 原生支持的能力，而不是“修好了某个报错”。