这个工具提供了哪些能力
点开任一能力,看清怎么用
每个能力展开后是三件事:它会给你什么、你需要准备什么、哪些必须由你把关。
常见场景:每天跑几十次参数变体实验,需要一个系统记录每次运行的全貌;论文修改阶段需要回溯某张图用的是哪次实验的哪个参数;需要保证实验结果可复现——包括配置、种子、依赖和源码版本;多个实验想在同一套参数基础上叠加变体,需要层级化配置管理
帮你自动记下实验的环境底细:不用你手写清单,它自动收集这次运行用了哪些代码、装了哪些包、什么版本、在哪台机器上跑、代码仓库当时什么状态,事后可以用来核查实验能不能复现。
它会给你什么
- 一份实验信息记录,包括源码、依赖和仓库状态。
- 一份机器环境信息,包括系统和硬件。
- 源码文件的存档副本。
你需要准备
- 实验代码里导入的各个模块。
- 运行时机器上已安装的包及版本。
- 实验所在的代码仓库,比如远程地址和当前提交。
由你把关
- 哪些环境变量会被一并记录,由你决定,避免泄露敏感信息。
- 自动发现漏掉的源码或依赖,需要你手动补登记。
- 自定义采集项是否收集正确,由你负责。
帮你把每次实验的记录变成能查能比的数据:把参数、随机种子、环境、输出和结果整理成固定格式的记录,还能跨多次运行检索和对比,不是记完就躺在那里没人看。
它会给你什么
- 结构化的运行记录,存在文件或数据库里。
- 指标随时间变化的序列数据。
- 去重保存的源码和产物文件。
你需要准备
- 一次运行的全部信息,包括配置、改动、环境、结果和屏幕输出。
- 伴随运行保存的文件和产物。
- 训练过程中记录的指标数值。
由你把关
- 用哪种存储和查看界面,由你或团队决定。
- 附加信息里的复杂对象序列化后还能不能读,由你确认。
- 跨版本读旧记录是否兼容,格式字段由你核对。
帮你给每次实验留档:从启动、运行到结束的整个过程,连同参数、种子、环境、输出、结果和报错信息,一起写进你选的文件、数据库或云端,还能在实验结束时给你发通知。
它会给你什么
- 一次运行的完整存档,存在文件、数据库或云端。
- 实验结束时的提醒消息,可发到聊天工具。
- 去重保存的源码和产物文件。
你需要准备
- 你的实验主函数或命令。
- 定稿的配置,包括随机种子。
- 运行开始时自动采集的环境信息。
由你把关
- 存储后端怎么选、连接和认证怎么配,由你或运维决定。
- 某种队列模式下服务中断会一直重试,需要你人工盯着。
- 判断一次运行是不是已经卡死,要看心跳时间和状态,由你核对。
帮你管好实验参数:把写死在代码里的数字变成一份可记录、可临时修改的配置,每次运行实际用了什么参数都留档,函数需要时自动把参数递进去。
它会给你什么
- 一次运行的完整配置,随记录一起保存。
- 配置改动了什么的清单,方便事后核查。
- 自动递给各个函数的参数值。
你需要准备
- 你用装饰器声明的配置函数,里面的变量就是配置项。
- 直接以字典形式添加的配置,内容要能存成普通格式。
- 配置文件,支持几种常见格式。
由你把关
- 配置项怎么命名、怎么分组,由你自己定规范。
- 配置类型变了会不会影响运行、是不是有意为之,由你判断。
- 配置里的复杂逻辑写得清不清楚,可读性由你负责。
帮你管住实验里的随机性:一次运行只需要一个总种子,各部分的随机数从它派生出来、互不干扰——就算调整代码里调用的先后顺序,结果也不会变,保证可复现。
它会给你什么
- 记在配置里的种子值,是复现的关键。
- 运行期间的全局随机数状态。
- 每个函数各自独立的种子和随机数生成器。
你需要准备
- 自动生成、或你自己指定的总随机种子。
- 想复现某次运行时,把它当时用的种子填回去。
- 各个随机数库是否安装,会被自动检测。
由你把关
- 没被覆盖到的第三方库的随机性要不要手动设种子,由你判断。
- 某些硬件层面的不确定性工具管不了,这一点由你知晓。
- 跨版本复现时是否锁定旧接口,由你决定。
第一次这样开始
把仓库地址直接交给 AI
先让 AI 说明环境和风险,再完成最小安装验证。开始前想清楚要用哪个能力、把对应材料备在手边——每张能力卡展开后有具体清单。
第一次直接复制
帮我安装这个库:https://github.com/IDSIA/sacred 安装前先告诉我需要什么环境,安装后帮我跑通一个最小示例。
别这样用
这些判断,仍然由你负责
- 不设置seed就运行——每次seed随机,导致实验不可复现
- 以为Sacred会自动seed所有库——它只处理Python/NumPy/TF/PyTorch四个库
- jsonpickle序列化把tuple变成list后,跨类型比较行为会改变
- QueueObserver在外部服务中断时无最终失败声明,可能无限重试而研究者不知情
技术依据
查看能力拆解、验证范围与来源
技术依据
查看能力拆解、验证范围与来源
处理机制
- 01
观察者事件生命周期
解释 sacred 五类能力(配置捕获、种子、依赖采集、运行记录、序列化)的共同架构支柱:RunObserver 基类定义的事件合同 + priority 排序 + 首 observer 决定 id + Run 状态机驱动事件分发。这个横切结构决定了为什么 File/Mongo/TinyDB/SQL/S3/GCS/Slack/Telegram/Neptune 九类后端能共用同一套运行记录逻辑,以及为什么 run 记录、id、status、heartbeat、artifacts 在所有后端表现一致。
已核对范围
- 静态确认 gathersourcesanddependencies 通过模块 inspect + pkgresources 自动发现源码与依赖(dependencies.py:726)
- 静态确认 experimentinfo 含 name/basedir/sources/dependencies/repositories(ingredient.py getexperimentinfo)
- 静态确认 collectrepositories 从 sources 提取 git url/commit/dirty
- 静态确认 hostinfo 含 cpu/os/hostname/pythonversion/gpu/ENV,可扩展 hostinfogatherer
- 静态确认 run.json/Mongo runs 文档字段合同(config/experiment/host/info/meta/result/status/times/capturedout/artifacts/resources)
- 静态确认 FileStorageObserver 目录结构(runxxx/{config.json,cout.txt,info.json,run.json,metrics.json} + sources/ + resources/)
- 静态确认 MongoObserver 三集合(runs/fs.files/fs.chunks)+ metrics 集合
- 静态确认前端生态(sacredboard/omniboard/incense/TinyDbReader/Neptune)查询路径
仍待核对
- 未运行验证 auto-discovery 在 95% 用例的覆盖率声明
- 未验证 gpu 信息采集在不同硬件下的实际输出
- 未验证 MODULEBLACKLIST 过滤的完整性
- 未运行验证 Mongo 查询的 filter 语法覆盖范围
- 未验证 TinyDbReader 三种检索(indices/expname/query)的实际行为
- 未验证 jsonpickle 序列化对 numpy/pandas 对象的实际输出形态
- 未运行验证 observer 端到端记录
- 未验证 QueueObserver 在外部服务中断时的重试与最终失败边界
相关文章
科研之我见
AI 科研全流程怎么搭,我梳理出三个核心入口
每天开工先固定阶段入口、材料入口和验证入口,把庞大的科研全流程收缩成一段可执行、可检查的任务。
查看内容