Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

実例で紹介する RAG導入時の知見と精度向上の勘所 クラスメソッド株式会社 新規事業部 生成AIチーム 山本紘暉

Slide 3

Slide 3 text

このセッションの内容 RAGとは (10分) 概要 考え方・目標感 構築時の知見 (10分) 方式・パーツ 機能・体験 精度改善時の勘所 (20分) プラクティス 実事例での取り組み

Slide 4

Slide 4 text

4 このセッションについて 目的 ・簡単に導入したい ・まずは試したい ・業務負荷を減らしたい 対象の方 ・PoCをやってみたい ・PoCを実施済みで改善したい ・なかなか開発リソースをかけられない (対象ではなさそうな方) ・コスト・時間をかけられる ・自分たちの手で自社サービスを作る (競争力・差別化ポイントにしたい)

Slide 5

Slide 5 text

5 自己紹介:山本紘暉 クラスメソッド株式会社 研究開発エンジニア 2020年 5月~ ・コンピュータビジョン 骨格検出や人物追跡 2023年 3月~ ・生成AIやLLM 最近はRAGに注力 「クラスメソッド 山本 ブログ」で検索 https://dev.classmethod.jp/author/yamamoto-hiroki/ 研究開発 ・最新研究と実適用の間の橋渡し ・妥当な期間・コスト・品質 ・着実に進めるために ・有り物だけでなく自作も

Slide 6

Slide 6 text

6 補足:導入事例 https://classmethod.jp/cases/kusurinomadoguchi/ https://classmethod.jp/cases/optage/ 詳細はリンク先をご覧ください 「クラスメソッド 生成AI 事例」で検索

Slide 7

Slide 7 text

1.はじめに

Slide 8

Slide 8 text

8 RAGとは LLM単体では知らないことを答えさせる (RAG:Retrieval Augmented Generation) 検索 で LLM を 拡張

Slide 9

Slide 9 text

9 LLMの問題点・RAGの目的 ユーザ 質問 誤った回答 LLM プログラム 質問 誤った回答 ユーザ 質問 正しい回答 LLM プログラム 質問 + 関連テキスト 正しい回答 参考 ドキュメント 検索 関連テキスト 通常 RAG

Slide 10

Slide 10 text

10 RAGの構成要素(ベーシックな構成) ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答 参考 ドキュメント インポート 検索 システム 質問 関連テキスト

Slide 11

Slide 11 text

11 RAGのシステム構成(例:AWSの場合) AWS ユーザ Slack App Slack Notion アップロード ドキュメント (PDF・ワードなど) Python プログラム (in コンテナ) App Runner Kendra インデックス S3 バケット Bedrock Anthropic Claude インポート

Slide 12

Slide 12 text

12 RAGを使ったチャットボットの動作(例) ユーザが社内情報に関して質問 ボットが社内情報を読んで回答 ボットは使用したドキュメントへのリンクも回答 (ユーザが元データを確認できる)

Slide 13

Slide 13 text

13 なぜRAG?(社会的なニーズが高い) 一般業務として困っている ・多くの会社で ・多くの部門で、多くの人が 「社内ドキュメントを検索して回答する」 という作業を効率化したい

Slide 14

Slide 14 text

14 なぜRAG?(生成AI活用のステップアップとして) 生成AI導入の流れ ・まず個人レベルの作業を 効率化する ・次に業務を任せてみる 質問回答から始める (社内の合意形成を図る) ・その後、専門業務を任せる 専門業務レベル (専門システムを構築) 一般業務レベル (パッケージを導入) 個人レベル (ChatGPT・Copilotを利用) 広まってる 今ここ もう少し先

Slide 15

Slide 15 text

15 他手法の比較(独自情報をLLMに答えさせる方法) ※ 大まかな傾向の比較です。ケースや基準によって異なります 構築の 難易度 構築 コスト 精度 (理想) 分析・改善の 難易度 (≒ 開発コスト) ランニング コスト (簡単な) fine-tuning ◯ 低い ◯ 安い ◯ ✕ 難しい (コスト高い) ◯ 安い RAG ◯ 低い ◯ 安い ◯ ◯ やりやすい (コスト低い) △ (検索サービスが 必要) モデルの独自 カスタマイズ (継続学習) ✕ 高い ✕ かなり高い ◎ ✕ 難しい (コスト高い) ◯ 安い

Slide 16

Slide 16 text

16 LLM 他手法との使い分け(目的に合わせて手法を選ぶ) 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル (簡単な) fine-tuning RAG 独自カスタマイズ (継続学習) 深い 役割・立場・内容 プロンプト

Slide 17

