🐈‍⬛
RAG・AI Agentを支えるRetriverの基礎知識と実装まとめ

Kengo Takemoto
2025/01/17に公開
 はじめに株式会社neoAIの研究開発組織 (neoAI Research) / 東京大学の竹本健悟です。
巷では昨年からRAG（Retrieval Augmented Generation）、そして最近ではAI Agentが大いに注目を集め世間を騒がせていますね。
これらの技術を活用して、社内ドキュメントを外部知識としてLLMに提供するアプリケーションを構築する際、実運用に足る精度を出すためには質問に対して適切なドキュメントを高精度で取得することが最も重要なカギとなります。
今回はそんなRAG・AI Agentの中核を担うRetrieverについて、ベクトル検索やキーワード検索といった代表的な手法や評価指標まで基礎的な知識を網羅的に解説していきます。
オープンソースのベクトルDBであるQdrantを用いた日本語キーワード検索の実装方法や、AWS、Microsoft Azure、GCPといったクラウドサービスでRetrieverを実現するための方法・各サービスの特徴の比較についても少し紹介します。

 Retrieverとは？入力(クエリ)に対して、データベース内の文書（ドキュメント）から関連度の高いものを抽出する機構のことをRetrieverと言います。
検索エンジン、質問応答システム、チャットボットなど、多岐にわたる分野で活用されており、今日ではLLMのめざましい発展によりLLMに与えるコンテキストをデータベースから取得する意味合いで用いられることが多くなっています。


Retrieverのイメージ図
OpenAI GPT-4o、Google Gemini 1.5 Flashといった高いマルチモーダル性能を誇る基盤モデルが登場した辺りから、画像や音声データを対象としたクロスモーダルなRetrieverの有用性が高まってきており、様々な手法が考案されてきていますが、今回はテキストデータに対するRetrieverを対象にして検索手法を解説していきます。

 ベクトル検索ベクトル検索では、BERTなどの事前学習済みのTransformerモデルを使用してテキストをエンコードして文章に対する埋め込み表現(Embedding)をベクトルとして得ます。
文脈・文意を踏まえてベクトルが作成されるので、ベクトル間のcos類似度、Euclid距離などを用いればベクトルの類似度≒文書の類似度を測ることができ、これによってドキュメントを検索するのがベクトル検索です。


ベクトル検索を用いたRAGシステム
Embeddingモデルによって入力できる文章の長さの上限（コンテキスト長）は異なっているため、それ以上の長さの文章をEmbeddingに反映することはできません。
そのため、ドキュメントはコンテキスト長以下の長さを持つひとまとまりの塊(チャンク)に分割してEmbeddingモデルに通すことが一般的です。また、文章の長さにドキュメント間で大きな乖離があると文章の長さがEmbeddingに影響してしまうので、チャンクの大きさは一定にすることが重要です。

 参考：近似最近傍探索以上であげたようにEmbeddingモデルでテキストをベクトル化し、全文書に対してマッチングすれば高速な検索ができるかというと、そういうわけではありません。
次元 Vのベクトル N個に対して真面目に全探索を行うと、その計算式は

n^* = \underset{n \in \{1, ..., N\}}{\arg\min} ||q - x_n||_2
となり、計算量がO(VN)と非常に遅くなってしまいます。
そのため、ベクトルの圧縮を行い高速に解を求めたり、厳密に最近傍でなくても良いので高速に解を求める近似最近傍探索 (ANN)を行うためのアルゴリズムが様々考案されています。


近似最近傍探索のアルゴリズム概観
この中で、大規模データに対する速度・精度のトレードオフで非常に優れており、多くのVectorDBで実装されているアルゴリズムがHNSW（Hierarchical Navigable Small World）です。
HNSWではベクトルに対して上層が疎で下層に行くほど密になる階層的なグラフ構造を作成し、各層で最も近いノードを見つけながら下位層に移動していくことで近傍点を効率的に探索します。


HNSWにおける階層的なグラフ構造
HNSWの他にも様々なアルゴリズムがあり、それらを組み合わせた手法なども存在します。それぞれのアルゴリズムでベクトル数によって応答速度・精度が異なるため、パフォーマンスを追求したい場合は各アルゴリズムの特徴を理解し、適切なアルゴリズムを選択する必要があります。
最近傍探索、近似最近傍探索については東大の松井先生のスライドが非常にわかりやすいのでおすすめです。
https://speakerdeck.com/matsui_528/jin-si-zui-jin-bang-tan-suo-falsezui-qian-xian

 キーワード検索ベクトル検索の弱点として正確な一致検索が苦手であるといったことが挙げられます。
