RAG リランキング
執筆:Ai Flowi · 公開日
公式情報源:Cohere Rerank ドキュメント
RAG リランキングは、言語モデルに送る根拠を選ぶ前に、質問に対して検索された候補の文章断片を並べ替えます。検索は候補を見つけ、リランカーはその特定のクエリへの関連性を判定します。回答プロンプトに届く断片を変えることはできますが、候補集合に存在しない根拠は復元できません。
このガイドでは、AI Flowi Workflow に Cohere Rerank の段階を加え、条件を統制して比較する方法を提案します。コンポーネントはカタログに記載されていますが、Ai Flowi による本番環境でのテストは行われていません。組み合わせた設計について、順位の改善、遅延の結果、文書形式の変換成功は記録されていません。
1. まず検索の基準結果を確認する
データを入れた Knowledge Base と、裏付けとなる断片にラベルを付けた質問を使います。knowledge_base、search_query、top_k を設定し、include_metadata を有効にします。並べ替え前の Results を保存してください。必要な断片が全く現れない場合は、根拠の順序が原因とせず、コーパスや検索クエリを見直します。
ナレッジベースのガイドは、検索可能な内容の準備と確認を扱います。ここでは質問ごとの候補一覧に注目し、断片のテキスト、ソース識別子、版、元の順序を一緒に保持します。変換を簡単にするためにメタデータを除くと、最終回答が適用可能なソースを使ったか確認しにくくなります。
2. リランカーのアカウントと候補形式を準備する
Cohere Rerank 用にご自身の Cohere アカウントと API キー、および検索・モデルプロバイダーで既に必要な認証情報が必要です。サービス料金は別途請求されます。カタログの説明はCohere API を使って文書を並べ替えます。
です。入力には model、search_query、search_results、top_n、api_key が載っています。
以下の JSON 試行を設定する前に、候補テーブルの変換境界をType Convert リファレンスで確認してください。
変換前に各候補を区別できるようにします。異なる版に同じ文章があっても、それぞれの識別情報を残してください。変換後の候補集合を元の一覧と比較し、順序と件数も確認します。二つのソースが一つのテキスト項目にまとまったら、順位付け前に停止します。後の順位では、失われたソースは分かりません。エクスポートはリランカーが必要とする文書スキーマを示していないため、有効な JSON 値であるだけでは不十分です。
3. 候補数と選択する根拠の件数を設定する
候補選択の設定:設定例であり、記録されたテストではありません
| コンポーネント | 設定するカタログ入力 | 続行前の確認 |
|---|---|---|
| Knowledge Base | top_k:8。include_metadata:true。search_query:完全なテスト質問。 | 八件は説明用の検索件数であり、推奨の既定値ではありません。 |
| Type Convert | input_data:候補の Table。output_type:"JSON"。 | data_output の文章断片と保持された識別子を確認します。文書レイアウトはエクスポートに記載されていません。 |
| Cohere Rerank | search_results:検証済みの候補 JSON。search_query:同じ質問。top_n:3。model:対応する設定済みの選択肢。 | reranked_documents を確認します。三件は試行用の選択件数であり、品質の主張ではありません。 |
| Parser | input_data:並べ替え後の JSON。pattern:エディターで確認した根拠の形式。mode:"Parser"。 | 選択したテキストとソースの対応が残っていることを確認します。 |
| Prompt Template | template:質問、選択した根拠、根拠に基づいて答えるための指示。 | モデルを呼び出す前に、動的なバインディングと最終プロンプトを確認します。 |
エクスポートには "rerank-english-v3.0"、"rerank-multilingual-v3.0" などのモデル名があります。これらはカタログの選択肢であり、現在プロバイダーで利用できるという主張ではありません。アカウントとエディターで選んだモデルを検証してください。api_key が任意という表示から、外部サービスが認証なしで動くとは判断しないでください。
4. 変換と順位付けを通して識別情報を保持する
Type Convert を通して候補のテキスト、識別子、版が残るかレビューします。次に JSON の Cohere Rerank の reranked_documents を確認します。カタログには、ネストされたフィールド、スコアの尺度、元の候補との対応が載っていません。実際の合成出力から対応を確定してください。index、text、score というフィールドが存在するとは考えないでください。
選択した各文書について、レビュアーが元の候補とソース断片を見つけられる必要があります。新しい順位だけでは回答の引用を安全に再構成できません。結果にメタデータがなければ元の候補一覧を保持し、回答生成前に明示的な照合ルールを検証します。繰り返される段落は同じ短縮テキストを持ち得るため、短縮した断片テキストだけで照合しないでください。
Parser リファレンスは入力を説明し、プレースホルダー文法が未記載であることを示します。エディターで整形構文を検証してください。
5. コーパスを変えずに順序を比較する
質問、索引化した文書、候補数、回答指示を固定します。各ケースで基準の候補順序と、リランキング後の選択を保存します。ラベル付き断片と必要な例外が選択した根拠に残るか確認してください。最初の断片の関連性が高くても、回答に必要な補完断片が除かれていれば不十分です。
| 統制する変更 | 選択結果の観測 | 解釈 |
|---|---|---|
| 同じ候補一覧の順序を入れ替える | 選択されたソースの識別情報を、元の順序での試行と比較します。 | 入力順序に左右される変更は、関連性によるものと判断する前にレビューが必要です。 |
| 候補を固定して top_n を減らす | 最初に除外された、必要な裏付けの断片を特定します。 | この質問には選択件数が少なすぎる可能性があります。 |
| 二つの候補のテキストは同じで、版が異なる | 各選択結果を元のソース一覧で見つけます。 | テキストだけの照合ではソースの識別情報を確定できません。 |
| 要求する選択件数より少ない候補を渡す | 実際の件数と、プロバイダーのエラーを記録します。 | 未記載の件数処理や不足分の補充挙動を想定しません。 |
選択の練習例では、一つの候補を主な指示、もう一つをその適用条件とラベル付けします。要求する選択件数が一つだけなら、関連性の高い指示でも不完全な根拠を生みます。同じ候補からより多く選んだ場合と、その除外を比較します。これにより、選択の打ち切りと検索の網羅性を切り分けられます。同時にコーパス文書を追加すると原因が分かりにくくなります。
RAG 評価で、検索の網羅性と回答の根拠への忠実性を区別します。リランカーの呼び出し失敗は運用上の失敗として数え、関連文書が空だったとは扱いません。基準検索へ戻すフォールバックを選ぶ場合は、その挙動を明示的に検証します。提案する連鎖には、自動復旧の分岐が文書化されていません。
6. 必要な根拠に合わせて件数を調整する
top_k は候補検索、top_n はリランキングでの選択に属する別の設定です。候補集合を増やしても利用可能なコンテキストが自動で増えるわけではなく、少数の選択では関連する事実が落ちることもあります。一度に一つの設定を変え、同じラベル付き質問をレビューして根拠が失われる位置を確認します。
この試行では、要求する選択件数を渡す予定の候補数以下に保ち、実際に返された件数を確認します。候補が少ない場合の挙動はエクスポートに定義されていません。文書長の制限やプロバイダーのバッチ処理ルールもありません。これらの未記載事項から、万能のサイズ推奨を作らないでください。
7. RAGでリランキングを追加する価値はありますか?
固定した検索が既に必要な根拠を確認可能な順序で返し、追加要求が観測された問題を解決しないなら、リランカーを追加しないでください。プロバイダー呼び出しと障害点が増えます。文書の権限、版管理、権限に基づくレビューの代わりにもなりません。
リランキングは、候補のシグナルをどう組み合わせるかを扱うハイブリッド検索 RAGとは異なります。どちらの設計も、特定の回答の正しさを証明しません。一回の試行から一般的な品質向上を主張せず、追加段階がご自身の環境で根拠の選択を有用に変えるか分かるよう、基準結果を残します。
リランキングの費用
プラン:Goは年払いで月額USD8から(月払いUSD10)、Plusは月額USD16から(月払いUSD20)、Pro 100は月額USD80から(月払いUSD100)、Pro 200は月額USD160から(月払いUSD200)、Pro 500は月額USD400から(月払いUSD500)。毎月5,000~250,000 Flowi Tokensが含まれ、追加購入も可能です。ノード実行1回につき1トークン。サードパーティのAPIとモデルの利用料金は含まれません。
利用量の見積もりには変換、選択、繰り返したプロバイダー呼び出しを含めます。検索文書数は、ワークフローのノード実行数やプロバイダーの課金対象利用量と同じ単位ではありません。