Q1：哪些团队可以参加？可以同时参加多个赛道吗？

高校、科研院所、企业、开源社区、独立团队和个人都可以参加，也支持跨单位组队。

同一参赛者可以选择文本、代码、多模态中的一个或多个赛道，但本期只能选择一种参赛组别，即开源方法榜或商业产品榜。三个赛道的准入、Smoke、Full 配额和成绩分别管理。

Q2：开源方法榜只提交 GitHub 仓库或 Docker 镜像可以吗？

不可以。第二期开源方法榜和商业产品榜都需要参赛方自行部署稳定、可访问的 Add/Search API。平台不会默认拉取仓库、启动容器或代替参赛方托管服务。

开源组还须提供公开仓库、固定 Commit、依赖、运行说明、原始工作与本次改动；这些材料用于复现与审核，不能代替在线服务。

Q3：开源组与商业组的主要区别是什么？

两组使用相同的参赛入口和 Add/Search 接入边界，主要区别在公开与资格要求：

• 开源方法榜需要公开足以核验和复现的版本，并遵守本期 Add/Search 模型约束；符合规则并通过审核的团队可以参与奖金评选。

• 商业产品榜可以不公开内部实现，但必须固定产品、模型、接口版本和关键运行条件；不参与奖金评选。

Q4：一个 AML Key 可以参加几个赛道？各赛道共享次数吗？

一个 AML Key 可以绑定多个赛道。文本、代码和多模态分开测试，不共享 Smoke 或 Full 次数。

同一 AML Key、同一赛道本届最多 30 次 Smoke、2 次 Full；文本赛道用掉一次 Full，不会占用代码或多模态赛道的 Full 配额。

Q5：报名需要一次性准备哪些材料？

至少准备：联系人和邮箱、团队或机构、系统名称与固定版本、组别与赛道、Add/Search 地址、鉴权方式、访问凭证、运行说明、并发与限流、典型耗时、请求体和存储容量、模型与外部依赖、多模态处理声明，以及服务维护安排。

如果提供 Health 或已经审核的异步 Add Status 地址，也应一并提交。开源组还需提供公开仓库、固定 Commit、来源和改动说明。

Q6：报名免费吗？评测成本由谁承担？

报名免费。统一 Answer、Evaluation 和评测编排由平台负责；参赛方承担自己的 API、数据库、模型调用、网络、存储、计算和运维成本。

Q7：开源组是否必须调用 gpt-4o-mini？完全不调用生成模型怎么办？

开源方法榜在 Add/Search 环节调用生成模型时，须使用本期指定的 gpt-4o-mini。若系统的 Add/Search 全链路完全不调用生成模型，不需要额外增加一次无意义的模型调用；应在材料中将该项写为 N/A，并说明系统实际使用的 embedding、reranker 或其他组件。

如页面清单的文字与实际系统形态不完全匹配，请在启动 Full 前通过官方邮箱取得书面确认，不要用模糊勾选代替真实披露。

Q8：开源组可以使用自行 fine-tune 的模型吗？

本期公开要求对开源组 Add/Search 的生成模型有明确限制。自行 fine-tune 的模型、蒸馏模型或任务内在线参数更新不能默认视为已经获准。

如果自训练模型是方法不可分割的一部分，请在准入申请中单独列明基座、训练流程、训练数据、权重开放方式和实际用途，并在 Full 前取得明确接入结论。依赖未获准自训练模型的方案，也可以根据自身公开与产品形态评估商业产品榜。

Q9：已经公开的 LoCoMo-Refined、BEAM 等评测数据可以拿来训练参评模型吗？

本期纳入评测的公开子集和样例用于理解任务、接口预检与评测复现，不应直接用于训练、微调参评系统或针对题目进行过拟合。正式评测收到的数据及其派生副本只能用于当前评测和必要审核，不得用于训练、产品分析、数据集重建或对外传播。

使用任何外部数据进行训练时，都应说明来源、许可证、与本期评测集的关系，以及避免数据污染的措施。

Q10：平台会公开一份完整、标准化的 Add 数据包供本地模拟吗？

公开样例用于验证字段、类型、顺序、隔离和幂等语义；受限评测数据不会因本地联调而完整公开。

参赛者可以按照 API Guide 构造自己的合成数据，覆盖长消息、多 session、时间戳、重复 request_id、空检索和异常响应。获得准入后，Smoke 才是平台提供的正式小规模端到端兼容性验证。Smoke 使用独立评测身份和命名空间，不应与 Full 的记忆空间混用。

Q11：Add 返回 HTTP 200，准确代表什么？

代表这一批内容已经成功持久化，并且后续 Search 可以立即检索到。仅接收请求、写入后台队列或尚未完成索引时，不能提前返回同步成功。

