コンテキスト検索技術

 (anthropic.com)
3 ポイント 投稿者 GN⁺ 2024-09-22 | 1件のコメント | WhatsAppで共有

Contextual Retrieval の紹介

  • AIモデルが特定の文脈で有用であるためには、背景知識が必要
  • カスタマーサポートのチャットボットには特定のビジネスに関する知識が必要であり、法務分析ボットには過去の事例に関する膨大な知識が必要
  • 開発者は一般的に Retrieval-Augmented Generation (RAG) を使ってAIモデルの知識を強化する
  • 従来のRAGソリューションは、情報をエンコードする際に文脈を取り除いてしまうため、関連情報を検索できないことが多い

Contextual Retrieval の方法

  • Contextual Retrieval は、RAGの検索段階を大幅に改善する方法
  • Contextual Embeddings と Contextual BM25 という2つの下位技術を使用する
  • 検索失敗回数を49%削減し、再ランキングと組み合わせれば67%まで削減できる
  • Claude を使って Contextual Retrieval ソリューションを簡単に展開できる

単純により長いプロンプトを使う

  • ナレッジベースが200,000トークン以下の場合、ナレッジベース全体をモデルに提供するほうがより良い方法である可能性がある
  • Claude のプロンプトキャッシュ機能を使えば、このアプローチはより高速でコスト効率も高い
  • ナレッジベースが大きくなると、よりスケーラブルなソリューションが必要になる

RAG の基本概念

  • RAG は大規模なナレッジベースを扱うために使われる
  • ナレッジベースを小さなテキスト断片に分割し、埋め込みモデルを使って意味をエンコードする
  • ベクターデータベースに保存し、意味的類似性に基づいて検索する
  • BM25 は正確な単語またはフレーズ一致を見つけるのに効果的

従来の RAG の限界

  • 文書を小さな断片に分割する過程で文脈が失われることがある
  • たとえば、特定企業の財務情報を探す質問に対して、十分な文脈を持たない断片が返されることがある

Contextual Retrieval の実装

  • 各断片に説明的な文脈を追加して、埋め込みおよび BM25 インデックスを生成する
  • Claude を使って各断片の簡潔な文脈を生成する
  • プロンプトキャッシュを使ってコストを削減できる

性能改善

  • Contextual Embeddings は検索失敗率を35%削減する
  • Contextual Embeddings と Contextual BM25 を組み合わせると、検索失敗率を49%削減する

実装時の考慮事項

  • 文書を断片に分割する方法、埋め込みモデルの選択、カスタム文脈化プロンプトなどを考慮する必要がある
  • より多くの断片を含めるほど、関連情報を含む可能性が高くなる

再ランキングによる性能向上

  • 再ランキングは、最も関連性の高い断片だけをモデルに渡すことで応答品質を向上させる
  • 再ランキングした Contextual Embedding と Contextual BM25 は検索失敗率を67%削減する

結論

  • Embeddings と BM25 を組み合わせると、より良い結果を得られる
  • Voyage と Gemini の埋め込みが最も効果的
  • 上位20個の断片をモデルに渡すのが最も効果的
  • 文脈を追加すると検索精度が大幅に向上する
  • 再ランキングは性能をさらに向上させる

GN⁺ のまとめ

  • Contextual Retrieval はAIモデルの検索精度を大幅に向上させられる方法
  • 特に大規模なナレッジベースを扱う際に有用
  • Claude のプロンプトキャッシュ機能を使えば、コスト効率よく実装できる
  • 類似した機能を持つ他のプロジェクトとして、OpenAI の GPT-3 や Google の BERT がある

関連記事

1件のコメント

 
GN⁺ 2024-09-22
Hacker Newsの意見

  • 1つ目の意見

    • 政府機関向けのエンタープライズRAGを構築した経験の共有
    • RAGAS指標を使ったA/Bテストの結果:
      • ハイブリッド検索（セマンティック + ベクトル）とLLMベースの再ランキングは、合成評価質問では大きな変化なし
      • HyDEは合成評価質問において、回答品質と検索品質を深刻に低下させた
    • ハイブリッド検索は常に有用だが、1つの方法が常に勝つわけではない
    • Azure AI Searchのセマンティック検索は、ベクトル類似性と組み合わせることで十分に効果的
    • さまざまな方法をテストする必要がある
    • 次に試すもの:
      • RAPTOR
      • SelfRAG
      • Agentic RAG
      • クエリ精製（拡張およびサブクエリ）
      • GraphRAG
    • 学んだこと:
      • 常にベースラインと実験を用いて、帰無仮説を反証しようと試みるべき
      • 3種類の評価質問/回答を使用: 専門家作成、実ユーザーの質問、合成質問

  • 2つ目の意見

    • プロンプトキャッシングを活用するやり方が気に入っている
    • キャッシングのおかげで、プロンプトコストが1/10に減った
    • キャッシングによるコスト削減で、さまざまなトリックが可能になった
    • コンテキスト付き検索とプロンプトキャッシングに関するノートを共有

  • 3つ目の意見

    • RAGの結果を改善するために、LLMを使って基本チャンクを拡張するアプローチは一般的
    • HyDEを使ったクエリ拡張は、必ずしも改善につながらない
    • Anthropicの新しい点は、プロンプトキャッシングを導入したこと
    • プロンプトキャッシングは、長い文書をコンテキストとして提供することでコストを削減する
    • Cohere APIには非常に満足している

  • 4つ目の意見

    • 文書をh1、h2、h3見出しを基準にチャンクへ分割し、チャンクの先頭にヘッダーを追加する方式を使用
    • 例:
      • 既存のチャンク: "成人の一般的な服用量は、1日3回、200mgの錠剤またはカプセルを1〜2個"
      • 新しいチャンク: "# 発熱 ## 治療 --- 成人の一般的な服用量は、1日3回、200mgの錠剤またはカプセルを1〜2個"
    • この方法はLLMなしでもうまく機能する

  • 5つ目の意見

    • この技術には反対の立場
    • ベクトル埋め込みは、最初の改行までのテキストブロックに過度に集中する可能性がある
    • IDF検索がある程度は克服するが、十分ではない
    • "semantic boost" を使うことで、埋め込みを文書のタイトルや要約などへ移せる
    • Trieve APIの "semantic boost" の説明を共有

  • 6つ目の意見

    • "linked list" 戦略を使い、チャンクが参照された項目に対して複数のポインタを持つようにする
    • 各コメントが元の投稿へのポインタになるやり方として説明
    • この技術の例を共有

  • 7つ目の意見

    • 200kトークンを使って小さなデータセットで最良の回答を得るという主張は、自分の経験とは異なる
    • プロンプトが大きくなるほど、出力は一貫しなくなり、指示にも従いにくくなる
    • 他の人も似た経験をしたか、またそれを避ける方法があるのか気になっている

  • 8つ目の意見

    • RAGを使って知識を検索するのではなく、ルールを検索する問題に直面している
    • 特定のルールが適用できるか判断するために、小さな分類器を訓練するアプローチを提案
    • 例: マルチユーザーダンジョンゲームで、特定のルールが適用されるかどうかを判断する方式
    • ルールが適用されるかどうかを決めることのほうが、より抽象的で難しい問題
    • この問題を解決する方法を探している

  • 9つ目の意見

    • ナレッジベースが200,000トークン（約500ページ）より小さい場合
    • Anthropicがトークナイザーを公開してくれることを望む

  • 10つ目の意見

    • AI業界が再びTF-IDFに戻る日を待っている