评测表里多了一列分数，团队却仍可能回答不了：谁打的分、用哪套规则、为什么判成这样。Langfuse在10月22日为定时对象存储导出加入评分元数据与来历字段，允许把评价配置和相关执行标识带进数据仓库。变化不在“多算一个平均分”，而在把分数重新接回产生它的过程；不过，这两组字段都需要主动启用。

快速看点：新组名为score_metadata和score_provenance，连新建集成也默认关闭；新增列放在核心列之后，只影响未来导出；下游读取仍需按完成清单处理文件并按ID去重。导出的内容更丰富，不等于历史文件自动补齐，也不等于每条评分都包含完整的评价执行链。

分值只是结果，还要知道评价怎样产生

score_metadata带出创建评分时附加的键值属性。score_provenance则包含作者、评分配置、标注队列、评价器、评价规则和执行追踪等标识。对于人工标注，可以按人员与队列查看差异；对于模型评价，可以沿execution_trace_id寻找产生判分的运行记录，而不是只盯着最后一个数字。

这解决的是数据关联，不是自动发现评价标准。企业仍要约定每个指标的含义、评分者需要看到哪些信息，以及什么情况允许人工复核。同名指标如果实际采用不同规则，合并后再精确计算平均数也可能造成误读。增加可追溯字段的意义，是让这些差异更容易被发现，而不是让它们自然消失。

字段还可能为空。例如，非评价器生成的评分不一定拥有评价器和规则标识。数据仓库不能把空字段直接解释为失败，也不应把每条记录都强制归为某个模型裁判。先区分人工、API和评价运行等记录类型，再决定如何关联，是建设稳定下游表的基础。

默认关闭，旧文件不会悄悄变成新格式

这两组评分列与已有核心列分开选择。启用后，后续导出的文件增加相应列；已有文件保持原状。文档说明，API配置中的exportFieldGroups需要包含core，省略这一属性则保留当前选择。这里的兼容重点，是避免已运行的数据消费任务突然收到一套未经准备的列。

交付时可以先保留一份样本文件和字段清单，确认新旧列名、空值与类型，再让下游任务处理新窗口。不要把“开启导出”与“历史回填已完成”写成同一验收项。如果业务确实需要重新处理历史，应作为独立作业评估范围和重复数据，而不是假定一次开关已经完成迁移。

还需要阅读评分类型。文档中TEXT评分的value为0，实际文本在string_value；CORRECTION类型不在这类评分导出范围内。这意味着单纯把所有value相加，可能得到没有意义的结果。指标消费程序应先识别data_type，再选择数值统计、分类汇总或文本审阅，不能让一条通用SQL代替类型判断。

看见文件不算完成，要等清单再入库

对象存储导出可能产生多个文件。产品约定在所有数据文件成功上传后，才写出这一轮的manifest；下游应读取其中files列出的完整对象键，而不是猜文件名或看到某个目录有新文件就开始汇总。清单在这里是完成信号，不是文件数量越多就代表进度越快。

相邻导出窗口共享包含边界，因此仍需按记录ID去重；存储事件本身也可能重复送达。团队应把处理哪一份清单、哪些记录已入库保存下来，让同一通知再次出现时不会把一轮实验算成两轮。这个去重责任不会因为评分多带了几个标识就自动转移给导出端。

异常验收也应独立设计。可以在非生产样本中检查清单未到、文件暂时不可读、相同通知重复到达时，下游是等待、告警还是安全重复处理。这里是建议的检查路径，并非本文已对产品执行故障注入，更不是对任何云存储事件交付语义作额外保证。

小编判断：把评测结果变成可检查的数据产品

这次变化不同于此前逐项比较实验分数的更新：它关注的是分数离开观测平台后，还能不能保留上下文。企业把AI评测送进自己的仓库、报表或运营流程时，既需要一个结果，也需要解释结果的路径。否则，图表越来越齐全，真正出现退步时却仍要重新手工追查。

可追踪也不等于不可篡改的审计链，更不代表自动满足某种合规要求。元数据可能含有人员与业务属性，字段选择、存储权限和保留范围仍需企业自行约定。公开文档对套餐与自托管可用范围另有限定，不能称所有账户默认开放。本文没有配置实际客户集成，也没有独立准确率或效率提升数据。

对FDE团队，更务实的验收是挑出一条评分，确认能解释其类型、规则和执行记录，再确认重复通知不会污染统计。只有当导出的数据既能读、又能关联、还能在失败后稳定恢复，新增列才真正成为运营能力，而不是换一份更长却同样难以复查的文件。