MetaScreener：多模型集成做系統性回顧摘要篩選，值不值得放進你的流程
AI-powered tool for efficient abstract and PDF screening in systematic reviews.
秒懂
- 它是什麼？
- MetaScreener 用多個開源 LLM 並行投票、再經校正與分層路由來決定文獻納入或排除，把不確定的案子交回人工。本文拆解它的四層架構、安裝路徑、成本假設，以及在什麼情況下它會是錯的工具。
- 適合誰用？
- 如果你已經在用 PubMed、Scopus 匯出的 .ris 或 .bib 做篩選，而且團隊願意把 Tier 3 的人工複核當成流程的一部分而不是例外，MetaScreener 值得裝起來試跑一個小型 review。若你的檢索結果只有幾十篇、或你的機構不允許把未發表的摘要送到 OpenRouter 這類第三方 API，這套工具的成本與合規負擔大於收益，直接用 Excel 加兩名 reviewer 更快。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 96 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是篩選階段的工時，不是整個回顧流程
系統性回顧最耗人的環節通常不是檢索，而是標題與摘要篩選。檢索策略跑一次可能吐出數千筆記錄，兩位 reviewer 各自讀完、再解決歧異，這段時間往往以週計。MetaScreener 的定位很明確：README 把它描述為自動化系統性回顧的 screening phase，輸入是 PubMed、Scopus 等來源匯出的搜尋結果，輸出是每筆記錄的 include/exclude 決定加上信心分數。它不負責檢索策略的生成，也不負責最終的統合分析。
目標使用者是已經有明確 PICO、PEO 或 SPIDER 條件的研究團隊。README 的 Web UI 流程把 Criteria 放在第 0 步，可以讓 AI 從你的研究問題生成條件，也可以上傳既有條件，這個順序說明工具預設你已經想清楚要納入什麼。若你還在探索題目、條件會反覆改動，這套流程的價值會打折。
另一個容易被忽略的設計：README 明講 uncertain cases are routed to human review。它不是要取代 reviewer，而是要把 reviewer 的注意力集中到模型不確定的那批記錄上。這個定位決定了後面所有架構選擇。
四層 Hierarchical Consensus Network 的實際資料流
README 把管線畫成四層。第一層 Inference：4 個以上的 LLM 透過 API 並行處理每一筆記錄，支援的模型清單列了 15 個開源 LLM，經由 OpenRouter 呼叫，包括 DeepSeek V3、Qwen 3、Kimi K2.5 等旗艦層，以及 Gemma 3 27B、Mistral Small 4、Phi 4 等輕量層。
第二層 Rule Engine 分成兩類規則：hard rules 直接自動排除，soft rules 對分數施加懲罰。這裡的設計意圖是讓明顯不符條件的記錄不必等模型投票就先出局，省下 API 呼叫。第三層是 CCA 加 ECS，也就是 Calibrated Confidence Aggregation 與 Element Consensus Scoring。前者用 Platt 或 Isotonic 這類 post-hoc calibration 把模型的原始分數映射成機率，後者針對 P、I、C、O 逐元素計算跨模型的一致程度。
第四層 Decision Router 把結果分成四個 tier：Tier 0 是硬規則排除，Tier 1 高信心自動決定，Tier 2 中等信心自動決定，Tier 3 轉人工。這個分層是整個專案最值得注意的地方，因為它承認了單一門檻無法同時處理「明顯該排除」與「模稜兩可」兩種情況。
需要說清楚的是：README 沒有交代 CCA 的具體聚合公式，也沒有說明 Platt 與 Isotonic 各自在什麼條件下被選用。校準是這類工具最關鍵也最難驗證的環節，而目前的說明停留在方法名稱的層次。
安裝有三條路，先確認你走哪一條
pip 路線最短。README 給的指令是 pip install metascreener，接著 python -m metascreener，服務起在 http://localhost:8000。前置條件是 Python 3.11 以上，以及一組 OpenRouter API key。
Docker 路線不需要本機裝 Python。docker pull chaokunhong/metascreener:latest 之後，docker run -p 8000:8000 -e OPENROUTER_API_KEY="sk-or-v1-your-key-here" chaokunhong/metascreener 即可。若你的環境有容器規範，這條路少掉依賴衝突的風險。
從原始碼建置則需要 uv 與 Node.js 18 以上。README 的步驟是 git clone 專案、cd MetaScreener、uv sync --extra dev、python run.py，然後後端在 8000、前端在 5173。這條路會同時起 FastAPI 與 Vite 兩個 dev server，前端是 Vue 3。
API key 有兩種設定方式：在 Web UI 的 Settings 頁貼上，或設環境變數 export OPENROUTER_API_KEY。要注意的是模型選擇、門檻調整也都在 Settings 頁，README 沒有提供對應的環境變數或設定檔格式，這代表批次或無介面的自動化目前沒有文件化的路徑。
成本數字來自免費額度供應商，不能直接當預算
README 的定價表列了三種 preset：Balanced 用 4 個模型、約 $0.005 每篇；Precision 用 2 個 thinking 加 2 個 large 模型、約 $0.009 每篇；Budget 用 1 個 anchor 加 3 個 fast 模型、約 $0.003 每篇。總覽段落另外給了每篇 $0.003 到 $0.009 的區間。
這些數字的來源是 free-tier API providers，也就是免費額度供應商的費率。免費額度會變動，也會有速率限制，而速率限制直接影響並行度。管線第一層的價值建立在「多個模型並行」上，一旦被限流，實際吞吐會低於預期。
換算起來，一萬筆記錄在 Balanced 設定下約 $50。這個量級對多數研究團隊不成問題，真正的成本在人工複核 Tier 3 的工時，以及 PDF 全文篩選階段。README 提到全文篩選有 intelligent chunking，但沒有說明 chunk 策略或它對 token 消耗的影響，而全文的 token 量遠高於摘要。做預算時應該把摘要與全文分開估算，不要用同一個單價推。
可重現性的代價：temperature=0.0 與 seed=42 只鎖住一半
README 把 Full Reproducibility 列為賣點，具體做法是 temperature=0.0、seed=42，並對每個決定留下 audit trail。History 頁提供 session 層級的稽核軌跡與 decision provenance。
這個承諾有邊界。temperature 與 seed 是送到供應商的參數，但供應商端的模型版本可能在你不知情時更新，同一個模型名稱在不同時間點未必是同一組權重。README 沒有說明工具是否記錄模型版本或供應商回傳的 metadata。若稽核軌跡只記模型名稱而不記版本，半年後重跑同一份資料得到不同結果時，你無法從軌跡判斷差異來自哪裡。
另一個變數是校準。Platt 與 Isotonic 都是從資料擬合出來的映射，active learning 又會依人工回饋即時調整模型權重。README 說 human feedback loop recalibrates model weights in real time，這意味著同一份輸入在累積回饋前後會得到不同的信心分數。要重現某次篩選，你必須連同當時的校準狀態一起凍結，而 README 沒有描述這個狀態存在哪裡、怎麼匯出。fp-audit-protocol-v1.0 這個 release 名稱指向某種偽陽性稽核協定，但 README 沒有展開它的內容。
什麼時候它會是錯的工具
第一個情境是資料不能出境。這套工具的核心是把每筆記錄的標題與摘要送到 OpenRouter，再由 OpenRouter 轉到各家模型供應商。若你的回顧涉及未發表的臨床資料、受保密協議約束的產業文獻，或機構政策要求資料不得離開自有基礎設施，這條路直接不通。README 沒有提供本地模型部署的選項，15 個模型全部標明 via OpenRouter。
第二個情境是規模太小。幾十篇到一兩百篇的篩選，設定條件、跑一輪、再逐筆複核 Tier 3 的總時間，未必低於直接讀完。這套工具的收益隨記錄數成長。
第三個情境是條件本身不穩定。Rule Engine 的 hard rules 與 soft rules 需要你先寫下可操作的納入排除條件。若你的 PICO 還在反覆修改，每次改動都可能要重跑整批，而重跑就是重新付一次 API 費用。
還有一個要自己驗證的點：README 列出 Risk-of-bias 評估支援 RoB 2、ROBINS-I、QUADAS-2，也列出從納入的 PDF 擷取結構化資料。這些是篩選之後的步驟，但它們的準確度與篩選是兩回事。若你打算用這些輸出，應該先確認它們在你領域的表現，不要因為篩選階段看起來合理就一併採用。
替代方案：單一模型腳本與商業篩選工具的差別
最直接的替代是自己寫一支腳本，用一個 LLM 對每筆摘要問同樣的問題。差別在架構而非模型能力。單模型沒有 ECS 這種跨模型元素共識，你拿到的是一個分數，沒有辦法區分「模型很確定」與「模型剛好猜對」。MetaScreener 的 Tier 3 之所以能運作，前提就是多模型之間的歧異本身是訊號。
另一個方向是商業系統性回顧平台，例如 Covidence 或 Rayyan。它們的差異在於人類工作流：雙人獨立篩選、衝突解決、PRISMA 流程圖輸出，這些是它們的核心。MetaScreener 走的是相反路線，先讓模型決定大部分案子，人只看剩下的。兩者不是同一件事的兩種實作，而是把人工放在流程的不同位置。Covidence 這類工具的篩選判斷完全來自人，AI 只是輔助排序；MetaScreener 則讓模型產出決定，人負責否決。
如果你的機構要求 PRISMA 報告中必須說明雙人獨立篩選的 kappa 值，MetaScreener 的 Tier 1 自動決定會讓這個指標失去意義。反過來說，若你的瓶頸是人力不足、寧可接受較高的人工複核比例來換取時間，這套分層設計正好對應。
授權是 Apache-2.0，允許商用與修改，需要保留著作權聲明與變更說明。但要注意授權只涵蓋這個專案的程式碼，不涵蓋你透過 OpenRouter 呼叫的模型，那些模型各自有自己的授權條款，商用前要逐一確認。這不是法律意見，實際條款請自行核對。
維護成本與版本狀態
專案未封存，最後推送時間是 2026 年 6 月。近期 release 有三個：fp-audit-protocol-v1.0 在 2026 年 5 月，v2.0.0a4 在 2026 年 2 月，v2.0.0a3 在前一天。v2 系列仍帶 alpha 標記，這對需要長期穩定性的研究流程是個提醒：alpha 版本意味著介面與行為可能變動。
維護成本主要來自兩個外部依賴。一是 OpenRouter 的模型清單，README 列的 15 個模型會隨供應商上下架而變動，preset 的組成也可能需要跟著調整。二是校準狀態，若你依賴 active learning 累積的回饋，這份狀態的保存與遷移在 README 中沒有說明。
從原始碼建置的人還要負擔前端依賴，Node.js 18 以上加上 Vite。若你只用 pip 或 Docker 路線，這一層可以略過，但也就無法修改前端行為。
Python 3.11 是硬性下限，這會排除仍在使用 3.9 或 3.10 的舊環境。在既有分析管線中整合時，這一點要先確認，否則會被迫升級整條管線的 Python 版本。
編輯結論
如果你已經在用 PubMed、Scopus 匯出的 .ris 或 .bib 做篩選，而且團隊願意把 Tier 3 的人工複核當成流程的一部分而不是例外，MetaScreener 值得裝起來試跑一個小型 review。若你的檢索結果只有幾十篇、或你的機構不允許把未發表的摘要送到 OpenRouter 這類第三方 API，這套工具的成本與合規負擔大於收益，直接用 Excel 加兩名 reviewer 更快。動手前先確認三件事：你的 Python 是否 3.11 以上、OPENROUTER_API_KEY 是否已備妥、以及 Balanced 預設的四模型在你的主題上跑出來的 Tier 3 比例有多高，因為那個比例直接決定你要投入多少人工複核工時。
社群筆記