bug: LLM-as-a-Judge evaluator creates two scores for the same target observation in a single job execution

快速结论：此问题出现在自托管 Langfuse Enterprise Edition v3.172.1 环境中，LLM-as-a-Judge 评估器对同一个目标观察（target observation）生成了两个分数记录。优先排查自托管版本是否低于包含修复的版本，并建议升级。

问题场景

用户在使用 Langfuse 自托管部署（Enterprise Edition）时，配置了 LLM-as-a-Judge 评估器，并设置为在实时传入的 GENERATION 类型观察上运行。当应用追踪中包含多个 GENERATION 观察时，评估器对每一个目标观察都创建了两个分数记录，而不是预期的单个分数。

报错原文

target_trace_id: b9abbaf4e85951b40cc0f71b2cfc0c15
target_observation_id: 3d62feddd2be3934
executionTraceId: 498b6a6cfdc0d5bda79d41c322963161
job_execution_id: 397a710ae92cd8ce7f41221c95f27645
job_configuration_id: 1e045b66-b307-438f-8577-302c5a4ec824

For this single evaluator execution and same target observation, two score records were created:
score_id: 5703b1dc-fdc0-4c8e-a73b-342503f0e9c2
score_id: 2200018d-06d5-435b-9960-dbb7ddc9c40d

Both scores have:
- same score name: Answer Correctness - Renewal Agent
- same value: 1
- same source: EVAL
- same target_trace_id
- same target_observation_id
- same job_configuration_id
- same job_execution_id
- same executionTraceId

原因分析

可能原因：评估器执行过程中，分数 ID 生成使用了随机 UUID（randomUUID()）。当评估作业因队列重试等原因被重新处理时，每次尝试都会为同一个逻辑评估生成一个新的分数 ID，导致同一个目标观察产生重复的分数记录。该问题在 v3.172.1 版本中存在，后续版本已修复。

环境排查

Langfuse 自托管版本：v3.172.1 或更早版本
评估器配置：LLM-as-a-Judge 类型，运行于 GENERATION 观察，实时运行启用，采样率 100%
检查队列重试机制是否开启
确认 ClickHouse 使用的表引擎是否为 ReplacingMergeTree

解决步骤

升级 Langfuse 版本：将自托管部署升级到包含 PR #13772 的后续版本。PR #13772 引入确定性分数 ID 生成（基于 UUID v5，使用 jobExecutionId、scoreName 和 occurrenceIndex），使分数写入可幂等，结合 ClickHouse 的 ReplacingMergeTree 自动去重。

（可优先尝试该步骤）
手动清理旧的重复分数（可选）：如果历史数据中存在重复分数，升级后需要手动清理。可以通过 target_observation_id 和 job_execution_id 查询并删除多余的分数记录。
验证评估器配置：确保评估器未配置为多次执行（例如，检查是否有多个规则或触发器同时作用于同一个观察）。

验证方法

升级后，重新发送一个包含 GENERATION 观察的追踪，打开 Scores 部分，确认每个 target_observation_id 只有一个分数记录。
检查评估器执行追踪（executionTraceId），确认没有重复的分数创建。
对比升级前后的 score_id 格式（原为随机 UUID，升级后应为基于 UUID v5 的确定性 ID）。