【AWS AIF対策】RAGとベクトルデータベース

Transcript

1. 2026年9月 RAGとベクトルデータベース AWS Certified AI Practitioner 対策 #10 赤神青空
2. ▪温度を下げるほど、答えのばらつきは小さくなる 前回のクイズの答えは「B」 前回のクイズ 社内の問い合わせに、同じ質問へは できるだけ同じ答えを返させたい。 推論パラメータをどう設定する？ 温度 低 毎回ほぼ同じ答えになる 温度 ⾼ 答えがばらつく 答えは B 今ココ おさらい A 温度を⾼くする ばらつきはむしろ⼤きくなる B 温度を低くする 確率の⾼い語が選ばれやすくなる C 最⼤出⼒トークン数を⼤きくする ⻑さの上限。ばらつきには効かない を⼤きくする D Top-K 候補が増えてばらつきが増える 2/13
3. ▪だから、答える前に資料を探して渡す 基盤モデルは、社内のことを知らない RAGなし 「経費精算の 上限は？」 社内の規程は学習していない。 知らない、または、もっともらしい誤り モデル RAGあり 「経費精算の 上限は？」 社内の資料を 検索 モデル 規程に基づいて 答えられる RAG ＝ 答える前に、関連する資料を探してモデルに渡す仕組み 今ココ RAGとは 3/13
4. ▪あらかじめ作っておき、質問のたびに検索する RAGは、準備と実行の2つに分かれる 準備（あらかじめ1回） 資料 チャンクに 分ける 埋め込みに する ベクトルDBに 保存 実⾏（質問のたび） 質問 埋め込みに する ベクトルDBを 検索 資料と質問を モデルへ 答え ⻘は同じベクトルデータベース。準備で作っておき、質問のたびに検索する 今ココ RAGとは 4/13
5. ▪本文とベクトルを一緒に置いておく 準備：チャンクに分けて、ベクトルにして保存 資料 チャンク 社内の 規程 埋め込み（ベクトル） 保存 3.2 経費の上限 [0.12, -0.34, …] ベクトル データベース 3.3 申請の期限 [0.08, 0.41, …] 1.1 出張旅費 [-0.21, 0.17, …] 本⽂ 1 ＋ ベクトル 本⽂ 2 ＋ ベクトル 本⽂ 3 ＋ ベクトル チャンクの本⽂とベクトルを⼀緒に保存する。検索でベクトルが当たったら、その本⽂を取り出す 今ココ RAGの中身 5/13
6. ▪語が一致していなくても見つけられる 検索：質問もベクトルにして、近いものを探す 意味が近いものほど、ベクトルも近い 取り出すのは、近い順に上位3件 経費規程 3.2 経費の上限 経費規程 3.3 申請の期限 質問 語が⼀致していなくても、意味が近ければ⾒つかる 今ココ RAGの中身 出張旅費規程 1.1 旅費の扱い ⽩は遠かった資料。取り出さない 件数は設定で変えられる 6/13
7. ▪指示・資料・質問をまとめて1回で渡す 取ってきた資料は、プロンプトに入れて渡す モデルに渡すプロンプト 指⽰ 資料だけを根拠に答えて 取ってきた資料 チャンク3件の本⽂ モデル 規程に基づいた 答え 質問 経費精算の上限は？ 渡す資料が多いほど⼊⼒トークンは増える。コンテキストウィンドウの上限に収める（第9回） 今ココ RAGの中身 7/13
8. ▪試験ガイドに例として挙がっている4つ 埋め込みを置ける AWS のサービス Amazon OpenSearch Service 検索エンジン。全⽂検索と ベクトル検索を⼀緒にできる Amazon RDS for PostgreSQL 同じく pgvector。既存の業務 データと同じDBに置ける Amazon Aurora リレーショナルDB。PostgreSQL 互換版で pgvector が使える Amazon Neptune グラフDB。Neptune Analytics で ベクトル検索ができる 試験ガイドに例として挙がっているのはこの4つ 旧版のガイドには DocumentDB を含む5つ。⼀覧にないサービスにもベクトルは置ける 今ココ AWSのサービス 8/13
9. ▪BedrockKnowledge Bases に任せる の機能。分割・埋め込み・保存・検索をまとめて引き受ける S などの データソース Knowledge Bases 分割‧埋め込み‧保存‧検索 マネージド型 ベクトルストアも Bedrock が⽤意する。 つなぐデータを指定すれば動く モデル 答え カスタマー管理型 ⾃分のベクトルストアを使う。 OpenSearch Serverless‧Aurora‧Neptune Analytics RAGの⼿順をまとめて引き受けるのが Bedrock Knowledge Bases 今ココ AWSのサービス 9/13
10. ▪知識をモデルの外に置くか、中に入れるか RAGとファインチューニングの使い分け RAG ファインチューニング 知識の置き場 モデルの外（ベクトルDB） 知識の置き場 モデルの中 更新 資料を⼊れ替えて取り込み直せば反映 更新 学習をやり直す必要がある 実⾏のたび 検索が⾛り、⼊⼒トークンが増える 実⾏のたび プロンプトは短くて済む 初期の⼿間 ⼩さい 初期の⼿間 学習のデータと費⽤が要る 情報がよく変わるなら RAG、振る舞いや書き⽅を変えたいならファインチューニング 今ココ 使い分け 10/13
11. ▪症状ごとに、直す場所が決まっている うまく答えられないときに見るところ うまく答えられないとき 今ココ 使い分け ⾒るところ 関係ない資料が出てくる チャンクの分け⽅∕リランクで並べ替える 必要な資料が出てこない 件数を増やす∕ハイブリッド検索を使う 資料はあるのに答えが違う 「資料だけを根拠に」と指⽰に書く 資料が⼊り切らない 件数を減らす∕コンテキストウィンドウの⼤きいモデルへ 11/13
12. ▪クイズの前に、持ち帰ってほしいことを振り返る 今回のまとめ RAGは、答える前に資料を探して渡す仕組み モデルを再学習せずに、社内の情報に基づいて答えられる 準備と実⾏の2つに分かれる 準備でベクトルDBを作り、質問のたびに検索して渡す 検索は、意味の近さで⾏う 語が⼀致していなくても、ベクトルが近ければ⾒つかる 埋め込みを置ける主なサービスは4つ ベクトルDB まとめて引き受けるのが Knowledge Bases Bedrock OpenSearch Service‧Aurora‧RDS for PostgreSQL‧Neptune 情報がよく変わるなら RAG、振る舞いを変えたいなら調整 今ココ おわりに 12/13
13. ▪動画に付けたクイズから回答できます。答え合わせは次回の冒頭で 今回のクイズ 社内規程に基づいて答えるチャットを作りたい。規程は毎月更新される。モデル の再学習はしたくない。最も適した方法は？ A ファインチューニング 今ココ おわりに B RAG C 事前学習 D 温度を下げる 13/13