Slide 17 text

17 導入時の進め方 構築 試用 分析 改良 (ループ) 精度改善 構築

Slide 18

Slide 18 text

18 導入時の考え方 精度改善 お客様ごとに異なる 状況に合わせて分析・改良 世の中の知見が出始めてきた 必要なものを選択して利用 構築 サービス構成は基本的に共通 まずはテンプレートでOK (一部は改修する必要があるかも)

Slide 19

Slide 19 text

19 導入時の目標レベル そのドキュメントを初めて渡された人が ちょっと検索して回答する そこそこ背景・状況をわかっている 優秀な人間が回答してくれる なんでもわかってる 気の回る完璧人間が対応してくれる 目指したい(理想) できればここ 現実的にはここ 難易度が高い

Slide 20

Slide 20 text

20 RAGの注意点(勘違いされやすい点) 全部のドキュメントを”学習”するわけではない ・検索でヒットした一部の文章のみをもとに回答する なので、回答の質は ドキュメントを初見の人が理解できる範囲で答える感じ = 新入社員の人が回答する感覚

Slide 21

Slide 21 text

21 「はじめに」のまとめ RAGとは ・検索を組み合わせることで LLM単体では知らないことを答えさせること ・他手法と比べて分析しやすい、RAGを使うのがオススメ RAGの導入時の進めかた ・構築:まずはテンプレートを使用すると進めやすい ・精度改善:状況に合わせて分析・改善が必要

Slide 22

Slide 22 text

2.構築時の知見

Slide 23

Slide 23 text

23 構築の方針(様々な方法がある) 文書検索サービス Amazon Kendra RAGアプリ作成サービス Amazon Bedrock(knowledge base) 文章検索エンジン用ライブラリ ライブラリ + ホスティングサービス 文書検索エンジンサービス Amazon OpenSearch Service embedding

Slide 24

Slide 24 text

24 構築の方針(目的のレイヤー・粒度はどれか?) 文書検索サービス RAGアプリ作成サービス 文章検索エンジン用ライブラリ 文章検索エンジンサービス 抽象度が高い サービス これで十分ならOK だが調整できる項目は少なめで、 不足感があるケースが多い 目的の粒度に合致している 調整がしやすい エンタープライズ検索が便利(後述) 粒度が少し細かすぎる まず導入時は検索できればよい ここまで調整できる必要がない (時間対効果が高くない) ※ エンジニア目線としては下側も大事

Slide 25

Slide 25 text

25 補足:検索エンジンを自作してみた例 https://dev.classmethod.jp/articles/imp lement-sales-documents-search-bot/ https://dev.classmethod.jp/articles/imp lement-sales-documents-search-bot/ エンジン設計やホスティングに手間がかかり その先の改良を始めるのに時間がかかった (データの前処理や運用も大変) 検索はあり物として考慮対象から外し データや体験の部分に集中した方が良い (パラメータを減らす)

Slide 26

Slide 26 text

27 構築の進め方(プロジェクトのステップ) ステップ0:RAG作成サービスを使ってみる ・(AWSの場合:Amazon Bedrock Knowledge Base・Amazon Q) ・十分ならそれでOK ・不十分なら、足りない点や改良点を把握する ステップ1:文書検索サービスを使って構築する ・検索サービスを選択する ・アプリを構築する

Slide 27

Slide 27 text

28 ステップ0: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

Slide 28

Slide 28 text

29 ステップ1:文書検索サービスを使って構築する エンタープライズ検索サービス ・検索サービスの1種、以下のような特長(傾向)がある ・さまざまなデータソースからドキュメントを収集する ・例:SharePoint・Google Driveなど ・ドキュメント読込時の前処理を行う ・条件をもとにタグ付けし、フィルタリングする ・ユーザに応じて、アクセス制御を行う → 目的の粒度に合っている機能が多い (実業務適用時に欲しくなる機能が豊富) Amazon Kendra PoCのときは使わない機能もあるが、 将来的に必要な機能

Slide 29

Slide 29 text

30 どこまで構築するか?(実装する機能) 質問 + 会話履歴 LLM (回答生成) プログラム 質問 + 関連テキスト + 会話履歴 回答 検索 システム 検索クエリ 関連テキスト 検索クエリ LLM (クエリ生成) 会話履歴 標準的な構成 (必要最低限の構成 + α) 会話履歴を保存する 質問から検索クエリを考える (前処理をはさむ) 検索クエリでドキュメントを検索する (質問文では検索しない) ドキュメントをもとに 回答を生成する

Slide 30

Slide 30 text

