Beating GPT-5.6 Sol on Retrieval with Castform and Neon

オープンウェイトモデルは検索においてフロンティアモデルを上回ることができる

ポストトレーニングされたオープンウェイトモデルは、特定の検索タスクにおいてGPT-5.6 Solのようなフロンティアモデルと同等以上のパフォーマンスを発揮しつつ、コストを最大100分の1に削減できます。汎用的なフロンティアモデルは強力ですが、エージェント的な検索ワークフロー（モデルが問題を解決するためにループ内で何度も計画と検索を繰り返す必要があるワークフロー）においては、コストが非常に高く、速度も遅くなりがちです。強化学習（RL）によるポストトレーニングを使用することで、開発者は小規模なモデルを専門化させ、これらの特定の検索および取得パターンをより効率的に処理できるようにできます。

従来のRAGからエージェント的検索への移行

検索は、ワンショットの埋め込み検索から、マルチホップのエージェント的ワークフローへと進化しました。従来のRetrieval-Augmented Generation (RAG) では、システムはLLMにコンテキストを提供するために単一の類似性検索を実行します。対照的に、エージェント的検索では、モデルが複雑な問題を小さなタスクに分解し、必要な情報が見つかるまでループ内で複数の検索クエリを発行します。

この移行は、主に2つの領域でモデルへの負荷を増大させます：

コンテキスト: 正しいデータを見つけるためのツールを提供する能力。
モデル: 何を検索すべきか、どのように反復すべきかを決定するモデルの能力。

フロンティアモデルにとって、この反復プロセスはコストがかかります。GPT-5.6 Solを使用した典型的なマルチターン検索リクエストは、10秒以上かかり、リクエストあたり約0.03ドルかかる場合があり、これは多くのプロダクション規模では持続不可能です。

CastformとNeonがいかにRLポストトレーニングを可能にするか

CastformとNeonは、GPUの内部構造や機械学習に関する深い専門知識を必要とせずに、生の企業データを専門的な検索モデルに変換するための統合パイプラインを提供します。

トレーニングパイプライン

CastformがRLループを管理し、Neon（Lakebase Search経由）がデータインフラストラクチャを提供します：

ステージ	Neon + Lakebase Search の役割
コーパスの保存	生のドキュメントはNeon上のPostgresに保存されます。
合成データの生成	Castformは `lakebase_text` と `lakebase_vector` を使用してトレーニングタスクを生成します。
RLトレーニング	すべてのロールアウトの検索ツールコールはLakebase Searchを利用します。
プロダクション推論	最終的なモデルは、ライブ推論中に同じ検索ツールを使用します。

データをタスクに変換する

ほとんどの企業には、クリーンなトレーニングデータセットが不足しています。Castformは、既存の独自のデータ（例：社内Wiki、サポート記事、製品レコード）から質問と回答のペアを合成的に生成することで、この問題を解決します。例えば、「列車の乗車は、14日前の予約が必要な標準キャビンクラスである必要があります」というポリシー文書は、予約ルールに関する特定の質問と、それに対応する正解（ground-truth）へと変換されます。

報酬関数

RLポストトレーニングは、モデルを導くための報酬関数に依存しています。検索タスクでは、報酬は以下の3つの要素に基づいて計算されます：

検索 (Retrieval): モデルは正しいデータチャンクを見つけたか？
引用 (Citation): 正しいソースを引用したか？
正確性 (Correctness): 正確な最終回答を提供したか？

ステートフルなエージェントのためのインフラストラクチャ

エージェントモデルのトレーニングは、数千の並列ロールアウトが同時に数十回の検索コールを行う可能性があるため、非常にバースト性の高いワークロードを生み出します。Neonの動的なコンピューティングスケーリングは、常に最大容量をプロビジョニングすることなく、これらのスパイクを吸収します。

さらに、Neonのブランチ機能とタイムトラベル機能により、ステートフルなエージェントのトレーニングが可能になります。ロールアウトごとに隔離されたデータベースブランチを作成することで、開発者はあるエージェントの行動が他のエージェントに干渉したり、プロダクションデータに影響を与えたりしないことを保証でき、エージェントの状態をリセットして検査するための安全な環境を提供します。

コミュニティの洞察と技術的な対案

Hacker Newsの業界の実務家は、特化型検索モデルに関するいくつかの重要な検討事項を強調しました：

"ルーティングコストが無視できる程度であれば、検索、リランキング、推論、生成がそれぞれ独自の最適化されたモデルを持つ方が理にかなっている。"

主な技術的課題

データの品質: 報酬関数自体がコーパスから派生しているため、コーパス内の古くなった情報や誤解を招く情報をシステムがどのように処理するかについて、一部のユーザーから疑問が呈されました。
検索の深さ: 「干し草の中の針」問題、具体的には、ある情報の発見をアンロックするために別の情報が必要な場合、モデルがペアになった「針」を見つけ出す能力についての懸念が示されました。
チャンキング戦略: RAGの根本的な欠陥は「盲目的なチャンキング」であると主張する者もおり、単純な埋め込み検索よりも、より豊かな親子セグメントモデルの方が効果的であると示唆しています。
プライバシー: 機密データの場合、クラウドプロバイダーに情報をアップロードする必要があることが大きな障壁となっており、レンタルGPU上で実行できるオープンソースのスタックへの需要があります。