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 確保它們從高基準開始,因此您的自訂是精煉,而非修復。