feat(t152): workers_ai_chat 種子（auth: binding，免金鑰）＋ 修 /init/seed 吃掉 3.12 欄位＋ 修 D1 LIKE 長查詢 500
SDD: workflow-discovery 3.12/3.13（不是新規格；3.12 已 confirmed 並實作完成） ## 1) workers_ai_chat 種子（新） Cloudflare Workers AI 走 env.AI binding ⇒ 用戶不必填任何 API 金鑰就能問答。 放種子表而非產品安裝器：「裝好後預設有哪些 recipe」是平台能力（rule 07 薄殼原則）。 換模型／換供應商＝改這一筆 recipe，workflow 不動。 選型實測（1.4.4 實例，真實長度 RAG prompt，每個模型連跑 2 次）： llama-4-scout-17b 2373／2173 ms ✅ 答案最完整、引用正確 ← 選它 llama-3.3-70b-fp8-fast 3261／2147 ms ✅ 可用但波動較大 mistral-small-3.1-24b 3560／3631 ms qwen2.5-coder-32b 3572／3353 ms gpt-oss-120b 1971／2295 ms ❌ 回應形狀不同，response 取不到文字 gemma-3-12b-it ❌ 5018 帳號無權限 對照舊路徑 Gemini gemma-4-31b-it：同型提問 16.87 s，且吐整段英文思考草稿。 ## 2) 修 /init/seed 靜默吃掉 3.12 欄位 3.12 給 RecipeDefinition 加了 body_template/response_map/auth/binding_name， 但 /init/seed 是**列舉欄位重建** recipe record ⇒ 不在名單上的欄位被丟掉。 最惡劣的地方是「哪裡都不會紅」：recipe 查得到、endpoint 對，只有跑起來像沒設定過。 與 08-02 syncManifest 吃掉 manifest.daemon 欄同型（教訓：東西還在不在也要進機械閘）。 加 tests/init-seed-recipe-fields.test.ts：拿掉修復會紅、補回會綠（已實測會擋）。 ## 3) 修 D1 LIKE pattern 50 bytes 上限造成的 500 /entries/search?q=… 只要 q 超過 48 bytes 就回 HTTP 500，沒有錯誤訊息。 逐 byte 二分：48→200／49→500；中文 16 字→200／17 字→500。 判別實驗：q 固定 48 bytes、其他 filter 全塞滿讓 SQL 變很長 → 仍 200 ⇒ 爆的是 LIKE 的 pattern（'%'+q+'%' = 50），不是 statement 長度。 中文問句超過 16 字是常態，而 rag_chat 用整句問題當 q ⇒ 聊天對正常問句等於不能用。 （＝InkStoneCo status.md 待辦第 1 條「KBDB keyword 長查詢會炸」的根因。） 修法：q ≤ 48 bytes 走原路（行為逐字不變），超過才拆詞／切 UTF-8 邊界片段。 kbdb 全套 83 測全綠（含新增 8 項）。 ## 4) 順手 - 移除被 commit 進 repo 的 node_modules 壞 symlink（指向 leo Mac 的絕對路徑， 害任何 fresh clone 裝不起來、切分支還會把裝好的蓋掉——本次撞了兩次）。 - pending-changes.md 加 P2 提案（fan-out 並行執行）＋等裁決，未動引擎。 驗證：cypher-executor 新增測試 17/17 綠；tsc 與基線逐字相同； 全套測試失敗集合與基線**逐字相同**（基線 14 個失敗，本分支 t173 既有，非本次引入）。
This commit is contained in:
@@ -8,6 +8,57 @@
|
||||
|
||||
## 待裁決
|
||||
|
||||
### P2｜fan-out 並行執行（一個節點的多條出邊目前是循序跑）— 2026-08-03
|
||||
|
||||
**觸發**：leo 08-03 原話——「這是在測試中的計畫，**希望體驗很好**，我發現用 gemma4 的反應非常慢。」
|
||||
把 rag_chat 的生成端換成 Workers AI 之後（16.87 s → 2.2 s），一量才發現
|
||||
**慢的大頭根本不是 LLM**。
|
||||
|
||||
**實測（1.4.4 實例，逐段疊加、每段取兩次的較快值）**
|
||||
```
|
||||
① prep（code） 208 ms
|
||||
② +kw_search 1,383 ms (+1,175)
|
||||
③ +sem_search 3,240 ms (+1,857)
|
||||
④ +fetch_triplets 5,198 ms (+1,958)
|
||||
⑤ +fetch_blocks a/b/c 7,793 ms (+2,595)
|
||||
⑥ +assemble（code） 8,421 ms (+628)
|
||||
+ask_llm（Workers AI） ≈10,400 ms (+2,000)
|
||||
```
|
||||
⇒ **6 個 KBDB 檢索節點合計約 7.6 s，佔全鏈 73%；LLM 只佔 20%。**
|
||||
而這 6 個節點**彼此完全獨立**（kw／sem／triplets／blocks×3 誰都不吃誰的輸出），
|
||||
只是因為 flow 被寫成一條鏈才一個接一個跑。
|
||||
|
||||
**根因在引擎，不在 workflow**（`cypher-executor/src/graph-executor.ts`）：
|
||||
- 起點節點**已經是並行**的（`:85` `Promise.all(startNodes.map(...))`）
|
||||
- fan-in **已經支援**（`:78-84` 入度 >1 的節點等所有上游到齊）
|
||||
- 但**出邊是循序的**（`:427` `for (const edge of outEdges)`，迴圈內 `await executeNode`）
|
||||
⇒ 一個節點分岔出 6 條 `ON_SUCCESS`，是一條跑完才跑下一條。
|
||||
⇒ **改 workflow 解不了**：把 6 個節點都掛在 prep 底下，只是把「鏈」變成「6 條循序出邊」，一樣慢。
|
||||
|
||||
**提案（擇一，我建議 A）**
|
||||
|
||||
- **A. 出邊並行 ＋ 沿用既有 fan-in**：把 `:427` 那個迴圈改成
|
||||
「同型別、無條件分支的出邊」用 `Promise.all` 併發，其餘（`ON_TRUE`／`ON_FALSE`／`ON_BRANCH`／`ON_FAIL`）
|
||||
維持原樣。rag_chat 的 6 個檢索節點改掛在 prep 底下、匯流進 assemble（入度 6，fan-in 現成）
|
||||
⇒ 預估 **7.6 s → 約 2 s**，全鏈約 **10.4 s → 4.5 s**。
|
||||
⚠️ **這是引擎核心、風險最高**（照本 repo 自己的規矩：先寫測試再改）。
|
||||
需要先講清楚的語意：多條邊並行時 `result` 怎麼合併（現行是「後一條覆蓋前一條」的隱含語意）、
|
||||
任一條失敗時的行為、trace 的順序。**既有 workflow 行為必須零變化，且要跑一次證明。**
|
||||
|
||||
- **B. 只砍節點數（完全不動引擎）**：`kw_search`／`sem_search` 在 v2 計分裡只是小加分
|
||||
（kw 命中 +2、sem 前十 +0.4，主導權在 IDF 字面重疊）⇒ 拿掉這兩個節點可省約 3 s。
|
||||
代價是**檢索品質**（少了兩個佐證訊號），屬產品取捨，不是我能裁的。
|
||||
|
||||
- **C. 不做**：接受目前的 10 s。
|
||||
|
||||
**影響分析**
|
||||
- 現行 active SDD `workflow-discovery`：A 屬引擎能力，與 3.9（`ON_TRUE`／`ON_FALSE` 走邊）同一塊，
|
||||
是**新增任務**，不作廢任何既有任務。
|
||||
- B 只動 `arcrun-rag/workflows/rag-chat.local.yaml`，不碰本 repo。
|
||||
- 三者都**不影響**已完成的 3.12（recipe 三層）與本次 Workers AI 換源。
|
||||
|
||||
**⏸ 停在這裡等 leo 裁**：回「A」我就先寫測試再改引擎；回「B」我只改 workflow；回「C」就記著不做。
|
||||
|
||||
### P1｜host fn 二進位通道（解開「零件無法處理非文字檔」的框架級限制）— 2026-07-27
|
||||
|
||||
**觸發**：leo 07-27 原話（arcrun-rag t73 收尾時）——
|
||||
|
||||
@@ -199,6 +199,17 @@
|
||||
一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）。
|
||||
**相容硬要求**：既有 recipe（無新欄位）行為完全不變。
|
||||
- [◐] 3.13 **驗收＝CP 步驟 5 考試（features/07）**
|
||||
◐ 08-03（t152，**3.13「真正的改寫」那半落地**）：`rag_chat` 的 `ask_llm` 從
|
||||
「整包 Gemini 細節寫在 workflow 節點」改成 `component: workers_ai_chat`（一個 recipe 名 ＋ 一個 prompt），
|
||||
`finalize` 從 **2786 字元縮到 12 行**（回應解讀搬進 recipe 的 `response_map`）。
|
||||
本 repo 側配套：`api-recipe-seeds.ts` 新增 `workers_ai_chat` 種子（`auth: binding`，
|
||||
3.12 第四型認證的第一個真實案例）＋修掉 `/init/seed` **列舉式重建吃掉 3.12 四個欄位**的洞
|
||||
（種子帶了 body_template/response_map/auth 卻進不了 KV，且哪裡都不會紅——與 08-02
|
||||
`syncManifest` 吃掉 `manifest.daemon` 同型）。回歸閘 `tests/init-seed-recipe-fields.test.ts`
|
||||
3 項，**拿掉修復會紅、補回會綠**（實測過會擋）。
|
||||
實例端到端（1.4.4 youlin 帳號，**零 API 金鑰**）：問答鏈全綠、有答案有出處。
|
||||
選型實測見種子檔註解（llama-4-scout 2.2s vs Gemini gemma-4-31b **16.87s**）。
|
||||
⚠️ 仍 ◐ 未 ✅：haiku 場景（缺件時只寫 recipe 就補全、零 JS）＝features/09 stage 端到端未驗。
|
||||
◐ 08-01：本地驗收綠（`tests/step5-acceptance.test.ts` 3 項），實跑輸出＝
|
||||
**舊寫法 1201 字元 / if×8 → 新寫法 350 字元 / if×0（下降 71%）**，
|
||||
且分流工作流 `success=true`、零 code 節點。
|
||||
|
||||
Reference in New Issue
Block a user