実データに対するユースケースでは「この製品番号が含まれている文書をとってきてほしい」というようなある単語が含まれる文書をジャストで取ってきたいというような場合があると思います。このような時に有用なのがキーワード検索という手法です。
以下でキーワード検索の各手法を解説します。

 tf-idftf-idfとは、

tf：単語の出現頻度（term frequency）

    tf = \frac{ドキュメントAにおける単語Xの出現頻度}{ドキュメントAにおける全単語の出現頻度の和}

idf：単語の希少度（inverse document frequency）

  idf = \log\left(\frac{全ドキュメント数}{単語Xを含むドキュメント数}\right)
の２つを掛け合わせたものです。（tfはあるドキュメントに対して一意に定義できるのに対して、idfが他ドキュメントとの関係で値が変動することに注意してください。）
上の計算式に従ってクエリ内の単語ごとにスコアが算出できます。
そのドキュメント内でよく出てきて、かつ他のドキュメントにはあまり出てこない単語の重要度が高いということなので、直感的に理解することができると思います。
!実際にtf-idfによってキーワード検索を行う際は、単語ごとのスコアを算出した後、Sparse Vector（疎ベクトル）を作成して検索を行います。（普通のEmbeddingは対比してDense Vector（密ベクトル）と呼ばれます。）
Sparse Vectorではベクトルの次元数は語彙数に対応し、文書に対して存在する単語に対応する次元だけに値が立ちます。つまり、あるドキュメントのSparse Vectorにおいて文書内に存在しない単語に対応するベクトル要素は全て0になっています。（これがsparse＝疎といわれる所以です。）
例えば以下のようなドキュメント群があるとします。
corpus_ja = [
    "東京は大阪の東にある",
    "大阪は東京の西にある",
    "京都は大阪の北にある",
    "札幌は東京の北にある",
    "那覇は大阪の南にある"
]
このドキュメント群に対してSparse Vectorは以下のような形になります。



ある
に
の
は
京都
北
南
大阪
札幌
東
東京
西
那覇


doc0
1
1
1
1
0
0
0
1
0
1
1
0
0

doc1
1
1
1
1
0
0
0
1
0
0
1
1
0

doc2
1
1
1
1
1
1
0
1
0
0
0
0
0

doc3
1
1
1
1
0
1
0
0
1
0
1
0
0

doc4
1
1
1
1
0
0
1
1
0
0
0
0
1

各ドキュメントにおいて存在している単語に対応する部分に値が入っていることがわかるかと思います！
Sparse Vectorは値の立っている次元数がDense Vectorと比べて圧倒的に少ないため検索効率はDense Vectorより非常に優れています。

 BM25tf-idfの弱点として以下のことが挙げられます。
文書の長さを考慮していない
同じ単語が多数出現するとTfのスコアが線形に増加していくためしてスコアが異常に高くなる

チューニングができない（いじれるパラメーターがない）
これらのTf-Idfの弱点を解決したのがBM25です。BM25の計算式が以下になります。

\text{score}(D, Q) = \sum_{i=1}^{n} \text{IDF}(q_i) \cdot \frac{f(q_i, D) \cdot (k_1 + 1)}{f(q_i, D) + k_1 \cdot \left(1 - b + b \cdot \frac{|D|}{\text{avgdl}}\right)}
なんのこっちゃという感じだと思いますか、各部分について見ていくとtfの増加を抑える、ドキュメント内の総単語数のばらつきによる不公平性を解消していることが数式から見て取れます。


BM25の各項の意味合いの解説
Tf-Idf、BM25についてはアイシアさんの以下の解説動画が非常にわかりやすいのでおすすめです。
【自然言語処理】tf-idf 単語の情報量を加味した類似度分析【Elasticsearch への道①】#084 #VRアカデミア
【自然言語処理】BM25 - tf-idfの進化系の実践類似度分析【Elasticsearch への道②】#085 #VRアカデミア
!Sparse Vectorを得るときは単語ごとにスコアを出す必要がありますが、多くのSparse Embedding Modelは日本語に対応しておらず、スペース区切りの文字列を一単語とみなしてベクトルを導出する場合が多いです。
そのため、日本語のドキュメントに対してBM25を行う場合は、前処理としてMeCabなどの形態素解析ライブラリを用いて文章の分かち書きを前処理として行う必要があります。
オープンソースのVectorDBであるQdrantのSparse Embedding Modelの実装は以下の通りです。
import MeCab
from fastembed import SparseTextEmbedding

