JieGou 为九个部门提供入门套件,每个套件包含 7-10 个 recipes 和 2-5 个 workflows。总计约 150 个 recipes 和 40 个 workflows。手动撰写每一个、使用真实输入进行测试、评估输出品质,并反复迭代直到达到可发布的标准——这对一个团队来说是全职工作量。
我们需要更好的方法。所以我们建立了 Recipe Factory:一个自动化流程,能够大规模生成、测试、评估和推广模板。
流程架构
Recipe Factory 执行五个阶段:
1. Catalog → Generate
每个 recipe 都从 catalog 中的规格开始:标题、描述、目标部门、预期输入栏位、预期输出栏位,以及品质标准。目前 catalog 包含横跨 9 个部门的约 150 个 recipe 规格。
生成阶段接收每个规格,使用 LLM 产生完整的 recipe:精致的提示词模板、包含栏位描述的详细输入 schema,以及结构化的输出 schema。LLM 遵循一个 meta-prompt,其中编码了我们对 recipe 品质的标准——清晰的指令、适当的细节层级,以及 schema 最佳实践。
2. Generate → Test Data
针对每个生成的 recipe,第二次 LLM 呼叫会产生 3-5 个合成测试输入。这些涵盖典型情况、边界情况(最小输入、异常长的输入、模棱两可的输入),以及部门特定场景。测试输入足够真实,能产生有意义的输出,而不需要真实客户资料。
3. Test Data → Run Tests
每个 recipe 使用合成测试输入,在真实的 LLM 上执行。这能捕捉在模板中看起来正常但在执行时失败的问题:schema 不匹配、产生偏离目标输出的提示词、超过 context 限制的模板,以及模型解读方式与预期不同的指令。
4. Run Tests → Evaluate
这是 LLM-as-judge 发挥作用的地方。一个独立的 LLM 在五个维度上评估每个测试结果:
- Schema 符合度 — 输出是否符合预期的 schema?所有必要栏位是否存在且类型正确?
- 完整性 — 输出是否涵盖输入的所有面向?是否有缺口或遗漏的部分?
- 可行动性 — 输出是否有用?人们能否在不需要大量额外工作的情况下采取行动?
- 格式品质 — 输出是否组织良好、撰写清晰,且细节程度适当?
- 一致性 — 在多个测试输入中,recipe 是否产生结构一致的输出?
每个维度获得 0-100 的分数。整体分数是加权平均值。
5. Evaluate → Promote
总分 75 以上且没有任何维度低于 50 的 recipes,会被推广到 Firestore 中的示范帐户。未通过的 recipes 会被标记,等待手动审查和迭代。
LLM-as-judge 教会我们什么
建立自动化品质评估系统产生了几个不明显的洞察。
提示词的具体性比长度更重要。 早期的 recipe 模板又长又详细。LLM-as-judge 持续在 schema 符合度和格式品质上给予较短、更具体的提示词更高分数。一个 200 字、明确说明要做什么的提示词,表现优于一个涵盖所有边界情况的 500 字提示词。模型更能遵循清晰的指令,而非全面的指令。
输出 schemas 是最重要的品质控制手段。 拥有详细输出 schemas 的 recipes——栏位描述、枚举限制、巢状物件结构——在完整性和一致性上得分显著更高。Schema 作为第二组指令,独立于提示词之外限制模型的输出。
边界情况测试输入揭示脆弱性。 标准测试案例通常有效。边界情况——最小输入、不寻常的格式、缺少选填栏位——暴露了在真实世界条件下会失效的 recipes。一个在典型情况下得分 90 但在边界情况下得分 40 的 recipe,还没有准备好上线。
评估标准需要校准。 我们第一次的 LLM-as-judge 评分太宽松。一些产生普通输出的 recipes 得分 85 以上。我们加强了评估提示词,加入每个分数等级的具体范例。80 分以上的「可行动性」意味着输出包含具体的下一步,而不只是分析。80 分以上的「格式品质」意味着清晰的标题、一致的结构,以及适当的长度。
跨部门一致性需要共享标准。 销售潜在客户研究 recipe 和 HR 履历筛选 recipe 都从非结构化输入中提取结构化资料。品质标准应该相同。我们在各部门间标准化了评估标准,让 factory 无论 recipe 的领域为何,都能应用一致的标准。
Workflow Factory
在 recipe factory 证明有效后,我们为 workflows 建立了等效的流程。Workflow factory 从规格生成多步骤 workflows,创建能执行完整 workflow 的测试输入(包括条件分支和回圈迭代),端到端执行它们,并评估综合输出。
Workflow 评估比 recipe 评估更困难,因为品质取决于步骤之间如何串接,而不只是个别步骤品质。一个每个步骤单独得分 85 的 workflow,如果资料在步骤间流动不顺畅,整体可能只得 60 分。评估标准包括步骤间资料完整性和整体连贯性。
执行 Factory
完整流程只需一个指令即可执行:npm run recipe-factory。它会接收 catalog 规格、生成 recipes、创建测试资料、执行测试、评估结果,并将通过的 recipes 推广到示范帐户。
个别阶段可以单独执行以进行迭代:
npm run generate-recipes— 从 catalog 规格重新生成 recipesnpm run generate-test-inputs— 创建新的测试资料npm run run-recipe-tests— 在 LLM 上执行 recipesnpm run evaluate-recipes— 对结果评分npm run promote-recipes— 将通过的 recipes 推送到 Firestore
这种模组化让我们能够在特定阶段上迭代,而不需要重新执行整个流程。
为什么这对使用者很重要
Recipe Factory 是内部工具,但其效果是面向使用者的。入门套件中的每个 recipe 都已经:
- 从定义品质标准的规格生成
- 使用包括边界情况在内的真实输入进行测试
- 由 LLM judge 在五个品质维度上评估
- 只有在达到品质门槛时才被推广
当您安装入门套件时,这些 recipes 不是粗略草稿。它们已经通过自动化品质流程,在到达您手中之前捕捉了最常见的问题。
话虽如此,它们是起点。您团队的特定术语、品质标准和输出偏好,是 factory 无法得知的。这些 recipes 设计为可自订——factory 确保它们从高基准开始,因此您的自订是精炼,而非修复。