Observability 与 Evaluation
一篇综述漏掉关键论文，可能因为查询没有覆盖它、检索排位太低、证据在上下文取舍中被移除，也可能是模型看到后没有采用。最终回答只能呈现问题，过程记录帮助我们找到问题发生的位置；评测再判断修改是否改善了研究结果。
一、过程记录如何帮助定位研究问题
Lito 用 Run 关联一次执行，并在记录中保存 Trace、Span、消息和工具调用标识。原文另外保存为证据账本：同一片段有稳定的 evidence_id 和内容哈希，可以沿检索阶段追踪，也能识别实际引用的材料。
| 需要回答的问题 | 当前保留的依据 |
|---|---|
| 当时用什么条件跑的？ | 问题、模型、请求参数、提示词 hash、检索配置、语料签名和代码版本 |
| 相关论文在哪一步消失？ | 查询、关键词与向量候选、融合排序、数量限制、相关性选择和上下文扩展 |
| 模型实际收到了什么？ | 模型输入及提供商请求记录，关联当轮 Trace / Span |
| 哪段原文被引用？ | 文献与片段标识、原文快照、阶段标记和最终引用关联 |
| 为什么停止，消耗多少？ | 结束原因、调用次数、实际返回的 token、费用与记录完整性状态 |
例如，某篇论文的反例没有进入比较，可以将预期原文片段标为 bad case。系统在各阶段记录中做字面匹配，帮助定位它是否曾被召回、是否进入模型输入。含义相同但措辞不同的片段仍需要阅读判断，因此这项检查适合缩小排查范围。
context_seen=true 表示系统在回答请求中匹配到完整的原文快照。当前检查只标记长度至少为 30 个字符的完整匹配，因此 false 也可能表示内容较短或只带入了部分原文。研究进展记录的问题、论文与证据清单同样用于还原过程，逐个观点是否得到充分支持仍由评审判断。
二、本地记录与 Langfuse 分别保存什么
本地记录保存深入排查需要的明细；Langfuse 提供模型调用追踪、分数展示和后续实验对比界面。当前二者接收数据的路径不同。
Langfuse 处理器把框架里的模型、工具、Agent 等 Span 转为云端记录，包含已埋点的输入输出、用量、错误与父子调用关系。RunControl.event() 则直接写入本地数据库；细粒度检索事件、完整证据账本和 Checkpoint 目前没有全量自动同步到云端。
一次研究运行会记录检索事件与证据快照。每次运行的事件记录累计预算为 64 MiB，后续事件超出预算时以 trace_complete=false 标记记录状态，并保留已保存的检查点与证据。普通研究保存过程记录，隐私对话抑制内容追踪。
运行记录供问题排查和评测使用。产品页面展示任务状态、回答和来源，追踪连接由管理端配置。
三、从批量执行到版本对比
V1.0和V1.1使用同一批28篇论文。每个可比批次执行56个案例，保存61轮回答与10条检索工具结果。多轮案例在同一对话内依次执行，各轮保留自己的输入、结果和运行标识。
| 环节 | 保存的材料 | 用来检查什么 |
|---|---|---|
| 准备批次 | 题集、评分规则、论文范围、模型与代码记录 | 这次运行与上一版是否采用相同任务 |
| 执行案例 | 实际回答、工具结果、完成或失败状态 | 产品真正交付了什么 |
| 导出评审包 | 原问题、回答、PDF与压缩运行证据 | 让裁判按原文和逐题规则评分 |
| 独立评分 | 每轮档位、扣分规则、原句与证据 | 哪些问题影响了任务完成 |
| 复核争议 | 原分、调整后分数和调整理由 | 评分是否遗漏关键条件或放宽要求 |
| 版本对照 | 分数分布、同题表现和具体改动 | 改进是否落在原来的失败案例上 |
实际批次由脚本执行和导出评审包，评分结果以Markdown和JSON归档。Langfuse用于查看已接入的调用追踪与评分；题目、PDF、真实回答和版本对照在本地研究目录保留完整记录。
四、一个遗漏问题如何查到具体环节
在P13与P32的比较题中，最终回答缺少P32。排查先确认两篇论文都在本次范围内，再沿候选、筛选结果、工具正文和主模型输入逐步检查。记录显示，候选包含两篇正文，但前列片段被P13占满，五次补查仍只把P13交给回答模型。
这一证据决定了修改位置：在比较任务中交错保留不同论文的候选，再按篇内相关性补充材料。复测继续检查两个结果——P32是否进入模型输入，以及正文是否真正比较了两篇论文。后一项还要核对研究条件和来源。
五、怎样阅读分数变化
V1.1的3–4分回答为47/61，V1.0为35/61；案例确定达成分别为35/46与24/46。分数用于概览，具体改动通过同题回答和过程记录解释。一次修改可以补齐论文覆盖，同时仍留下机制解释错误；一次检索可以成功返回证据，回答却停在进度句。