做实验跟踪这件事说句实话很多做机器学习的朋友早期都是硬着头皮上的。最早我用 Excel 记参数、在文件名里塞日期遇到一次模型效果回退折腾两天才发现是训练数据和前一轮不一致。后来我把这套东西换成结构化工具才意识到所谓“实验管理”并不只是记账它决定了一个项目的可复盘性。NeptuneAI 博客中文翻译这个系列做到第六期这一期原文把视线从传统 ML 拉到了 LLM 应用上讲的是怎么把实验跟踪、评估和比较这套方法论搬到生成式 AI 项目里。这篇文章我就以这期内容为引子结合我自己跑过的几个真实项目场景把 LLM 实验管理的核心思路、记录结构、评估打法和常见坑一次性讲清楚。这篇东西适合谁看如果你正在做 RAG 应用、Prompt 调优、模型微调或者已经在用某种实验跟踪平台但总觉得团队配合不顺畅那你花二十分钟读一遍应该能省下后面一周的无效摸索。我没有打算把原博客逐段照翻而是把它的核心思想抽出来用中文语境重新讲一遍该补的代码补代码该踩的坑也毫不避讳。1. 本期博客的核心命题LLM 应用的实验管理为什么这么难1.1 传统 ML 实验管理与 LLM 实验管理的关键差异传统机器学习项目里一次实验的要素相对固定数据集版本、特征处理逻辑、模型超参数、随机种子、评估结果。这些要素可以被固化下来跑完之后只要记录一组标量指标再配合训练曲线就能还原大部分情况。哪怕换一个人接手只要拿到训练日志和 checkpoint还是有很大概率顺利复现。但到 LLM 应用这个阶段情况发生了变化。一次“实验”不再仅仅指一次训练任务而是变成了完整的一次“运行”你调用的模型是什么版本、Prompt 写了什么、温度参数设了多少、上下文窗口怎么截断、外部知识库返回了哪些片段、Agent 工具调用的顺序是怎么样这些都直接影响最终输出。更麻烦的是同样的输入和同样的参数换个时间点调用同一个模型返回结果也可能不完全一样。因为模型本身可以在服务端更新甚至在提示词完全不变的情况下输出的概率分布也会漂移。做传统实验时你可以把问题归结为“模型拟合得好不好”但 LLM 应用里你却要同时回答好几个问题是 Prompt 没写清楚还是知识库检索没找对还是模型本身能力不够还是评估标准有问题这四件事纠缠在一起导致很多团队调了两周成果却肉眼可见地少。1.2 从博客里读出来的主线跟踪、比较、复盘这期 NeptuneAI 博客原文给我的感觉是它把 LLM 实验管理的主线拉成了三个动作跟踪、比较、复盘。听起来像是老生常谈但放在 LLM 场景里每个动作都有新的难点。跟踪不光是记录模型名和参数而是要把整个调用链路上的元数据都存下来。比如当时用的系统 Prompt、用户 Prompt、上下文里注入的检索片段、模型的原始返回、后处理逻辑版本这些信息缺一个环节后续就没法判断问题出在哪一步。比较也不是简单把两张曲线图叠在一起而是要基于同一套评估维度在不同运行之间做横向对比。比如“回答相关性”和“回答完整性”这两个维度在两个 Prompt 版本之间有升有降你不能只看一个分数就下结论得能钻到具体 case 里去对比。复盘则更考验团队习惯。很多项目到了上线阶段才发现线上效果和离线评估对不上回过头来要对日志做二次分析但是这个分析不能只拿线上日志来做——你还需要跟当初的实验记录做交叉比对看线上数据和离线测试数据分布是否一致。这三件事相互依赖缺了任何一环整个流程都会打折扣。1.3 实际场景为什么“跑了记录却依然复现不了”我在一个项目里就吃过这个亏。当时做的是一个企业内部文档问答工具我明明把每个版本的系统 Prompt 都保存在一个共享文档里结果过了一个月回去看发现共享文档里最新版本和我代码里实际使用的版本并不一致。原因是有人直接改了代码里 Prompt 字符串但忘了更新共享文档。这种信息漂移是团队协作里最常见的隐形杀手。所以博客里的“跟踪”二字其实要求的是把记录动作嵌入到运行代码本身而不是靠人手动维护。也就是说实验记录应该由代码自动完成而不是事后靠谁来补写。这也是 NeptuneAI 这类平台存在的最大价值它们做成一个独立存储层让每一次运行自带完整上下文。这样哪怕三个月后的你再翻出某条 run也还能准确看到当时到底跑了什么。2. 追踪单元从“模型”变成了“一次运行”2.1 为什么传统表格在这里失效了用表格记录实验信息本质上是在给实验做“降维”。一个单元格只能装一个标量所以 Prompt 这种长文本没法完整放进表格只能放个备注链接结果链接一旦失效上下文就断了。数据集的指纹也往往只是记一个名字但同一个名字对应的文件可能早就被覆盖过。模型版本同样麻烦你以为记了“gpt-4o-2024-05-13”就够但线上调用时可能已经默认切换到更新版本而你完全感知不到。表格还解决不了嵌套关系的问题。一次运行的上下文是树状的一个根节点代表一次实验下面挂着数据版本、Prompt、参数、指标、日志、trace这些子节点内部又有自己的分支。强行压成 Excel 的扁平结构等于把一棵树切成一条线损失的信息不只是细节而是父子之间的对应关系而这些关系恰恰是排查问题的关键线索。2.2 用 run 结构代替散落的格子这一期博客里反复出现的概念是 run我理解下来就是把一次完整的前后调用过程和上下文打包成一个独立对象任何和这次调用相关的实体都是它的子属性。用 NeptuneAI 这类平台来做的话基本结构是这样import neptune run neptune.init_run( projectmy-team/llm-app, nameprompt-v3-temperature-0.2, )初始化之后后面记录的每一类信息都会挂在同一个 run 下面。比如我可以记录模型配置、Prompt 版本、数据指纹、评估结果、运行日志。这个 run 从创建到结束承载了某一次实验的全部生命周期。这样做不是单纯换了个存储方式而是改变了思考方式你不再问“我改了什么”而是问“这次运行和上次运行到底差在哪”。我自己的经验是把 run 当作一个“集装箱”来理解最直观。普通的日志像是码头上的散货每个箱子各管各的丢了也不好查run 则是一个标准集装箱箱子外面的标签写清楚里面装了什么搬上船之后还能回溯整条航线。团队里的人不用去猜你用了哪版 Prompt只看 run 的标签就知道全局。2.3 记录对象清单与字段设想具体要记录什么我给自己列了一份操作清单这一段也可以直接抄作业模型配置模型名称、版本标识、temperature、top_p、max_tokens、stop 序列。Prompt 信息系统 Prompt、用户 Prompt、少样本示例文本以及这些内容的版本号或哈希值。上下文注入内容比如 RAG 场景里检索回来的 top-k 文档片段最好连 score 一并记录。后处理逻辑输出走了什么解析流程、是否经过敏感词过滤等记录代码版本号。运行环境依赖库版本、Python 版本、调用时间是哪个时段。结果与指标模型返回结果、耗时、token 用量、成本估算、自动评估分数。人工备注评估人员可以挂一些文字评价或者给某个 case 标记有问题的 tag。这份清单看着内容多但真正埋点到代码里之后每次运行并不会多花多少时间。关键是第一次把基础设施搭好后面只是往里面写数据。3. 实验跟踪的落地配置工具选择与记录结构3.1 为什么可以选 NeptuneAI 作为核心存储NeptuneAI 这类平台是专门为实验管理设计的它和普通日志系统的最大区别是提供了“结构化检索 可视化对比 协作能力”。你可以根据任意字段筛选出一批 run再把这些 run 放到同一个视图里进行对比。对于做 Prompt 版本对比或者模型对比的场景这个能力几乎是刚需。我不是说必须给所有项目上平台如果只是一个人写脚本用本地 JSONL 记录也足够。但只要超过两个人协作或者你有几十个实验版本要横向比较平台的价值就会立刻体现出来。博客原文里给的观点我也认可工具选型不需要一步到位但至少要保证记录的结构是有语义的而不是一堆相互割裂的文本。实际落地时你只需要关心两件事第一能不能在代码里通过 SDK 把数据写入 run第二能不能把评估结果和原始记录挂在一起。这两个需求一旦满足后面所有对比、筛选、复盘都有了基础。3.2 从一次 KV 记录到结构化嵌套的演进我最初用 Neptune 这类工具时只会写最简单的键值对run[model/name] gpt-4o run[model/temperature] 0.2 run[prompt/template_version] v3后来发现这种扁平结构虽然简单但当我要查“某个温度参数下所有样本的平均分”时就得自己写一堆过滤逻辑。更好的做法是用命名空间组织字段让不同类型的数据自然分层。比如run[config/model] gpt-4o-2024-05-13 run[config/sampling/temperature] 0.2 run[data/source_file] eval_set_v2.parquet run[data/context_docs] retrieved_docs run[eval/metrics/accuracy] 0.87 run[eval/metrics/faithfulness] 0.91这样做的直接好处是后续横向做筛选对比时你可以直接针对config/sampling/temperature这一类字段做范围查询。尤其是当实验数量上百条之后命名混乱意味着对比表无法自动生成又得靠人肉整理。这个规范最好在项目一开始就定下来不然后面改造成本太高。3.3 记录 Prompt 文本的几种方式Prompt 文本的存储方式比较有讲究如果你直接把整段字符串塞进 run 的某个字段里也能用但会有两个麻烦一是字段会很长看列表的时候刷屏严重二是相同 Prompt 在不同 run 里重复拷贝对比起来还要肉眼找差异。更聪明的做法是给 Prompt 加上版本号或者哈希。比如每次修改 Prompt 后先计算sha256然后把哈希值和 Prompt 原文都记进 run。哈希值可以用来快速判断两个 run 是否用了同一版 Prompt原文则放在另一个更详细的字段里。我一般会在团队里维护一个 Prompts 目录每个文件对应一个版本运行代码时自动读取并计算哈希这样记录过程不会增加人工负担。import hashlib template_path prompts/system_v3.md prompt_text open(template_path, encodingutf-8).read() prompt_hash hashlib.sha256(prompt_text.encode(utf-8)).hexdigest()[:8] run[prompt/template_path] template_path run[prompt/template_hash] prompt_hash run[prompt/system_text] prompt_text这么处理还有个隐藏优势当团队里有人偷偷改了 Prompt 文件但没更新版本号时哈希差异会直接暴露问题不用等到评估分数出来才发现“结果怎么变怪了”。4. 评估环节怎么接自动指标与人工判断并存4.1 从“准确率”到多维度评估LLM 应用的评估不像分类模型那样有一个明确的正负标签很多任务最终给出的是一段自由文本。所以评估不能只盯一个数而要拆成多个维度。这期博客里我比较认可的一个点是把评估维度拆成“输出是否忠实于上下文”“回答是否完整覆盖用户问题”“表达是否清晰”“事实性错误有几处”等再各自打分。自评指标可以用模型来打分也可以规则判定。我之前在一套问答系统里用过这样的做法让一个 eval 模型扮演评审角色对每个回答从 1 到 5 给相关性打分。同时用一套规则脚本检测回答中是否出现“基于以上资料”这类话术来判断模型是否真正使用了提供的知识片段。两套结果合在一起比单一分数可信得多。要注意的是自动评估的 Prompt 本身也有版本问题。评估模型的口径必须稳定不能今天让评估者要求“长一点”明天又让它忽略无关内容。所以评估 Prompt 一样要做一个版本标签把它和被测系统的 Prompt 记录分开不然下次复盘的时候会分不清波动来自业务模型还是评估器。4.2 人工评估的流程与工具搭配自动指标不是万能的尤其是“语气是否得体”“内容是否有潜在偏见”这类判断模型评估不一定可靠。所以我在项目中一直保留人工评估环节流程是这样的从待测 run 的样本里抽取一定数量一般 50 到 100 条由团队成员对照原始输入、检索上下文、模型输出进行评分。具体评分方式用一个统一的界面来做最省事。如果团队人手有限我个人建议先做一个简单的评估表格包含任务 ID、输入原文、候选输出、评分维度、备注再配合 Neptune 里的排行榜功能来查看结果毕竟表格文件本身没法承载模型输出里附带的超链接和上下文片段。人工评估完成后把结果回写进 run 的eval/manual命名空间下次对比的时候就能同一个视图里看到“机器觉得好但人觉得差”的样本。4.3 用排行榜模式挑出最优版本实验数量多了之后逐条看 run 列表是一种折磨。这个时候排行榜leaderboard就相当实用选好评估指标按某一项分数排序快速定位到核心指标最好的那批 run再点进去看明细。如果是用 NeptuneAI 这类工具它会根据字段自动聚合出榜也可以对 run 做 tag给“候选上线”“被否决”“待重测”标记。我在项目里常用的筛选链路是先按metrics/faithfulness 0.85筛出候选再按cost/total_est_usd排序最后在排行榜页面里直接打开两个 run 做案例分析。这样一套流程下来基本十几分钟就能给出一个可上线候选。5. 实操过程还原一个完整的跟踪周期5.1 准备环境和初始化实验这个部分我拿一个简化但完整的例子来演示。假设你要做一个“产品客服助手”需要测试两组 Prompt 在相同数据集上的表现。第一步是用代码初始化run并把基础信息写进去。import neptune import os run neptune.init_run( projectmy-team/customer-support, nameprompt-a-temp-0.1, tags[candidate, prompt-a], )这一步会创建一个独立实验记录空间。之后运行过程中调用的所有记录接口都会把信息写到这个 run 里直到你调用stop()结束它。我的习惯是在代码入口就初始化在代码出口或异常处理的finally块里停止运行防止脚本跑到一半崩溃导致记录不完整。5.2 记录 Prompt、参数、数据和结果接下来是往 run 里面写数据。典型流程是先记录配置再执行调用最后记录结果run[config/model_name] gpt-4o-2024-05-13 run[config/temperature] 0.1 run[prompt/system_hash] sha256_of_system_prompt run[data/eval_dataset] customer_intents_v7.parquet responses [] for item in eval_dataset: response call_llm(item, system_prompt, temperature0.1) responses.append(response) eval_metrics compute_metrics(responses) run[eval/metrics/accuracy] eval_metrics[accuracy] run[eval/metrics/faithfulness] eval_metrics[faithfulness] run[info/total_cost] sum_estimated_cost看起来很简单但有几个细节值得强调。第一不要在循环里频繁访问run的写接口否则会产生大量底层请求建议攒一批统一写入。第二记录eval_dataset只用文件名是不够的最好再记录一个数据集内容的哈希确保别人拿到同一份数据。第三模型版本标识不要只写一个 display name还要把 API 返回的实际模型标识记录下来很多服务端会在你不注意的时候对模型进行升级替换。5.3 多版本对比与结果复盘跑完两个 run 之后真正的对比才开始。先看自动指标如果prompt-a的准确率明显高但真实感分低这可能说明它在没有足够上下文时更容易编造内容。再进入两个 run 各自的样例列表找出几个分数差异最大的 case逐条看差异。我在复盘时经常发现一个跑分更高的 Prompt 实际上并没有变好只是它倾向于给出更保守、更短的回复所以被评估器扣分更少。这就是为什么要保持评估集和评估 prompt 稳定。一旦发现类似情况就要回到 case 层面去看实际效果不能只依赖排行榜上的名次做决定。6. 常见问题与排查技巧实录6.1 参数名称混乱导致对比结果错位这个问题我几乎每次带到新团队都会碰到。A 同事在字段里写tempB 同事写temperature两个人各自记录后想横向对比却发现表格里有两列完全不同的字段。根源不是他们不认真而是缺少统一的字段命名规范。解决办法是在项目启动时约定一份最小命名规范并且用代码里的常量来约束比如FIELD_TEMPERATURE config/sampling/temperature FIELD_SYSTEM_PROMPT_HASH prompt/system_hash把所有字段名集中放在一个fields.py文件里不允许任何人凭空造字符串。哪怕后续加字段也要先改这个常量文件。这样对比阶段的错位问题能直接消除大半。6.2 数据版本不一致导致复现失败另一个高频事故是“数据集文件被覆盖但所有实验记录里都写的同一个文件名”。因为大多数人记录数据集时只记录文件名而文件内容已经无声无息变了。这会造成两个实验明明挂着同一个数据集名称实际输入内容却不同最终指标差异被误判为 Prompt 优化效果。后来我坚持要在记录数据集信息时增加“文件内容哈希”。具体做法是读取数据文件后计算md5或sha256连同文件名一起写入。每次加载数据时都会校验一遍只要内容变了哈希就会变对比的时候一眼就能看出来。这个习惯成本很低收益却很直接。6.3 API 调用延迟与异步写入注意事项有人在跑大批量评测时会把运行数据写操作放在每次请求之后同步进行结果评测速度被拖慢很多。Neptune 这类平台的写入接口并非完全没有开销虽然它做了异步缓冲但如果你在循环里频繁调用仍然可能造成不必要的等待。更好的做法是先把关键指标算好再批量写入。终结前再用wait()确保数据真正落库。我在代码里的实践是run[eval/results] results run.wait() run.stop()有的平台也支持上传本地文件作为 artifact比如把评估结果映射成了 JSON 文件可以直接让 run 关联该文件这样可视化时能直接打开查看。6.4 团队协作时的权限与 tag 管理多人协作时还有一个不小的坑不同人往同一个 project 里写 run模板多样命名随意整个项目变得像公共垃圾桶后面筛选效率低到令人崩溃。这里比较实用的做法是给 run 加上统一的 tag 前缀比如按模块划分module/retrieval、module/prompt_test、stage/pre_prod。另外给用户分配权限不让所有人都有删改权限避免有人清理实验库时误删正在使用的 run。还有一个容易被忽略的点实验记录是有时效性的。某些实验里的模型服务可能已经下线如果你不及时把结论和状态标记好后续复用旧 run 的意义就不大。所以我的习惯是每个 run 在收尾时都写一段“总结与后续建议”哪怕只是几句话也给未来的自己留下足够线索。7. 续写这个系列能带来的直接收获说实话从传统 ML 转到 LLM 应用后我开始觉得实验管理是所有工程基建里投入产出比最高的一项。它不直接提升模型效果但能让你快速定位到影响效果的因素是什么。有时候团队加班改 Prompt改了几十个版本心里根本没底是因为没有一套结构化的反馈机制把它显性化。如果你也想在自己的项目里动手我给一个最小可行的建议别追求一步到位先从定义“一次运行的记录结构”开始把配置、Prompt 哈希、数据集哈希、核心指标这四类信息固定下来。跑两周后再回头看你会发现自己能快速回答“哪个版本更好”“为什么好”“下一个应该试什么”。这个过程本身就是效率巨大的提升。再做这个系列的中文翻译与解读时我也越发确认工程界不缺炫酷的模型缺的是扎扎实实把每一次尝试都变成可积累资产的人。希望这篇内容能帮你少走一段弯路。