RAG と微調整: まず問題を診断します

観察できる障害を特定する

失敗した例から始めて、システムが応答に必要な証拠を持っているかどうかを尋ねます。ポリシー文書が存在しない場合、モデルを変更すると、検索の問題が解決されるのではなく、隠蔽されてしまう可能性があります。証拠は存在するが、出力が必要な形式を繰り返し無視した場合は、指示と動作を調査してください。これらの障害クラスを分離しておくことをお勧めします。それらはさまざまな実験につながり、改善がそれを生み出した変化によるものであると考えやすくなります。

実用的なベースラインを確立する

トレーニング パイプラインを追加する前に、明確な指示、代表的な例、および関連するコンテキストを試してください。 OpenAI は反復的な評価と最適化のプロセスについて説明していますが、現在のドキュメントでは、その微調整プラットフォームが終了しつつあり、新規ユーザーが利用できないことも警告しています。微調整は、プロバイダーとモデルによって利用可能かどうかが異なるアーキテクチャ オプションとして扱います。サポートされているサーフェスとそのベース モデルのライフサイクルを確認せずに、古いチュートリアルに基づいてプロジェクトを設計しないでください。

証拠: OpenAI モデルの最適化 [1]

適切なメトリクスを比較する

証拠の入手可能性と回答サポートに関するテスト検索の変更。観察した正確な一貫性の問題に基づいて動作の変更をテストします。共有された保持セットは最終アプリケーションの比較に役立ち、コンポーネントの測定値はパフォーマンスが変化した理由を示します。トレーニング例を最終評価から除外し、重複に近いものをどの程度処理するかを文書化します。この表は測定の定義を提案しています。 1 つの技術が特定の精度を達成する、または単一のしきい値がすべての製品に適用されるとは主張しません。

更新実験を実行する

製品制限の改訂など、管理されたソース変更を選択し、システム全体でそれに従ってください。どのドキュメント、インデックス、プロンプト、サンプル、キャッシュを更新する必要があるかを確認します。古いポリシーが新しいポリシーをオーバーライドしていないこと、およびアクセス権のないユーザーがポリシーを取得できないことを確認します。この実験により、静的ベンチマークでは見逃される運用上の作業が明らかになります。チームがメンテナンス要件を所有できるアプローチを選択し、材料ソースまたはモデルを変更するたびに評価を繰り返します。

RAG は AI の何を表しますか?

RAG は検索拡張生成の略です。アプリケーションは情報を取得し、それを回答を生成するためのコンテキストとして提供します。検索によりモデルに追加の証拠が与えられます。答えが正しいかどうかは証明されません。 RAG の取得には、適切なソース、アクセス境界、欠落または矛盾する証拠を特定する方法が依然として必要です。

会話型アプリケーションの場合、Rubrex では、以前の仮定を引き継ぐのではなく、フォローアップの質問で現在のリクエストの証拠が得られるかどうかを確認することを推奨しています。エージェント RAG を使用すると、システムはタスク中に取得ステップやその他のアクションを選択できます。最終的な答えだけでなく、それらの決定と停止条件も評価します。自由度を追加する前に、ベースラインとして単純な固定ワークフローを使用します。

よくある質問