MARCは臨床推論を追跡可能なエージェント・パイプラインに分解するが、初版では精度比較を未実施

MARC v1は、臨床LLMアプリケーションを、単一の大規模プロンプトから、順序と役割分担が固定されたエージェント・パイプラインへと変更する。デフォルトのフローでは、最初のエージェントがエビデンスを抽出し、2番目のエージェントが推論して標準化されたverdictを出力し、3番目のエージェントは回答の取り出しだけを担当する。元の入力と前段階の結果は明示的に受け渡され、各ステップの記録も残る。この設計の要点は、エージェント同士を自由に対話させることではなく、データの読み落とし、推論エラー、フォーマット失敗を切り分けて特定できるようにすることだ。

[論文](https://arxiv.org/abs/2608.13476)では、このシステムをLevel 2の決定論的ワークフローと位置付けている。エージェントの順序、モデル、プロンプトファイル、各エージェントのRAGデータソースはすべてYAMLに記述され、設定は事前にPydanticで検証される。デフォルトのtemperatureは0だ。DecomposerはMedGemma 4Bを使用して自然言語によるタスク記述を3つの役割に分解し、`{input}`、`{previous_agent_output}`、固定形式のverdictを含むプロンプトを生成する。その後、構造上の制約を満たしたものだけが設定に書き込まれる。

[MIT Licenseのリポジトリ](https://github.com/Penn-RAIL/MARC-v1)はGeminiとOllamaのバックエンドを提供する。RAGにはChromaを使用し、文書は1,000文字単位に分割される。ローカルモードを利用すれば、病院はデータを外部APIへ送信せずに運用できる。著者らは、生物医学分野の質問応答、放射線レポート生成、胸部CTやUSMLE形式のタスク向けパイプラインの自動構築を実演しているが、これらはアーキテクチャのユースケースであり、包括的な性能実験ではない。

したがって、現段階のMARCは、検証済みの臨床システムというより、監査可能な研究用harnessに近い。論文では、単一プロンプトと比較した精度、レイテンシ、コスト、医師にとってのユーザビリティが報告されていない。逐次実行は、前段階のエラーを増幅させる可能性もある。現行の実装では、各実行時に選択できるグローバルバックエンドは1種類だけであり、デフォルトのGeminiモデル名をそのままOllamaへ渡すこともできない。エンジニアリングチームはMARCを使って追跡可能なプロトタイプを構築できるが、次の重要なマイルストーンは、複数のデータセットとモデル、臨床レビュー担当者を対象とした比較評価になるべきだ。