全部場數

060 · 五十萬顆感測器逼瘋 LLM

Phaidra 工程師拆解如何用樹狀索引與結構化查詢，讓 LLM 面對數十萬顆設備時仍能精準回答查詢。

2026-07-1216:24Raahul Singh、Vanč Levstik（Phaidra）Agent評估開發工具模型看原片

原標題：Semantic Blindness: 500,000 Sensors Confused an LLM - Raahul Singh & Vanč Levstik, Phaidra

重點摘要

  • 語意失焦的根源Phaidra 幫資料中心客戶做能理解自身設備的 AI agent，但規模一大，LLM 的 context window 很快被塞滿，輸出大量相似設備名稱時還會觸發內建的 frequency penalty 而中斷。
  • naive 解法都撐不住把設備切片後平行丟給多個 LLM，會出現召回率差、憑空生出不存在的幻覺設備、也會悄悄漏掉真實設備；向量嵌入面對只差一兩個字元的名稱（如 chiller 6 與 chiller 7）也分不清楚。
  • 用樹狀深度取代規模AI factory 的設備天生是階層結構（data center、data hall、aisle、row、rack、GPU），深度成長得很慢、寬度成長得很快，系統應該跟著 tree depth 縮放，而不是跟著設備總數縮放。
  • LLM 只規劃、不搜尋讓 LLM 把模糊查詢轉成結構化輸出（要收集什麼、範圍在哪、篩選條件是什麼），真正的搜尋交給後端預先建好索引的子樹，靠集合運算取得精準結果。
  • 正式數據對比懸殊舊架構在 64 顆 GPU 時正確率有 80%，拉到 460,000 顆掉到約 30%；新架構同樣規模下維持 100% 正確率，單次評測 token 用量也從 1.16 億降到 39 萬。
  • 借 Karpathy 的框架反著走傳統軟體是從 Software 1.0（確定性程式碼）走向 3.0（prompt 驅動的行為），但新的 AI-native 系統反而是先做出 3.0 demo，碰到真實規模後再把資料本身有結構的部分收斂回 1.0。

時間軸

時碼點下去會跳到影片的那一段。

時碼段落重點
00:00開場自介Raahul Singh（staff AI Research Engineer）與 Vanč Levstik（Senior Engineering Manager）介紹 Phaidra，要分享給 LLM 五十萬個 sensor 名稱時發生的語意混亂問題。
00:32使用情境與命名亂象客戶查詢五花八門，但業界沒有統一的設備命名規範，從簡單好懂到幾乎無法理解的編碼都有。
01:27demo 與規模的落差小規模時讓 LLM 直接看全部設備名稱還行，但到 gigawatt 級工廠（40 萬顆以上 GPU）context window 很快被塞滿，產品不能像 demo 一樣偶爾失敗。
02:03向量嵌入的侷限把設備名存進 vector embedding 也解決不了問題，只差一兩個字元的名稱相似度太高，召回準確度差，還會觸發 LLM 的 frequency penalty 而中斷輸出。
03:23分片平行呼叫失敗把設備切片後平行丟給多個 LLM 處理，反而召回率差、生出不存在的幻覺設備，也會漏掉真實設備，對關鍵任務系統是不能接受的風險。
04:12用樹狀深度取代規模團隊發現 AI factory 的實體設備天生是階層樹狀結構，深度成長得很慢、寬度成長得很快，系統設計應該跟著 tree depth 縮放。
05:25壓縮上下文、LLM 只規劃把樹狀結構摘要成固定幾層就能到葉節點的路徑，讓 LLM 拿到的 context 大小接近常數；同時讓 LLM 只負責把模糊查詢轉成結構化輸出，不用自己比對搜尋。
07:55預先索引與模式比對後端依位置與彼此關係預先建好子樹索引，靠集合運算取得精準結果；面對非常模糊的查詢，則讓 LLM 找出命名或資料裡的 pattern，而不是整份名單塞給它。
09:54端到端查詢流程從使用者查詢到 planner LLM 產生搜尋計畫，再交給確定性 resolver 做索引與集合運算得出結果，整個流程只有兩三步，不是會一直循環的 agentic loop。
10:40上線前的評測方法Vanč Levstik 接手說明，上線前用相同模型與資料對新舊兩套架構做三輪測試，目標是證明新架構真的撐得住生產環境的邊界案例。
11:18準確度與成本數據舊架構在 64 顆 GPU 時正確率 80%，拉到 460,000 顆剩約 30%；新架構同規模下維持 100% 正確率，token 用量從 1.16 億降到 39 萬，單次查詢成本固定在約 9,000 tokens。
12:38Karpathy 框架與結語借用 Karpathy 對 Software 1.0 與 3.0 的分類，團隊觀察到傳統軟體從 1.0 走向 3.0，但新創的 AI-native 系統反而是先做出 3.0 demo，再把有結構的部分收斂回 1.0，讓 LLM 保留在真正需要判斷的地方。

值得記的話

名詞與人物

Phaidra這場演講主角公司，幫資料中心與 AI factory 客戶做能理解自身設備狀態的 AI agent。
semantic blindness這場演講定義的問題：LLM 面對數量龐大、名稱相近的設備時失去分辨能力。
frequency penaltyLLM 內建機制，重複輸出相似詞元時會被抑制，導致列舉大量設備名稱時輸出中斷。
tree depth團隊提出的擴展方向，讓系統效能跟著設備階層的深度成長，而不是跟著設備總數成長。
pre-indexed subtree依位置與設備關係預先建好的索引子集合，讓後端能用集合運算快速找到答案。
Software 1.0 / 3.0借用 Karpathy 的分類，1.0 是確定性程式碼，3.0 是靠 prompt 驅動 LLM 的行為。
Raahul SinghPhaidra 的 staff AI Research Engineer，負責設計這場講的架構解法。
Vanč LevstikPhaidra 的 Senior Engineering Manager，負責驗證架構在生產環境下是否可靠。

延伸

  • 講者引用 Karpathy 對 Software 1.0 與 3.0 的分類框架，但沒有進一步說明他原本演講的完整脈絡。
  • 業界目前沒有統一的設備命名規範，這場只提到幾種常見的命名方式，沒有說明是否有標準化的努力。