triAIge：評審報告

triAIge 是一套在邊緣運算上執行的 AI 交接系統，處理台灣急救最前面的幾分鐘。救護車上的救護員（EMT）把看到的情況說出來或打字輸入，系統就填寫消防局的救護紀錄表，並傳到急診（ED）。檢傷護理師打開的是預先填好、附上建議檢傷級數的評估表，醫師拿到的是交接摘要，以及一份附出處的鑑別診斷與建議檢查。

這份報告的讀者大概只會讀一次，所以每一項說法都附上檔案出處，路徑都相對於 repository 根目錄；repository 裡沒有的數字，報告也不寫。

這是黑客松原型，不是經過臨床驗證的產品。哪些有量測、哪些沒有，第 7 節逐項說明。

1. 目前完成了什麼？

web app 的線上版：https://triaige.wayneh.tw 與 https://triaige-demo.vercel.app（README.md、infra/inventory/group_vars/servers.yml 的 CORS 清單）。展示用的病人都是虛構的；/internal 的資料只存在瀏覽器。

2. 要解決什麼問題？

在台灣，消防局的救護員一邊處置病人，一邊在紙本格式的救護紀錄表上記錄；到了急診，同樣的問題又被問一次。急診檢傷護理師要從台灣急診檢傷與急迫度分級量表（Taiwan Triage and Acuity Scale，TTAS）的五個級數中選一個，醫師則要很快掌握關鍵事實。docs/product/triaige.md §2 列出這個流程出問題的地方：

• 救護員在壓力下打字或手寫，資訊因此晚到，或重複出現。
• 到院時，急診又重問一次主訴、病史、過敏與生命徵象。
• 院前資料、檢傷資料與醫院病歷分散在不同的系統。
• 醫師需要的是主要問題、危險徵象、已給的處置、生命徵象趨勢、病史、用藥、過敏與資訊缺口。

參考表單是救護紀錄表與 TTAS 判定標準，兩者都是公開的政府文件（docs/references/、README.md）。

產品的定位很明確：AI 只負責擷取、整理與提出建議，凡是有公開規則可循的臨床決定，都由確定性規則處理（docs/product/triaige.md §3.3）。AI 不設定檢傷級數；級數由護理師送出，改動建議級數時要附上理由（docs/api/data-model.md §10）。鑑別診斷、急救責任醫院分級與 AI 整理的摘要，都只是供人參考的選項，不是診斷，也不是醫囑（server/src/triaige_server/llm/prompt_sets/ems_compact/differential.py、docs/api/openapi.yaml 的 AiHandoffSummary）。

3. 系統從頭到尾做了哪些事？

flowchart LR
  EMT["救護員平板：救護端 app"] -->|"一句話 = 一則訊息"| API["DGX Spark 上的 FastAPI 伺服器"]
  API --> SCH["排程器：同時最多 3 個模型呼叫，分 P0、P1、P2、閒置四級"]
  SCH --> NAT["NeMo Agent Toolkit 工作流程"]
  NAT --> LLM["透過 vLLM 執行的 Nemotron 3 Super"]
  LLM --> CHK["確定性檢查"]
  CHK --> REC["PostgreSQL 裡的救護紀錄：每個欄位的來源、證據、歷程"]
  REC -->|"推播事件"| EMT
  REC -->|"送出"| NURSE["急診檢傷護理師：預先填好的評估表"]
  NURSE --> TTAS["TTAS 規則引擎：建議級數與理由"]
  TTAS -->|"護理師決定並送出"| DOC["醫師端：規則版摘要、AI 整理、鑑別診斷"]
  NAT -.->|"鑑別診斷 agent 搜尋"| KB[("知識庫 kb_passages")]
  KB --> NAT

