Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

[總管回報] kbdb 語意查詢 bug：?mode=semantic 加 owner_id/entry_type 過濾回 0（既有，非本次 ingest 造成） #11

New Issue
Closed
opened 2026-07-06 05:41:57 +00:00 by Leo · 3 comments
Leo commented 2026-07-06 05:41:57 +00:00
Owner
Copy Link
Copy Source

發現於 Arcrun#8 Phase B ingest 驗收（實測，非猜測）。

症狀

GET /entries/search?mode=semantic&q=… 不帶過濾正常命中；一旦加 owner_id=… 或 entry_type=… 過濾就 回 0 命中。

影響（為何要修）

所有 owner-scoped / 類型-scoped 的語意查詢都失效：

  • 多租戶語意查（每個 user 只查自己的）。
  • 收件夾分流台（Arcrun#9） 要「per-project / per-owner 過濾 + 語意」，會踩到。
  • 任何「語意 + 過濾」的組合。

定性

既有 kbdb Vectorize 行為，非本次 ingest 造成（本次 ingest 的 embed 標/寫入都正確、不帶過濾語意命中正常）。疑似 Vectorize query 的 metadata filter 與寫入時的 metadata index 對不齊。

建議

另案查 kbdb embed 模組的 Vectorize query metadata filter（寫入 index 的欄位 vs 查詢 filter 的欄位是否一致、型別是否吻合）。優先序：擋 Arcrun#9 收件夾就要用。

[總管] 2026-07-06，來源 Arcrun#8 Phase B 驗收

**發現於** Arcrun#8 Phase B ingest 驗收（實測，非猜測）。 ## 症狀 `GET /entries/search?mode=semantic&q=…` **不帶過濾正常命中**；一旦加 `owner_id=…` 或 `entry_type=…` 過濾就 **回 0 命中**。 ## 影響（為何要修） **所有 owner-scoped / 類型-scoped 的語意查詢都失效**： - 多租戶語意查（每個 user 只查自己的）。 - **收件夾分流台（Arcrun#9）** 要「per-project / per-owner 過濾 + 語意」，會踩到。 - 任何「語意 + 過濾」的組合。 ## 定性 **既有 kbdb Vectorize 行為，非本次 ingest 造成**（本次 ingest 的 embed 標/寫入都正確、不帶過濾語意命中正常）。疑似 Vectorize `query` 的 metadata filter 與寫入時的 metadata index 對不齊。 ## 建議 另案查 kbdb embed 模組的 Vectorize query metadata filter（寫入 index 的欄位 vs 查詢 filter 的欄位是否一致、型別是否吻合）。優先序：**擋 Arcrun#9 收件夾就要用**。 _[總管] 2026-07-06，來源 Arcrun#8 Phase B 驗收_
Leo commented 2026-07-06 06:06:16 +00:00
Author
Owner
Copy Link
Copy Source

[總管] ✅ 已修+部署+驗（owner_id/entry_type 過濾）

根因：不是 app 對不齊——semanticSearch 的 filter 接線與 embedOnWrite 寫入 metadata 本來就對（實查 e_05c676f1 metadata=owner_id:"leo"）。真兇＝arcrun-kbdb-embed Vectorize index 從沒建任何 metadata index（metadata_index/list 回 []）。CF Vectorize v2：要 filter 某 metadata 欄必須先建該欄 index，否則帶過濾一律 0 命中。第二層：metadata index 只索引「建後 upsert」的向量→既有 45 筆需 reindex。

修（main commit befc63c）：① cli/deploy.ts 加 ensureVectorizeMetadataIndexes()（部署時冪等建 owner_id/entry_type/source，以後不再踩）② embed.ts/routes/embed.ts 加 reindex+offset，POST /embed/backfill {reindex:true} 重推既有向量讓新 index 收錄（守鐵律：不動表/走API/零SQL）③ 6 tests pass。

部署：CF API 建 3 index → wrangler deploy leo21c（Version 17b434bb，未污染官方 D1）→ reindex processed:45 remaining:0。

驗收（curl，修前0→修後）：owner_id=leo 0→20；entry_type=graph_node_gloss→20、wiki_card→3；組合→20；owner_id=nobody→0（真過濾）。Arcrun#9 收件夾 per-owner/類型語意解鎖。

⚠️ 另案（非本症狀，已停手不硬幹）：source 過濾對現有資料回 0——所有 source 值 89–91 bytes > Vectorize string index 64-byte 上限（平台限制）。修需改「存短/hash source 鍵」＝schema 設計變更，另案等總管定。owner_id/entry_type 皆短值不受限、已正常。收件夾用 project(短值) 過濾不受此影響。

