RAGは死んだのか？
ここで今RAGを使う理由があるのか考察
そもそもRAGが生まれた経緯は？
https://zenn.dev/spiralai/articles/8af7cbf526c2e1GPT連携アプリ開発時の必須知識、RAGをゼロから解説する。概要＆Pythonコード例
> この技術は、大規模な言語モデルが生成するテキストの品質と関連性を向上させるために、外部の情報源からの情報を取得（retrieval）して利用します。
情報の正確性を上げる
Perplexity.aiがgoogleの検索結果を持ってくるいち早いサービスだった
>要は、ChatGPTなどの言語モデルに特殊な知識に関連した情報を喋らせる技術だと言えますね。
特殊な知識を与える
コンテキスト長を生かすことでRAGを置き換えられる？
情報の正確性を上げる
もともとハルシネーションを減らすために導入された(と思われる)が、最近のモデルは優秀なのでそこまで重要視されていないかも
ドメイン知識を与える
ドキュメントを渡すことで特定領域の知識を参考にした回答を得る
これはコンテキスト長が長くドキュメントが小さいならそのまま入れてもいいが...
サービスの場合はAPIの料金を見ると本体は高いのでアドバンテージがある
pricing
| OPENAI API | iuput | output |
| text-embedding-3-large | $0.13 / 1M tokens | |
| gpt-3.5-turbo-0125 | $0.50 / 1M tokens | $1.50 / 1M tokens |
RAGはドキュメントのどこを参考に出力したのかわかるので正しい情報なのか確かめに行ける
ローカルではコンテキスト長に任せるには悩みもある
VRAMの必要量がコンテキスト長の二乗のコストがかかる
他のサービスのようなコンテキスト長を長くして計算するにはコストが膨大
結論
ドキュメントがある場合、ファイルを渡すだけでドメイン知識を返してくれるAIができるのは便利
流石に数百ファイル渡すのはお金/時間がかかる
ローカルで動かす分にはコンテキスト長を増やすとコストが爆増し動かないので効果がある
数ページならコンテキストに乗せるのも現実的
参考
https://zenn.dev/ye7777/articles/b543d4728acb3c巨大コンテキスト長を持つモデルの誕生によってドキュメントのchunkingは時代遅れとなるか？