著: Muratcan Koylan & Amit Kumthekar
掲載先: https://www.sully.ai/research/context-engineering-over-iteration
臨床AIシステムがエラーを犯したとき、そのコストは臨床医の時間で計られる。でっち上げられた薬剤名や誤った発言者の帰属は、臨床医が見つけて修正しなければならない。15分の診察では見直しの余裕は薄い。出力を一行ずつ監査する必要があるなら、どんなに素早く画面に表示されようと、そのシステムは失敗している。
これによって、精度がプロダクション段階での臨床AIの一次設計制約となる。速度も重要だが、それは臨床ワークフロー特有の理由による。診療件数の多いクリニックでは、臨床医は少ない移行時間で診察を移り渡り、診察終了60秒後に届く文書は次の患者への注意と競合する。入院診療では、適切なタイミングでの文書作成がケアコーディネーションに直接影響する——専門医のアセスメントはプライマリチームの回診前に参照できる状態でなければならないし、救急現場での引き継ぎ文書は患者安全に直接影響する。速度は臨床要件だ。しかし精度のない速度は、遅くても正確なものより悪い。
多くの臨床AIシステムはこのどちらか一方しか達成できていない。最も一般的なアプローチはシングルモデル呼び出しだ：プロンプト1つ、1パス、返ってきたものを受け入れる。速い。でも信頼性がない。モデルは薬剤をでっち上げ、発言者を誤って帰属し、セクション全体を欠落させる。臨床医はすぐに出力を信頼できないと学ぶ。
2つ目のアプローチはセーフティネットを追加する。ドラフトを生成し、ジャッジモデルでエラーを見つけ、違反を修正エージェントに送り、ジャッジが通るまで繰り返す。このパターンは、精度を重視するほとんどのプロダクションシステムに様々な形で存在する。私たちのシステムでも、このループは実際の問題を捕捉していた。ループを完全に除去した対照アブレーションを実施すると、臨床的次元全体で出力品質が11%低下した（内部評価スケールで3.17→2.85、n=126対n=114）。最大の低下は臨床安全性（+0.58）と根拠推論（+0.54）で、これらはエラーが最も高い臨床リスクをもたらす次元だ。ループは本物の臨床的役割を果たしていた。しかし各修正サイクルはシリアル計算に10〜15秒を要し、ループはパイプライン全体の半分以上の時間を消費していた。
私たちはループの品質と速度を同時に改善しようと何ヶ月も費やした。小型のジャッジモデル。よりタイトなプロンプト。反復回数の削減。改善は限界的だった。問題はループの速度ではなかった。問題は、ループが必要だったことそのものだった。
私たちが問い始めた質問：なぜ最初のパスは信頼性がないのか？
私たちの仮説は、弱い最初のパスはモデルの能力問題ではなかった、ということだ。タスク設計の問題だった。完全な臨床文書を生成する単一モデルは、同時に6〜8個の認知タスクをこなしている：長い書き起こしを解析する、情報を正しいセクションにルーティングする、セクション固有の文書化ルールを適用する、専門科ロジックを処理する、でっち上げを避ける、複雑なスキーマに一致する構造化出力を生成する。1つのモデルがこれらすべてを同時にこなすと、個々のタスクの精度が低下する。修正ループはその過負荷コンテキストを補償するために存在する。
これが以降のすべての形を決めた発見だ：コンテキストエンジニアリングと反復は補完関係ではなく、代替関係にある。複雑なタスクを焦点を絞ったサブタスクに分解すると、各コンポーネントは根本的に狭いコンテキストを見る。モデルは8つではなく1つのことをする。最初のパスが信頼性を持つようになる。修正ループは不要になる。そして焦点を絞ったコンポーネントは並列実行できるので、アーキテクチャは正確であることの構造的帰結として速い——その逆ではない。
私たちはこれを、各自が文書の狭いスライスを担当し、タスクに関連するコンテキストだけを見る並列専門コンポーネントを中心にパイプラインを再構築することでテストした。1回の品質チェックが反復ループに取って代わった。
10万件以上のプロダクション事例全体で、品質は維持または改善された：各コンポーネントの最初のパスは、過負荷アプローチが生成したものより正確だった。レイテンシはp50で37秒から7.5秒に、p95では100秒超から16.3秒に低下した。速いモデルを見つけたからではなく、パイプラインを遅くしていたアーキテクチャパターンを排除したからだ。
この発見はクリニカルドキュメンテーション以外にも拡張できる。出力が独立してアドレス可能なセクションを持ち、入力が注意を希薄化するほど長い構造化生成タスクなら、コンテキストエンジニアリングは反復修正より効果的なレバーだ。もしシステムに修正ループがあるなら、そのループが過負荷コンテキストを補償しているのではないか問うてみよう。
■ モノリシックエージェントが弱い最初のパスを生む理由
単一エージェントに複雑な複数部分の出力を求めると、1つのコンテキストウィンドウ内で競合する複数の認知タスクをこなさなければならない。1つのプロンプトに詰め込む目標が多いほど、個々の目標の実行は悪化する。これは競合する要求の下でのLanguage Modelのアテンションの一般的特性であり、マルチエージェントシステム設計のあらゆる実践的帰結を持つ。私たちはこれを臨床ドキュメンテーションを通じて最も明確に学んだが、構造化生成が長い入力と出会う場所ならどこでもパターンは当てはまる。
単一モデルが臨床文書を生成するとき、実際に何をしているか考えてみよう。典型的なノートには12以上のセクションがある：患者の病歴、系統別レビュー、薬剤、身体診察所見、アセスメントと治療計画、処置・診断コード、その他。各セクションには独自の文書化ルールがある。モデルはこれらすべての指示を同時に受け取る——完全な書き起こし（しばしば数千語）、EHRからの臨床コンテキスト、安全制約、各セクションのキーを持つ出力スキーマと一緒に。
1つのプロンプトに詰め込まれた少なくとも6つの同時認知タスク：
・長い非構造化会話を解析して誰が何の問題について何を言ったか特定する
・各情報を正しいセクションにルーティングする（この症状はHPIへ、あの所見は身体診察へ、この薬剤は薬剤リストへ）
・各セクションで異なるセクション固有の文書化ルールを適用する
・専門科ロジックを処理する（内分泌科のホルモン療法文書化ルール、整形外科の術部位仕様）
・全セクション同時でっち上げを避ける
・15キーの動的スキーマに一致する構造化JSON出力を生成する
最近の研究は私たちが実践で観察したことを定量化している。256モデルのテスト全体で、指示遵守精度は200トークンの指示で92%から4,000トークンで60%に低下する（Gupta et al., 2025）。最高のフロンティアモデルでさえ、500の同時指示を遵守する際に68%の精度しか達成できない（Jaroslawicz et al., 2025）。ポストトレーニングも推論チェーンも修正しない。競合する目標下でのアテンションの動作の根本的特性だ。
ジャッジ違反にその結果を見た。ジャッジは構造化エラーレポートを返した：どのセクションに問題があったか、どのテキストが間違っていたか、修正はどうすべきか。パターンは一貫していた。書き起こしの薬剤が間違ったセクションに現れた。帰属エラーがセクション全体で複合した——患者が報告した症状が臨床医の観察として文書化されていた。ナレーティブに関連するセクション（HPIとアセスメント）が互いに矛盾していた——モデルが単一の過負荷コンテキスト内でそれらを独立して処理したからだ。
ジャッジはこれらのエラーを捕捉した。しかし私たちが予期しなかったのは：修正エージェントが頻繁に悪化させたことだ。
修正ループが実際に何をしたかを理解するために約50件のプロダクショントレースを分析した。ジャッジがフラグを立てた違反の約45%を解決した——主にICD-10コーディングエラー、セクションコンテンツの欠落、薬剤ドキュメントのギャップといった素早い修正だ。しかし元のノートに存在しなかった新しい違反をほぼ同じ率で導入した：15件の新しい臨床精度エラー、13件の新しい構造・テンプレートコンプライアンスエラー、11件の新しいアセスメントと治療計画の精度問題。完全に解決されたのはトレースの8%のみ。39%では、ノートに改善が見られなかった。
パターンは一貫していた：修正は小さく明確に定義された問題（コードの欠落、不完全なセクション）を修正し、より大きな臨床精度と構造問題を扱えなかった——または積極的に悪化させた。セクションエージェントが薬剤を省略する。ジャッジがその省略をフラグする。修正エージェントが薬剤を追加し直すが、遭遇の間違った部分に帰属させるか、書き起こしに一度も言及されなかった用量を追加する。ノートは不完全から捏造へと変わる。
言語モデルの自己修正に関する研究がこのパターンを支持する。外部フィードバックなしにモデルが自分の出力を修正する内在的自己修正は、概して効果がないままだ。ジャッジと生成器は同じ盲点を共有する。一方に他方を修正させることは、同じ人に休憩後に自分の仕事をレビューさせることに近く、本物のセカンドオピニオンを得ることとは程遠い。
ジャッジアブレーションからの一つの詳細が私たちを驚かせた。セクションエージェントは、下流にジャッジループがあるかどうかに関わらずほぼ同一のパフォーマンスを示した。ジャッジあり：セクションはドラフトを+0.23ポイント改善；ジャッジなし：+0.33。セクションエージェントはどちらにしても自分の仕事をしていた。品質の差は完全に、ジャッジ/修正ループが後片付けをするために存在するかどうかから来ていた。これは、正しい問いが「どうジャッジをよくするか」ではなく「どうセクションを十分によくしてジャッジが不要になるか」だと教えてくれた。
この気づきがアプローチを変えた。私たちはジャッジを速くしようとするのをやめた。ジャッジを不要にしようとし始めた。
■ タスク分解をコンテキストエンジニアリングとして
修正策は、よりいいモデルでも、モノリシックエージェントへのより賢いプロンプトでもなかった。各エージェントが明確な単一目標を持つようにタスクを分解することだった。
これが私たちの研究の中心的発見であり、臨床ドキュメンテーションをはるかに超えて一般化する。Andrej Karpathyはコンテキストエンジニアリングを「次のステップのためにコンテキストウィンドウをちょうど正しい情報で満たす繊細な技芸と科学」と表現した。私たちはプロダクション側から同じ結論に至った：モデルが見るものをコントロールすることで、モデルが正しくするものをコントロールできる。
旧パイプラインでは、現在の病歴（HPI）セクションを生成するエージェントは、アセスメントと治療計画、系統別レビュー、処置コード、その他すべてのセクションの指示も見ていた。情報をルーティングし、15の異なるルールセットを適用し、15キーのJSONオブジェクトを生成しなければならなかった——10,000語の書き起こしを解析しながら。新パイプラインでは、HPIエージェントはHPI指示だけを、HPI出力キーだけを、そして同じ書き起こしを見る。1つのことだけをする。
書き起こしは同じ。モデルは同じでよい。しかしモデルのコンテキストウィンドウで見るものは根本的に狭い。
コンテキストの変化
各セクションエージェントは2カテゴリの情報を受け取る：
共有コンテキスト（全エージェントで同一）：完全な書き起こし、EHRからの臨床人口統計、安全ルール（でっち上げ禁止指示、帰属ルール、情報欠落時のフォールバック動作）。これがノートの原材料だ。
焦点コンテキスト（エージェントごとに固有）：担当セクションの指示のみ、担当セクションキーのみを持つ動的生成の出力スキーマ。Chief ComplaintとHPIを担当するエージェントは2キーのスキーマを得る。アセスメントと治療計画、CPTコード、ICD-10コードを担当するエージェントは3キーを得る。ドラフトエージェントの15キーと比較してほしい。
2キー対15キー。エージェントごとのタスク複雑度が5〜7倍低下する。目標が少なければ目標ごとの精度が高くなる。最初のパスの精度が高くなれば修正ループは不要になる。
出力スキーマ自体がコンテキストエンジニアリングの一形態だ。書き起こしを読む前にモデルに何を生成すべきかを告げる。chief_complaintとhistory_of_present_illnessというキーを持つスキーマは、暗黙的にタスクをスコープする。モデルはスキーマに従って書くのであって、それを避けながら書くのではない。
これがアーキテクチャ的に何を可能にするか
各エージェントが独立して焦点を絞っているとき、並列実行できる。ウォールクロック時間は最も遅い単一エージェントの時間になり、全ステージの合計にはならない。実際には、複数のセクションをより少数の並列スペシャリスト呼び出しにグループ化できる。正確なグループ化は原則よりも重要ではない：コンテキスト依存関係を共有するセクションは一緒に属し、無関係な作業は同一プロンプトで注意を競合させるべきではない。
プロダクションでは、これは具体的に現れる。50万回のセクションエージェント呼び出し全体で、セクションエージェントごとのp50レイテンシは2秒以下だ。完全に組み立てられたノートを見るQAエージェントはより時間がかかる——p50 4.3秒——しかし1回、すべてのセクションエージェントが並列完了後に実行する。総p50エンドツーエンドは7.5秒だ。短い書き起こし（1,000語以下）では4.3秒に下がる。
単一のQAエージェントがすべてのセクションエージェント完了後に結合ノートをレビューする。1回のパスでインラインで問題を検出・修正する。反復なし。
131件の複雑な臨床ケースの評価で、システムはわずか2%の重要問題で臨床項目の83%平均キャプチャ率を達成した。診断は95.6%精度、症状は95.0%、薬剤は93.0%でキャプチャされた。最も改善余地があった領域——患者指示とプラン項目——は最も広書き起こし横断合成を必要とするセクションに対応し、まさに焦点コンテキストが最高のレバレッジを持つタスクだ。省略（問題の43.6%）が捏造（11.4%）を支配したことは注目に値する——システムは臨床ドキュメンテーションにおいてより安全な失敗モードである不完全性に向かって誤り、臨床医レビューが自然に発見する。
■ コンテキストエンジニアリングと反復は代替関係
これを明示的に表現したい関係だ。
広いコンテキストと反復を持つことができる：1エージェントがすべてを見て弱い最初のパスを生成し、ジャッジループが複数ラウンドで修正する。これが私たちのV1だ。機能した。遅かった。
あるいは焦点コンテキストと単一パスを持てる：各エージェントは必要なものだけを見て信頼できる最初のパスを生成し、1つの軽量QAチェックが残りを捕捉する。これがV2だ。シリアル依存関係を排除するので5倍速い。
ジャッジループは間違っていなかった。正しい問題——品質保証——を間違ったレバーで解決していた。反復がコンテキストエンジニアリング問題を補償していた。根本原因を修正すると、症状が消えた。
Anthropicのエージェント向けコンテキストエンジニアリングに関する研究は、異なる方向から類似の結論に達している：「コンテキストは限られたリソースであり収穫逓減がある」、各エージェントのコンテキストをスコープするサブエージェントアーキテクチャは、より長いコンテキストウィンドウを持つモノリシックアプローチよりも良い結果を生む（Anthropic, 2025）。Cursorの自走式コードベースに関する研究も同じパターンを発見した：あまりにも多くの役割を与えられた単一エージェントは「病理的挙動を示した」そして「振り返ると、圧倒されていたのは理にかなっている」。役割を焦点を絞ったスペシャリストに分離することで問題が解決した（Cursor, 2026）。
このパターンは臨床AIの外でも成立する。出力が独立してアドレス可能なセクションを持ち、入力が注意を希薄化するほど長い構造化生成タスクなら成立する。文書生成、レポート組み立て、複数ファイルにまたがるコード生成、複数セクションのコンプライアンスレビュー。もしパイプラインに修正ループがあるなら、そのループが過負荷コンテキストを補償しているかどうかを問うてほしい。
■ いくつかの補足設計上の選択
ここでの核心的発見は分解であり、フレームワーク設計ではない。それでも、プロダクションでそのアイデアを素早く安全にテストすることを可能にした補足的選択がいくつかある。
統一エージェントインターフェース
私たちのシステムのすべてのエージェントは、オーケストレーターに同じインターフェースを提示する。オーケストレーターは呼び出しているエージェントの種類を知らない。型付き入力を送り、型付き出力を受け取り、実行メタデータを記録する。
これが重要な理由：旧パイプラインから新パイプラインへの移行にエージェントレイヤーへの変更はゼロで済んだ。同じエージェント、異なる配線。ドラフトステージを削除し、ジャッジループを削除し、QAエージェントを追加し、トポロジーを再配線した。エージェント自体は触れなかった。パイプラインアーキテクチャに関する仮説をテストするとき、エージェントへの変更と結果を混同したくない。統一インターフェースがその分離をきれいにした。
同じパターンがあらゆるマルチエージェントシステムに適用される。エージェントが特定のオーケストレーショントポロジーと密結合されていれば、すべてのアーキテクチャ実験が書き直しになる。交換可能なら、1日でトポロジーを入れ替えられる。
動的出力コントラクト
各エージェントは自分が生成するものを宣言する——入力からリクエスト時に生成される構造化スキーマ。8セクションのテンプレートは8キーのスキーマを生成する。単一セクションエージェントは1キーのスキーマを生成する。スキーマはリクエスト時に構築され、ハードコードされない。
これは2つの目的を果たす。モデルにとって、スキーマは生成をガイドする。2キーのスキーマに書くモデルは、15キーのスキーマに書くモデルにはない集中を保つ。システムにとって、スキーマはパース可能な出力を保証する。並列エージェントの結果を結合することは、各エージェントの出力が既知の構造にスロットインするので決定論的だ。ファンアウトは簡単だ。ファンインは並列システムが壊れる場所だ。動的コントラクトがファンインを信頼できるものにする。
■ 副次的発見：分解がモデル選択の方程式を変える
モノリシックパイプラインと分解パイプラインでモデルをベンチマークしたとき、予期しないことを発見した：アーキテクチャがどのモデルが実行可能かを変えた。
焦点タスクで品質ギャップが縮小する
完全なノート生成タスクでは、大型モデルが一貫して小型モデルを上回った。ギャップは有意で安定していた。セクションレベルのタスクでは、小型モデルがそのギャップを大幅に縮めた。パラメータ数の何分の一かのモデルが、焦点を絞った抽出と構造化で大型モデルに匹敵または上回った。
これを定量化するために、フロンティアクラスのモデルとより小型のオープンソースモデルを同じ分解アーキテクチャで比較する実験を行い、共有評価セット上の同一LLMジャッジで評価した。これは探索的比較であり、プロダクション判断ではなかった。目標は分解がモデル選択方程式を変える場所を理解することだった。
精度ギャップは均一ではないことを学んだ——それがこの発見を有用にしている。診断、症状、薬剤は小さなギャップを示す（5%未満）。最大の低下は書き起こし横断合成を必要とするセクションに集中する：フォローアップ、バイタル、プラン項目、患者指示。これらは焦点コンテキストとターゲットプロンプトエンジニアリングが最高のレバレッジを持つセクションであり、より大型モデルに切り替えることなくギャップが狭いことを意味する。
実験は、分解がモノリシックパイプラインがアクセスできない品質-速度トレードオフの領域を開くことを示した。エンドツーエンド生成には遅すぎるモデルが、複数の並列コンポーネントの1つであれば実行可能になる。アーキテクチャが単一モデル選択を強制しないこと、その柔軟性こそが実践的価値の所在だ。
これはより広い研究と一致する。ファインチューニングされた1Bモデルが焦点を絞った分類タスクでGPT-4.1に99%精度で匹敵し、18倍のスループット改善を達成した（arXiv:2510.21970）。Microsoftはファインチューニングされた小型モデルが検索関連性でGPT-4oを上回り、17倍速く19倍安いことを発見した（Kang et al., 2026）。臨床ドメインでは特に、ファインチューニングされた8Bモデルが4つのデータセット全体で人間レベルの精度（90%完全一致）を臨床情報抽出で達成し、デスクトップGPU1枚で動いた（Liu et al., Nature Scientific Reports, 2025）。
タスク複雑度こそがモデル能力ではなく出力品質を決定する。タスクを単純化すれば小型モデルが実行可能になる。分解はレイテンシ戦略であるだけでなく、モデル選択戦略でもある。
レイテンシ-品質フロンティアがシフトする
完全なノート生成に15秒かかるモデルが、複数の並列コンポーネントの1つであれば実行可能になる。5つのシリアル呼び出しではなく1つの呼び出しのレイテンシを支払う。アーキテクチャがモノリシックパイプラインではアクセスできない速度-品質トレードオフの領域を開く。
並列エージェントは単一呼び出しより総トークン数が多いが、各呼び出しはより小さい（焦点を絞った指示、小さいスキーマ）、これが重複を部分的に相殺する。そして私たちは自社推論インフラ（Nvidia, 2026）で実行しているので、コスト方程式はトークンごとのAPIプライシングではなく計算時間になる。
エージェント全体でのモデル多様性が実用的
異なるエージェントは異なる要件を持つ。焦点を絞った抽出を行うセクションエージェントは推論速度の速さから恩恵を受ける。横断セクション推論を行うQAエージェントはより強い分析能力から恩恵を受ける。私たちのアーキテクチャは異なるエージェントの役割に独立して異なるモデルを割り当てることをサポートする。
私たちの研究チームは昨年、異なるドメインでこの原則を探索した。コンセンサスメカニズム（Kumthekar et al., 2025）は医療推論にスペシャリスト分解を適用した：トリアージモデルがクエリを分類し、エキスパートモデルが専門科の視点から並列推論し、コンセンサスモデルが出力を統合する。アンサンブルは4つの医療ベンチマーク全体でOpenAIのO3-highを3.4〜8.2%上回った。アーキテクチャがそこでは異なることを可能にした——並列性によるレイテンシではなくスペシャリストの深さによる精度向上——しかし根本的な洞察は同じだ。タスクを分解する。各ピースを正しいモデルに割り当てる。結果を結合する。
小型モデルの品質限界に達しているなら、答えは大型モデルではないかもしれない。エージェントごとのより単純なタスクかもしれない。
■ 検証方法
旧パイプラインを新パイプラインに置き換えなかった。4ヶ月間、同じプロダクショントラフィックで並列実行した。
パイプライントポロジー、モデル選択、プロンプトを独立して変えることができ、患者ケアを危険にさらすことなく1度に1変数を分離できた。すべてのエージェント呼び出しはエンドツーエンドでトレースされた：モデル、プロンプトバージョン、トークン数、レイテンシ、リトライ、成否。合成ベンチマークは不要だった。プロダクショントラフィックが実験であり、可観測性レイヤーが評価ハーネスだった。
本稿執筆時点で、新パイプラインは10万件以上のプロダクションノートを処理している。プロダクション数値がその物語を語る：
レイテンシは書き起こし長と優雅にスケールする。短い事例（1K語以下）はp50 4.3秒で完了する。長い事例（5K語以上）はp50 11秒かかる。関係はほぼ線形で指数的でない——アーキテクチャに複雑度の崖がない。
初期の対照実験が品質はレイテンシ目標で維持されることを確認し、プロバイダーベンチマークはインフラ選択が同じ並列性で2〜3倍レイテンシをシフトすることを示した——インフラがアーキテクチャと同じくらい重要であることを確認。
研究からプロダクションへのサイクルは数四半期ではなく数日だった。2025年後半にアーキテクチャ研究を開始した。2026年初頭には新パイプラインがプロダクショントラフィックの大部分を処理していた。そのイテレーションの速度は、別のデプロイメントや評価スタックを立ち上げることなく本番トラフィックでアーキテクチャ変更を直接テストできたことから来ている。
コスト問題には正直な答えが必要だ。新パイプラインは複数のコンポーネントが同じ書き起こしを処理するため、ノートごとの総トークン数が多い。そのトレードオフは現実だ。品質とレイテンシの改善が実質的だったため、またインフラがそのトレードオフをトークンごとAPIモデルとは異なって管理できるため、私たちはそれを受け入れた。
■ トレードオフと現時点で不明なこと
品質と速度の改善は現実であり、10万件以上のプロダクションノートで測定されている。しかしまだ対処中のトレードオフがある。
速度は品質が維持される場合のみ重要
すべての顧客と専門科にわたって継続的評価を実行している。品質の後退はアラートをトリガーする。記述したアーキテクチャ比較——専門スペシャリストを優先してジャッジループを削除する——はレイテンシ削減とともに品質改善を生み出した。臨床医も気づいている：移行後、顧客満足度スコアが有意に増加し、プロバイダーはノートがより正確で以前より速く利用可能だと一貫して報告している。しかしその品質ラインを維持するには継続的投資が必要だ。
モデル比較実験では、フロンティアと小型モデルのギャップは最高複雑度セクション——プラン項目、指示、フォローアップ——で最大だった。これはプロンプトエンジニアリングと分解戦略が最大のレバレッジを持つ場所であり、アーキテクチャを変えることなくより強力なモデルをそれを必要とするセクションに割り当てることができる。
強化学習でファインチューニングされた小型言語モデルを特定のセクションタイプ向けに実験中であり、焦点を絞った抽出タスクの速度と精度をさらに改善することを目標としている。
シングルパスQAが十分でない場合
反復ジャッジループはシングルQAパスが時々見逃す横断セクション矛盾を捕捉した。セクションAがセクションBと矛盾する。治療計画に記載された薬剤が病歴に言及されていなかった。QAエージェントは完全に組み立てられたノートを見てその多くを捕捉するが、1回のパスで動作する。反復ジャッジは微妙な矛盾を見つける複数の機会を持っていた。
ジャッジアブレーションはセクションエージェントを超えてループが何に貢献したかを定量化している：テンプレートコンプライアンスで+0.27、指示コンプライアンスで+0.29、テンプレート指示違反で+0.23。これらはコンプライアンス次元だ——シングルQAパスが1回のチャンスしか持たない横断セクション一貫性チェックがまさにそれだ。特定の専門科にまたがる複雑な複数問題の事例では、まだ判断がついていない。これらのケースを綿密に監視しており、より安全な選択肢であり続ける場所では旧パイプラインを使用する能力を維持している。
プロンプト品質が荷重を担う
これは私たちの働き方を変えたトレードオフだ。セーフティネットとしてのジャッジループなしでは、各エージェントのプロンプトの品質が出力品質を直接決定する。旧パイプラインでは平凡なセクション指示が修正エージェントに修正されていた。新パイプラインでは、それが出荷される。
これはリスクであると同時に、プロンプトエンジニアリングをインフラとして投資する最大の動機だ。エージェントごと・組織ごとに組み立てられた構造化バージョン管理プロンプトブロックに大きく投資している。セクションエージェントが一貫したエラーパターンを生成するとき、それを引き起こした特定の指示ブロックに追跡し、そのブロックを修正する。
原則的な分解フレームワークを持っていない
どのセクションをグループ化すべきか？1エージェント1セクション？関連セクションの結合？最適な粒度はセクション複雑度、セクション間の情報依存関係、専門科に依存する。Chief ComplaintとHPIがグループ化されているのは、ナレーティブのつながりを共有するからだ。アセスメントと治療計画が処置・診断コードとグループ化されているのは、臨床推論がそれらの出力全体で一貫性を必要とするからだ。
これらのグループ化は経験的であり、データがどこに次のフォーカスを向けるかを教えてくれる。すべての評価全体で、アセスメントと治療計画は分解が最大のインパクトを持つセクションだ——モデルやパイプラインバリアントに関わらず、フラグされた項目の33〜46%を一貫して集中させる。HPIは15〜17%で2番目に複雑なセクションだ。これは予想通り：これらのセクションは最も書き起こし横断合成を必要とする。分解の粒度が合成複雑度が最高の場所で最も重要であり、A&Pへのプロンプトエンジニアリング投資が不均衡なリターンをもたらすことを教えてくれる。
テンプレートごと・専門科ごとに異なる構成をテストする。選択は臨床ワークフロー知識によって情報提供されプロダクションメトリクスで検証される。しかし正式なフレームワークから導出されているわけではない。
ここで共有したことは普遍的真実ではない。私たちのシステム、私たちのデータ、私たちの臨床ドキュメンテーションタスクで機能したパターンだ。あなたの分解境界は異なるだろう。最適な粒度も異なるだろう。しかしパイプラインに反復修正ループがあり最初のパスが信頼性がないなら、診断の問いは同じだ：反復が過負荷コンテキストを補償しているか？
■ 次のステップ
プロンプト品質が荷重を担うという発見が、私たちの臨床AIへの投資方法を変えた。
臨床医の文書作成が各エージェントの最初のパスの信頼性に依存するとき、それらのエージェントをガイドする指示は臨床インフラになる。異なる専門科は異なる文書化要件を持つ。異なる組織は異なるワークフローを持つ。内分泌科の診察で機能するプロンプトは整形外科のフォローアップで重要なことを見落とすかもしれない。コード変更なしに臨床コンテキストごとにカスタマイズ可能な、構成可能でバージョン管理された指示を作るシステムを構築している。
2つ目の投資は継続的改善にある。臨床医のフィードバックが一貫したエラーパターンを示すとき、プロンプト全体を書き直すのではなく、それを引き起こした特定の指示に追跡してその指示を修正する必要がある。臨床医のフィードバックがそれを必要とする特定のコンポーネントへのターゲットを絞った根拠に基づく改善を駆動するクローズドループシステムを構築している。目標は四半期ごとではなく毎週改善するプロンプト品質だ。
本稿で説明したアーキテクチャは最初のステップだった。速度で品質を高く維持することはコンテキストエンジニアリング問題だ。専門科と組織にわたって時間とともに品質を向上させ続けることは、より難しく臨床的に影響力のある作業が横たわる場所だ。