1. 接收輸入。 救護員一次送出一句話，並標上說話者（救護員、病人、旁人）。伺服器先存下這句話、立刻回應，再在背景執行 AI，所以畫面不必等模型（docs/specs/2026-10-13-backend/design.md〈Extraction flow〉）。
2. 擷取欄位。 每一句只呼叫一次模型（現場擷取關閉推理），回傳 12 個紀錄欄位的 JSON：年齡、性別、主訴、體溫、心跳、呼吸速率、SpO₂、收縮壓與舒張壓、疼痛、過去病史、重點用藥類別，以及藥物過敏（docs/specs/2026-10-13-backend/spec.md §1.3、docs/api/field-mapping.md §6）。每一句的提示詞會帶上最多三句前文，以及紀錄上已有的內容，所以「不對，是一百三」能更正到正確的那個值（eval/README.md〈R1 上下文（X1）〉）。
3. 在欄位上複查，不用阻斷式對話框。 救護員、病人與旁人說的內容走同一套寫入規則：寫進空欄位，或取代還沒複查的值。這個欄位會標成「待複查」，附上來源句與說話者，救護員可以確認、修改、改選另一個候選值、清除或復原。人填的值或已確認的值不會被覆蓋，AI 給的不同值以替代選項列在旁邊。說話者辨識信心低的救護員句子也照同一套規則寫入，並標明來源。缺漏的必填欄位與 TTAS 參考級數固定顯示在一個區域，不用彈出視窗（docs/api/data-model.md §2、server/src/triaige_server/engine/record.py、docs/specs/2026-10-14-inline-review/plan.md）。
4. 救護端的背景建議。 兩種建議都是補充：失敗只記稽核，不擋任何操作，也不算「AI 暫停」。
   • 建議追問。 對話停了 8 秒、而且擷取都結束，伺服器讀一次案件，請模型列出救護員還該問的事（發病時間、疼痛分數、過去病史、過敏、是否懷孕、血糖）。每個頻道最多同時開 3 題；欄位已有值的不開，忽略過的不會再回來。問題放進既有的建議清單，不彈出、不發聲（server/src/triaige_server/ai/followups.py、engine/followups.py、task_rules/followup_checks.py）。
   • 急救責任醫院分級。 紀錄表欄位變動後，模型讀已填欄位，建議重度、中度或一般急救責任醫院，並附一句理由與引用的欄位；欄位標「待複查」，救護員可以改。臨床下限由規則加上：到院前檢傷 1–2 級、危急個案、心電圖疑似 STEMI 任一成立時，模型建議的「一般」一律改成「中度」。這個欄位只給救護端參考，不進送出的快照，急診看不到（server/src/triaige_server/engine/hospital_level.py、task_rules/hospital_level_checks.py）。
5. 檢傷。 紀錄送出後，護理師看到院前紀錄已預先填入檢傷表；救護端沒人確認過的欄位會標成「未複查」，並附上來源。TTAS 引擎算出建議級數，每一項理由都附上觸發的規則，需要人判斷的條件（例如「有沒有休克？」）會列出來，引擎不替人決定（docs/api/data-model.md §10、server/src/triaige_server/engine/ttas.py）。護理師可以在檢傷畫面打一段話：一次模型呼叫把它擷取成檢傷欄位的提案，掛在那則訊息上，護理師按「套用」才寫入；只提案白名單欄位與合法的值，數值必須是原文裡寫出的數字，護理師已經填的值不會被蓋掉。護理師端也有建議追問，例如 TOCC 還沒問的題目（server/src/triaige_server/ai/nurse_notes.py、engine/nurse_notes.py、task_rules/nurse_note_checks.py）。
6. 醫師摘要。 目前狀況、院前經過與危險徵象，由規則從紀錄與檢傷資料組出，每一句都附上來源欄位的參照（server/src/triaige_server/engine/views.py）。規則版旁邊多一塊「AI 整理」：救護端送出與檢傷送出之後，模型把送出的紀錄表、備忘與檢傷評估改寫成最多 6 句，每句不超過 160 字，並附來源。確定性檢查會丟掉來源不存在或沒有內容的句子、數字不在引用欄位裡的句子，以及含診斷、治療或劑量用語的句子。呼叫失敗或檢查不過時，畫面照實標示失敗，規則版照常顯示；不重試，也沒有備援模型（server/src/triaige_server/engine/ai_summary.py、task_rules/summary_checks.py）。
7. 鑑別診斷。 案件送出（之後內容有變的再送出也算）與檢傷送出之後，後端在背景執行一個會呼叫工具的 agent（NeMo Agent Toolkit 的串流函式，在同一個行程內執行）。它讀的是案件事實：最新送出的紀錄、檢傷評估、已確認的身分與院內既往資料裡填了值的欄位，每個欄位有一個編號（f1、f2…）。模型開推理，最多搜尋 4 次知識庫（工具 search_knowledge，可限定來源，每次回傳 1–8 段，每段給模型最多 1,800 字），讀完段落後回答兩份清單：常見的前 5 項，以及最致命的前 5 項（漏掉會致命或致殘，即使可能性低也要列）。每一項包含診斷名稱、支持的事實、不符合或還缺的資料、2–4 項建議檢查，並用事實編號與段落編號標出依據（server/src/triaige_server/ai/nat_differential.py、llm/prompt_sets/ems_compact/differential.py）。
   • 確定性檢查（task_rules/differential_checks.py）：事實編號必須對得到案件裡填了值的欄位，對不到的拿掉，一個都不剩的項目整個丟掉；段落編號只認這一次搜尋真的回傳過的，並換成「來源、章節、頁碼」的出處字串，書中原文不會進輸出；每份清單最多 5 項，重複的診斷丟掉；診斷名稱含百分比，或文字裡出現機率、信心分數的項目整個丟掉；任何一份清單沒有合格的項目，整次就失敗。失敗時畫面明說，不重試，也沒有備援模型。
   • 排程。 優先級是最低的「閒置」：只在沒有任何其他 AI 工作時才開始，即時句子一到就取消、排回隊伍重跑；等了 60 秒或被取消 3 次，就升成一般背景工作。一次執行上限 600 秒（server/src/triaige_server/ai/scheduler.py、ai/service.py、llm/profiles/nemotron_3_super/__init__.py）。
   • 耗時。 約 1–3 分鐘（推理開啟；實測 70–110 秒，正式機 UAT 一次約 2.5 分鐘）。
   • 醫師看到什麼。 每一步（搜尋了什麼、讀到哪些來源、章節與頁碼，最後整理成清單）即時經 SSE 事件 differentials.updated 推給醫師，護理師與救護員收不到。「看診區」轉場會逐步列出這些步驟；整理中或失敗時，醫師摘要仍保留上一次通過檢查的結果，並標明狀態（server/src/triaige_server/engine/differentials.py、docs/api/asyncapi.yaml、web/src/hooks/use-differentials-progress.ts）。