sparse_embedding_model = SparseTextEmbedding(model_name="Qdrant/bm25")

# 分かち書き用の形態素解析エンジン
mecab_tagger = MeCab.Tagger("-Owakati -d /usr/lib/x86_64-linux-gnu/mecab/dic/mecab-ipadic-neologd")

doc = "私はお腹が減っています。"

# "私はお腹が減っています。" -> "私 は お腹 が 減っ て い ます 。"
doc = mecab_tagger.parse(doc)

# valuesはtf値、indicesは各単語に対応するベクトルの次元数
# values=array([1, 1, 1, 1, 1, 1, 1, 1], dtype=int32)
# indices=array([ 779452707,  795346439, 1779716456, 1076539182,  335790990,1007676082, 1977135928, 1821910969], dtype=int32)
sparse_vector = list(sparse_embedding_model.query_embed(doc))[0]
また、先ほど述べた通り、tfはあるドキュメントに対して一意に定義できるのに対して、idfは他ドキュメントとの関係で値が変動するため事前計算ができません。
ではどうやってVectorDBでSparse Embedding Modelによってtf-idfやBM25を実現しているのかというと、Sparse Embedding Modelはtf値を算出し、idfはVectorDB内で存在するドキュメントに応じて再計算されるように設定します。
Qdrantでは、DBを作成時に以下のように設定することでidf値の補正を有効化できます。
from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="{collection_name}",
    vectors_config={},
    sparse_vectors_config={
        "text": models.SparseVectorParams(
            modifier=models.Modifier.IDF,
        ),
    },
)

 SPLADETf-Idf・BM25のようなキーワードは単語の完全一致が前提となっているため、同義語に対応ができないという弱点があります。
これに対応するため、確率計算ではなくLM(Language Model)を用いてSparse Vectorを得る手法が近年考案されています。
LMを用いてSparse Vectorを得ることで、文脈理解ができるというベクトル検索の強みとシンプルで効率の良いキーワード検索の良いところどりをするイメージです。
SPLADEは、BERTなどの事前学習済みのTransformerモデルを使用してテキストをエンコードし、語彙全体に対して各単語の重要度スコアを計算します。これにより、入力テキストに含まれない関連単語にも非ゼロの重みを付与することが可能です。ここで正則化手法（例えば、L1正則化）を適用して、ベクトル(=単語空間)の多くの要素がゼロになるように学習が行われています。


日本語SPLADEモデルにおける語彙拡張の例
上の画像を見れば、クエリに無い「効果」「良い」といった単語に対してもスコアが算出されているのがわかると思います。
@hotchpotchさんが作成された日本語で学習されたSPLADEモデルは、パラメータ数・次元数が少ないにも関わらず、multilingual-e5-largeといったエンベディングモデルよりも高いベンチマークスコアを叩き出しています。


日本語SPLADEモデルのベンチマークスコア

 ハイブリッド検索とRerankerハイブリッド検索とRerankerはベクトル検索、キーワード検索単体で望んだ検索精度が得られない場合に精度向上に有用な手段です。以下でそれぞれ解説していきます。

 ハイブリッド検索これまで見てきたベクトル検索とキーワード検索の長所と弱点をまとめると、以下のようになります。



長所
弱点


ベクトル検索
文脈や文章全体の意味を捉えることができる
学習データに精度が依存するため、学習データに含まれない固有単語に対する対応ができない


キーワード検索

クエリと正確に一致するキーワードを含む文書を返すため、意図した情報を得やすい
単語の出現有無のみを判断するため、文脈や意味を考慮した検索ができない、言い換えに対応できない


これらの検索手法を組み合わせることで弱点を補い合おうというのがハイブリッド検索です。
ハイブリッド検索では、各検索手法において算出されたスコアが融合されて最終的なスコアが計算されます。
代表的なスコア融合アルゴリズムとしてはRRF（Reciprocal Rank Fusion）があります。大体のRetrieverではデフォルトでRRFでのスコア融合を用いるようになっているイメージです。