31 どう構築するか?(利用できるテンプレート) まず世の中のテンプレートを使ってみる ・フロントエンド(Web画面)もある ・バックエンドも組まれている ・(これで十分なケースもある) これをもとに構成を理解して、 不足している部分を追加する ・プロンプトの修正、データの前処理 ・自社ツール(例:Slack)との接続 (これでも足りなければ自作で構築) https://github.com/aws-samples/generative-ai-use-cases-jp/

Slide 31

Slide 31 text

32 参考:どこまで構築するか?(実装する機能) https://arxiv.org/abs/2312.10997 まずは、ここまで構築 (試用・分析後、適宜改良していく) Naive RAG Advanced RAG Modular RAG

Slide 32

Slide 32 text

34 「構築時の知見」のまとめ 文章検索サービスを使って構築するのがオススメ ・RAG作成サービスで十分ならOK(ただ多くの場合で不足感がある) ・検索エンジンを自作するのは少し大変、成果に結びつきにくい エンタープライズ検索サービス(文章検索サービスの1種)が便利 ・マネージドなサービスなので、データや体験の改善に注力できる ・データ連携・アクセス制御機能があり、将来を見据えて開発できる テンプレがあるのでそこからスタートすると良い ・デプロイして試用し、不足点を見つける

Slide 33

Slide 33 text

3.精度改善時の勘所

Slide 34

Slide 34 text

36 精度改善時のポイント いきなり精度改善を始めるのは難しい ・そもそも”精度”って何? どう定義したら良い? ・ユーザはどういう使い方をしたい? → 認識合わせのフェーズを先に実施すると良い どう精度改善を進めたらいいか、わかりにくい ・どこが問題点? ・世の中プラクティスがたくさんある、どれを使えば良い? → まずはデータに着目する(その後、課題に合わせて取り込んでいく)

Slide 35

Slide 35 text

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/ (社内での検証 + お客様導入)

Slide 36

Slide 36 text

38 補足:導入事例 https://classmethod.jp/cases/kusurinomadoguchi/ https://classmethod.jp/cases/optage/ 詳細はリンク先をご覧ください 「クラスメソッド 生成AI 事例」で検索

Slide 37

Slide 37 text

39 精度改善の進め方:2段階に分ける 試用 分析 認識合わせ・目標ぎめ フェーズ1 認識を合わせる・目標を決める フェーズ2 改良点を洗い出す・改善を繰り返す 試用 分析 改良 ループ ※一例です

Slide 38

Slide 38 text

40 フェーズ1(認識合わせ・目標決め)の進め方 ステップ1-1:試用 ・実ユーザに使ってもらう ステップ1-2:分析 ・処理過程を分析し、結果をグルーピングする ステップ1-3:認識合わせ・目標ぎめ ・サービスの全体感・ユーザストーリーを決める (フェーズ1では、改良を目的としなくてOK)

Slide 39

Slide 39 text

41 ステップ1-1:試用 ポイント:実ユーザに使ってもらう ・プロジェクト推進者と異なる ・想定外のユースケースが意外と多い 準備 ・最初はサンプルデータ(FAQ表など)でも良い ・ユーザがフィードバックできる 仕組みを用意しておく ・例:「役に立った」「役に立たなかった」 ・処理過程を出力し、ログをとる

Slide 40

Slide 40 text

42 ステップ1-2:分析 「役に立った」回答 ・これはOK ・使用方法を軽く把握しておけば良い 「役に立たなかった」回答 ・以下を見てみる ・質問内容 ・ドキュメントに該当する内容があるか ・検索結果 ・回答内容 ・グルーピングする 様々なケース ・専門用語が多い ・重箱の隅をつつく質問 ・コンテキスト(社内の話)を 知らないと答えられない ・単語のみしか書いてない (検索エンジン的な使い方) ・ドキュメントに情報がない ・ドキュメントはあるが 検索でヒットしなかった ・検索できたが回答できなかった

Slide 41

Slide 41 text

43 ステップ1-3:認識合わせ・目標ぎめ システムの全体感・ユーザストーリーを決める ・対応する「ケース」を決める(対応しないものも決める) ・優先順位をつける ・ユーザへの周知の仕方(アナウンス)も含めて ・(可能なら実ユーザも交えて決める) RAGの改善だけで補い切れないなら、体験全体として提供 ・体験・他の機能によって補う ・例:タグでフィルタリング、1つのファイルを選択してさらに聞く

Slide 42

Slide 42 text