救護端與急診端的畫面共用同一組元件。根路徑連真伺服器，/internal 連瀏覽器內的模擬後端，兩邊的案件規則相同，並由漂移測試確保兩個引擎一致（docs/architecture/README.md §2、server/tests/unit/test_engine_parity.py）。

4. 用了哪些 <帳號> 技術？

模型、伺服器與資料庫都跑在同一台 Spark 上，推論不使用任何雲端模型（docs/product/triaige.md §3.2）。

鑑別診斷用的知識庫

知識庫是 PostgreSQL 的 kb_passages 表，共 3,714 段，來自三個來源。檢索是 PostgreSQL 全文檢索：英文用 english 設定的 tsv（標題權重高於內文），中文沒有空白斷詞，匯入與查詢時都切成相鄰兩字，存進 tsv_zh；查詢字串含中文字就用 tsv_zh，否則用 tsv；排序用 ts_rank_cd。agent 只依賴 KnowledgeBase.search 這個介面，之後換成向量檢索，agent 與提示詞都不用改（server/src/triaige_server/kb.py、migrations/003_kb_search.sql）。三份索引先在開發機用 eval/scripts/*_rag.py 建好，再由 server/scripts/export_kb.py 合成一個檔案，部署時匯入 Spark 上的資料庫（-e triaige_kb_import=true，infra/README.md〈知識庫〉）。檔案含版權內容，只放 private/，不進 git。

31 份指引的清單。 完整清單（PMCID、授權）在 private/guidelines/fetched.json（不進 git）；repo 裡有候選來源清單 eval/guidelines/sources.json（簡稱、PMCID、主題）。依主題：

• 胸痛：ANMCO-SIMEU 2016、Brazilian Chest Pain ED 2025、SIRM-SIC 2025
• 呼吸、給氧與肺栓塞：GOLD 2023、BTS Oxygen 2017、TSANZ Oxygen 2015、BTS Outpatient PE 2018、PERT Consortium PE 2019
• 心衰竭：KSHF Acute HF 2023
• 敗血症與感染：J-SSCG 2020、SEOM Febrile Neutropenia 2018
• 神經：ED Delirium GRADE 2026、EUSEM Syncope 2024、Acute Vertigo ED Consensus 2024
• 消化與腹部：WSES 腸繫膜缺血 2022、WSES 消化性潰瘍 2020、ESGE 非靜脈曲張上消化道出血 2018、ESGE 靜脈曲張出血 2020、Asia-Pacific 非靜脈曲張上消化道出血 2018、WSES 胰臟炎 2019、WSES 膽囊炎 2016、WSES-SICG 高齡膽囊炎 2017、BSG 腹水 2021
• 內分泌與代謝：高血糖危象共識 2024（Diabetologia）、JBDS HHS 2023、ESE-ES 腎上腺功能不全 2024、ED 高血鉀共識 2021
• 創傷：歐洲創傷出血指引 2023、WSES 高齡創傷 2023、WSES-AAST 胸部創傷 2025、Scandinavian 頭部外傷 2013

（以上資料來源與數字：eval/README.md〈Tintinalli 檢索（RAG）〉、〈開放指南索引〉、〈臺北市到院前救護手冊檢索〉，docs/references/ems-protocol-taipei/README.md，段落數由 server/scripts/export_kb.py 匯出的檔案逐來源計數。）

5. 模型換版時，程式怎麼不受影響？

模型更新得很快，為某一個模型做的調整，不該分散在整個程式裡。現行模型的所有設定都集中在套件 server/src/triaige_server/llm/ 的 ModelProfile 物件裡，包括提示詞、取樣參數、怎麼關閉推理、怎麼把模型的回覆整理成一個 JSON 物件、怎麼讀取對數機率、逾時，以及同時請求數（docs/architecture/README.md §6）。

flowchart TB
  API["api：路由、推播事件"] --> AI["ai：排程、NAT 黏合、寫入閘門"]
  API --> ENG["engine：案件規則、TTAS"]
  AI --> ENG
  AI --> TR["task_rules：合格答案長什麼樣"]
  AI --> LLM["llm：ModelProfile、提示詞、回覆清理、對數機率評分"]
  AI --> KB["kb：知識庫檢索"]
  ENG --> TR
  LLM --> TR
  INFRA["infra：模型部署手冊與變數"] -.-> LLM

• 換模型只需要改 llm/，加上 infra/ 裡那個模型的部署腳本（playbook）。步驟寫在 docs/architecture/README.md §9；infra/inventory/group_vars/servers.yml 裡的 triaige_model_profile、llm_served_name 與 llm_port，同時提供給伺服器與 vLLM 的部署腳本使用。
• task_rules/ 放的是任何模型都需要的檢查（數值範圍、允許的詞彙、翻譯檢查，以及各項 AI 輸出的檢查），只用標準函式庫；engine/ 與 llm/ 都不能 import ai/。
• 這條邊界由測試強制，不靠團隊慣例：server/tests/unit/test_architecture.py 禁止往上層 import，也禁止 llm/ 以外出現模型名稱、取樣參數與端點字串，而且沒有例外清單（docs/architecture/README.md §3）。
• 這個流程實際跑過一次：2026-10-18 評估 Nemotron 3.5 Super VL。事先宣告的標準上三項都比 Super 差（11 個結構化欄位 F1 0.997 對 0.999，主訴 F1 0.525 對 0.547，幻覺欄位 2/402 對平均 0.33），逐句重播的重複填入率是 Super 的 5 倍（8.7% 對 1.6%）；它比較快（整段口述延遲中位數少 23%）。所以正式環境維持 Super，評估前後正式環境的 AI 約 57 分鐘不能用（eval/results/nemotron-3-5-super-vl-2026-10-18/README.md）。
• 限制：提示詞是針對 Super 調整的，對數機率的測試資料（fixture）也只在 Super 上錄過，換成別的模型會得到什麼分數，目前沒有證據。換模型的步驟規定，換之前要依事先宣告的評測標準（yardstick）完整重新評測。

6. 安全上做了哪些設計？

還不能算是安全檢查的部分：Guardrails 自我檢查護欄（關閉），以及信心等級的顯示（關閉）。

7. 評測結果與限制

用的是什麼資料？

請先讀這一段。eval/README.md〈誠實規則〉要求我們這樣描述資料：

• 133 張案例卡來自公開的 MIMIC-IV-ED demo，是美國急診 47 位病人的救護車到院紀錄。生命徵象是檢傷站量的，不是在救護車上量的（eval/README.md〈目前產出〉）。
• 資料裡沒有院前的文字或語音。繁體中文的口述稿由模型寫成，經過程式檢查；擷取這些口述稿的也是同一個模型家族。沒有臨床人員審閱過案例卡或口述稿。
• 所以下面的數字說明的是這條流程從乾淨、由模型寫成的中文裡擷取欄位的能力，不代表臨床驗證、對吵雜語音的耐受度，也不代表在台灣救護案例上的表現。
• 大多數結果只跑一次，而 temperature 0 的呼叫並不確定：一次 A/A 對照在 163 對句子中，有 17 對文字不同（eval/results/choice-confidence-latency-2026-10-14/README.md）。千分之幾的差異是雜訊。

量到了什麼？

哪些還沒有量？

• TTAS 準確度。 規則集是 TTAS-adult@105-draft；eval/labels/ 裡的草稿標記是 ai_draft_unreviewed，不能當作標準答案（eval/README.md）。
• 鑑別診斷。 評分流程已經有了，但還沒有醫師的標準答案，所以沒有數字（eval/README.md〈鑑別診斷評測〉）。線上的 agent（最多搜尋 4 次、搜尋 PostgreSQL 知識庫）也沒有準確度數字；有單元測試的是確定性檢查，檢查通過只代表來源與格式合格，不代表內容正確。
• AI 整理的摘要、建議追問、護理師輸入擷取、急救責任醫院分級。 這四項階段 2 功能沒有保留集評測，只有確定性檢查與單元測試。
• 檢索的線上品質。 三個來源合併後的全文檢索，沒有量過召回率。
• 真實語音、真實救護車環境、台灣案例、兒童。 資料裡沒有兒童案例（eval/README.md〈目前產出〉）。
• 真實救護員或護理師使用時的易用性。

8. 怎麼部署？

架構是：平板或瀏覽器連到 web app（https://triaige.wayneh.tw、https://triaige-demo.vercel.app），再透過 Cloudflare Tunnel 連到 API https://triaige-api.wayneh.tw。對外服務跑在比賽現場借用的 ASUS GX10（infra/inventory/host.yml 裡的第二台主機）；第一台 Spark 是評測與先前部署用的機器，這份報告的 soak 與評測結果都在那一台量。在借用的這台上，triaige-server（port 8100，記憶體上限 1536 MB）連到 PostgreSQL（port 5433，上限 2 GiB，因為知識庫的索引需要空間，其他主機預設 512 MB），以及執行 Nemotron 3 Super 的 vLLM（port 8000）（infra/inventory/group_vars/servers.yml、docs/architecture/README.md §10）。

• 每個服務一個指令。 Ansible 部署腳本 infra/playbooks/deploy-nemotron-super.yml、deploy-triaige-server.yml、deploy-cloudflared.yml 與 deploy-dashboard.yml 先以 --check --diff 試跑。架構、GPU、Docker runtime 或可用記憶體（至少 100 GB）不符時，事前檢查會中止這次部署（infra/README.md）。
• 版本固定，可以重現。 vLLM 映像標籤、服務參數、PostgreSQL 映像 digest 與記憶體上限都寫在 infra/inventory/group_vars/servers.yml。換到另一台機器，只要在 infra/inventory/host.yml 加一台主機、在 host_vars/ 放它的連線資料；借用的這台就是這樣加進來的。第一次啟動會下載約 75 GiB 的權重（infra/README.md）。後端映像在主機上原生建置，標籤是部署當時的 git revision。
• 連線。 模型端點沒有 API 金鑰，所以只開放給本機與 Tailscale 介面（防火牆擋不住 Docker 開放的 port，infra/README.md 記錄了這項測試）。後端只聽本機，從外部只經 Cloudflare Tunnel 連線；這台機器的 Tailscale Funnel 沒有取得公開的 DNS 記錄，所以改用 Tunnel（infra/inventory/host_vars/）。
• 知識庫匯入。 知識庫的匯出檔不進 git；部署時加 -e triaige_kb_import=true，playbook 把檔案複製到主機並在後端容器內匯入，可重複執行，輸出每個來源的段落數（infra/README.md〈知識庫〉）。
• 功能開關。 Spark 上開啟鑑別診斷與急救責任醫院分級，關閉案件備忘整理、Guardrails 自我檢查與路由分類器；同時模型呼叫數是 3；AI 整理、建議追問、護理師輸入擷取、對數機率評分與主訴翻譯用程式的預設值（開啟）（infra/inventory/group_vars/servers.yml、server/src/triaige_server/config.py）。
• 維運。 後端把每一次模型請求寫成一行 JSON（任務、token 數、延遲、結果、輸入輸出摘錄；TRIAIGE_LLM_CALL_LOG，3 個檔，每個最多 20 MB），維運儀表板（infra/dashboard/）讀它。公開的唯讀版在 https://triaige-ops.wayneh.tw：沒有測試面板，不顯示行程的指令列與案件編號，但會顯示 LLM 輸入輸出的摘錄（server/src/triaige_server/ai/call_log.py、infra/README.md）。
• Web。 web/ 在 bun run check 通過後，由 GitHub Actions 從 demo 分支部署到 Vercel（README.md）。/ 連哪個後端，由建置時的 NEXT_PUBLIC_API_BASE_URL 決定（web/src/api/config.ts）。

9. 已知限制與下一步

限制：

1. repository 裡沒有語音辨識器（§1），評測的是文字路徑。
2. 評測資料是美國急診的案例卡，加上模型寫的口述稿，沒有臨床人員審閱（§7）。
3. TTAS 規則集是草稿，涵蓋第一層的生命徵象調節變數與疼痛；依主訴而定的判定標準還沒有資料來源（server/src/triaige_server/engine/ttas.py）。每個級數仍由護理師決定。
4. 階段 2 的 AI 功能（鑑別診斷、AI 整理、建議追問、護理師輸入擷取、急救責任醫院分級）沒有保留集評測，只有確定性檢查與單元測試（§7）。鑑別診斷要 1–3 分鐘，而且優先級最低：伺服器忙時會往後排，被取消就重跑，最長 600 秒；失敗時醫師看到明確的失敗原因與上一次的結果，不會有備援。
5. 信心等級不會顯示給使用者。門檻已在保留集上校準過兩次（2026-10-17、2026-10-18），第一次保留集沒有達到精確度目標，第二次達標，但 τ 分不出差別，所以 enabled=false 維持不變（eval/results/choice-confidence-2026-10-17/、choice-confidence-2026-10-18/summary.md）。
6. Guardrails 自我檢查與路由分類器目前關閉，因為兩者都要在以秒計的延遲預算裡，多一次模型呼叫；案件備忘整理也關閉，等保留集通過再打開。
7. 對外服務只有一台機器，沒有備援。同時模型呼叫上限在 Spark 上是 3（程式預設是 2）：舊版 vLLM（v0.28.0）在三條同時呼叫時曾出現一次原因不明的 CUDA 錯誤；v0.31.0 的 soak 沒有再出現，但不能因此排除這個問題，而且 soak 是在第一台 Spark 上跑的，借用的這台沒有重跑（docs/specs/2026-10-13-ai-routing/soak-results.md、server/src/triaige_server/llm/profiles/nemotron_3_super/__init__.py）。
8. 紀錄裡的主訴保留英文。中文顯示採保守做法，像「up and down」這類片語，是已記錄的已知缺口（eval/complaint_zh/README.md）。
9. 知識庫的三個來源，兩個有著作權：Tintinalli's Emergency Medicine Manual（第 7 版）與臺北市到院前救護手冊。它們不進版本控制，但全文現在放在 Spark 的資料庫裡，供鑑別診斷搜尋；兩者的授權問題都還沒有解決（§4）。另有 16 份指引的 Creative Commons 授權是非商業或禁止改作。
10. 提示詞與對數機率 fixture 是 Nemotron 3 Super 專用的（§5）。
11. 知識庫共 3,714 段。Tintinalli 是 2012 年版，兒科章節沒有收；臺北市手冊是臺北市的作業程序，不是全國規範。

下一步，依優先順序：

1. 請臨床人員審閱標準答案、TTAS 規則集與翻譯檢查，並替鑑別診斷與其他階段 2 功能建立標準答案（docs/team-discussion-todo.md）。
2. 處理知識庫的授權：向臺北市消防局取得書面同意，並把 Tintinalli 換成醫院自行取得授權的知識庫（server/src/triaige_server/kb.py 的介面可換實作）。
3. 重新校準對數機率門檻，讓分級分得出差別，再顯示「高／需留意」等級（docs/specs/2026-10-14-inline-review/plan.md §15，C3）。
4. 依 docs/api/README.md §6 的規格，在平板的瀏覽器內做語音辨識。
5. 階段 2 剩下的項目：是否加向量檢索、NeMo Evaluator、沙箱（docs/specs/2026-10-13-backend/decision.md）。
6. 依 docs/architecture/README.md §9 的步驟評估下一個模型；上一個候選（Nemotron 3.5 Super VL）沒有通過。

10. 想查細節時，去哪裡找？