RRF(d) = \sum_{i=1}^{k} \frac{1}{c + rank_i(d)}
ある検索手法iにおけるドキュメントdの順位を rank_i(d)と定義しています。
cは順位の重みづけを調整するパラメータであり、cを小さくするとある検索手法で上位のドキュメントが支配的になり、大きくすると上位と下位の文書間でのスコアの差が縮まるため複数の検索手法でランキングすることが重要になってきます。デフォルト値としては60がよく使われるようです。

 RerankerLM（Language Model）を用いてドキュメントを質問文に対して関連する順に並べ替え直し、最終的な順位を決定するのがRerankerの役割です。基本的にはベクトル検索などで絞り込んだ文書に対してRerankerを適用してリランキングを行います。


Rerankerによるリランキングの仕組み
日本語に特化して学習されたRerankerとしては、@hotchpotchさんが作成されたjapanese-reranker-cross-encoderなどがあります。
!ベクトル検索に用いられる埋め込みモデルとRerankerはどちらもLM(Language Model)を用いた処理ですが、両者には大きく２点違う部分があります。以下でそれぞれを解説していきます。
再ランク性能が高い
ベクトル検索に用いられる埋め込みモデルはBi-Encoderで特徴量を得ており、1つのセンテンスに対して1つのエンベディングが得られます。
対してRerankerでは、質問文と文章を一つのペアにして評価するCross-Encoderによりスコアを算出することで、より細かなニュアンスや質問と文章の関連性からの文脈的理解を行うことができます。

事前計算ができず遅い
前述の通り、ベクトル検索に用いられる埋め込みモデルでは1つのセンテンスに対して1つのエンベディングを得るため、ドキュメントのエンベディングを事前に計算しておけば、クエリに対して1度エンベディングしさえすれば全ドキュメントに対して少ないコストで類似度を計算することができます。
しかしRerankerでは、クエリとドキュメントの１つ１つをセットで入力する必要があるため、各ペアごとに何度もLMの計算を行う必要があります。
そのため、ベクトル検索やハイブリッド検索で上位ドキュメントに絞り込んだ後で、限られたドキュメントに対してRerankerを適用し最終的なスコアを算出するのが一般的なRerankerの適用方法になっています。

 評価指標基本的にRetrieverの評価に用いられる評価指標は推薦システムのものと同じです。以下で代表的な評価指標を幾つか紹介します。

 Recall@k各クエリに対して、上位 k個のRetrieverで取得したドキュメントに含まれる正解ドキュメント数が、総正解ドキュメント数のうちどの程度の割合含まれているかを計算し、最後にクエリ全体で平均を取って計算します。

 MRR(Mean Reciprocal Rank)
MRR = \frac{1}{|Q|} \sum_{i=1}^{|Q|} \frac{1}{\text{rank}_i}
各クエリ iに対して、取得ドキュメントを上から見たときに最初に正解が出てきた時の順位をrank_iと定義しています。上位に正解ドキュメントがでくるほどスコアが高くなるような式になっていますね！

 MAP(Mean Average Precision)
P@j：上からj番目の予測におけるPrecisionの値（上位j個の予測中に正解がk個あればPrecisionは k / jとなる）

y：j 番目のドキュメントが正解なら１、不正解なら0をとる

GTP：総正解数
これらの値を用いてAP(Average Precision)を以下のように計算します。

AP_i = \frac{1}{GTP} \sum_{j=1}^{k} P@j \cdot y_j
上位の予測に正解が多く含まれているほどPrecisionが高くなりスコアが大きくなるような式になっています。
このAPを各クエリに対して計算し、その平均を取ったものがMAPになります。

MAP = \frac{1}{|Q|} \sum_{i=1}^{|Q|} AP_i

 nDCG(normalized Discounted Cumulative Gain)まずあるクエリに対しての上からj番目の予測について、「おすすめ度＝どれだけ取ってきて欲しいか」をrel_j (0 ≤ rel_j ≤ 1)で定義します。
これを用いてDCGを以下のように計算します。

DCG = \sum_{j=1}^{k} \frac{2^{rel_j} - 1}{\log_2(j + 1)}
上位予測ほど分母が小さいため影響度が大きく、rel_jの値によって、分子が最大1最小0の間の値をとります。
nDCG は、計算された DCG を、考えうる限り最も理想的な DCG （＝予測上位ドキュメントがおすすめ度の最も高い順に並んでいるような場合）で割って正規化します。
!
 参考：ranxこれらの評価指標を自動で算出してくれるライブラリとして、ranxがあります。
ranxでは以下のようにQrelsとRunを定義してあげることで、各評価指標の計算を簡単に行うことができます。
from ranx import Qrels, Run