**[總管] ✅ 已修+部署+驗（owner_id/entry_type 過濾）** **根因**：不是 app 對不齊——`semanticSearch` 的 filter 接線與 `embedOnWrite` 寫入 metadata 本來就對（實查 `e_05c676f1` metadata=`owner_id:"leo"`）。真兇＝`arcrun-kbdb-embed` Vectorize index **從沒建任何 metadata index**（`metadata_index/list` 回 `[]`）。**CF Vectorize v2：要 filter 某 metadata 欄必須先建該欄 index**，否則帶過濾一律 0 命中。第二層：metadata index 只索引「建後 upsert」的向量→既有 45 筆需 reindex。 **修**（`main` commit `befc63c`）：① `cli/deploy.ts` 加 `ensureVectorizeMetadataIndexes()`（部署時冪等建 owner_id/entry_type/source，以後不再踩）② `embed.ts`/`routes/embed.ts` 加 `reindex`+`offset`，`POST /embed/backfill {reindex:true}` 重推既有向量讓新 index 收錄（守鐵律：不動表/走API/零SQL）③ 6 tests pass。 **部署**：CF API 建 3 index → `wrangler deploy` leo21c（Version `17b434bb`，未污染官方 D1）→ reindex processed:45 remaining:0。 **驗收（curl，修前0→修後）**：`owner_id=leo` 0→**20**；`entry_type=graph_node_gloss`→20、`wiki_card`→3；組合→20；`owner_id=nobody`→0（真過濾）。**Arcrun#9 收件夾 per-owner/類型語意解鎖。** **⚠️ 另案（非本症狀，已停手不硬幹）**：`source` 過濾對現有資料回 0——所有 source 值 89–91 bytes > Vectorize string index **64-byte 上限**（平台限制）。修需改「存短/hash source 鍵」＝schema 設計變更，另案等總管定。owner_id/entry_type 皆短值不受限、已正常。收件夾用 `project`(短值) 過濾不受此影響。
Leo commented 2026-08-09 13:08:33 +00:00
Author
Owner
Copy Link
Copy Source

✅ 結案（2026-08-09 逐票查核）

這張票描述的問題現在已經不存在。

證據
語意查詢加 owner_id/entry_type 過濾不再回 0。commit `befc63c` 自證修復，並有 leo21c 實測紀錄。

查核方式：讀現行程式碼實證，非讀票面推測。總管另抽驗過同批中三張（#5／#58／#59），全部屬實。

如果我判錯了，重開就是——關錯票的成本遠低於留著一堆假的待辦，而假待辦會讓 leo 看不出還剩什麼。

## ✅ 結案（2026-08-09 逐票查核） 這張票描述的問題**現在已經不存在**。 **證據** 語意查詢加 owner_id/entry_type 過濾不再回 0。commit \`befc63c\` 自證修復，並有 leo21c 實測紀錄。 查核方式：讀現行程式碼實證，非讀票面推測。總管另抽驗過同批中三張（#5／#58／#59），全部屬實。 如果我判錯了，重開就是——**關錯票的成本遠低於留著一堆假的待辦**，而假待辦會讓 leo 看不出還剩什麼。
Leo closed this issue 2026-08-09 13:08:34 +00:00
Leo commented 2026-08-09 13:12:02 +00:00
Author
Owner
Copy Link
Copy Source

[總管·票務複驗 2026-08-09 晚] ✅ 關票——問題已不存在，證據是我自己跑出來的。

befc63c fix(kbdb/embed): 語意查詢 metadata 過濾根因修復（Arcrun#11） —— 加了在部署時冪等建 owner_id／entry_type／source 三個 Vectorize metadata index，commit 訊息附 leo21c 實測「修前 0 → 修後命中」。

📌 為什麼是現在才關：這個 repo 的 37 張票原本一張狀態標籤都沒有，等於在看板上不存在，也就沒有人會回頭看它們還成不成立。今晚做了一次全面驗傷，只有實際跑指令驗到問題真的消失的才關；查不出來的一律留著並標明卡在哪。
如果我判錯了（例如你要的其實比程式碼裡這些更多），直接重開這張票，我不會有意見。

[總管·票務複驗 2026-08-09 晚] ✅ **關票——問題已不存在，證據是我自己跑出來的。** `befc63c fix(kbdb/embed): 語意查詢 metadata 過濾根因修復（Arcrun#11）` —— 加了在部署時冪等建 `owner_id`／`entry_type`／`source` 三個 Vectorize metadata index，commit 訊息附 leo21c 實測「修前 0 → 修後命中」。 --- 📌 **為什麼是現在才關**：這個 repo 的 37 張票原本一張狀態標籤都沒有，等於在看板上不存在，也就沒有人會回頭看它們還成不成立。今晚做了一次全面驗傷，**只有實際跑指令驗到問題真的消失的才關**；查不出來的一律留著並標明卡在哪。 如果我判錯了（例如你要的其實比程式碼裡這些更多），直接重開這張票，我不會有意見。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
p
high
高——擋住交付或有時間壓力
p
low
低——想做，但晚一點沒關係
s
backlog
驗過了、確定要做，但還沒排進任何 sprint（wishlist／功能需求／待規劃）
s
doing
進行中——現在有人在做
s
pending
卡住——等外部/等人，不是沒人做
s
stage
已推上 stage，等 leo 去 youlin 的 stage 環境驗收（出貨流程第⑤步）
s
todo
待辦——已進池子，還沒開工
s
triage
新進來的，還沒驗傷——還沒決定要不要做
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
oscar Leo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Leo/Arcrun#11
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?