高度なRAGテクニックは、常に優れているわけではない。時として優れているだけだ。
高度なRAGテクニックは、無料のアップグレードではありません。トレードオフを伴うツールなのです。
テストのために、RAGパイプラインに5つの検索テクニックを追加しました。最も重要な結果は、失敗したテクニックから得られました。
HyDEは検索精度を向上させると期待していました。しかし、特定のクエリに対しては逆効果となりました。Recall（再現率）は0.80から0.17に低下しました。このテクニックは、単に役に立たなかっただけではありません。誤ったデータを積極的に検索結果に引き込んでしまったのです。
テストしたすべての高度なテクニックには、次のような特性があります。
- Hybrid search (BM25 + dense): 完全一致する用語に最適です。クエリが特定のパラメータに依存している場合に使用してください。
- HyDE: 文書の語彙と一致しないカジュアルな質問に最適です。クエリがすでにコーパスとよく一致している場合には失敗します。
- Reranking: 正しいチャンクが結果に含まれているものの、リストの下位に位置している場合に最適です。
- Contextual retrieval: 文脈が不足している短いチャンクに最適です。ただし、すべてのチャンクに対してLLMを使用する必要があるため、コストが増加します。
このパイプラインはAnthropicのドキュメントを使用して構築しました。PostgresにpgvectorとHNSWインデックスを使用しました。私はこれをバックエンドエンジニアのように扱いました。そのテクニックが「最先端（state of the art）」かどうかではなく、その「複雑さに見合う価値があるか」を問い直したのです。
追加するコンポーネントはすべて、運用、デバッグ、そしてコストの支払いが必要な対象となります。
複雑なツールを追加する前に、単純なdense retrieval（密ベクトル検索）を使用してベースラインを測定しました。
結果として、2つの異なる指標が得られました。
- Faithfulness: 0.96
- Context precision: 0.60
このデータによって、私のアプローチは一変しました。ほとんどのテクニックは検索（retrieval）を対象としています。私の場合は、検索が失敗の原因でした。もしFaithfulnessが低ければ、プロンプトを調整していたでしょう。しかし、検索精度が低かったため、検索プロセス自体を調整する必要がありました。
また、評価ツールについても教訓を得ました。Ragasを使ってみましたが、遅すぎました。失敗した呼び出しをリトライし続け、数時間もかかってしまいます。代わりに、独自の非同期ハーネス（async harness）を構築しました。その結果、11時間かかっていた同じ指標の測定を、221秒で完了できました。
教訓はシンプルです。
テクニックを盲目的に適用しないでください。クエリルーターを使用して、適切な質問に対して適切なモードを選択してください。まずはデータを測定してください。その上で、特定の失敗モードを解決するツールを選んでください。
モデルは新しいものですが、エンジニアリングの規律（discipline）はそうではありません。
Source: https://dev.to/yogesh23012001/advanced-rag-techniques-arent-better-theyre-better-sometimes-4m2o