osFoundry / Platform
パイプラインステージ
AIパイプラインの各ステージ ― 検索、リランク、生成、後処理 ― を定義してバージョン管理。
概要
パイプラインステージは、AIワークフローを1つの不透明なプロンプトとして扱うのではなく、名前と順序を持つ明確なステップに分解するためのosFoundry Studioの機能です。典型的な検索拡張型パイプラインは「検索 → 再ランク → 生成 → 後処理」という流れで動作しますが、ここではそれぞれが独立したステージになり、単体で設定、確認、変更できます。検索は知識やデータから候補となるコンテキストを引き出し、再ランクは本当に重要なものへと絞り込み、生成はモデルを呼び出し、後処理は出力がパイプラインを離れる前に整形や検証、再構成を行います。ステップが明示されているため、回答がどこから来たのか、誤っているときにどのステージを直せばよいのかを正確に把握できます。
osFoundryでは、すべてのステージがStudio内で定義され、ワークスペースの他の部分と同じBYOKモデル層を通して実行されます。そのためステージごとにモデルを選べます。再ランクには軽量なローカルモデルを、生成にはクラウドモデルを、といった具合に用途に合わせて使い分けられ、費用はリセラーのマークアップなしにプロバイダーへ直接支払います。ステージはバージョン管理されており、プロンプトやモデル、パラメータを変更しても以前の定義は保持されます。そのためバージョンを比較したり、劣化した変更を元に戻したり、ある結果がどの構成から生まれたのかを確認したりできます。ローカルファーストのデスクトップワークスペースであるため、パイプラインの定義やそれが扱うデータは、ホスト型サービスを経由させずに手元の端末に留めておけます。
これが重要なのは、AIの品質問題の多くがステージの問題だからです。検索が誤ったドキュメントを返しているとき、生成ステップでいくらプロンプトを調整しても解決しません。ステージを分離してバージョン管理することで、「AIが間違っている」という漠然とした状態が、特定の1ステップに関する検証可能な問いへと変わります。そして、履歴という信頼できる裏付けを持ちながら、一度に1つずつ変更を加えるという、他の工学的なシステムと同じやり方でパイプラインを改善できるようになります。
主な機能
- AIパイプラインを1つの巨大なプロンプトではなく、検索、再ランク、生成、後処理といった順序と名前を持つステージとして定義できます
- 各ステージを独立してバージョン管理できるため、構成を比較し、劣化した変更を元に戻し、どの定義がその結果を生んだのかを追えます
- ステージごとにモデルを選べます。自分のAPIキーでローカル、クラウド、自己ホストのいずれも利用でき、マークアップなしでプロバイダーに直接支払えます
- 品質問題を1つのステップに切り分けられます。原因が検索、再ランク、生成、後処理のどこにあるのかを特定できます
- パイプラインの定義とそのデータを、ホスト型サービスを経由させずにデスクトップ上でローカルファーストに保てます
活用例
- RAG構築者：検索と再ランクを生成から分離しておくことで、誤った回答をプロンプトのせいにせず、検索の不備までたどれます
- MLエンジニア：チューニング中に各ステージをバージョン管理し、新しい再ランカーや生成モデルを以前の定義と比較してから確定できます
- プライバシー重視のチーム：検索はローカルの知識に対して行い、パイプライン定義全体を端末上に保ちながら、生成ステージでのみクラウドモデルを呼び出せます
よくある質問
osFoundryのAIパイプラインにはどんなステージがありますか？
よくあるパターンは「検索 → 再ランク → 生成 → 後処理」です。候補となるコンテキストを引き出し、最も関連するものに絞り込み、モデルを呼び出し、出力を検証または再構成します。ワークフローに必要なステージを自分で定義し、順序を設定でき、それぞれを個別に構成します。
ステージごとに異なるモデルを使えますか？
はい。osFoundryはBYOK方式のため、各ステージで異なるモデルを呼び出せます。再ランクにはローカルモデル、生成にはクラウドモデル、別の場所には自己ホストのモデル、といった使い分けを、自分のAPIキーでリセラーのマークアップなしに行えます。
ステージをバージョン管理すると実際に何が得られますか？
ステージのプロンプトやモデル、パラメータを変更しても、以前の定義が保持されます。バージョンを比較し、変更で結果が悪化した場合は元に戻し、ある出力をそれを生んだ正確なステージ構成へと結びつけられます。