開源醫療 AI
MARC Breaks Clinical Reasoning Into a Traceable Agent Pipeline, but Its First Release Lacks Accuracy Comparisons
The open-source MARC v1 uses YAML to define extraction, reasoning, and output agents, with support for the Gemini API or local deployment through Ollama. It improves error localization and data control, but presents only three types of use cases and does not demonstrate that a multi-agent approach is more accurate than a single prompt.
MARC v1 replaces the single large prompt used in clinical LLM applications with a fixed-sequence agent pipeline whose roles are clearly separated. In the default workflow, the first agent extracts evidence, the second reasons over it and produces a standardized verdict, and the third only retrieves the answer. The original input and the previous stage’s output are passed explicitly between agents, and every step is logged. The point of this design is not to let agents converse freely with one another, but to separately identify failures caused by overlooked data, reasoning errors, and formatting problems.
The [paper](https://arxiv.org/abs/2608.13476) positions the system as a Level 2 deterministic workflow. Agent order, models, prompt files, and per-agent RAG data sources are all specified in YAML, with configurations validated by Pydantic before execution; the default temperature is 0. The Decomposer uses MedGemma 4B to break a natural-language task description into three roles and generate prompts containing `{input}`, `{previous_agent_output}`, and a fixed verdict format. The configuration is written only after it passes structural constraints.
The [MIT-licensed repository](https://github.com/Penn-RAIL/MARC-v1) provides Gemini and Ollama backends. Its RAG implementation uses Chroma and splits documents into 1,000-character chunks. Local mode can help hospitals avoid sending data to external APIs. The authors demonstrate biomedical question answering, radiology report generation, and the automatic creation of pipelines for chest CT and USMLE-style tasks, but these are architectural use cases rather than comprehensive performance experiments.
For now, MARC is therefore better understood as an auditable research harness than as a validated clinical system. The paper does not report accuracy relative to a single prompt, latency, cost, or usability for physicians, and sequential execution can amplify errors introduced in earlier stages. The software can currently select only one global backend per run, and the default Gemini model name cannot be passed directly to Ollama. Engineering teams can use it to build traceable prototypes, but the next critical milestone should be controlled evaluation across datasets, models, and clinical reviewers.