Open6
RAG周りの論文メモ
atfujitaImproving Text Embeddings with Large Language Models
問題意識
- Contriever, OpenAI Embeddings, E5, BGEはマルチステージ学習(最初に大規模な弱教師ありテキストペアで対照学習して、小規模で高品質なデータでファインチューニングしている)。ただ、幅広いタスクと言語に対処するために大量のラベル付きデータが必要になる。
- Doc2Query, Promptagatorのように文飾からラベルとなるクエリ文を生成するアプローチもある。GPLのようにクエリ文から文書を生成するアプローチもある。ただ、クエリ文 or 文書のどちらかのデータの準備が必要。
- RepLlama-2, SGPT, GTR, UdeverのようにLLMから埋め込みを得るアプローチもある。一方でその精度は小さな埋め込み専用（双方向のエンコーダー）モデルには及ばない。
本論文のアプローチ
- GPT4を使って、事前に生成したタスクのリストから、タスクの種類、クエリの長さと明瞭さ、（正例と負例の）文書の単語数、言語の種類をランダムに割り振ってデータを生成した。
- 生成したペアデータセットからタスクごとに準備した指示チューニング用のテンプレートへ入力。手動でタスクを定義したMS-MARCOデータセットや13のPublicデータセットも使用。クエリと文書の末尾にEOSトークンを追加して、最後のレイヤのEOSのベクトルをそれぞれの埋め込み表現とする。
- モデルは事前訓練済みのMistral-7bを使用。RoPEで32kまで入力コンテキストを取れるようにした。
- 1 epochのファインチューニングでRankLlamaのレシピとLoRA(ランクサイズ=16)を使用。損失関数はInfoNCE loss。GPUメモリ削減のため、Gradient checkpointing, Mixed Precision, DeepSpeed ZeRO-3を使用。学習時間はV100 * 8で3日ほど。
評価とAblation Study
- MTEBデータセットで評価。他との比較のため、先頭の512トークンだけで評価した。基本的にSOTAであったが、全データの場合が最も良かった。また、合成データだけ、合成データ+MSMARCOでも十分な結果であった。一方でMIRACLデータセットで多言語比較すると英語以外ではE5に劣る言語が多かった。これはMistral-7bがほぼ英語データセットで事前訓練されているからとの分析。
- 対照学習での事前訓練は必要か分析。論文の手法についてはその恩恵はほとんどなく、ファインチューニングだけで効果的に埋め込みモデルが得られるとの結論。
- 長いコンテキストでの能力を評価するため、合成データセットで評価。スライディングウィンドウのサイズとRoPEを変えて比較。ウィンドウサイズをデフォルトの4kから32kへ徐々に大きくしていくとRoPE rotation baseを10^4から10^5に変更しないと著しく精度が落ちる結果に。一方で、長いコンテキストに対応するための変更は、短いコンテキストで精度が落ちるというトレードオフが依然として存在した。
- Poolingのタイプ、LoRAのランクでパフォーマンスは大きく変わらなかった。一方で、指示チューニング用の指示文はパフォーマンスに大きく影響を与えた（指示文次第でファインチューニング自体を行わなくても良い可能性もあり）。
atfujitaSeven Failure Points When Engineering a Retrieval Augmented Generation System
- 3つのケーススタディからRAGの構築で起きうる7つの障害点を見つけた。
- RAGシステムが失敗する7つのポイント
- コンテンツの欠落
- 検索された関連文書から回答が導き出せない質問でもシステムは応答し、誤った回答をしてしまう可能性がある。
- 関連文書の見逃し
- 質問に関する回答は文書集合にあるが、システムで利用されるTop kに含められないケース。
- コンテキスト生成段階での欠落
- 検索された関連文書からコンテキストを生成する段階で、回答部分がコンテキストから漏れてしまうケース。
- LLMが抽出できない
- コンテキストに回答が含まれるが、LLMがそれを利用できないケース。これはコンテキスト内にノイズが多かったり、矛盾が含まれている場合に発生する。
- 誤ったフォーマット
- 質問では表やリストなど特定フォーマットで出力することが指定されているが、LLMがそれを無視してしまっているケース。
- 誤った具体性
- LLMから応答が返されるが、それが具体性に欠けたり、ユーザのニーズに対応するには具体的過ぎるケース。これはユーザの質問が曖昧な場合でも発生する。
- 不完全な回答
- 回答が誤ってはいないが、一部の情報が欠落して全てを満たせていないケース。良いアプローチは個別に質問するなどの対応。
- コンテンツの欠落
- この分析で得られたこと
- 文書のチャンキングは、質問クエリとの類似度を高めるために重要。体系的な評価フレームワークが確立されると良い。文書検索精度を高めるためのクエリの前処理も重要。
- 質問と期待される応答がアプリケーション固有でテスト手法が確立されていないため、RAGシステムの検証は運用でのみ実行可能な状態。したがって、RAGシステムのロバスト性は、最初の設計段階ではなく、システムを進化させていくことで得られる。
atfujitaText Embeddings by Weakly-Supervised Contrastive Pre-training
問題意識
- 言語モデル（BERT, T5など）を限られた数のラベル付きデータセット（SNLI, MS-MARCO）でFine-tuningする先行研究は短いセンテンスの埋め込み表現に焦点が当てられていて、長い文書での問題はそのままになっている。
- 言語モデルそのものは埋め込みモデルに理想的とは言えないので、埋め込みモデルを事前学習するアプローチも増えている。しかし、大量の低品質生成データで事前学習したモデルでは、BM25のような古典アプローチに勝てないケースもある。
本論文のアプローチ
- Zero-shot, Few-shotで使える汎用の事前学習済み埋め込みモデル、E5（EmbEddings from
bidirEctional Encoder rEpresentations）を提案。 - 大規模に収集したテキストペアデータセット、CCPairsデータセットを構築。
- Redditの投稿とコメント、Stackexchangeの質問と最も投票された回答、英語Wikipediaのエンティティ名+セクションタイトルとパッセージ、Common Crawlのタイトルとパッセージなどが含まれる。クリーニング後のペア数は1.3BでそのほとんどはRedditとCommon Crawlから来ている。
- Consistency-based filter: 一度、1.3Bで学習したモデルでそれぞれのテキストペアのパッセージを100万件のランダム抽出したパッセージの中で検索。top k（論文ではk=2）に入らないペアは品質が低いと判断した。その結果、約270Mのテキストペアとなった。
- モデルの事前学習はCCpairsを使った対照学習。損失関数はInfoNCE loss。質問とパッセージがどちらでも問題ないデータソースはランダムに入れ替え。学習中の負例の選択方法はin-batch negatives（バッチ内の他のペアからのパッセージを使う）。MiniLM（E5 small）, BERT base（E5 base）, BERT large（E5 large）に基づいたモデルでBS=32,768（負例を多く含めたい）、20k steps（2.5 epoch相当）学習。V100（16, 32, 64枚）で1-2日程度。Gradient checkpointing, Mixed Precisionを使用。
- パフォーマンスをさらに向上させるためにラベル付きデータセットでFine-tuningをした。データセットはSNLI, MS-MARCO, NQ。BS=256で3 epochs、8 GPUsで学習。
評価とAblation Study
- BEIRベンチマークで評価。Fine-tuningをしていない事前学習済みモデルでもほとんどのデータセットでBM25や既存の手法に勝った。Fine-tuning済みではさらに性能が向上。MTEBベンチマークでもパラメータが300MしかないE5 largeで4.8BのSentence-T5 xxlなどに匹敵するパフォーマンスであった。
- BERT+Fine-tuningと比較したが、CCpairsデータセットで事前学習している方が性能が良かった。
- 負例を増やすためにバッチサイズを大きくするアプローチは有効だった。
- ダウンストリームのタスクによって、最良の結果が得られるFine-tuningに使うデータセットの組み合わせは異なる。
- Consistency-based filterはパフォーマンス向上に貢献する。
- Negative Samplingの手法として、in-batchが一番良かった。
- BERT → RoBERTaはパフォーマンスが落ちた。
atfujitaTowards General Text Embeddings with Multi-stage Contrastive Learning
E5との差分があまりなかったので、気づいた違いの部分だけを列挙
- より大規模でより多様なデータソース（プログラミングコードも使用）を特にフィルタリング、クリーニングなどせずに事前学習に使用（約800Mテキストペア）。高品質な教師ありデータをこれまたいろいろと集めてFine-tuningに使用（約3Mテキストペア）。
- query, passageなどのタスク特有のプロンプトを使っていない。
- 事前学習時にデータソースの不均衡を緩和するために多項分布サンプリングうを使用。
- 学習中の負例の選択方法はin-batch negativesを使用するが、クエリとパッセージ間でも入れ替える。
atfujitaMultilingual E5 Text Embeddings: A Technical Report
問題意識
- ほとんどの埋め込みモデルは英語のデータセットで学習されており、多言語での適用に限界がある。
本論文のアプローチ
- E5を多言語に拡張したmE5を提案（2023年中頃にリリースされている）。さらにこの論文ではImproving Text Embeddings with Large Language Modelsで提案されたGPT3.5/4で生成したデータを使ってInstruction-tuningされたmE5-large-instructについても提案。
- 基本はE5の学習手続きに従っている。データはWikipedia, mC4, Multilingual CC News, NLLB, Redditなどから多言語のテキストペアを1Bほど集めて対照学習による事前学習。バッチサイズ=32k, 30k steps, 損失関数はInfoNCE loss, 学習中の負例の選択方法はin-batch negatives（バッチ内の他のペアからのパッセージを使う）。他のハイパーパラメータはE5論文に従う。
- さらにいろいろなところから教師ありデータを1.6Mほど集めてきてFine-tuning。
- mE5-large-instructでは、GPT3.5/4で生成した500kのデータを使用（150kの固有の指示と93の言語をカバーしている）。指示テンプレートは元論文に従っている。
評価とAblation Study
- MTEBベンチマークの英語部分で比較するとmE5-large-instructはCohere-multilingual-v3, BGE-Large-en-v1.5を上回りSOTAの性能であった。
- MIRACLベンチマークで他言語での検索性能を比較するとm5EはBM25, mDPR（MIRACLのTrainでFine-tuningされている）を上回る性能だった。
- Bitext Mining（語彙の重なりがほとんどない2つの文をマッチングするタスク）においても、mE5-large-instructは、mContriever-msmarco, LaBSEを上回る結果だった（BUCC 2018 4 langs, Tatoeba 112 langsで評価）。
- MIRACLの言語別精度がAppendixにあったが、日本語に関してはmE5-large-instructよりもmE5-largeの方が若干精度が高い結果であった。
atfujitaJapanese SimCSE Technical Report
問題意識
- ほとんどの文埋め込みの研究は英語を対象としているので、日本語の文埋め込みについてまとまったリサーチがない。
本論文のアプローチ
- 教師あり学習用データセット：JSNLI, JaNLI, NU-NLI（今回の研究用にChatGPTを使ってSNLIとMNLIを翻訳したデータセットを作成。）
- 教師なし学習用データセット：Wiki40B, Wikipedia, BCCWJ, CC100
- 評価用データセット：JSICK, JSTS
- 24の日本語or多言語事前学習モデルをすべてのデータセットで4つのバッチサイズパターン、3つのlearning rateパターンで実行。
- NVIDIA A100とRTX A6000で実験。
- BF16、gradient checkpointing、linear warmupを使用。
- 最大シーケンス長は64。
- 温度パラメータはOptunaを使ってTuningした結果、0.05に設定。
評価とAblation Study
- 結果の一覧：https://github.com/hppRC/simple-simcse-ja/tree/main/results
- モデルとデータセットの評価
- 今後の研究のベースラインとして日本語文埋め込みモデルを公開