実例で紹介するRAG導入時の知見と精度向上の勘所

2024/04/24に開催したセミナーで登壇した際に、使用した資料です

https://dev.classmethod.jp/news/240424-ai-rag-webinar/

Transcript

2. 実例で紹介する RAG導入時の知見と精度向上の勘所 クラスメソッド株式会社 新規事業部 生成AIチーム 山本紘暉
3. このセッションの内容 RAGとは (10分) 概要 考え方・目標感 構築時の知見 (10分) 方式・パーツ 機能・体験 精度改善時の勘所 (20分) プラクティス 実事例での取り組み
4. 4 このセッションについて 目的 ・簡単に導入したい ・まずは試したい ・業務負荷を減らしたい 対象の方 ・PoCをやってみたい ・PoCを実施済みで改善したい ・なかなか開発リソースをかけられない (対象ではなさそうな方) ・コスト・時間をかけられる ・自分たちの手で自社サービスを作る (競争力・差別化ポイントにしたい)
5. 5 自己紹介：山本紘暉 クラスメソッド株式会社 研究開発エンジニア 2020年 5月～ ・コンピュータビジョン 骨格検出や人物追跡 2023年 3月～ ・生成AIやLLM 最近はRAGに注力 「クラスメソッド 山本 ブログ」で検索 https://dev.classmethod.jp/author/yamamoto-hiroki/ 研究開発 ・最新研究と実適用の間の橋渡し ・妥当な期間・コスト・品質 ・着実に進めるために ・有り物だけでなく自作も
6. 6 補足：導入事例 https://classmethod.jp/cases/kusurinomadoguchi/ https://classmethod.jp/cases/optage/ 詳細はリンク先をご覧ください 「クラスメソッド 生成AI 事例」で検索
7. １．はじめに
8. 8 RAGとは LLM単体では知らないことを答えさせる （RAG：Retrieval Augmented Generation） 検索 で LLM を 拡張
9. 9 LLMの問題点・RAGの目的 ユーザ 質問 誤った回答 LLM プログラム 質問 誤った回答 ユーザ 質問 正しい回答 LLM プログラム 質問 + 関連テキスト 正しい回答 参考 ドキュメント 検索 関連テキスト 通常 RAG
10. 10 RAGの構成要素（ベーシックな構成） ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答 参考 ドキュメント インポート 検索 システム 質問 関連テキスト
11. 11 RAGのシステム構成（例：AWSの場合） AWS ユーザ Slack App Slack Notion アップロード ドキュメント (PDF・ワードなど) Python プログラム (in コンテナ) App Runner Kendra インデックス S3 バケット Bedrock Anthropic Claude インポート
12. 12 RAGを使ったチャットボットの動作（例） ユーザが社内情報に関して質問 ボットが社内情報を読んで回答 ボットは使用したドキュメントへのリンクも回答 (ユーザが元データを確認できる)
13. 13 なぜRAG？（社会的なニーズが高い） 一般業務として困っている ・多くの会社で ・多くの部門で、多くの人が 「社内ドキュメントを検索して回答する」 という作業を効率化したい
14. 14 なぜRAG？（生成AI活用のステップアップとして） 生成AI導入の流れ ・まず個人レベルの作業を 効率化する ・次に業務を任せてみる 質問回答から始める (社内の合意形成を図る) ・その後、専門業務を任せる 専門業務レベル (専門システムを構築) 一般業務レベル (パッケージを導入) 個人レベル (ChatGPT・Copilotを利用) 広まってる 今ここ もう少し先
15. 15 他手法の比較（独自情報をLLMに答えさせる方法） ※ 大まかな傾向の比較です。ケースや基準によって異なります 構築の 難易度 構築 コスト 精度 （理想） 分析・改善の 難易度 (≒ 開発コスト) ランニング コスト (簡単な) fine-tuning ◯ 低い ◯ 安い ◯ ✕ 難しい (コスト高い) ◯ 安い RAG ◯ 低い ◯ 安い ◯ ◯ やりやすい (コスト低い) △ (検索サービスが 必要) モデルの独自 カスタマイズ (継続学習) ✕ 高い ✕ かなり高い ◎ ✕ 難しい (コスト高い) ◯ 安い
16. 16 LLM 他手法との使い分け（目的に合わせて手法を選ぶ） 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル (簡単な) fine-tuning RAG 独自カスタマイズ (継続学習) 深い 役割・立場・内容 プロンプト
17. 17 導入時の進め方 構築 試用 分析 改良 (ループ) 精度改善 構築
18. 18 導入時の考え方 精度改善 お客様ごとに異なる 状況に合わせて分析・改良 世の中の知見が出始めてきた 必要なものを選択して利用 構築 サービス構成は基本的に共通 まずはテンプレートでOK (一部は改修する必要があるかも)
19. 19 導入時の目標レベル そのドキュメントを初めて渡された人が ちょっと検索して回答する そこそこ背景・状況をわかっている 優秀な人間が回答してくれる なんでもわかってる 気の回る完璧人間が対応してくれる 目指したい(理想) できればここ 現実的にはここ 難易度が高い
20. 20 RAGの注意点（勘違いされやすい点） 全部のドキュメントを”学習”するわけではない ・検索でヒットした一部の文章のみをもとに回答する なので、回答の質は ドキュメントを初見の人が理解できる範囲で答える感じ = 新入社員の人が回答する感覚
21. 21 「はじめに」のまとめ RAGとは ・検索を組み合わせることで LLM単体では知らないことを答えさせること ・他手法と比べて分析しやすい、RAGを使うのがオススメ RAGの導入時の進めかた ・構築：まずはテンプレートを使用すると進めやすい ・精度改善：状況に合わせて分析・改善が必要
22. ２．構築時の知見
23. 23 構築の方針（様々な方法がある） 文書検索サービス Amazon Kendra RAGアプリ作成サービス Amazon Bedrock（knowledge base） 文章検索エンジン用ライブラリ ライブラリ + ホスティングサービス 文書検索エンジンサービス Amazon OpenSearch Service embedding
24. 24 構築の方針（目的のレイヤー・粒度はどれか？） 文書検索サービス RAGアプリ作成サービス 文章検索エンジン用ライブラリ 文章検索エンジンサービス 抽象度が高い サービス これで十分ならOK だが調整できる項目は少なめで、 不足感があるケースが多い 目的の粒度に合致している 調整がしやすい エンタープライズ検索が便利(後述) 粒度が少し細かすぎる まず導入時は検索できればよい ここまで調整できる必要がない (時間対効果が高くない) ※ エンジニア目線としては下側も大事
25. 25 補足：検索エンジンを自作してみた例 https://dev.classmethod.jp/articles/imp lement-sales-documents-search-bot/ https://dev.classmethod.jp/articles/imp lement-sales-documents-search-bot/ エンジン設計やホスティングに手間がかかり その先の改良を始めるのに時間がかかった （データの前処理や運用も大変） 検索はあり物として考慮対象から外し データや体験の部分に集中した方が良い (パラメータを減らす)
26. 27 構築の進め方（プロジェクトのステップ） ステップ０：RAG作成サービスを使ってみる ・(AWSの場合：Amazon Bedrock Knowledge Base・Amazon Q) ・十分ならそれでOK ・不十分なら、足りない点や改良点を把握する ステップ１：文書検索サービスを使って構築する ・検索サービスを選択する ・アプリを構築する
27. 28 ステップ０：RAGアプリ作成サービスを使ってみる https://dev.classmethod.jp/article s/try-bedrock-knowledge-base/ https://dev.classmethod.jp/article s/try_amazon_qbusiness_api/ Amazon Bedrock Knowledge base Amazon Q
28. 29 ステップ１：文書検索サービスを使って構築する エンタープライズ検索サービス ・検索サービスの１種、以下のような特長(傾向)がある ・さまざまなデータソースからドキュメントを収集する ・例：SharePoint・Google Driveなど ・ドキュメント読込時の前処理を行う ・条件をもとにタグ付けし、フィルタリングする ・ユーザに応じて、アクセス制御を行う → 目的の粒度に合っている機能が多い （実業務適用時に欲しくなる機能が豊富） Amazon Kendra PoCのときは使わない機能もあるが、 将来的に必要な機能
29. 30 どこまで構築するか？（実装する機能） 質問 + 会話履歴 LLM (回答生成) プログラム 質問 + 関連テキスト + 会話履歴 回答 検索 システム 検索クエリ 関連テキスト 検索クエリ LLM (クエリ生成) 会話履歴 標準的な構成 （必要最低限の構成 + α） 会話履歴を保存する 質問から検索クエリを考える （前処理をはさむ） 検索クエリでドキュメントを検索する （質問文では検索しない） ドキュメントをもとに 回答を生成する
30. 31 どう構築するか？（利用できるテンプレート） まず世の中のテンプレートを使ってみる ・フロントエンド(Web画面)もある ・バックエンドも組まれている ・(これで十分なケースもある) これをもとに構成を理解して、 不足している部分を追加する ・プロンプトの修正、データの前処理 ・自社ツール(例：Slack)との接続 (これでも足りなければ自作で構築) https://github.com/aws-samples/generative-ai-use-cases-jp/
31. 32 参考：どこまで構築するか？（実装する機能） https://arxiv.org/abs/2312.10997 まずは、ここまで構築 (試用・分析後、適宜改良していく) Naive RAG Advanced RAG Modular RAG
32. 34 「構築時の知見」のまとめ 文章検索サービスを使って構築するのがオススメ ・RAG作成サービスで十分ならOK（ただ多くの場合で不足感がある） ・検索エンジンを自作するのは少し大変、成果に結びつきにくい エンタープライズ検索サービス（文章検索サービスの１種）が便利 ・マネージドなサービスなので、データや体験の改善に注力できる ・データ連携・アクセス制御機能があり、将来を見据えて開発できる テンプレがあるのでそこからスタートすると良い ・デプロイして試用し、不足点を見つける
33. ３．精度改善時の勘所
34. 36 精度改善時のポイント いきなり精度改善を始めるのは難しい ・そもそも”精度”って何？ どう定義したら良い？ ・ユーザはどういう使い方をしたい？ → 認識合わせのフェーズを先に実施すると良い どう精度改善を進めたらいいか、わかりにくい ・どこが問題点？ ・世の中プラクティスがたくさんある、どれを使えば良い？ → まずはデータに着目する（その後、課題に合わせて取り込んでいく）
35. 37 以前の取組み結果：ブログにまとめてます https://dev.classmethod.jp/articles/improve-work- efficiency-with-generateive-ai-chatbot-using-rag/ （社内での検証） https://dev.classmethod.jp/articles/rag- knowledge-on-real-projects/ （社内での検証 + お客様導入）
36. 38 補足：導入事例 https://classmethod.jp/cases/kusurinomadoguchi/ https://classmethod.jp/cases/optage/ 詳細はリンク先をご覧ください 「クラスメソッド 生成AI 事例」で検索
37. 39 精度改善の進め方：２段階に分ける 試用 分析 認識合わせ・目標ぎめ フェーズ１ 認識を合わせる・目標を決める フェーズ２ 改良点を洗い出す・改善を繰り返す 試用 分析 改良 ループ ※一例です
38. 40 フェーズ１（認識合わせ・目標決め）の進め方 ステップ１－１：試用 ・実ユーザに使ってもらう ステップ１－２：分析 ・処理過程を分析し、結果をグルーピングする ステップ１－３：認識合わせ・目標ぎめ ・サービスの全体感・ユーザストーリーを決める (フェーズ１では、改良を目的としなくてOK)
39. 41 ステップ１－１：試用 ポイント：実ユーザに使ってもらう ・プロジェクト推進者と異なる ・想定外のユースケースが意外と多い 準備 ・最初はサンプルデータ（FAQ表など）でも良い ・ユーザがフィードバックできる 仕組みを用意しておく ・例：「役に立った」「役に立たなかった」 ・処理過程を出力し、ログをとる
40. 42 ステップ１－２：分析 「役に立った」回答 ・これはOK ・使用方法を軽く把握しておけば良い 「役に立たなかった」回答 ・以下を見てみる ・質問内容 ・ドキュメントに該当する内容があるか ・検索結果 ・回答内容 ・グルーピングする 様々なケース ・専門用語が多い ・重箱の隅をつつく質問 ・コンテキスト(社内の話)を 知らないと答えられない ・単語のみしか書いてない (検索エンジン的な使い方) ・ドキュメントに情報がない ・ドキュメントはあるが 検索でヒットしなかった ・検索できたが回答できなかった
41. 43 ステップ１－３：認識合わせ・目標ぎめ システムの全体感・ユーザストーリーを決める ・対応する「ケース」を決める（対応しないものも決める） ・優先順位をつける ・ユーザへの周知の仕方(アナウンス)も含めて ・(可能なら実ユーザも交えて決める) RAGの改善だけで補い切れないなら、体験全体として提供 ・体験・他の機能によって補う ・例：タグでフィルタリング、１つのファイルを選択してさらに聞く
42. 44 補足：認識合わせ・目標決めの観点 RAGシステムとして ・検索精度面 ・回答品質面 チャットボットとして ・体験面 社内プロジェクトとして ・運用面 ・コスト面 研究だと知見は少なめ、かなり実践的 世の中の事例を参考にすると良い 研究で取り組まれている知見を活かせる 論文や公開サンプルを活用する 今までのソフトウェア開発と同様 考え方・手法を活かせる
43. 45 補足：「精度」の定義がかなり難しい 研究・世の中の事例 ・正解/評価が定義できている ・データセットを作成し実験 実際（導入時） ・そもそも使われ方が分かっていない ・正解/評価が定義できていない ・全体的な体験で評価したいのか 個別機能を評価したいのか 回答内容は少し間違っているが、 「詳細は参照先を見て確認してね」 と回答したケース ・間違ってはいない ・これは正解？不正解？ ドキュメントにデータがないケース ・そもそも正解？不正解？ ・全体としてはミス（改良すべき点）
44. 46 補足：「精度」よりも「品質」の方が意識を共有しやすい グラデーション感がでる ・正解/不正解の２つだけでなく、その間があることを意識できる ・品質をあげるために、どうするばいいか考えるようになる ・自分たちの理想を考えるようになる ・その間ギャップを考えるようになる ・条件や項目を列挙できるようになる 精度 品質
45. 47 フェーズ２（改良点洗出し・改善）の進め方 ステップ２－１：試用・分析によって課題を見つける ステップ２－２：世の中のプラクティスを調べる ステップ２－３：改良する ・機能を追加・修正する ・データの前処理を工夫する (以下ループする) 状況ごとに異なる、ここからが本番
46. 48 ステップ２－１：実際にやってみると こっちよりも
47. 49 ステップ２－１：実際にやってみると まずはこっち
48. 50 ステップ２－１：実際にやってみると システムの構成・機能 データ部分 ＜
49. 51 ステップ２－２・２－３：課題と解決の例 課題例１：CSVファイルの途中が抽出されてしまった ・解決策：ファイルの分割 課題例２：似たようなドキュメントの内容が混同して回答された ・解決策：タグ付け・フィルタリング 課題例３：パワポファイルの読まれ方が意図しない形になってしまった ・解決策：マルチモーダルなモデルを使って読み込む 課題例４：ドキュメントに書かれてない社内知識が必要だった ・解決策：用語集をつくる
50. 52 課題例１：対応しない箇所をもとに回答をしてしまった 質問 「〇〇できないときの対処方法を教えて」 回答 「設定画面を開き、有効になっているか確認 ...」
51. 53 課題例１の原因：抽出する範囲が合っていない タイトル 回答例 詳細情報・回答根拠・リンク先情報 ログインパスワードを忘れたときの手順を教えて "ログインパスワードが分からなくなった場合は Slackで情シス宛に初期化依頼をしてくだい。 詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/1)" "初期化する権限は情シスのみが保有しています。 ユーザのみでは行えないので、ご連絡ください。" 〇〇が反応しないときの対処手順を教えて "設定画面を開き、〇〇が有効になっているか確認してください。 確認方法や詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/2)" "〇〇は誤って無効にされてしまうケースが多いです。 設定を改めてご確認ください" 〇〇できないときの対処方法を教えて "ソフトウェアの再起動をしてください。 詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/3)" "再起動処理が完了するまでに、数分かかります。 再起動後アイコン上はすぐに接続できるように見えますが、 処理中の状態ですので、時間をあけて接続して下さい" 行をまたいで、途中が抽出されしまった ヘッダーの情報もない
52. 54 課題例１の解決方法：ファイルを小さく分割する FAQ.csv FAQ_0.csv FAQ_1.csv FAQ_2.csv
53. 55 課題例１の結果：正しく読み込まれた 質問 「〇〇できないときの対処方法を教えて」 回答 「ソフトウェアの再起動をしてください ...」
54. 56 課題例２：似たドキュメントを内容を混同してしまった 起動手順 ・アプリを起動 ・リストをタップ ... 製品A マニュアル 起動手順 ・アプリを起動 ・ファイルを確認 ... 製品B マニュアル 質問 「製品Aの起動手順を教えて」 回答 「アプリを起動し、リストをタップした後、 ファイルを確認してください」
55. 57 課題例２の解決方法：タグ付け・フィルタリングをする 起動手順 ・アプリを起動 ・リストをタップ ... 製品A マニュアル 起動手順 ・アプリを起動 ・ファイルを確認 ... 製品B マニュアル 製品型番：A 製品型番：B 検索 サービス (フィルタリング)
56. 58 課題例３：読み込まれるテキストの順序がおかしかった https://www.jinji.go.jp/saiyo/siken/senkou/setsumeikai_17.pptx 順番が変わる （オブジェクトのレイヤー順で読まれてる ※推測） 親子関係がわかりにくいテキストになる ① ② ③ ① ③ ②
57. 59 課題例３：画像が読まれない https://www.jinji.go.jp/saiyo/siken/senkou/setsumeikai_17.pptx そもそも画像があったかどうかも わからない ※ Kendraのリファレンスにも デフォルトでは画像が読み込まれないことは明記されています 補足：既存のドキュメントローダーでは、 画像は読み込まれるものの、 変換後のテキストは簡素で情報が足りないことが多い
58. 60 課題例３の原因：人間の読み方とシステムの読み方が異なる 読むと理解できる 意図しない読まれ方をする システム ドキュメント 人間が読んでわかりやすい ≠ システムが読み込んだあとの形式がわかりやすい 人間
59. 61 課題例３の解決方法：マルチモーダルなモデルを使う 人間 読むと理解できる 人間と同じような読み方 ドキュメント マルチモーダルなモデル
60. 62 課題例３の結果：人間が読む順序で文字起こしできた 詳細はこちらのブログをご覧ください https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3/ # 経済産業省のMission ## 日本経済・国民の暮らしを豊 かにする ### 産業政策 - 人工知能、IoT、ヘルスケア - データ活用、中小企業 - 産業構造・・・ ### 通商・貿易 - EPA、TPP、インフラ輸出 - 新興国戦略、ルール形成 - 戦略・・・ ### 資源・エネルギー - 電力自由化、新エネ・省エネ - 原発、資源外交・・・ ### 手段 - 経済成長 - 産業競争力の強化 - イノベーション - 世界の富の取り込み - エネルギー安定供給 ### 目的 - 社会課題の解決 Ex.少子高齢化、貧困問題、 世界の不安定化 - 豊かな社会の実現
61. 63 課題例３の結果：画像を説明させることができた 詳細はこちらのブログをご覧ください https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3/ # 活気ある職場・働きやすい環境 1 ## 職場風景 [オフィスの様子が写っている。複数の人が机を囲んで作業を している。] [3人の男女がパンフレットを見ながら話し合っている。壁に は絵画が掛かっている。] ## 働きやすい職場環境 - テレワーク ※29FYは延べ7,000人以上が実施。中央省庁では 最多。 - ペーパーレス ※4年で37%削減 - フレックス - 風通しのよい職場 (職員意識調査:職場満足度77割以上) - 様々な研修制度 (年間100回以上の勉強会の開催など) [2台のノートPCが写っている。] 個人PC:軽量で持ち運びが容易 ※ プロンプトの指示は簡易なものを使用したので、 出力される説明は改良の余地があります
62. 64 課題例４：社内知識・業務知識が必要 例： ・質問 「20期の年末年始の スケジュールを教えて」 ・ドキュメント ・2023年の年末年始 ・2022年の年末年始 ポイント ・20期が何なのか把握させる ・20期が何年に対応するのか 計算させる ・1期が何年なのか教える 普遍的な社内知識に対応させる （こうしたケースが大量にある）
63. 65 課題例４の原因：情報量の差 回答に関係する情報（社内情報に関するQAの場合） システムが使用している情報は、人間に比べてごく一部 → 暗黙的な情報が隠れている 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる（しやすい）範囲
64. 66 課題例４の解決策(の１つ)：用語集をつくる [# ドキュメント]のテキストの中から、社内 用語集を作成したいです。 社内用語を抽出し、その単語の意味も推測 して出力してください。 出力は[# 出力の形式]に従ってください。 ドキュメント LLM 20期：2023年7月～ 2024年6月のこと 用語と意味のリスト
65. 67 課題例４の結果：社内用語とその説明を抽出できた 2255ファイルから5153件を抽出できた（※ 重複あり） 一例 #01help-me 社内のヘルプデスクやサポート窓口を指す用語。社員がIT関連のトラブルや問題を報告するための連絡先 第14期 会社の年度を表す用語。会社の創業年を1期として、その年から数えて14年目を表す。2017年度を指す。 入場アンケートフォーム 新入社員や異動者が入社・異動時に提出するフォーム。必要なPCやシステムのアクセス権限などを申請するため に使用される。 Nulabアカウント Cacooを利用するために必要なアカウント。社内の手続きを経て発行される 2代目めそ子 社内用語で、社内向けイベントカレンダーにイベントを追加する際に招待するゲストの名前。社内システムや ツールを指している可能性がある。 04.パソコン・周辺機器利用・返却申請 WF 社内のパソコンや周辺機器の利用申請や返却手続きを行うためのワークフロー。 Lab チームでワイワイ開発したり、もくもくと作業をするエリアの名称 Hub ビジネスについて議論するエリアの名称。電話やオンライン会議も可能 Core 財務経理室、労務の執務室、倉庫、セキュリティルームのエリアの総称 キャリブレーション 評価の基準を合わせるための会議。評価者間で評価のばらつきを防ぐために行われる JD 社内の人事評価制度に関連する用語。職務記述書（Job Description）の頭文字から取った略称で、目標設定や評 価の面談やシートを指す。 FU-1102（どんたく） 福岡オフィスの11階にある会議室の名称。4人収容可能
66. 68 補足：Kendra（エンタープライズ検索）の機能 前処理 ・Custom Document Enrichmentで、Lambda関数を呼ぶことで、 組み込み可能 タグ付け・フィルタリング ・Custom Document Enrichmentのベーシックルールで、 パスに基づいたタグ付けが可能 他にも機能があり、処理を統合しやすい
67. 69 さらにやりたいなら https://arxiv.org/abs/2312.10997 さらに深めていく 研究や開発などの知見を活かし 精度向上を進めていく
68. 70 このあたりは取り入れても良さそう (Advanced RAGな範囲) 検索精度面 ・クエリ検討モデルをfine-tuningする ・取り出す範囲を拡大する ・(チャンクではなく) ファイル全体を取得する ・親/兄弟要素も取り出す ・検索エンジンを自作する 回答品質面 ・回答モデルをfine-tuningする ・プロンプトエンジニアリングを進める 体験面 ・一つのファイルを選択して、 その内容を深堀りして聞けるようにする 運用面 ・社内ドキュメントサービスとの接続 ・社内チャットツールとの接続 ・データを自動更新できるようにする ・フィードバックループ(体制)をつくる
69. 71 「精度改善時の勘所」のまとめ ２つのフェーズに分けるのがオススメ ・最初から精度や目標を決めるのが難しい まずユーザに試してもらい、状況を把握し、目標とする”品質”を決める ・決めた目標と現状の差をもとに、改良を重ねていく データ周りを見直すと有効なことが多い ・色々な知見がある、課題に合った手法を選ぶことが大事 ・コスト面や運用面の考慮も忘れずに
70. ４．おわりに
71. 73 全体のまとめ：RAGを始めたい・始めた方に向けて RAGとは ・検索 + 生成AIのこと ・進め方：「テンプレで構築し、分析→改善のループ」がオススメ 構築時の知見 ・エンタープライズ検索を使うと進めやすい、目的に合致しやすい ・まずは標準的な構成からスタートするのがオススメ（後で改良） 精度改善時の勘所 ・検証時の結果を分析しながら進めることになる ・データ部分/ドキュメントの改善が有効（なケースが多い）
72. 補足 ２．構築時の知見
73. 76 検索方式 全文検索 + セマンティック ・キーワード検索 + 意味的な検索 頻度ベクトル検索（疎ベクトル） ・単語の頻度をもとに検索 埋め込みベクトル検索（密ベクトル） ・文章の意味の近さをもとに検索 ナレッジグラフ ・文章を分解し、意味構造を作る 情報が多い・理解しやすい 比較的扱いやすい 世の中のエンタープライズ検索で 使われている(利用しやすい) → 敷居は低め(まずはオススメ) 情報が少ない・理解が難しい 比較的扱いが難しい (理想的には)精度が高い → 敷居が高め
74. 77 ベクトル検索の種類 https://docs.pinecone.io/guides/data/understanding-hybrid-search https://www.pinecone.io/learn/splade/ 検索方式 長所 短所 例 疎ベクトル 単語の頻度 キーワード一致に強い (専門用語・特殊な用語の 検索に適している) 「似たような意味だが 違う単語」だとヒットしない TF/IDF BM25 密ベクトル (embed) 意味的な近さ 単語が違っても 意味が同じなら対応可能 (抽象的な概念でも 検索可能) 同じキーワードが有っても、 検索でヒットしないことがある (表面上似た意味の “文章”がヒットしてしまう) GPTベース (各社API) ハイブリッド (上記２つの組合せ) ー (上記の両者) ー 係数で 重み付け 疎埋め込み ベクトル 単語の頻度 + 意味的な近さ (上記の両者) ー SPLADE
75. 78 検索システムの仕様 テキストの取り出し方が違う Kendra queryメソッド １ファイル、１箇所 Kendra retrieveメソッド １ファイルあたり、箇所の上限なし ② ③ ① ※ 改行あり ※ 改行なし ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ 見落としが少ない方を選ぶ （この場合だとretrieveの方が良い）
76. 79 テキストの取り出し方：Amazon Kendra ② ③ ① ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ queryメソッド retrieveメソッド ・チャンク数：１ファイル１箇所 ・サイズ ：中（数百文字） ・チャンク数：１ファイルあたり上限なし ・サイズ ：中（数百文字） ・ランク ：チャンクごと ※アップデートやAPIのバージョンにより 異なる可能性があります
77. 80 テキストの取り出し方：Azure AI Search ② ④ ① ③ ⑤ ⑥ ② ③ ① ④ ⑤ ⑥ query_type：simple query_type：semantic ・チャンク数：１ファイル１箇所 ・サイズ ：大（数千文字） ・チャンク数：１ファイル１箇所 ・サイズ ：中（数百文字） ② ③ ① ④ ⑤ ⑥ query_type：vector ・チャンク数：１ファイル上限なし ・サイズ ：中（数百文字） ・ランク ：チャンクごと ※アップデートやAPIのバージョンにより 異なる可能性があります
78. 81 テキストの取り出し方：Google Vertex AI Search ・チャンク数：１ファイル複数箇所 ・サイズ ：中（数百文字） ・ランク ：ファイルごと ※ 複数箇所：数を設定可能 パラメータ名：max_extractive_segment_count 最大10箇所 ① ③ ④ ⑤ ⑥ ② ※アップデートやAPIのバージョンにより 異なる可能性があります
79. 82 構築時の要素 LLM 回答 指示 ・あなたはC社の質問受付ボット ・関連情報に基づいて回答して 関連情報 ・サービスAは〇〇です ・サービスBでは ・〇〇の場合：ーーです ・✕✕の場合：ーーです 質問 ・〇〇ってなんですか？ プロンプト 入力 出力 プロンプトの全体を工夫する （改良点２） いいモデルを使う （改良点１） 情報の渡し方を工夫する （改良点３） ※ 最初は改良点１・改良点２は固定して 改良点３に注力をすると エンジニアリング的に進めやすし、効果が高い （パラメータを減らす） RAGのコアな部分（回答生成）
80. 83 構築時の要素：どのモデルを使うか 完璧人間：100点 普通人間：85点 LLM ：80点 Anthropic Claude3 Opus OpenAI GPT4 Google Gemini LLMの選択肢 情報が十分にあれば、人間と同様のレベルに回答できる モデルによって大きな差はない （モデル選びの時間対効果は低い） → まずは構築するクラウドや許容コストに合わせて選択
81. 84 構築時の要素：どういったプロンプトを使うか あなたは会社内の質問を受け付け、社内ドキュメントをもとに回答を行う担当窓口です。 ユーザからの質問と、その回答で利用できる情報があります。 {回答生成の手順} の通りに、ユーザの質問に対する回答を生成してください。 <回答生成の手順> - {制約} {ドキュメントのファイルパスと内容} をすべて理解してください。 - {制約} は、回答を生成する際に守らなければならないことです。必ず従ってください - {ドキュメントのファイルパスと内容} には、参考とするべきドキュメントが含まれています。ドキュメントはデータベースに保存されており、そのファイルパスが与えられます。 - このあとユーザとあなたの会話のやりとりと、最後にユーザからの質問が続きますので、会話の内容と、ユーザの疑問点を理解してください - 会話のやりとりは、これまでのユーザの質問とあなたの回答です - ユーザからの質問が、ユーザが最も知りたいことなので、重要視してください。 - {ドキュメントのファイルパスと内容} の中から、ユーザの疑問点に関連する情報を見つけ、その情報をもとに回答を行ってください - その際、{制約} に必ず従ってください。 - ドキュメント間で矛盾している内容がある場合は、その内容をユーザに補足として伝えてください </回答生成の手順> <制約> - 質問に関係のない情報は無視し、関係ある情報にのみ基づいて回答してください。 - 使用したドキュメントは、その番号を引用の形式で示してください。例：[0],[2] - 回答に「AI:」は含めないでください。必ず従ってください。例外はありません。 </制約> <ドキュメントのファイルパスと内容> {available_info} </ドキュメントのファイルパスと内容> 世の中のプロンプトテンプレートを参考にできるので、まずはこれを使う → 必要が生じたら、構成・要素・形式を改良する プロンプトの内容（現状）
82. 85 構築時の要素：使用する検索件数（何件とりだすか） 件数が多いほど回答が良くなる（∵ 情報の見落としが減るため） ・無駄な情報が増えるため回答がおかしくなることもあるが、 ケースとしては少ない印象 目安：10件程度 ・社内検証の場合、9・10件目が 回答に使われるケースが2割程度あった 可能なら：20件程度 ・ただしコストが増えるので注意 https://dev.classmethod.jp/articles/im prove-work-efficiency-with- generateive-ai-chatbot-using- rag/#toc-8 精度改善時に再度調整する
83. 補足 ３．精度改善時の勘所
84. 87 課題例３：PDFファイルの読まれ方（ヘッダ・フッタ） 本文間にフッターやページ数が 入り込んでしまう
85. 88 課題例３：PDFファイルの読まれ方（表） 表部分がテキストの羅列になってしまう チャンクが表の途中で途切れてしまう （→ カラム名が分からなくなる）
86. 89 課題例３の結果：人間が理解する形で文字起こしできた # セキュリティ体制 ## ISMS・ITSMS上の役割 役割 | 氏名 --- | --- 最高情報責任者（CIO） | Aさん 情報セキュリティ管理責任者（CISO） | Aさん サービス管理責任者 | Aさん ISMS事務局、ITSMS推進事務局 | Aさん ITSMS推進（AWS事業本部オペレーション部） | Aさん ...(※ 略)... AWS事業本部（モダンアプリケーションコンサルティング 部） | Aさん | Aさん AWS事業本部（サービス企画室） | Aさん | Aさん CX事業本部（Business 部） | Aさん | Aさん CX事業本部（Delivery 部） | Aさん | Aさん データアナリティクス事業本部（インテグレーション部） | Aさん | Aさん ...(※ 略)... 不要な情報（フッター・ページ数）を削除 ページの切れ目があってもつなげて出力 表部分をMarkdown形式で出力 (Claude3は１リクエストに複数画像を含めることができる) (※ 略) は正しい結果が出力されていました
87. 90 課題例３の補足：マルチモーダルモデルで読み込んだ結果 https://dev.classmethod.jp/articles/read-powerpoint- document-with-claude-3/ https://dev.classmethod.jp/articles/read-powerpoint- document-with-claude-3-on-lambda-funcion/
88. 91 課題例３の補足：OCR AIと組み合わせて補助 https://dev.classmethod.jp/articles/simple- examination-on-recognizable-char-size-with-claude-3/ https://dev.classmethod.jp/articles/fix-claude3-text- recognition-mistake-with-azure-document- intelligence/
89. 92 課題例４の補足：暗黙的な情報を追加する（前提１） 人間が利用している情報とは（社内情報に関するQAの場合） ※ 山本独自の用語です 性質 １質問に関わる量 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 明文化 (ドキュメント) 業界の常識 間接的・普遍的 直接的・専門的 少ない 多い ドキュメント化されている割合
90. 93 課題例４の補足：暗黙的な情報を追加する（前提２） ドキュメントに付随する情報（社内情報に関するQAの場合） ドキュメント本文 メタデータ コンテキスト 「〇〇の手続き方法は」 ファイルの場所（パス・URL） 作成日時・作成者 更新日 社内状況 今までの経緯 ※ 他にもあるはず
91. 94 課題例４の補足：暗黙的な情報を追加する（前提３） ドキュメント本文に含まれる情報 本文テキスト 画像 リンク 「〇〇の手続き方法は」 png （リンク先情報） ※ 他にもあるはず
92. 95 課題例４の補足：暗黙的な情報を追加する（前提４） 質問に付随する情報（社内情報に関するQAの場合） 質問の本文 メタデータ コンテキスト 「〇〇はどうやったら良いですか？」 質問してきた人の名前・属性 日時 質問者と回答者の関係性 会話内容（スレッド内） 回答者が今まで質問した内容（別スレッド） 今までの経緯 ※ 他にもあるはず
93. 96 課題例４の補足：暗黙的な情報を追加する（前提５） 回答に関係する情報（社内情報に関するQAの場合） 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる（しやすい）範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲
94. 97 課題例４の補足：人間が使っている暗黙的情報 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる（しやすい）範囲 暗黙知 社会の常識 ある程度はLLMが対応できる
95. 98 課題例４の原因：情報量の差 回答に関係する情報（社内情報に関するQAの場合） 質問本文 メタデータ コンテキスト ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲
96. 99 課題例４の補足：課題の根本原因と対策 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる（しやすい）範囲 テキスト 画像 リンク 通常の検索システムの 対象範囲 検索システムを 変更する プログラムを 改良する プログラムを 改良する 別の検索システムを追加する（？） できる限り範囲をふやす （制約：そもそもデータがあるか・実装コスト・運用可能か） どうする？ (明文化してもらう)
97. 100 課題例４の解決策：メタデータを付ける（ファイルパス） ファイルパスを付ける ・実装しやすい ・そもそもドキュメントが階層化されている ・効果が高い ・LLMがパスをもとに情報の必要性を 判断できるようになる ・副次的な効果もある ・参考文献を出力させられる ・ユーザが内容を確認できる（安全）
98. 101 今後：まだまだ課題がたくさん https://arxiv.org/abs/2312.10997 ここまで構築 研究の知見を取り入れていく Naive RAG Advanced RAG Modular RAG
99. 102 さらに手を出せる範囲としては（Modular RAGな範囲） 検索精度面 + 回答品質面 ・ドキュメントを読み込み、自動で再検索 ・クエリを大幅に書き換える 体験面 ・Agentライクな動作 ・聞き返し・確認 全体として動的に処理フローが変わる （ここはまだまだ大変）
100. 103 今後：まだまだ課題がたくさん https://dev.classmethod.jp/articles/discussion-on-needs-for-g-of-rag/ https://dev.classmethod.jp/articles/estimate-user-intention-in-genai-bot-with-rag/
101. 104 他にも課題はたくさん データ工学(分析・前処理)・情報検索・ 機械学習(生成AI・LLM) デザイン(UI・UX)・HCI・システム工学 などの知見をフル活用 https://dev.classmethod.jp/articles/improve-work- efficiency-with-generateive-ai-chatbot-using-rag/