44 補足:認識合わせ・目標決めの観点 RAGシステムとして ・検索精度面 ・回答品質面 チャットボットとして ・体験面 社内プロジェクトとして ・運用面 ・コスト面 研究だと知見は少なめ、かなり実践的 世の中の事例を参考にすると良い 研究で取り組まれている知見を活かせる 論文や公開サンプルを活用する 今までのソフトウェア開発と同様 考え方・手法を活かせる

Slide 43

Slide 43 text

45 補足:「精度」の定義がかなり難しい 研究・世の中の事例 ・正解/評価が定義できている ・データセットを作成し実験 実際(導入時) ・そもそも使われ方が分かっていない ・正解/評価が定義できていない ・全体的な体験で評価したいのか 個別機能を評価したいのか 回答内容は少し間違っているが、 「詳細は参照先を見て確認してね」 と回答したケース ・間違ってはいない ・これは正解?不正解? ドキュメントにデータがないケース ・そもそも正解?不正解? ・全体としてはミス(改良すべき点)

Slide 44

Slide 44 text

46 補足:「精度」よりも「品質」の方が意識を共有しやすい グラデーション感がでる ・正解/不正解の2つだけでなく、その間があることを意識できる ・品質をあげるために、どうするばいいか考えるようになる ・自分たちの理想を考えるようになる ・その間ギャップを考えるようになる ・条件や項目を列挙できるようになる 精度 品質

Slide 45

Slide 45 text

47 フェーズ2(改良点洗出し・改善)の進め方 ステップ2-1:試用・分析によって課題を見つける ステップ2-2:世の中のプラクティスを調べる ステップ2-3:改良する ・機能を追加・修正する ・データの前処理を工夫する (以下ループする) 状況ごとに異なる、ここからが本番

Slide 46

Slide 46 text

48 ステップ2-1:実際にやってみると こっちよりも

Slide 47

Slide 47 text

49 ステップ2-1:実際にやってみると まずはこっち

Slide 48

Slide 48 text

50 ステップ2-1:実際にやってみると システムの構成・機能 データ部分 <

Slide 49

Slide 49 text

51 ステップ2-2・2-3:課題と解決の例 課題例1:CSVファイルの途中が抽出されてしまった ・解決策:ファイルの分割 課題例2:似たようなドキュメントの内容が混同して回答された ・解決策:タグ付け・フィルタリング 課題例3:パワポファイルの読まれ方が意図しない形になってしまった ・解決策:マルチモーダルなモデルを使って読み込む 課題例4:ドキュメントに書かれてない社内知識が必要だった ・解決策:用語集をつくる

Slide 50

Slide 50 text

52 課題例1:対応しない箇所をもとに回答をしてしまった 質問 「〇〇できないときの対処方法を教えて」 回答 「設定画面を開き、有効になっているか確認 ...」

Slide 51

Slide 51 text

53 課題例1の原因:抽出する範囲が合っていない タイトル 回答例 詳細情報・回答根拠・リンク先情報 ログインパスワードを忘れたときの手順を教えて "ログインパスワードが分からなくなった場合は Slackで情シス宛に初期化依頼をしてくだい。 詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/1)" "初期化する権限は情シスのみが保有しています。 ユーザのみでは行えないので、ご連絡ください。" 〇〇が反応しないときの対処手順を教えて "設定画面を開き、〇〇が有効になっているか確認してください。 確認方法や詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/2)" "〇〇は誤って無効にされてしまうケースが多いです。 設定を改めてご確認ください" 〇〇できないときの対処方法を教えて "ソフトウェアの再起動をしてください。 詳細はリンク先を参照してください。 [リンク先](http://sample.classmethod.jp/sample/sample/3)" "再起動処理が完了するまでに、数分かかります。 再起動後アイコン上はすぐに接続できるように見えますが、 処理中の状態ですので、時間をあけて接続して下さい" 行をまたいで、途中が抽出されしまった ヘッダーの情報もない

Slide 52

Slide 52 text

54 課題例1の解決方法:ファイルを小さく分割する FAQ.csv FAQ_0.csv FAQ_1.csv FAQ_2.csv

Slide 53

Slide 53 text

55 課題例1の結果:正しく読み込まれた 質問 「〇〇できないときの対処方法を教えて」 回答 「ソフトウェアの再起動をしてください ...」

Slide 54

Slide 54 text

56 課題例2:似たドキュメントを内容を混同してしまった 起動手順 ・アプリを起動 ・リストをタップ ... 製品A マニュアル 起動手順 ・アプリを起動 ・ファイルを確認 ... 製品B マニュアル 質問 「製品Aの起動手順を教えて」 回答 「アプリを起動し、リストをタップした後、 ファイルを確認してください」

Slide 55

Slide 55 text

