RAG に関する資料をメモ的にまとめます。
概要
触ってみる
OpenAI を使った記事です。シンプルにまとまっていて、利用例としてイメージが湧きやすいです。
プロンプトに関連情報を埋め込みます。
prompt = PromptTemplate(
template="""
文章を前提にして質問に答えてください。
文章 :
{document}
質問 : {question}
""",
input_variables=["document", "question"],
)
このように書かれています。
「何を抽出するか」と言うところがRAGで一番難しいところである。
これについては以下の記事が詳しいです。
ローカル LLM
Azure
AzureでRAGをガンガン試行錯誤してみて得たナレッジを紹介します!https://t.co/Clds6aVeEF
— 幻日 (@__genzitsu__) February 8, 2024
わりと普通の着地になってるけど、index登録時に入れるテキストを整形すること、特定性の高い情報はmetadataに入れておくとよいという感じ
凡事徹底が意外とできんのよな(説明コスト的に)
「Azure OpenAI ServiceではじめるChatGPT/LLMシステム構築入門」を共同執筆しました。
— Hirosato Gamo | AI Cloud Solution Architect (@hiro_gamo) December 22, 2023
ChatGPTが登場して、ほとんどLLMの仕事しかしてないメンバばかりで作った渾身の1作です。
さいきん血反吐だしてた理由はこれの執筆も一因です。
内容は↓
・LLMの基礎やプロンプトエンジニアリング
・Azure… pic.twitter.com/B3SoJ2Zbja
RAGにおいて、Microsoft Azure AI Searchだと、全文検索とベクトル検索を組合せたHybrid検索に、セマンティックランキングを組合せた方法が一番精度出る。
— Shinichi Takaŷanagi(減量中) (@_stakaya) March 2, 2024
※毎度どこかに行ってしまう情報源なのでメモhttps://t.co/6yEUmEThYt pic.twitter.com/yKhZz6EgJk
AzureでRAGを構築するアーキテクチャがまとまってて良い。
— Shuichi Ohsawa (@ohsawa0515) March 12, 2024
Azure素人からするとAzure OpenAI Service以外にどんなサービスがあってどう組み合わせればいいか分からなかったからとてもありがたい。
この記事を目印にドキュメントを読んでいけば欲しい情報は得られそう。https://t.co/WVAQzWTITl
手法など
RAG Fusionについてはおじろさんの資料がわかりやすかった。
— ML_Bear (@MLBear2) February 17, 2024
従来のRAGでは1個のクエリで事前知識を検索して利用するのに対し、RAG Fusionではクエリ拡張て得られた複数の検索クエリで幅広に検索した上で、その結果をReciprocal Rank Fusionでマージして使おうという発想。https://t.co/dDcPjQ8VeE
HippoRAGが従来のRAGと大きく違う点は、ベクトルデータベースやコサイン類似度による検索を強いない点です。これはかなり大きい特徴です。HippoRAGのポイントは、ナレッジグラフを活用した(ベクトルDBを使わない)RAGである点・ナレッジグラフを賢く更新する点です。
情報検索
しばらくRAGの精度向上案件ばかりやっていたけど、vector searchもhybrid searchも魔法ではないので「そもそものデータを綺麗にしろ」ってケースが多すぎる。
— Mitarashi (@mitarashiponta) July 12, 2024
検索周り頑張るよりも、ドキュメントをLLMでひたすら整形→想定問答集みたいなQA作ってRAGしたほうが精度良い。…
Retrieval(情報検索)はベクトル検索に限定されない一般の検索技術
RAGについて。昨今広まってるが同じ単語でも人によって使い方が違うのでまとめとく。
— ざわきん/zawakin (@zawawahoge) April 7, 2024
RAGは、外部情報をLLM入力に含めてLLMの能力を“拡張“できるようにする手法。
適切な外部情報の見つけ方は何でも良くてベクトル検索でも全文検索でもLLMによる行動選択でも良い。
ベクトル検索だけがRAGじゃない。
RAGというとなぜかベクトル検索(Semantic Retrieval)とセットで語られることが多いが、Retrieveは別になんでも良くて、全文検索でもgrepでもDB queryでもなんかAPI叩いて返ってきた結果でも、本当になんでも良い
— すずどら (@sz_dr) April 5, 2024
RAGのRetrieval部分は要するに「検索システム」。これをEmbeddingによるベクトル化が必須だと考える必要はない。既存の検索エンジン、SQLサーバー、検索エンジン用に進化した検索システム・・・、自然言語によるクエリーで自然言語の情報がとってこれれば、あとはLLMに渡してRAG成立。
— 平岡 憲人(HIRAOKA, Norito) Stand with Ukraine (@onokoro48) April 4, 2024
RAGにおいて、ベクトル検索だけじゃなく全文検索も加えたハイブリッド検索じゃないとパフォーマンスが出ないことを試してみた、というMicrosoft方の記事。RAG =ベクトル検索という風潮があるが、そうではない、と。https://t.co/NGanOFABgc
— Shinichi Takaŷanagi(減量中) (@_stakaya) June 11, 2024
RAGについて個人的に一番問題だと思ってるのが、Retrieval-Augmented Generationなのにretrieval(情報検索)分からない人がやってるってことじゃないですか!?
— べいえりあ (@mr_bay_area) April 4, 2024
検索エンジンは難しい。IndexingやScoring、クエリの組み立てなど構成要素一つ一つに専門的知識必要で、ふわっとベクトル検索すればいいとかそういうものではない。なのだけど、ふんわり検索でRAGみたいな話が聞かれることが増えている。というのも規約とか元データとしてある程度綺麗なドキュメントな…
— 松本 勇気 | LayerXはSaaS+Fintechの会社です (@y_matsuwitter) April 4, 2024
LLMの結果をRAGで改善、と言ってるのに全く検索エンジンの中身を調べたこと無い勢のみなさ〜ん、こ〜んに〜ちは〜!!
— Toshinori Sato (@overlast) April 4, 2024
今から以前に読んだ本をオススメするから買ってね〜!!
まずこちら。実装周りを網羅的に扱った日本語で読める中では最も最近のもの。悩まず買ったら良いhttps://t.co/MEA3uxCYTb
巨大コンテキストウィンドウ
【悲報:Genimi 1.5 ProでRAG終焉のお知らせ】
— チャエン | 重要AIニュースを毎日発信⚡️ (@masahirochaen) February 18, 2024
前々からセミナー等では話していた、「コンテキストウィンドウが膨大になればRAGは不要になる」という未来が3年後くらいかなと思いきや、もう現実になった。
AI事業者は必見の内容です。
本当に最近のAI技術革新が激しすぎる。
58ページのGenimi 1.5… pic.twitter.com/CJi4HlV7yM
タイトルは煽りっぽいけど資料が豊富。1.5は対象データセットが1M tokenに収まればRAG作る苦労がないしrecall rateも高くてすばらしい一方で、生成にかかる遅延も無視できなくなる。データセットの大きさや遅延の要件に応じてRAGと使い分けかな。 https://t.co/h3NX7FNDFw
— Kazunori Sato (@kazunori_279) April 9, 2024
コンテキストが長くなりRAG is dead的な主張、APIの多くはトークンあたりで課金され、全ドキュメントを読み込ませるのはリクエストの都度お金かかるからやっぱり検索を挟めるRAG大事!!、というので落ち着いたのかと思ってた。
— Yuki Yada / 矢田宙生 (@arr0w_swe) April 4, 2024
自前でモデル作るガッツがあってもまぁまぁ、お金掛かりそう。
LLM
LLM(大規模言語モデル)の簡単な仕組みの解説
— 山本一成🌤️チューリングのCEO (@issei_y) February 8, 2024
ChatGPTを含めたLLMは驚異的な性能を誇ります。ではLLMはどのような機械学習でその能力を獲得したのでしょうか。秘密は「次の単語の予想」です。… pic.twitter.com/WZ0d6PHHVc
発言埋め込み
X の発言は URL を書くだけで埋め込めますが、中身が表示されるまでタイムラグがあるため blockquote で埋め込んでいます。