Rag
Filed under
7 posts
ベクトルデータベースは何が最初に壊れるかで選ぶ
ほぼすべてのRAGシステムはpgvectorから始めるべきだ。問うべきはどのベクトルデータベースが最速かではなく、どの障害モードが最初に自分に届くかである。
モデルへの扉はひとつに。第7回 Azure AI Searchかベクトルデータベースか
Azure AI Searchはベクトル数ではなくSKUでキャパシティを課金し、vector indexはtierのメモリで上限が決まる。第7回はretrievalを機能ではなく制限で決める。
自社ドキュメント経由のプロンプトインジェクション: RAGの攻撃面
ナレッジベースは信頼できない入力源だ。検索は攻撃者が書いたテキストをそのままモデルに渡してしまうため、取り込み時点でのスキャンが最も有効な対策となる。
コンテキストウィンドウは味方ではない
巨大なコンテキストウィンドウは検索の代わりにはならない。プロンプトが長くなるほど再現率は落ち、トークン数に比例してコストは増え、中間部分は読み飛ばされる。
エージェント型RAGの正体は、大半が不要なレイテンシである
エージェント型RAGは検索ホップをループで回し、各ホップはモデルとの往復になる。ほとんどの質問には1回の良いクエリで十分だ。ループはレイテンシに見合う場合だけ使う。
ファインチューニングをやめよ。必要なのはRAGとキャッシュとより良いプロンプトだ
ファインチューニングとプロビジョンドスループットの組み合わせは、ほとんどのLLMの問題に対する高価な答えだ。より安価な道は検索、プロンプトキャッシュ、より良いプロンプトにある。
Knowledge Baseのチャンキングこそ、RAGの品質が死ぬ場所
ほとんどの誤ったRAGの回答は、モデルの問題ではなく検索の問題だ。Bedrock Knowledge Basesにおける固定長、セマンティック、階層型チャンキングがどう品質を決めるかを解説する。