如果系统需要异步写入，应先完成对应赛道的异步接入审核，绑定 Add Status 地址并按正式状态协议返回；只返回一个 task_id，不等于已经满足异步接入要求。

Q12：平台重试 Add 时，会更换 request_id 吗？

正常网络错误、超时或可重试状态码下，平台沿用同一逻辑请求的 request_id 和请求内容。参赛系统应把 request_id 作为幂等键，处理“写入已经成功，但成功响应在网络中丢失”的情况。

不要只在单个进程内缓存幂等状态。Full 或恢复期间发生无状态重启时，必要的幂等记录仍应保留。

Q13：user_id 和 session_id 分别是什么？

user_id 是 Search 的记忆隔离边界。不同 user_id 的记忆绝不能混在一起。

session_id 表示内容来自哪一个会话，用于组织历史，但不替代 user_id。同一 user_id 下可能包含多个 session；Search 请求通常不提供 session_id 过滤，因此相关的跨会话历史仍应可以被检索。

Q14：Search 的 options 字段包含正确答案吗？应该怎样使用？

选择题可能会把全部题面选项作为 options 传入，其中自然包含正确选项，但平台不会告诉系统哪一项正确，也不会发送额外金标。开放题不传 options，也就是该字段为空。

参赛系统可以使用或忽略 options。选项中包含干扰项，不建议不加判断地把全部选项直接当作事实写入或拼入检索文本。

Q15：messages[].timestamp 一定会有吗？

该字段在基础接口中是可选字段。平台发送时，它表达事件时间语义，参赛系统应按原顺序保留，不应无条件用接口到达时间覆盖。

系统仍需兼容不含 timestamp 的请求；不要把一个可选字段变成 Add 的强制前置条件。

Q16：Search 返回多少条？必须正好返回 100 条吗？

不需要。top_k 表示最大条数。文本正式评测使用 top_k=100；系统可以返回少于 100 条，但不能超过本次请求给出的上限。没有相关记忆时，正常返回：

返回顺序就是证据优先顺序，靠前内容更可能进入平台侧 Answer 的上下文。

Q17：score 必须跨查询可比、严格递减吗？

score 是可选字段，是参赛系统自己的相关性分数，不是官方成绩。基础接口不要求不同查询之间的分数天然可比，也不要求必须使用某一种归一化方法。

真正决定证据优先级的是 data 数组顺序。分数可以并列，但返回顺序必须稳定、可解释，并与系统声明的相关性排序一致。

Q18：可以把多条记忆整合成一段叙述后再返回吗？

可以在申报方法范围内对合法写入的记忆进行摘要、结构化或证据组织，但必须满足三个边界：

1. 内容只能来自该 user_id下允许使用的历史；

2. 不能引入未来信息、外部答案或金标；

3. 不能读取当前问题后直接生成最终答案，再把答案伪装成历史记忆。

如果系统会使用生成模型合并证据，应在材料中说明模型、提示词功能和版本，并遵守所在组别的模型要求。

注意，如果返回的记忆内容超出上限，可能会被截断，影响表现。

Q19：普通文本评测是否一定先完成所有 Add，再开始 Search？

普通文本批量链路在对应写入阶段完成后进入 Search；第二期同时包含 Streaming 持续记忆评测，该分支会按事件顺序交错调用 Add 和 Search。因此，务必确保Add请求在真正完成后再给出返回值。

因此，系统既要支持普通批量写入后的检索，也要支持“写入一部分—检索—继续写入—再次检索”的时序过程。不同评测身份和 user_id 之间仍须严格隔离。

Q20：单次 Add/Search 可以运行多久？平台会怎样处理限流和临时错误？

本期单次 Add 和 Search 的最长等待时间均为 30 分钟。

需要限流时返回 429，并提供合法的 Retry-After。平台会对约定的网络错误、超时和部分临时状态码执行有界重试；确定性的鉴权、路径、JSON 类型或必填字段错误不会通过反复重试自行恢复。

Q21：Health 接口怎样实现？

如配置 Health 地址，应提供无鉴权 GET 接口，返回任意 2xx 表示服务健康。Health 只用于判断服务能否访问，不应暴露密钥、模型配置、数据库地址或其他内部信息。

Q22：代码赛道也是 Add/Search 接入吗？最终怎么评分？

是。参赛方先通过 Add 接收相关或带噪声的历史工程轨迹；平台侧解题 Agent 在处理代码仓库和任务时调用 Search，将返回的历史经验作为辅助上下文。Agent 最终要在隔离环境中实际修改代码，平台通过任务验证程序判断补丁是否解决问题。

本期共 150 个基础任务，每题在 relevant 和 noisy 两种记忆条件下运行，共 300 个评测单元。两个条件是记忆环境，不应简单理解为两个“难度等级”。