57 課題例2の解決方法:タグ付け・フィルタリングをする 起動手順 ・アプリを起動 ・リストをタップ ... 製品A マニュアル 起動手順 ・アプリを起動 ・ファイルを確認 ... 製品B マニュアル 製品型番:A 製品型番:B 検索 サービス (フィルタリング)

Slide 56

Slide 56 text

58 課題例3:読み込まれるテキストの順序がおかしかった https://www.jinji.go.jp/saiyo/siken/senkou/setsumeikai_17.pptx 順番が変わる (オブジェクトのレイヤー順で読まれてる ※推測) 親子関係がわかりにくいテキストになる ① ② ③ ① ③ ②

Slide 57

Slide 57 text

59 課題例3:画像が読まれない https://www.jinji.go.jp/saiyo/siken/senkou/setsumeikai_17.pptx そもそも画像があったかどうかも わからない ※ Kendraのリファレンスにも デフォルトでは画像が読み込まれないことは明記されています 補足:既存のドキュメントローダーでは、 画像は読み込まれるものの、 変換後のテキストは簡素で情報が足りないことが多い

Slide 58

Slide 58 text

60 課題例3の原因:人間の読み方とシステムの読み方が異なる 読むと理解できる 意図しない読まれ方をする システム ドキュメント 人間が読んでわかりやすい ≠ システムが読み込んだあとの形式がわかりやすい 人間

Slide 59

Slide 59 text

61 課題例3の解決方法:マルチモーダルなモデルを使う 人間 読むと理解できる 人間と同じような読み方 ドキュメント マルチモーダルなモデル

Slide 60

Slide 60 text

62 課題例3の結果:人間が読む順序で文字起こしできた 詳細はこちらのブログをご覧ください https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3/ # 経済産業省のMission ## 日本経済・国民の暮らしを豊 かにする ### 産業政策 - 人工知能、IoT、ヘルスケア - データ活用、中小企業 - 産業構造・・・ ### 通商・貿易 - EPA、TPP、インフラ輸出 - 新興国戦略、ルール形成 - 戦略・・・ ### 資源・エネルギー - 電力自由化、新エネ・省エネ - 原発、資源外交・・・ ### 手段 - 経済成長 - 産業競争力の強化 - イノベーション - 世界の富の取り込み - エネルギー安定供給 ### 目的 - 社会課題の解決 Ex.少子高齢化、貧困問題、 世界の不安定化 - 豊かな社会の実現

Slide 61

Slide 61 text

63 課題例3の結果:画像を説明させることができた 詳細はこちらのブログをご覧ください https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3/ # 活気ある職場・働きやすい環境 1 ## 職場風景 [オフィスの様子が写っている。複数の人が机を囲んで作業を している。] [3人の男女がパンフレットを見ながら話し合っている。壁に は絵画が掛かっている。] ## 働きやすい職場環境 - テレワーク ※29FYは延べ7,000人以上が実施。中央省庁では 最多。 - ペーパーレス ※4年で37%削減 - フレックス - 風通しのよい職場 (職員意識調査:職場満足度77割以上) - 様々な研修制度 (年間100回以上の勉強会の開催など) [2台のノートPCが写っている。] 個人PC:軽量で持ち運びが容易 ※ プロンプトの指示は簡易なものを使用したので、 出力される説明は改良の余地があります

Slide 62

Slide 62 text

64 課題例4:社内知識・業務知識が必要 例: ・質問 「20期の年末年始の スケジュールを教えて」 ・ドキュメント ・2023年の年末年始 ・2022年の年末年始 ポイント ・20期が何なのか把握させる ・20期が何年に対応するのか 計算させる ・1期が何年なのか教える 普遍的な社内知識に対応させる (こうしたケースが大量にある)

Slide 63

Slide 63 text

65 課題例4の原因:情報量の差 回答に関係する情報(社内情報に関するQAの場合) システムが使用している情報は、人間に比べてごく一部 → 暗黙的な情報が隠れている 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる(しやすい)範囲

Slide 64

Slide 64 text