#クエリq_1に対して正解ドキュメントd_12の関連度は5という意味（自分で定義）
qrels_dict = { "q_1": { "d_12": 5, "d_25": 3 } }

# クエリq_1に対して取得されたドキュメントとそのスコア（Retrieverで取得）
run_dict = {"q_1": { "d_12": 0.9, "d_23": 0.8 }}

qrels = Qrels(qrels_dict)
run = Run(run_dict)

# nDCG@5(k=5)を計算
evaluate(qrels, run, "ndcg@5")
埋め込みベンチマークのようなドキュメント間の関連度を取得しやすいデータセットを用いてRetrieverを評価したいような場合には、非常に便利なライブラリです。
!
 参考：ragasRetriever自体の評価をしたい場合は以上で挙げた評価指標を用いれば良いのですが、LLMと組み込んだアプリケーションを構築する際には、RAGパイプライン全体としての性能を評価したいことがよくあると思います。そんな時に便利なのがragasというライブラリです。
ragasでは、以下の4種類の情報のいくつかを入力として、LLMやCross-Encoder Modelを用いて評価値を計算してくれます。

question：RAGシステムに入力された質問

contexts：外部知識ソースからRetrieverによって取得されたコンテキスト

answer：questionとcontextsを元にしてLLMが生成した回答

ground_truths：質問に対する理想的な回答（教師データ）
ragasによって評価できる指標は以下の通りです。


評価指標
評価基準
入力
評価対象


Faithfulness
生成された回答が、どの程度コンテキストに基づいているか
question, contexts, answer
生成モデル

Answer Relevancy
質問に対して簡潔かつ適切に回答しているか
question, answer
生成モデル

Context Precision
コンテキストを正確に取得できているか
question, contexts
検索モデル

Context Relevancy
コンテキストと質問に関連性があるか
question, contexts
検索モデル

Context Recall
教師データからコンテキストをどの程度再現できるか
contexts, ground_truths
検索モデル

Answer Semantic Similarity
回答が教師データとどの程度類似しているか
answer, ground_truths
End to End

Answer Correctness
回答がどの程度正確か
answer, ground_truths
End to End

Aspect Critique
回答が特定の品質基準を満たしているか
question, context, answer
生成モデル


 各種クラウドサービスにおけるRetrieverの特徴最後に各種クラウドサービスでどのようにRetrieverを実現できるのか、主に検索手法に重点を置いて提供されているサービスの特徴を見ていきます。
ざっと調べただけなので情報が古かったり解釈を間違えている可能性がありますのでご了承ください🙏

 AWSAWSでは、Retriever用のサービスとしてAmazon OpenSearch Serviceが提供されています。
https://aws.amazon.com/jp/opensearch-service/
Amazon OpenSearch Serviceの主な特徴としては以下が挙げられます。
テキスト内の文字の置換、削除、テキスト分割後の後処理も指定できる
日本語の解析は形態素解析エンジンの Kuromoji がベースのトークナイザで行われる
カスタム辞書を作成可能
ハイブリッド検索は可能だが、リランカーの実装にはAmazon Kendra Rerankerとの連携が必要（参考）
Dashboardがイケてて、データ収集・分析のための機能が豊富
他にもAmazon KendraがRetriever用のサービスとして提供されており、こちらはAmazon OpenSearch Serviceより少し料金がかかるようですが、SharePointやBoxといった外部データサービスとの連携やPDFなどのドキュメントの文章化を内部的に行えるなど便利な機能をたくさん内包しています。

 Google Cloud Platform (GCP)GCPでは、Retriever用のサービスとしてVertex AI Searchが提供されています。
https://cloud.google.com/generative-ai-app-builder/docs/enterprise-search-introduction?hl=ja
Vertex AI Searchの主な特徴としては以下が挙げられます。
Vertex AI Agent Builderの一部として内包されており、LLMを用いたエージェントアプリケーションの構築を簡単に行える
Vertex AI の生成 AI を使用すると、テキスト エンベディングとマルチモーダル エンベディングの両方を作成することができる
日本語解析の機能はついておらず、ハイブリッド検索を行うには形態素解析を用いて自前でSparse Vectorを作成しなければならない（参考）
VertexAIの高性能なエンベディングモデルなどのサービスとの連携がVertex AI Search独自の強みかなと思います。

 Microsoft AzureMicrosoft Azureでは、Retriever用のサービスとしてAzure AI Searchが提供されています。
