MedicalGPT レビュー: PT/SFT/RLHF/DPO/ORPO/GRPO を1リポジトリに収めた医療ドメイン向け学習パイプライン
MedicalGPT: Training Your Own Medical GPT Model with ChatGPT Training Pipeline. 训练医疗大模型，实现了包括增量预训练(PT)、有监督微调(SFT)、RLHF、DPO、ORPO、GRPO。
ひと目でわかる
- これは何？
- 医療分野の大規模言語モデルを自前で学習させるための学習スクリプト集。ChatGPT 型の多段階パイプラインを Python で実装し、Apache-2.0 で公開されている。設定ファイルとシェルスクリプトの粒度で何ができるかを確認する。
- 誰に向いている？
- 採用を検討すべきなのは、医療や医薬など固有のドメインコーパスをすでに持っていて、その上で SFT と選好学習の段階を自分で回したいチームである。逆に、汎用チャットモデルをそのまま使いたい場合や、学習済みの臨床判断を求める用途には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
汎用モデルではなくドメインコーパスを学習させたい人向けのリポジトリ
MedicalGPT が解こうとしているのは、公開されている汎用 LLM に医療分野の語彙や言い回しを後から覚えさせる作業を、段階ごとに分割して実行できるようにする問題である。README は「训练医疗大模型」と述べ、第一段階の PT（Continue PreTraining、增量预训练）から第二段階の SFT、第三段階の RLHF または DPO という順序を明示している。対象読者は、自前の診療記録や医学文献のコーパスを持ち、それをベースモデルに注入したいエンジニアである。モデルそのものを配布するプロジェクトではなく、学習手順とスクリプトを配布するプロジェクトだと理解したほうがよい。Hugging Face 上の shibing624 アカウントには過去に微調整済みモデルが公開されているが、リポジトリの主眼は学習側にある。
三段階のパイプラインをどう分割しているか
README の記述に従えば、第一段階の PT は領域文書による二次事前学習で、任意とされている。第二段階の SFT は指示データセットを構築し、事前学習済みモデルに指示意図を合わせながら領域知識を注入する。第三段階は二つの経路に分かれる。RLHF は報酬モデル（RM）の学習と強化学習の2ステップから成り、RM は helpful, honest, harmless の原則に沿った人間の選好順序データセットで訓練される。もう一方の DPO は、報酬モデルを介さず言語モデルを直接最適化する。README は DPO について、RLHF より実装が容易で訓練しやすく、効果も良いと述べている。この対比は、同じ第三段階をどちらのコストで支払うかという設計判断として読める。
v2.5 以降で増えた学習手法とモデル対応
リリースノートによれば、v2.5 で Qwen3.5 系（Base、Instruct、MoE 変種）が PT/SFT/DPO/ORPO/GRPO の全流程に適応され、qwen3、qwen3_5、qwen3_nothink、qwen3_5_nothink という対話テンプレートが追加された。MoE については DeepSpeed ZeRO-3 での学習が挙げられている。v2.4 では LoRA と全パラメータの GRPO が入り、v2.6 ではエージェントのツール呼び出し（Function Call）向け微調整と、モデルごとに異なるツールデータ形式の変換・解析コードが追加され、data ディレクトリに toolcall のサンプルが置かれた。v2.7 では OPD（On-Policy Distillation）が入り、training/opd_training.py という独立した学習エントリと scripts/run_opd.sh が用意された。手法が増えるほど、どの段階をどの手法で回すかの選択肢も増える。
学習を回すための入口はスクリプト単位で分かれている
README とリリースノートから確認できる起動の入口は、scripts ディレクトリ配下のシェルスクリプトである。ORPO については scripts/run_orpo.sh を参照するよう明記され、OPD については scripts/run_opd.sh が追加されたと書かれている。学習本体のコードは training ディレクトリにあり、OPD は training/opd_training.py が独立したエントリとして新設された。つまり設定は、シェルスクリプト内の引数と training 以下の Python エントリの組み合わせで渡す形になっている。Python は 3.8 以上が requirements.txt のバッジで示されている。RAG を使いたい場合は demo/chatpdf.py が用意され、微調整後の LLM と知識ベースファイルを組み合わせた質問応答ができると README は述べている。学習だけでなく推論側の足回りも同じリポジトリに入っている点は、構成を把握するうえで助けになる。
データ形式が手法ごとに違うという制約
このリポジトリを実際に使うときの最初の壁は、GPU の確保よりもデータ形式のほうである。SFT は指示データセット、RLHF の RM は選好順序データセット、DPO や ORPO も選好データを前提とする。v2.6 でツール呼び出し用のデータ形式変換コードが追加されたという事実は、逆に言えばモデルごとに形式が異なり、変換層を挟まないと回らないことを示している。医療分野では選好データの作成自体が高コストで、誰がどの回答を好ましいと判定したのかを記録しておかないと RM の学習が成立しない。README はデータ作成の運用面にはほとんど触れていない。ここは自分で設計するしかない部分であり、パイプラインの実装が整っていてもデータの側が整わなければ第三段階には進めない。
RLHF と DPO のどちらを選ぶかは計算資源の配分の問題になる
RLHF は報酬モデルの学習と強化学習の2段階を要求するため、SFT 済みモデルとは別に RM を保持し、方策の更新中に報酬を計算する構成が要る。DPO は報酬モデルを省き、言語モデルを直接最適化する。README は DPO の利点として実装の容易さと訓練のしやすさを挙げ、効果もより良いと書いている。ただしこれは DPO が常に優位という主張ではなく、報酬モデルを別途訓練して管理する運用コストを払う価値があるかどうかの話である。医療のように評価基準を明文化しにくい領域では、RM を作り込むより DPO で選好を直接与えるほうが現実的だという判断も成り立つ。逆に、報酬の内訳を説明可能な形で保持したい要件があるなら、RM を持つ RLHF の構成に意味が出てくる。
向かないケースと、確認せずに進めると詰まる点
このリポジトリは学習パイプラインであって、臨床判断を下すシステムではない。医療QAの精度を上げたいだけなら、既存の公開モデルをそのまま使い、demo/chatpdf.py のような RAG 経路で自施設の文書を参照させるほうが短距離で済む場合が多い。PT から回す構成は、コーパスと計算資源の両方を持っていることが前提になる。また、リポジトリには Homepage が設定されておらず、ドキュメントは GitHub wiki とリリースノートに分散している。手法ごとのパラメータの意味を網羅的に確認したいなら、wiki 側を読む必要がある。ライセンスは Apache-2.0 で、リポジトリの LICENSE に従う限りにおいて改変と再配布が許される。ただし学習に使うコーパスや、生成したモデルの出力を医療用途で使う際の規制上の扱いは、このライセンスが定める範囲の外にある。
編集部の結論
採用を検討すべきなのは、医療や医薬など固有のドメインコーパスをすでに持っていて、その上で SFT と選好学習の段階を自分で回したいチームである。逆に、汎用チャットモデルをそのまま使いたい場合や、学習済みの臨床判断を求める用途には向かない。着手前に確認すべきは scripts/ 配下の各 run_*.sh が前提とするデータ形式と、training/ 以下の学習エントリが自分の GPU 構成でどの DeepSpeed 設定を要求するかの2点である。
コミュニティノート