66 課題例4の解決策(の1つ):用語集をつくる [# ドキュメント]のテキストの中から、社内 用語集を作成したいです。 社内用語を抽出し、その単語の意味も推測 して出力してください。 出力は[# 出力の形式]に従ってください。 ドキュメント LLM 20期:2023年7月~ 2024年6月のこと 用語と意味のリスト

Slide 65

Slide 65 text

67 課題例4の結果:社内用語とその説明を抽出できた 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人収容可能

Slide 66

Slide 66 text

68 補足:Kendra(エンタープライズ検索)の機能 前処理 ・Custom Document Enrichmentで、Lambda関数を呼ぶことで、 組み込み可能 タグ付け・フィルタリング ・Custom Document Enrichmentのベーシックルールで、 パスに基づいたタグ付けが可能 他にも機能があり、処理を統合しやすい

Slide 67

Slide 67 text

69 さらにやりたいなら https://arxiv.org/abs/2312.10997 さらに深めていく 研究や開発などの知見を活かし 精度向上を進めていく

Slide 68

Slide 68 text

70 このあたりは取り入れても良さそう (Advanced RAGな範囲) 検索精度面 ・クエリ検討モデルをfine-tuningする ・取り出す範囲を拡大する ・(チャンクではなく) ファイル全体を取得する ・親/兄弟要素も取り出す ・検索エンジンを自作する 回答品質面 ・回答モデルをfine-tuningする ・プロンプトエンジニアリングを進める 体験面 ・一つのファイルを選択して、 その内容を深堀りして聞けるようにする 運用面 ・社内ドキュメントサービスとの接続 ・社内チャットツールとの接続 ・データを自動更新できるようにする ・フィードバックループ(体制)をつくる

Slide 69

Slide 69 text

71 「精度改善時の勘所」のまとめ 2つのフェーズに分けるのがオススメ ・最初から精度や目標を決めるのが難しい まずユーザに試してもらい、状況を把握し、目標とする”品質”を決める ・決めた目標と現状の差をもとに、改良を重ねていく データ周りを見直すと有効なことが多い ・色々な知見がある、課題に合った手法を選ぶことが大事 ・コスト面や運用面の考慮も忘れずに

Slide 70

Slide 70 text

4.おわりに

Slide 71

Slide 71 text

73 全体のまとめ:RAGを始めたい・始めた方に向けて RAGとは ・検索 + 生成AIのこと ・進め方:「テンプレで構築し、分析→改善のループ」がオススメ 構築時の知見 ・エンタープライズ検索を使うと進めやすい、目的に合致しやすい ・まずは標準的な構成からスタートするのがオススメ(後で改良) 精度改善時の勘所 ・検証時の結果を分析しながら進めることになる ・データ部分/ドキュメントの改善が有効(なケースが多い)

Slide 72

Slide 72 text

補足 2.構築時の知見

Slide 73

Slide 73 text

76 検索方式 全文検索 + セマンティック ・キーワード検索 + 意味的な検索 頻度ベクトル検索(疎ベクトル) ・単語の頻度をもとに検索 埋め込みベクトル検索(密ベクトル) ・文章の意味の近さをもとに検索 ナレッジグラフ ・文章を分解し、意味構造を作る 情報が多い・理解しやすい 比較的扱いやすい 世の中のエンタープライズ検索で 使われている(利用しやすい) → 敷居は低め(まずはオススメ) 情報が少ない・理解が難しい 比較的扱いが難しい (理想的には)精度が高い → 敷居が高め

Slide 74

Slide 74 text

77 ベクトル検索の種類 https://docs.pinecone.io/guides/data/understanding-hybrid-search https://www.pinecone.io/learn/splade/ 検索方式 長所 短所 例 疎ベクトル 単語の頻度 キーワード一致に強い (専門用語・特殊な用語の 検索に適している) 「似たような意味だが 違う単語」だとヒットしない TF/IDF BM25 密ベクトル (embed) 意味的な近さ 単語が違っても 意味が同じなら対応可能 (抽象的な概念でも 検索可能) 同じキーワードが有っても、 検索でヒットしないことがある (表面上似た意味の “文章”がヒットしてしまう) GPTベース (各社API) ハイブリッド (上記2つの組合せ) ー (上記の両者) ー 係数で 重み付け 疎埋め込み ベクトル 単語の頻度 + 意味的な近さ (上記の両者) ー SPLADE

Slide 75

Slide 75 text

78 検索システムの仕様 テキストの取り出し方が違う Kendra queryメソッド 1ファイル、1箇所 Kendra retrieveメソッド 1ファイルあたり、箇所の上限なし ② ③ ① ※ 改行あり ※ 改行なし ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ 見落としが少ない方を選ぶ (この場合だとretrieveの方が良い)

Slide 76

Slide 76 text

79 テキストの取り出し方:Amazon Kendra ② ③ ① ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ queryメソッド retrieveメソッド ・チャンク数:1ファイル1箇所 ・サイズ :中(数百文字) ・チャンク数:1ファイルあたり上限なし ・サイズ :中(数百文字) ・ランク :チャンクごと ※アップデートやAPIのバージョンにより 異なる可能性があります

Slide 77

Slide 77 text

80 テキストの取り出し方:Azure AI Search ② ④ ① ③ ⑤ ⑥ ② ③ ① ④ ⑤ ⑥ query_type:simple query_type:semantic ・チャンク数:1ファイル1箇所 ・サイズ :大(数千文字) ・チャンク数:1ファイル1箇所 ・サイズ :中(数百文字) ② ③ ① ④ ⑤ ⑥ query_type:vector ・チャンク数:1ファイル上限なし ・サイズ :中(数百文字) ・ランク :チャンクごと ※アップデートやAPIのバージョンにより 異なる可能性があります

Slide 78

Slide 78 text

81 テキストの取り出し方:Google Vertex AI Search ・チャンク数:1ファイル複数箇所 ・サイズ :中(数百文字) ・ランク :ファイルごと ※ 複数箇所:数を設定可能 パラメータ名:max_extractive_segment_count 最大10箇所 ① ③ ④ ⑤ ⑥ ② ※アップデートやAPIのバージョンにより 異なる可能性があります

Slide 79

Slide 79 text

82 構築時の要素 LLM 回答 指示 ・あなたはC社の質問受付ボット ・関連情報に基づいて回答して 関連情報 ・サービスAは〇〇です ・サービスBでは ・〇〇の場合:ーーです ・✕✕の場合:ーーです 質問 ・〇〇ってなんですか? プロンプト 入力 出力 プロンプトの全体を工夫する (改良点2) いいモデルを使う (改良点1) 情報の渡し方を工夫する (改良点3) ※ 最初は改良点1・改良点2は固定して 改良点3に注力をすると エンジニアリング的に進めやすし、効果が高い (パラメータを減らす) RAGのコアな部分(回答生成)

Slide 80

Slide 80 text

83 構築時の要素:どのモデルを使うか 完璧人間:100点 普通人間:85点 LLM :80点 Anthropic Claude3 Opus OpenAI GPT4 Google Gemini LLMの選択肢 情報が十分にあれば、人間と同様のレベルに回答できる モデルによって大きな差はない (モデル選びの時間対効果は低い) → まずは構築するクラウドや許容コストに合わせて選択

Slide 81

Slide 81 text

84 構築時の要素:どういったプロンプトを使うか あなたは会社内の質問を受け付け、社内ドキュメントをもとに回答を行う担当窓口です。 ユーザからの質問と、その回答で利用できる情報があります。 {回答生成の手順} の通りに、ユーザの質問に対する回答を生成してください。 <回答生成の手順> - {制約} {ドキュメントのファイルパスと内容} をすべて理解してください。 - {制約} は、回答を生成する際に守らなければならないことです。必ず従ってください - {ドキュメントのファイルパスと内容} には、参考とするべきドキュメントが含まれています。ドキュメントはデータベースに保存されており、そのファイルパスが与えられます。 - このあとユーザとあなたの会話のやりとりと、最後にユーザからの質問が続きますので、会話の内容と、ユーザの疑問点を理解してください - 会話のやりとりは、これまでのユーザの質問とあなたの回答です - ユーザからの質問が、ユーザが最も知りたいことなので、重要視してください。 - {ドキュメントのファイルパスと内容} の中から、ユーザの疑問点に関連する情報を見つけ、その情報をもとに回答を行ってください - その際、{制約} に必ず従ってください。 - ドキュメント間で矛盾している内容がある場合は、その内容をユーザに補足として伝えてください 回答生成の手順> <制約> - 質問に関係のない情報は無視し、関係ある情報にのみ基づいて回答してください。 - 使用したドキュメントは、その番号を引用の形式で示してください。例:[0],[2] - 回答に「AI:」は含めないでください。必ず従ってください。例外はありません。 制約> <ドキュメントのファイルパスと内容> {available_info} ドキュメントのファイルパスと内容> 世の中のプロンプトテンプレートを参考にできるので、まずはこれを使う → 必要が生じたら、構成・要素・形式を改良する プロンプトの内容(現状)

Slide 82

Slide 82 text

85 構築時の要素:使用する検索件数(何件とりだすか) 件数が多いほど回答が良くなる(∵ 情報の見落としが減るため) ・無駄な情報が増えるため回答がおかしくなることもあるが、 ケースとしては少ない印象 目安:10件程度 ・社内検証の場合、9・10件目が 回答に使われるケースが2割程度あった 可能なら:20件程度 ・ただしコストが増えるので注意 https://dev.classmethod.jp/articles/im prove-work-efficiency-with- generateive-ai-chatbot-using- rag/#toc-8 精度改善時に再度調整する

Slide 83

Slide 83 text

補足 3.精度改善時の勘所

Slide 84

Slide 84 text

87 課題例3:PDFファイルの読まれ方(ヘッダ・フッタ) 本文間にフッターやページ数が 入り込んでしまう

Slide 85

Slide 85 text

88 課題例3:PDFファイルの読まれ方(表) 表部分がテキストの羅列になってしまう チャンクが表の途中で途切れてしまう (→ カラム名が分からなくなる)

Slide 86

Slide 86 text

89 課題例3の結果:人間が理解する形で文字起こしできた # セキュリティ体制 ## 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は1リクエストに複数画像を含めることができる) (※ 略) は正しい結果が出力されていました

Slide 87

Slide 87 text

90 課題例3の補足:マルチモーダルモデルで読み込んだ結果 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/

Slide 88

Slide 88 text

91 課題例3の補足: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/

Slide 89

Slide 89 text

92 課題例4の補足:暗黙的な情報を追加する(前提1) 人間が利用している情報とは(社内情報に関するQAの場合) ※ 山本独自の用語です 性質 1質問に関わる量 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 明文化 (ドキュメント) 業界の常識 間接的・普遍的 直接的・専門的 少ない 多い ドキュメント化されている割合

Slide 90

Slide 90 text

93 課題例4の補足:暗黙的な情報を追加する(前提2) ドキュメントに付随する情報(社内情報に関するQAの場合) ドキュメント本文 メタデータ コンテキスト 「〇〇の手続き方法は」 ファイルの場所(パス・URL) 作成日時・作成者 更新日 社内状況 今までの経緯 ※ 他にもあるはず

Slide 91

Slide 91 text

94 課題例4の補足:暗黙的な情報を追加する(前提3) ドキュメント本文に含まれる情報 本文テキスト 画像 リンク 「〇〇の手続き方法は」 png (リンク先情報) ※ 他にもあるはず

Slide 92

Slide 92 text

95 課題例4の補足:暗黙的な情報を追加する(前提4) 質問に付随する情報(社内情報に関するQAの場合) 質問の本文 メタデータ コンテキスト 「〇〇はどうやったら良いですか?」 質問してきた人の名前・属性 日時 質問者と回答者の関係性 会話内容(スレッド内) 回答者が今まで質問した内容(別スレッド) 今までの経緯 ※ 他にもあるはず

Slide 93

Slide 93 text

96 課題例4の補足:暗黙的な情報を追加する(前提5) 回答に関係する情報(社内情報に関するQAの場合) 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる(しやすい)範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲

Slide 94

Slide 94 text

97 課題例4の補足:人間が使っている暗黙的情報 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる(しやすい)範囲 暗黙知 社会の常識 ある程度はLLMが対応できる

Slide 95

Slide 95 text

98 課題例4の原因:情報量の差 回答に関係する情報(社内情報に関するQAの場合) 質問本文 メタデータ コンテキスト ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲

Slide 96

Slide 96 text

99 課題例4の補足:課題の根本原因と対策 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる(しやすい)範囲 テキスト 画像 リンク 通常の検索システムの 対象範囲 検索システムを 変更する プログラムを 改良する プログラムを 改良する 別の検索システムを追加する(?) できる限り範囲をふやす (制約:そもそもデータがあるか・実装コスト・運用可能か) どうする? (明文化してもらう)

Slide 97

Slide 97 text

100 課題例4の解決策:メタデータを付ける(ファイルパス) ファイルパスを付ける ・実装しやすい ・そもそもドキュメントが階層化されている ・効果が高い ・LLMがパスをもとに情報の必要性を 判断できるようになる ・副次的な効果もある ・参考文献を出力させられる ・ユーザが内容を確認できる(安全)

Slide 98

Slide 98 text

101 今後:まだまだ課題がたくさん https://arxiv.org/abs/2312.10997 ここまで構築 研究の知見を取り入れていく Naive RAG Advanced RAG Modular RAG

Slide 99

Slide 99 text

102 さらに手を出せる範囲としては(Modular RAGな範囲) 検索精度面 + 回答品質面 ・ドキュメントを読み込み、自動で再検索 ・クエリを大幅に書き換える 体験面 ・Agentライクな動作 ・聞き返し・確認 全体として動的に処理フローが変わる (ここはまだまだ大変)

Slide 100

Slide 100 text

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/

Slide 101

Slide 101 text

104 他にも課題はたくさん データ工学(分析・前処理)・情報検索・ 機械学習(生成AI・LLM) デザイン(UI・UX)・HCI・システム工学 などの知見をフル活用 https://dev.classmethod.jp/articles/improve-work- efficiency-with-generateive-ai-chatbot-using-rag/