人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用【免费下载链接】KilnBuild, Evaluate, and Optimize AI Systems. Includes evals, RAG, agents, fine-tuning, synthetic data generation, dataset management, MCP, and more.项目地址https://gitcode.com/gh_mirrors/ki/Kiln点击查看免费下载导读在 Kiln 的 V2 评估体系中EvalRun长期同时承载「模型生成痕迹trace」与「评判分数scores」两类数据导致一个严重的实践问题只要给已有评估新增一个评判器judge整个评估就会因去重键包含eval_config.id而从零开始重新生成全部输出——而 V2 的 8 种评估类型中有 7 种exact_match、pattern_match、contains、set_check、tool_call_check、step_count_check、code_eval都是本地计算、评分近乎免费只有llm_judge消耗真金白银。本文基于 功能规格书配套阅读 架构文档 与 研究文档完整讲解 Kiln 如何把 trace 与 score 拆分为两种独立记录实现「加评判器只重新评分、不重新生成」「生成结果先落盘、评分失败不毁迹」「评判器之间可做配对比较」三大目标。读完你将掌握这一重构的数据模型、复用键设计、运行器改造、读路径兼容与迁移方案的全部细节。1. 问题与目标为什么必须拆分1.1 缺陷的本质EvalRun当前以EvalConfig为父节点存储一份记录里同时装了两类语义完全不同的数据trace 侧input、output、task_run_trace、task_run_usage、dataset_id/eval_input_id、task_run_config_idscore 侧scores、intermediate_outputs评判思维过程、skipped_reason/skipped_detail。研究文档以一张证据表确认了这个缺陷的真实性research.md §1EvalConfig(..., parent_of{runs: EvalRun})把 trace 和 score 绑在同一记录上already run 去重键包含eval_config.id对应libs/core/kiln_ai/adapters/eval/eval_runner.py中的collect_tasks逻辑新 EvalConfig 从空集合起步导致每个任务都重新执行evaluator.run_task(...)。从数学上看trace 是 (input, task_run_config) 的函数score 是 (trace, eval_config) 的函数。把两者塞进一个以eval_config为键的记录里等于让昂贵的生成环节被廉价的评分环节绑架。1.2 三个目标复用而非重生成给已有评估新增评判器时复用已有 trace只重新评分。trace 先于评分持久化生成一旦完成立即落盘后续评分失败绝不销毁它。评判器配对比较两个评判器对同一份生成结果打分差异可归因于评判器本身而非生成噪声——这正是我的评判器好不好这一核心工作流的统计基础。1.3 非目标不改变任何评估度量本身给定(item, run config, eval config)所产生的分数保持不变。2. 总体形态trace 就是 TaskRunEvalRun 只做纯分数记录这是整个重构最关键的设计决策决策 D12/D15不新建任何 trace 实体。Eval trace 直接复用TaskRunEvalRun则从trace score 混合体收窄为纯粹的分数记录。Task ├── runs/ TaskRun —— 数据集语料 AND 评估生成的 trace ├── eval_inputs/ EvalInput不变 └── evals/ └── {eval}/ └── configs/ └── {config}/ └── runs/ EvalRun —— 现在纯粹是分数记录TaskRun已经携带一个 trace 所需的全部要素trace、output以及 run config既以output.source.run_config_id形式、又以冻结的output.source.run_config属性形式存在。复用它还免费获得output.rating人工评分、feedback子记录和repaired_output。磁盘布局上评估生成的 trace 直接落在Task.runs/目录中见 task.py 中的 runs 访问器说明。3. 复用键不靠哈希靠三条不变式一个 trace 由(source_type, source_id, task_run_config_id)唯一标识决策 D9——没有哈希没有指纹。这不是新发明而是数据模型早已宣称的不变式的兑现TaskRunConfig的语义是用相同的 RunConfig 跑相同的输入应对模型发起完全相同的调用。其中source_type必不可少id 只在各自 store 内唯一TaskRun和EvalInput的 id 可能碰撞这正是eval_splits.ItemKey存在的原因。两个来源类型含义如下source_typesource_id指向适用场景eval_inputEvalInput.idV2 EvalInput 支撑的 splittask_runTaskRun.id数据集条目本身V1 TaskRun 支撑的 split因此一个 legacy 来源的评估 trace就是eval_source指向另一个TaskRun 的 TaskRun生成的 trace 回指它生成所依据的数据集条目两者始终是不同的记录。这与 splits 分支的ItemKey Tuple[ItemSource, ID_TYPE]完全同构见 eval_splits 相关代码。4. 数据模型变更详解4.1TaskRun新增一个字段eval_sourceclass EvalItemSource(BaseModel): The eval *dataset item* this run was generated for. Not the run config — that already lives on this TaskRun at output.source.run_config_id. source_type: Literal[eval_input, task_run] source_id: ID_TYPE class TaskRun(...): eval_source: EvalItemSource | None None在源码中EvalItemSource定义在 task_run.py 而非eval.py——eval.py仅在TYPE_CHECKING下导入TaskRun把类型放回eval.py会制造真实的循环导入。配套的eval_item_key()辅助函数把 source 转换为 splits 分支的ItemKey词汇task_run.py。几个关键设计要点eval_source的存在本身就是评估生成的标记。没有单独的布尔值——评估生成的 run 必有来源条目普通数据集 run 必无二者不可能产生分歧。它刻意不指名任何 Evaltrace 与评估无关这正是它能跨评估复用的原因D1、D12。所有其他 TaskRun 字段与验证器保持不变。实现细节source_id用str而非ID_TYPEOptional[str]因为无 id 的 source 会让 trace-index 键与其他所有无 id 来源碰撞不存在已由eval_source本身为None表达。4.2Task.runs()默认排除评估生成的 runTask.runs(readonlyFalse, include_intermediate_runsFalse, include_eval_generatedFalse) # NEW源码实现在 task.py过滤在既有叶子过滤之后执行if not include_eval_generated: runs [r for r in runs if r.eval_source is None]两个过滤器可叠加run 必须同时通过两者才被返回。默认排除而非 opt-out 过滤是刻意为之忘记处理评估 trace 时失败方式是可见的数据缺失而不是静默的微调集被污染、评估输出渗入 few-shot prompt。架构文档 §4 对全部调用点做了审计architecture.md §4确认每个调用点默认排除都是正确的调用点用途默认排除是否正确run_api.py:284,355数据集列表与计数正确run_api.py:632标签计数正确dataset_split.py:146微调集拆分正确dataset_formatter.py:378微调导出正确prompt_builders.py:206few-shot 示例正确——最关键的一处评估输出进 few-shot 是反馈回路finetune_api.py:234微调样本选择正确agent_api.py:235数据集统计正确eval_api.py:541,549,1625golden 集过滤器、split 成员正确——golden 项是人工评分的用户 runD11eval_runner.py:149,257数据集条目收集器正确——V1-backed split 迭代的是用户 run评估 trace 绝不能作为条目出现整个仓库只有TraceIndex._seed()传include_eval_generatedTrue。4.3EvalRun一个新增字段、五个废弃字段新增两个字段scored_run_id: ID_TYPE | None None # 这条分数计算所依据的 TaskRun eval_usage: Usage | None Field( defaultNone, descriptionThe usage of the evaluation model (judge) that produced this eval runs scores, aggregated across every LLM call the judgment made. ..., )eval_usage填补了一个真实缺口LLM 评判器的 token 成本此前无处记录。它也是废弃task_run_usage的自然对应物——任务的usage 移到 TaskRun评判器的usage 在分数记录上取而代之。源码见 eval.py。保留且有意义的字段字段角色父EvalConfig哪个评判器产生了这条分数scores分数本身task_run_config_id反范式化的 run config供免 join 聚合dataset_id/eval_input_id数据集条目——这就是 ItemKeyintermediate_outputs评判器思维过程skipped_reason/skipped_detail评分跳过记录eval_usage新——评判器自身的 token/成本消耗eval_config_eval不变已随 V1 发布D18废弃字段永远保持声明与可加载但新记录永不写入D15input、output、task_run_trace、task_run_usage、reference_answer。其中input从必填改为可选。源码中这些字段的 description 均带DEPRECATED:前缀使废弃状态直达生成的 OpenAPI schema 与前端类型。什么都不删除现有文件一律不重写。4.4 三种记录状态Pointer / Skipped / Legacy inline每份记录恰好处于一种状态由验证器强制D17源码见 eval.py 的 validate_record_mode状态判别器scored_run_idscoresinput trace 字段Pointer新已评分scored_run_id已设、无 skip必填非空必须为 NoneSkippedskipped_reason已设可选——trace 存在则设生成前跳过则 None空新记录必须为 None见下注Legacy inlinescored_run_id为 None、无 skipNone非空input必填trace 字段允许关于 Skipped 行的注记必须为 None是新记录写入的规则而非验证器强制。只有 pointer 记录被禁止携带内联数据。一条无scored_run_id的跳过记录可以携带内联数据——因为拆分前的每条 EvalRun 都必填input字面执行该行会拒绝磁盘上所有已存在的跳过记录。所以规则是凡scored_run_id已设内联数据一律禁止否则允许。pointer 规则的禁止半边才是真正发挥作用的pointer 模式记录绝不能携带它所评分内容的过期第二份拷贝。validate_scores保持不变——除非跳过非空分数仍然必填。不存在没有分数的 EvalRun状态因为已生成但未评分表现为一个没有 EvalRun 指向它的 TaskRun。验证器还有一个顺序细节skip 分支在 pointer 分支之后检查这样在评分时跳过的记录带scored_run_id仍会执行无内联数据检查。validate_output_fields增加 pointer 模式提前返回避免旧的V1 EvalRun 必须带 output规则误伤新记录。5. Runner 行为活的 trace 查询 即时的 trace 持久化5.1 每任务流程对每个(item, run_config, eval_config)任务Trace 查找——找一条eval_source (source_type, source_id)且output.source.run_config_id task_run_config_id的 TaskRun。命中复用不生成。未命中生成然后在评分前立即持久化 TaskRun。Score 查找——在该EvalConfig下找scored_run_id 那条 TaskRun的 EvalRun。命中无事可做。未命中评分持久化 EvalRun。源码中_resolve_trace先检查校准项golden 项直接作为 trace 返回否则构造(item_key, run_config_id, world)键交给TraceIndex.get_or_create生成回调_generate_trace调用evaluator.run_task(...)后盖上eval_source再保存eval_runner.py分数统一经_persist_score写出永不设置内联 trace 字段_persist_judgment与_persist_skip都是它的薄封装eval_runner.py。5.2 trace 查找必须是活的第一步的查找在任务执行时评估而非在collect_tasks()阶段预计算。这是对既有already_run模式的刻意背离预计算的集合看不到同一次运行中早前已持久化的 trace会造成并发重复生成与重试时再生成。新组件TraceIndexlibs/core/kiln_ai/adapters/eval/trace_index.py是运行器自有的活索引构造时从磁盘种子一次、随后持续更新并带 per-key 锁TraceKey tuple[str, ID_TYPE, ID_TYPE] # (source_type, source_id, run_config_id) class TraceIndex: def __init__(self, task: Task): self._task task self._paths: dict[TraceKey, Path] {} self._key_locks: dict[TraceKey, asyncio.Lock] {} self._registry_lock asyncio.Lock() self._seed() async def get_or_create( self, key: TraceKey, generate: Callable[[], Awaitable[TaskRun]] ) - tuple[TaskRun, bool]: Returns (trace, was_generated). generate must persist the TaskRun. async with self._registry_lock: lock self._key_locks.setdefault(key, asyncio.Lock()) async with lock: path self._paths.get(key) if path is not None: return TaskRun.load_from_file(path), False run await generate() if run.path is None: raise ValueError(generate() must persist the TaskRun before returning) self._paths[key] run.path return run, True设计要点源码均有对应实现与注释存路径而非对象评估 trace 是大字段全量驻留内存不可接受ModelCache使按路径 mtime 的重复load_from_file保持廉价。两级锁_registry_lock只守卫锁的创建纳秒级持有per-key 锁横跨整个生成过程仅串行化会重复劳动的作业不同键的作业互不阻塞。源码用AsyncLockManager实现并自动回收闲置条目。种子不是额外扫描collect_tasks本就遍历task.runs()同一趟构建索引。setdefault实现 D8 的先到先得处理同步产生的重复 trace。generate返回前必须持久化满足trace 先于评分落盘的硬性要求_generated_path还会核对生成的 run 是否按请求的键自归档从 run 自身的eval_source、output.source.run_config_id、world_episode反读防止看似正常却永不复用的静默重生成。读侧_load_indexed对文件丢失、解析失败、键漂移三种情况降级为移除条目并重生成绝不因一条坏 trace 拖垮整个作业。5.3 重试idempotent 查找就是阶段划分重试机制不变。AsyncJobRunner继续在RetryableError时重试整个run_job。由于 trace 查找是活的评分失败后的重试会找到已持久化的 TaskRun跳过生成只重新评分。幂等查找本身就是阶段划分——不需要把重试粒度改到单阶段。5.4 重复 trace先到先得同键可能有多条 TaskRun 匹配——同步意味着唯一性无法保证两个人分别运行后同步。系统对此已具备容忍度首个匹配胜出D8没有任何路径会刻意创建第二条。种子与写路径都通过setdefault实现这一点。5.5 校准calibration不生成、不标记在eval_config_evalTrue的校准模式下不进行任何生成被评分的 TaskRun就是人工评分过的 golden 数据集条目。scored_run_id直接指向它不创建任何评估生成的 TaskRun——因此 golden 条目永远不会被打上评估标记、永远不会被默认排除、永远不会被删除保护拒绝。源码中_resolve_trace对校准任务直接return job.item, Falseeval_runner.py。5.6 跳过三种情况三种落盘条件落盘记录该条目无法生成如incompatible_input_shapeEvalRun设skipped_reason无scored_run_idtrace 存在但该评判器无法评分missing_reference_key、extraction_failed、missing_trace、code_eval_not_trusted、type_not_availableEvalRun设skipped_reason设scored_run_id生成本身失败什么都不落盘D14——TaskRun.output必填失败的生成无可表示之物。条目显示为未完成下次运行重试与现行absence not-yet-run约定一致6. 读路径分数聚合不变usage 汇总换源6.1 分数聚合一行不动compute_score_summary、eval-config 对比汇总、per-run-config 汇总全部读取eval_config.runs()并按task_run_config_id与条目键分桶。分数计算触及的每个字段都留在EvalRun上所以那部分代码完全不动。完整性判定仍为(eval_config, run_config, item)三元组的 EvalRun 存在性未评分的 trace 视为不完整——这是正确的。唯一例外per-run-config 汇总从eval_run.task_run_usage汇总 token、成本和延迟对应 eval_api.py 的汇总函数。该字段废弃后汇总改从 join 到的 TaskRun 读取。6.2 读TaskRun.usage不读cumulative_usage——两个已验证的理由usage已覆盖 run 内每一次 LLM 调用。它是运行累加器而非单轮值源码中usage call_usage工具调用循环内litellm_adapter.py与usage turn_result.usage跨轮次都有实锤。一个 5 轮 agentic run 报告全部 5 轮的用量。TaskRun.cumulative_usage的 docstring 也一致——对全新非 seedruntoken/成本字段与usage相等。cumulative_usage会静默丢弃延迟。它类型为MessageUsage刻意不含total_llm_latency_ms——跨整条 trace 聚合会混合不同时间点的延迟。Usage是增加该字段的子类而汇总今天就在报告它。两字段仅在 run 从seeded prior trace续跑时不同cumulative_usage汇总整条消息列表usage只计本次 run 自己的调用。新生成的评估 trace 没有 seeded prior trace二者相等。若未来出现 seeded 评估 trace正确做法不是换字段而是 token/成本读cumulative_usage、延迟读usage——它们回答的是不同问题。Legacy 记录仍携带task_run_usage故scored_run_id未设时汇总回退到它。6.3 run-results 视图改为 join 视图get_eval_run_results原返回List[EvalRun]内联input/outputpointer 模式下这些字段为 None。端点改为返回join 视图模型EvalRunWithTraceeval_api.py——EvalRun 字段加上从被引用 TaskRun 拉取的input、output与 trace前端契约得以保留。内容不反范式化到 EvalRun 上因为存储拷贝会过期scored_run_id为 None → 读 EvalRun 自身内联字段from_own_fields。scored_run_id已设 → 加载 TaskRun使用input、output.output绝不使用repaired_output——修复可能发生在评分之后、trace、usagefrom_scored_run。TaskRun 缺失 → 四个字段全为 None分数照常渲染。显示规则展示分数计算所依据的内容时显示TaskRun.output绝不显示repaired_output。端点用Task.from_ids_and_parent_path批量加载被引用 TaskRun一次目录扫描而非逐 id 读取。api_schema.d.ts随之重新生成。6.4 悬挂引用优雅降级若scored_run_id指向缺失的 TaskRun分数照常显示、聚合照常计数仅 trace 下钻不可用。不要级联删除分数不要在悬挂 id 上抛错——这正是删除保护之外同步/导出场景下分数仍能存活的保证。7. 删除保护唯一的用户可见新表面删除带eval_source的 TaskRun 被拒绝返回信息This is needed for an eval.D16。无需反向引用扫描——TaskRun 上的标记本身就足够无论当前是否有 EvalRun 指向它保护都成立。这是整个项目唯一新增的用户界面产品面 scope 决策 D20复用可见性、强制全新生成、配置编辑过期处理全部明确划出范围。源码实现在 libs/server/kiln_server/run_api.pydelete_run与批量delete_runs都增加if run.eval_source is not None守卫抛出 HTTP 409请求格式正确、资源状态禁止故用 409 而非 400批量端点对被拒的评估 run 是上报而非静默跳过——既有的 per-run 错误收集把原因带回给用户让其明白选择为何被部分删除。此外run_api.py还拒绝客户端通过 PATCH 设置eval_source{eval_source: null}同样被拒确保该标记只能由评估运行器写入。8. 旧数据共存V1 原样存活V1 EvalRung_eval/llm_as_judge配置下以 legacy-inline 模式完全按今天的方式加载与渲染永不迁移、永不重写。EvalConfig 构造上不可变D21eval_api只暴露 create/get/list没有 PATCH 或 DELETE。因此分数相对其配置永远不会过期。配合复用键每条 EvalRun 由三件不可变之物完整描述条目、run config、eval config。无任何 V1 文件格式变更无任何 schema 字段被移除。研究文档D21特别强调这是承重不变式而非附注整个复用设计建立在其上——分数不可能相对其配置过期因为配置不可能改变。9. 迁移V2 内部数据的migrate-eval-runs命令V2 尚未发布但内部项目已携带 V2 评估数据。迁移脚本是必备交付物作为最终阶段运行懒加载折叠不可用因为记录要跨目录搬迁。对每个 V2EvalRun父EvalConfig.config_type v2从内联 trace 字段input、output、task_run_trace、task_run_usage为每条 EvalRun 创建一个 TaskRuneval_source由dataset_id/eval_input_id对设定run config 取自task_run_config_id。将 EvalRun 重写为 pointer 模式设scored_run_id清空内联字段。刻意不去重——多个 eval config 的 EvalRun 可能描述同一份生成按(item key, task_run_config_id)归组会坍缩成共享 TaskRun但这是单一内部项目的数据重复量小而无害且今后的活 trace 查找自然会按键产出一条 trace。校准 EvalRuneval_config_evalTrue已通过dataset_id引用真实 TaskRun——直接设scored_run_id dataset_id不创建任何东西。无 trace 的跳过 EvalRun——清空内联字段scored_run_id保持未设。V1 EvalRun 整体跳过。脚本幂等已是 pointer 模式的 EvalRun 原样跳过。实现位于 libs/core/kiln_ai/cli/commands/migrate_eval_runs.py带--dry-run旗标只打印计划、写零字节与-y/--yes跳过确认顺序保证先存 TaskRun、后重写 EvalRun使中断的运行留下无害的孤儿 TaskRun默认不可见而非悬挂指针_exit_if_incomplete对部分迁移的项目以非零退出码结束干跑亦如此便于脚本化预检。10. 词汇统一scoring vs calibration新代码、注释、文档与 UI 统一采用存储字段eval_config_eval保持原名概念术语评估一个 task run config先生成再评判。模型 A 比模型 B 好吗scoring评估一个 eval config评判人工评分条目并做相关性分析。我的评判器靠谱吗calibrationTrace 指 TaskRunScore 指 EvalRun。这个命名并非表面文章eval_config_eval的旧名把两种不同语义塞进一个布尔值且 False 分支的含义完全不在名字里而 scoring/calibration 的区分正是整个拆分后模型语义的自然投影——calibration 下被评分的 TaskRun 就是 golden 数据集条目本身没有任何生成发生。11. 范围之外刻意不做的事事项原因用此评判器给现有 run 打分动作现有 Run 按钮在 trace 可复用后已自动实现复用可见性 / 进度计数快就够了一次快速运行不算 bug强制全新生成范围蔓延且今天本就没有 force-fresh配置编辑过期处理不存在此问题EvalConfig 不可变D21跨评估复用作为功能任务级 trace 存储自然带出无 pointer-EvalInput 类型D2Metrics / 观测型评估作为读侧概念推迟由 split ref 限定范围D3EvalInput-backed golden 集人工评分住在TaskRun.output.ratinggolden 保持 TaskRun-onlyD11移除eval_config_eval已证明冗余但随 V1 发布——无关的兼容性搅动D18multi_turn_drive_config移到EvalInput归 eb-v2 分支所有是多轮跨评估复用的前置条件不是本项目工作D5既有的生成漂移漏洞接受未冻结动态 prompt、按 id 引用工具、task.instructionD1012. 依赖与约束依赖claude/eval-splits-evals-v2分支——本项目建立在其上。Eval.splits、resolve_split()、ItemKey、eval_run_item_key()全部复用而非重实现成员关系一律经resolve_split()解析。eb-v2 / multi-turn 分支——multi_turn_drive_config在发布前移到EvalInput已与 eb-v2 达成一致。落地后复用键无需额外项即可覆盖它drive config 成为条目的一部分落地前多轮 trace 不得跨评估复用。约束向后兼容绝对优先磁盘上每条 V1 记录原样加载、原样渲染任何 schema 字段不删除。目录规模runs/现在同时容纳数据集语料与全部评估 trace已单独基准测试并接受。零新增依赖。每个全新任务两次保存而非一次均在 git-syncSaveContext内完成。13. 测试矩阵设计如何被验证重构的正确性由覆盖四个层面的测试守护详见 architecture.md §9数据模型test_eval_model.pyvalidate_record_mode的六种合法/非法组合磁盘上每条 V1 fixture 仍能原样加载D15 回归护栏Task.runs()默认排除/显式包含/与include_intermediate_runs叠加。TraceIndextest_trace_index.pyseed 命中复用seed 忽略无eval_source的 run重复种子先到先得25 个并发get_or_create对同一键恰好调用一次generate且拿到同一 run护住钱袋子的那条测试不同键并发生成互不串行未保存的generate返回值直接抛错。Runnertest_eval_runner.py头号测试——跑一次评估、加第二个 eval config、再跑一次断言第二次run_task调用次数为零且出现第二组 EvalRun校准不创建 TaskRun 且scored_run_id dataset_id评分失败后 trace 仍在、重试零重生成trace 的eval_source与条目 ItemKey 匹配V1 legacy 路径不变characterization。APItest_eval_api.pyEvalRunWithTrace对 pointer 与 legacy 记录解析出同形结果TaskRun 同时有 output 与 repaired_output 时返回前者悬挂scored_run_id→ 全空字段 HTTP 200usage 汇总 pointer 记录读TaskRun.usage、legacy 读task_run_usage。删除保护test_run_api.py删评估生成 run → 409混合批量删除 → 非评估 run 删除、评估 run 上报原因。迁移含 V1、V2 pointer、V2 inline、校准、跳过记录的 fixture 项目 → 只有 V2 inline 记录发生变化第二遍跑是 no-op干跑零写入。14. 实施顺序的关键约束这是一次横跨约 8 个文件的内聚变更而非一组各自独立的复杂组件。唯一硬性顺序约束Task.runs()默认排除§4.2必须先于run_task开始持久化§5.1落地。反序落地会让两者之间的每一个数据集界面都被评估 trace 污染——这正是整个设计要消灭的静默失败模式。延伸阅读功能规格书 · 架构文档 · 研究文档含 D1–D21 完整决策表赞分享人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用【免费下载链接】KilnBuild, Evaluate, and Optimize AI Systems. Includes evals, RAG, agents, fine-tuning, synthetic data generation, dataset management, MCP, and more.项目地址https://gitcode.com/gh_mirrors/ki/Kiln点击查看免费下载相关推荐Kiln 评测架构详解拆分 Eval 轨迹Trace与评分Score让每个新 Judge 复用已有生成Kiln 评测架构详解拆分 Eval 轨迹Trace与评分Score让每个新 Judge 复用已有生成 导读 本文围绕 Kiln 项目中 evals人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用MLOps面向 AI 系统的产品级评估框架get-shit-done 的 gsd-eval-planner 与 gsd-eval-auditor 实战指南面向 AI 系统的产品级评估框架get shit done 的 gsd eval planner 与 gsd eval auditor 实战指南 在由 TÂC人工智能AI 应用提示工程开发工具工作流自动化AI AgentCalibre电子书格式转换实战指南15分钟转出第一本书Calibre电子书格式转换实战指南15分钟转出第一本书 MOBI书在新平板上打不开手机里的EPUB又变不成设备认得的格式Calibre是一款免费开源的电人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用MLOps上一篇Source Han Serif CN免费开源中文字体终极指南下一篇N_m3u8DL-RE跨平台流媒体下载终极指南 - 免费开源工具快速上手教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考