Q23：多模态系统只能使用 caption，能参加吗？

可以申请 caption-only 方式，但接口必须能够正确接收图文内容数组，不能因为出现图片字段就报错。参赛材料和公榜信息中应如实披露是否处理原图、是否使用 OCR、是否只使用 caption，以及是否返回图片证据。

caption-only 不等于原图理解；具体分项和奖项资格以本期冻结的多模态配置为准。

Q24：多个赛道能共用同一个服务吗？

可以，但配额分开并不代表计算资源也会自动隔离。多个 Full 同时运行时，服务器、数据库、索引、模型额度和带宽压力可能叠加。

如果共用服务，应确保不同运行和 user_id 的状态严格隔离，并为总并发、存储峰值和故障影响范围预留容量。

Q25：Smoke 通过后，是否说明 Full 一定能跑完？

不是。Smoke 验证的是小规模接口兼容性和端到端链路；它不能证明正式规模下的持续并发、存储、索引速度、外部模型额度和长时间稳定性。

启动 Full 前，请再次检查请求成功率、P95/P99 延迟、429 和 5xx、存储和内存、上游模型余额、调用额度、告警以及故障联系人。

Q26：Full 没有 100% 完成，会不会发布部分成绩？

只有完整成功并通过复核的 Full 才能形成正式成绩并进入公榜。个别记录最终仍然失败、评测单元缺失或产物不完整时，不能缩小分母后发布成一份“完整成绩”。

平台会对临时错误执行有界重试，并在符合条件时恢复同一个任务。已经完成且通过一致性校验的步骤可以复用，但参赛方必须保留原版本、记忆状态、幂等记录和运行命名空间。

Q27：Full 失败或取消后，是否可以直接新建一次而且不占次数？

不能这样理解。自动重试、记录重新排队和同一 root evaluation 的断点恢复仍属于同一个 Full，不会因为恢复而重复计次。

如果失败来自参赛接口、依赖服务或提交实现，该次 Full 原则上已经发起；不要预期系统会自动返还配额。经核实属于平台基础设施故障的，由组委会按任务记录处理恢复或资格。发生异常时，优先恢复原任务，不要反复创建新任务。

Q28：两次 Full 的冷却期怎样计算？

同一 AML Key、同一赛道本届最多 2 次 Full。第二次在首次 Full 成功完成 30 天后解锁。同一任务内部的自动重试和断点恢复不另行产生 30 天冷却。

拥有两次配额不代表赛程内一定来得及使用两次。准备复测的团队应从 11 月 4 日评测停止时间倒排，尽早完成首次 Full。

Q29：Full 运行中可以更换接口、模型或修复算法吗？

不能。Full 受理后，系统版本、端点、鉴权、评测契约和计分参数都与本次任务绑定。运维层面的无状态重启可以进行，但必须保证数据、模型和协议行为不变。

如果必须修改模型、算法、提示词或会改变结果的实现，应申报新版本并重新通过接入流程，不能把新实现直接接到旧任务的检查点上。

Q30：为什么 Full 完成后仍然没有出现在公榜？

Full 执行结束后，结果先对绑定身份私有可见，还需要通过完整性、版本、计分和合规审核。只有审核通过的有效结果才能进入对应公榜。

正式成绩采用同赛期、同赛道的最新有效 Full。后一次任务尚未完成或未通过审核时，不会自动替换此前仍有效的成绩；后一次成为有效成绩后，不取两次中的最高分。

Q31：任务完成后多久需要删除评测数据？

任务完成后 30 天内，应删除该任务涉及的评测数据及其派生副本；如确需延长，应事先取得平台书面许可。建议保留内部可核查的删除记录，如任务 ID、删除时间、执行结果和审计日志摘要。

如果任务仍在恢复或平台已通知需要复核，应先确认允许保留的范围与新期限。服务继续在线，不代表可以无限期保留评测数据。

Q32：遇到问题，怎样让组委会更快定位？

请发送邮件至：

[email protected]

并尽量提供：

• 系统名称、固定版本、赛道和组别；

• 申请记录或 Run/Job ID；

• 发生时间和时区；

• Smoke/Full 及 Add / Search / Answer / Evaluation / 审核阶段；

• 错误码、预期行为和实际行为；

• 受影响范围、已经完成的排查；

• 可安全提供的脱敏日志和时间线。

不要在邮件中发送访问密钥、完整受限评测数据、金标答案或其他参赛者信息。

一般情况下，组委会会在收到邮件后 5 个工作日内给予初步回复。如超过上述时间仍未收到回复，请在原邮件中继续跟进，并检查垃圾邮件箱。

如有其他问题，欢迎通过官方邮箱反馈。我们会继续根据实际接入情况补充文档和常见问题。