https://learn.microsoft.com/ja-jp/azure/search/search-what-is-azure-search
Azure AI Searchの主な特徴としては以下が挙げられます。
日本語アナライザーを搭載しており、日本語のキーワード検索にネイティブ対応している
セマンティックリランカーによるリランキング、Microsoft 製のLLMである Turing モデルによって抽出的要約を行った意図の答えとなるチャンクの断片をピンポイントで返してくれる「セマンティックアンサー」を機能として備えたセマンティックハイブリッド検索という強力な検索方法を使うことができる
Reranker、Sparse Embeddingモデルを用意しなくても高精度な検索を実現できることがAzure AI Searchを用いる大きな利点であるといえます。

 比較他サービスと比較して、Azure AI SearchはRerankerまでを含めた高度な検索手法をそれ単体で実現できるのが大きなアドバンテージだなと感じました。
しかし、Amazon OpenSearch Serviceにはテキスト処理のカスタマイズ性や豊富な分析機能、Vertex AI SearchにはVertex AIとの強力な連携など各サービス独自の強みがあるので、各サービスの独自の強みを活かしつつ、プロジェクトの要件に最適なものを選択することが重要です。
今回は検索手法に主に重点を置いて各サービスについて比較して見ましたが、実際にアプリケーションを構築する際にはデータをインデックスする際の手軽さ、他サービスとの連携、料金といった面も考慮に入れて考える必要があると思います。

 おわりにこちらのテックブログは，画像生成やLLM開発などを通して，社内の技術力を先導しているneoAIの研究組織「neoAI Research」メンバーで執筆しています．
「未来を創る生成AIの先駆者になろう」
neoAIでは最先端技術を駆使するプロフェッショナル集団として，業務効率化を超えて社会に新たな価値を創出していきます．あなたの好奇心と可能性を，neoAIで開花させてみませんか？
【現在採用強化中です！】
・AIエンジニア/PM職
・Biz Dev
・自社プロダクトエンジニア職
・オープンポジション
【詳しい採用情報はこちらから！】

https://neoai.jp/career
	長所	弱点
ベクトル検索	文脈や文章全体の意味を捉えることができる	学習データに精度が依存するため、学習データに含まれない固有単語に対する対応ができない
キーワード検索	クエリと正確に一致するキーワードを含む文書を返すため、意図した情報を得やすい	単語の出現有無のみを判断するため、文脈や意味を考慮した検索ができない、言い換えに対応できない
neoAIPublication
neoAIは生成AIに特化した東大松尾研発スタートアップです。
	ある	に	の	は	京都	北	南	大阪	札幌	東	東京	西	那覇
doc0	1	1	1	1	0	0	0	1	0	1	1	0	0
doc1	1	1	1	1	0	0	0	1	0	0	1	1	0
doc2	1	1	1	1	1	1	0	1	0	0	0	0	0
doc3	1	1	1	1	0	1	0	0	1	0	1	0	0
doc4	1	1	1	1	0	0	1	1	0	0	0	0	1
評価指標	評価基準	入力	評価対象
Faithfulness	生成された回答が、どの程度コンテキストに基づいているか	question, contexts, answer	生成モデル
Answer Relevancy	質問に対して簡潔かつ適切に回答しているか	question, answer	生成モデル
Context Precision	コンテキストを正確に取得できているか	question, contexts	検索モデル
Context Relevancy	コンテキストと質問に関連性があるか	question, contexts	検索モデル
Context Recall	教師データからコンテキストをどの程度再現できるか	contexts, ground_truths	検索モデル
Answer Semantic Similarity	回答が教師データとどの程度類似しているか	answer, ground_truths	End to End
Answer Correctness	回答がどの程度正確か	answer, ground_truths	End to End
Aspect Critique	回答が特定の品質基準を満たしているか	question, context, answer	生成モデル
はじめに

Retrieverとは？

ベクトル検索

参考：近似最近傍探索

キーワード検索

tf-idf

BM25

SPLADE

ハイブリッド検索とReranker

ハイブリッド検索

Reranker

評価指標

Recall@k

MRR(Mean Reciprocal Rank)

MAP(Mean Average Precision)

nDCG(normalized Discounted Cumulative Gain)

各種クラウドサービスにおけるRetrieverの特徴

AWS

Google Cloud Platform (GCP)

Microsoft Azure

比較

おわりに

Discussion
