開源醫療 AI
MARC 將臨床推理拆成可追蹤代理管線，但首版尚無準確率比較
開源 MARC v1 用 YAML 定義抽取、推理與輸出代理，並支援 Gemini API 或 Ollama 本機部署。它改善錯誤定位與資料控制，卻只展示三類使用案例，未證明多代理比單一提示更準確。
MARC v1 把臨床 LLM 應用由單次大型提示，改成固定順序、角色分工的代理管線。預設流程讓第一個代理抽取證據、第二個代理推理並輸出標準化 verdict，第三個代理只負責取出答案；原始輸入和上一階段結果會明確傳遞，每一步亦留下紀錄。這種設計的重點不是代理彼此自由對話，而是把漏讀資料、推理錯誤和格式失敗分開定位。
[論文](https://arxiv.org/abs/2608.13476)將系統定位為 Level 2 的確定性工作流。代理順序、模型、提示檔與個別 RAG 資料源均寫在 YAML，設定會先經 Pydantic 驗證；預設使用 temperature 0。Decomposer 則以 MedGemma 4B 把自然語言任務描述拆成三個角色，產生含 `{input}`、`{previous_agent_output}` 與固定 verdict 格式的提示，再通過結構限制才寫入設定。
[MIT 授權程式庫](https://github.com/Penn-RAIL/MARC-v1)提供 Gemini 與 Ollama 後端，RAG 使用 Chroma，文件以 1,000 字元切塊；本機模式可讓醫院避免把資料送往外部 API。作者展示生醫問答、放射報告生成，以及自動建立胸部 CT／USMLE 類任務管線，但這些是架構案例，不是完整效能實驗。
因此，MARC 現階段較像可稽核的研究 harness，而非已驗證的臨床系統。論文沒有報告相對單一提示的準確率、延遲、成本或醫師可用性；循序執行也會放大前段錯誤。程式目前每次執行只能選一種全域後端，預設 Gemini 模型名稱更不能直接交給 Ollama。工程團隊可用它建立可追蹤原型，但下一個關鍵里程碑應是跨資料集、模型與臨床審查者的對照評估。