Contextual Agentic Vision Platform のオンプレ展開経路に関する作業から得られた、訓練と運用についての覚書である。
我々が関与する産業領域（重工業、インフラ、半導体製造、エネルギーおよびオフショア資産、防衛隣接の検査プログラム）では、最初の会話の早い段階で必ず何らかの形で口にされる一文がある。すなわち、データは建物の外に出さない というものだ。図面、SOP、検査履歴、社内規程、現場で映り込んだ人物画像。そのいずれもが、明示的なコンプライアンス制約か、もしくは独自コンテンツを第三者の AI API へ送信することに対する暗黙の企業姿勢のいずれかに縛られている。
本ノートが扱うのは、この制約を本気で受け止めると決めたときに実際に何が要求されるか、である。具体的には、顧客インフラ内部でエージェンティック・ビジョン・スタックをどう訓練し、どう運用しているか、そしてその展開作業の下に横たわる未解決の研究課題について述べる。
オンプレは「モデルをローカルでホストする」だけではない
オンプレ展開の素朴な解釈はこうだ。オープンウェイトのモデルを取り、ファイアウォールの内側で走らせれば終わり。実務上は、エージェンティック・ビジョン・プラットフォームには、オンプレに常駐させるべき三つの異なる要素があり、それぞれが固有の制約を抱えている。
1. 専門 CV モデル群。物体検出、セグメンテーション、OCR、深度、トラッキング。これらは概してホスティングが最も容易である。スコープが明確で GPU と相性がよく、サービング手法も成熟している。同時に、欠陥分類体系や許容公差帯が産業や拠点ごとに異なるため、顧客ごとにファインチューニングされる可能性が最も高い層でもある。
2. VLM オーケストレータ。より大きく、運用が難しい層であり、フロンティアの継続的な改良から最も恩恵を受ける層でもある。現実的な選択肢は、オープンウェイトの基盤モデル（例：Qwen-VL や同等のファミリ [1]）を顧客 GPU 上にホストし、その上にパラメータ効率の良い適応を載せる構成である。
3. 検索とコンテキスト層。顧客の図面、SOP、検査履歴は顧客側の環境に存在する。検索インデックスもそこに置かれる必要があり、VLM は顧客境界を一切越えずにそれを呼び出さねばならない。
各層には固有の訓練・運用ストーリーが存在する。これらを一枚岩のモデルとして扱うのは誤りである。
全パラメータ再学習ではなく、パラメータ効率の良い適応
VLM オーケストレータと、顧客別の専門モデル調整のいずれにおいても、我々はパラメータ効率の良いファインチューニング（PEFT）、とりわけ LoRA とその派生 [2] に依拠している。
この選択は計算コスト（フロンティア規模 VLM の全パラメータファインチューニングを顧客 GPU 上で行う選択肢はほぼ取れないため、これも無視できない論点ではある）だけが理由ではない。より重要な理由は次の三点である。
汎用能力の保持。狭い産業コーパスでファインチューニングされた VLM は、オーケストレータとして役に立つ前提となっていた汎用視覚理解のロングテール部分で、しばしば劣化する。LoRA の低ランク更新は、ドメイン外入力における基盤モデルの挙動を、典型的なファインチューニング予算下では全パラメータ再学習よりも確実に保持する。
顧客・タスクごとに積み重ね可能な適応。LoRA アダプタは小さく、差し替えが容易である。単一の VLM ホスティングが、リクエスト時に該当アダプタをロードすることで複数顧客に対応できる。顧客ごとにモデル本体を複製する必要はない。これが、社内多数チームへスケールするオンプレ展開と、そうならないものとを分ける。
監査可能性。LoRA アダプタは小さな成果物であり、訓練コーパスを文書化・版管理できる。全パラメータ再学習されたチェックポイントは、比較して不透明である。
専門 CV モデル側で同等の手筋にあたるのは、バックボーンを凍結してタスクヘッドのみを適応させること、加えて、サプライヤのテストセットで優秀だったモデルが顧客サイトの分布で劣化するという失敗様態を避けるための、丁寧なデータキュレーションである。
データのサニタイズはモデル訓練パイプラインの一部である
アダプタ訓練に入る前に、顧客の訓練データは、固有表現認識とルールベースのリダクションを組み合わせたサニタイズ・パイプラインを通過する。このパイプラインは、PII、クライアント識別子、機微な取引・位置情報フィールドを訓練コーパスに入る 前に 取り除く。これにより、アダプタがそれらを記憶して後の生成物に再出力するリスクを低減する。
同じ原則は産業検査データ全般にも当てはまる。シリアル番号、インフラ画像上の GPS 座標、現場映像に映り込んだ識別可能な人物。そのいずれもがアダプタ訓練の前に除去され、リダクション自体もログとして残されるため、訓練セットに何が含まれ何が含まれなかったかを監査者が検証できる。
運用：効くポイントの選び方
サービングスタックは、「モデルをローカルで走らせた」と「アナリストが実際に使うレベルで走らせた」とを分ける場所である。重要な構成要素は三つある。
推論エンジンとしての vLLM。PagedAttention [3] は、KV キャッシュメモリを「バッチサイズの上限」という硬い制約から、スケジューラが管理できる量へと転換する。我々が扱うワークロード（画像とテキストが混在する長文脈 VLM 呼び出し）では、素朴な HF transformers サービングループに対する実効スループット改善が大きく、典型的なオンプレ GPU 予算において実現可能かどうかの境界を分ける。
入り口としての Triton。Triton Inference Server に vLLM バックエンドを組み合わせた構成 [4] により、VLM と専門モデルの両方に対して統一されたサービング表面を持てる。バッチング、キューイング、マルチモデルホスティングはモデルコードの外側で処理される。要点は Triton そのものではない。要点は、サービング層が Flask アプリの背後の Python スクリプトではなく、実運用に耐えるインフラの一部分でなければならない、ということだ。
ローカルでの検索拡張生成（RAG）。VLM は自身の重みだけで回答することはない。すべての呼び出しは、顧客の図面・SOP・検査履歴を対象としたローカルベクトルインデックスから検索を行い、プロンプトは取得チャンクの引用を要求する。これはテキスト LLM で標準化された RAG パターン [5] を、エージェンティック・ビジョンの設定に持ち上げたものである。VLM のアナリスト層の散文は検索可能なエビデンスを指し示さねばならず、これは下流のジャッジ層が依拠する性質でもある。
この三つ（効率的な推論、本物のサービングインフラ、必須化された検索）が揃って初めて、オンプレ展開は単に「準拠している」ものから「実際に使える」ものになる。
より難しい問題：オーケストレータと専門モデルの共同訓練
ここまでは展開エンジニアリングの話である。その下にある研究課題はより難しく、我々の作業のなかで最も長い半減期を持つと考えている部分でもある。
我々のプラットフォームは、VLM が専門 CV モデル群をオーケストレートするアーキテクチャを取る。そこから自然に立ち上がる訓練上の問いはこうだ。意思決定の結末が正しくなるように、オーケストレータのツール使用ポリシーをどう訓練すれば、適切な専門モデルが、適切な順序で、適切なクエリと共に呼び出されるか？ 個々のツール呼び出しが直感的にもっともらしく見えるかどうかではなく、結末 に対して、である。
これが難しいのには明確な理由がある。ワークフロー（どのスカウトを、どの順序で、どのクエリで呼ぶか）は 離散的 である。一方、モデルパラメータ（VLM のポリシーヘッド、専門モデルの重み）は 連続的 である。勾配ベースの最適化は微分可能な損失を前提とするが、離散的なツール選択判断はそれを自然な形では提供しない。両者の体系は噛み合わず、素朴な共同訓練は、ワークフロー構造を無視して個別のモデル呼び出しに過適合するか、もしくはモデルを凍結してワークフローのみを学習し、利用可能な信号の大半を取り逃がすか、いずれかに帰着してしまう。
ここで我々が追っている研究方向は、訓練可能なツール使用ビジョンのための反事実クレジット割当 である。すなわち、別のツール呼び出しが行われていた場合に結末がどうなっていたかという反事実ロールアウトに基づいて個々のツール呼び出しにクレジットを割り当て、その信号を用いてオーケストレータのツール選択ポリシーと専門モデルのパラメータの両方を更新する、という方向である。数理的な着想は、強化学習におけるクレジット割当の広範な文献 [6]、および結末レベルの報酬でツール使用言語モデルを訓練する近年の研究 [7] から得ている。ビジョン固有の具体化、すなわちツール出力が自由形式テキストではなくキャリブレーション済み不確実性を伴う型付きレコードである場合の構造については、既存文献で扱われている例を見ていない。これが我々が現在まとめている部分である。
本ノートとの関係で言えば、上述の展開ストーリー（LoRA、vLLM、Triton、RAG）は、研究を扱える形に保つための基盤である。なぜなら、各層の入出力が報酬モデルでスコアリングできる程度に十分構造化されているからだ。オンプレのストーリーと研究のストーリーは別系統ではない。同じアーキテクチャを二つの角度から眺めたものに過ぎない。
主張していないこと
率直な但し書きをいくつか。
- PEFT は万能ではない。全パラメータファインチューニングが正解であるタスクは存在し、予算とデータが正当化される範囲ではそれを用いる。デフォルトは PEFT であり、選択は顧客・タスク単位で行う。
- オンプレが常に高速なわけではない。クラウド API は、ほとんどの顧客が自前では保有しない種類のハードウェア上で動いている。オンプレの価値主張は、生のスループットではなく 制御性、監査可能性、データレジデンシー である。差分の大半を埋めるサービングスタックは持っているが、あらゆる設定で同等性を主張するものではない。
- 訓練可能なツール使用は研究である。アーキテクチャ自体は本番運用に乗っている。訓練手順の方はまだ検証中であり、結果が公表可能な水準に達した時点で別途まとめる。
References
- Bai, J. et al., Qwen-VL: A Frontier Large Vision-Language Model with Versatile Abilities. Alibaba. arxiv.org/abs/2308.12966
- Hu, E. et al., LoRA: Low-Rank Adaptation of Large Language Models. Microsoft Research. arxiv.org/abs/2106.09685
- Kwon, W. et al., Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. arxiv.org/abs/2309.06180
- NVIDIA Triton Inference Server, vLLM backend. docs.nvidia.com/deeplearning/triton-inference-server
- Lewis, P. et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arxiv.org/abs/2005.11401
- Sutton, R. and Barto, A., Reinforcement Learning: An Introduction. MIT Press, 2nd edition. incompleteideas.net/book
- Schick, T. et al., Toolformer: Language Models Can Teach Themselves to Use Tools. Meta AI. arxiv.org/abs/2302.04761