リクルート新人研修2024​ テキスト生成AI活用

2024年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. リクルート新人研修2024 テキスト生成AI活用 シニアサーチエンジニア 大杉直也
2. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
3. 大杉 直也 ボードゲーム 経歴 / Career 2014年にリクルート新卒入社。 2017年、N高等学校に3年次編入（社会人高校生）。 2020年、同高校卒業。 現在は、シニアサーチエンジニアとして働く傍ら、プロ ンプトエンジニアリングの社内研修や事業現場へのヒア リングを踏まえた大規模言語モデルの利活用推進を実施 している。 現在、デジタル庁でもAI部門 担当者として兼業中。 趣味 / Hobbies データ推進室 データプロダクトユニット アジリティテクノロジー部 A/Bテスト実践ガイド（翻訳） Apache Solr 入門（第3版） 出版物 / Publications
4. リクルートでは、2023年7月に「AI活用指針」を策定し、AIガバナンスの取り組みについても公表。 従来から行っていた「標準プロセス」と呼ばれるサービス審査に加え、「フェアネスモニタリング」を実施 し、サービスリリース後も人権侵害、差別の助長、多様性の排除が、実際のアルゴリズムやサービスにおい て生じていないかのチェックを実施。 4 リクルートでは、2023年7月に「AI活用指針」を策定し、AIガバナンスの取り組みについても公表。 従来から行っていた「標準プロセス」と呼ばれるサービス審査に加え、「フェアネスモニタリング」を実施 し、サービスリリース後も人権侵害、差別の助長、多様性の排除が、実際のアルゴリズムやサービスにおい て生じていないかのチェックを実施。 4 前提：リクルートにおけるAI利活用について
5. 講義の狙い 大規模言語モデル = 生成AI =ChatGPT ↑この解像度で会話されると困るので、ここの解像度を上げる
6. 経済産業省 AI事業者ガイドライン案より ここがスコープ
7. 講義の狙い 大規模言語モデル ≠ 生成AI 生成AIはテキスト以外の出力もありえる 画像、動画、音声。。。 大規模言語モデルはテキスト生成AIの中身の一形態 機械翻訳などもテキスト生成AIの一種だとみなせる（定義次第だが） GPT以前のseq2sec (LSTMなど)は一般に大規模言語モデルとは言わないがテキストを 生成可能
8. 講義の狙い 生成AI≠ChatGPT 生成AIはチャットインターフェース以外での用途も大量にある →スライド後半の内容 ChatGPT (OpenAI社)以外にもプレイヤーがたくさんいる →Anthropic, Alphabet, OSS系, 国産勢 ベンダーロックインを防ぐためにも選択肢を広く押さえておくべき
9. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
10. マーケ担当者必見！ChatGPTを"実際に"業務 利用するには 株式会社リクルート データ推進室 大杉 直也
11. 「書かせる」より「読ませる」 https://www.coursera.org/learn/generative-ai-for-everyone/lecture/K56zF/ai-is-a-general-purpose-technology 大規模言語モデル(ChatGPTの中身)は、チャットインターフェース以外でも利用可能だし、「書く」だけでなく「読む」方も得意 「ChatGPT」という特定のWebサービスや、「生成AI」という用語にひきづられているせいか、「チャット」や「書く」に活用 方法の検討が偏りがち。実際に、リクルートで活用筋を検討していく中で「読む」能力が非常に重要だった
12. https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/#gemini- 15 「読む」能力はどんどん進化している (2024/04/08 補足)
13. 「読ませる」事例 広告表現ガイドライン（※ダミーデータをもとにGraffer AI Studioを利用） 長いので中略
14. 「読ませる」事例 広告表現ガイドライン（※ダミーデータをもとにGraffer AI Studioを利用） 長いので中略
15. 「読ませる」事例 日本語表現の校正（※Graffer AI Studioを利用し、情報を一部マスキング） 長いので中略
16. 「読ませる」事例 ペルソナなりきり（※Graffer AI Studioを利用し、情報を一部マスキング） 長いので中略
17. 「読ませる」事例 ペルソナなりきり チャットで会話を続ける
18. 「書かせる」より「読ませる」 https://www.coursera.org/learn/generative-ai-for-everyone/lecture/K56zF/ai-is-a-general-purpose-technology 「書かせる」に主眼を与えたときも「読ませて」書かせるテクニックがある 大量ルール読み込みが可能なのは示したので、他の事例を紹介
19. 「読ませ」て「書かせる」事例 例示を与えてトンマナを指定（※ダミーデータをもとにGraffer AI Studioを利用） 長いので中略 トンマナなどが、言語化できる場合は明示化すべき とはいえ、言語化困難な場合は過去のGood Exampleを与え ることで、それっぽい感じに書いてくれる
20. 持ち帰りまとめ • 「書かせる」や「チャットインターフェース」に引っ張られない。むしろ、「読ませる」方が活用筋あり • もう手元で動かせる状態なので、使ってみる。活用しているところはとっくに活用している • 「独自データ」があるところではプラスを狙う。「独自データ」なくできるところは危機感を持つ • リクルート内の知見だけでなく、外の世界の「製品化」されているものをキャッチアップした方が良い
21. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
22. 「なんでGPT4じゃないの？」へ のアンサー via BigQuery+PaLM2 2023/10/13 リクルート シニアサーチエンジニア 大杉直也
23. 自己紹介 2014 若手研究者 (脳科学) 2023 国家公務員(人工知 能) 他にも、検索改善したり、Solr入門書いたり、GM(管理職)やってやめたり、N高を卒業したりといろいろありました リクルートでエン ジニア A/Bテスト実践ガイド - アスキードワンゴ (asciidwango.jp)
24. 今日の発表の趣旨 「いやいや、こういうユースケースならBigQuery + PaLM2が最高な んですよ」って答える（≒布教する） なんでGPT4 じゃないの？
25. BigQuery MLからPaLM2を呼び出せることは既知とする API利用料がはるかに安い（ありがとう文字数課金） ぶん回す前のコスト見立てが容易（ありがとう文字数課金） 既にBigQueryに入っているデータに対してならSQLで完結（開発コスト激小） この特性は具体的にどんなユースケースだと明確なメリットになるか LTの前で宣伝されているはず。。。。
26. 私の答え（あくまで一例です） すでにBigQueryにはいっているテキスト情報に変なものがないかの一斉調査 さっと安く試せるなら、やらない理由が少ない（コスパの大幅改善の結果） 数件でもやばい例が見つかったら儲けもの、くらいの期待値で始めやすい（今までやってなかっ た場合は特に） 具体的にはどんなケースが考えられるか？
27. ※ここから先の例はあくまで例えです 所属する組織でおきた実際の問題とは限りません
28. 口コミに公序良俗に反する表現が使われていないか確認 ※自社にとって「不利」な口コミを検閲したいわけではない 単純に、「その表現やばくない？」を見つけたい だいたいのコンテキストでアウトな差別的言動など 仮に人間が審査している場合でも、見落としはゼロではないので、コストがほぼかからないので あれば、やったほうがいい案件 １件でも見つかれば儲けもの。これで見落としたとしてもやらないよりマシ 品質要件が十分低い
29. 入力情報にミスがないかの検知 まれに、価格などで変な数字が入る可能性がある 変な価格、は商品によって変わるので一律な機械的判定は難しい なぜかLLMは自身の知識を使って妥当な判断をできることがある LLMの「知識」という謎多き存在・・・ コストがほぼかからないのであれば、やったほうがいい案件 １件でも見つかれば儲けもの。これで見落としたとしてもやらないよりマシ 品質要件が十分低い
30. 過去に自動生成・抽出した文章や単語の再精査 LLM以前にいろいろとやってきていた場合 古くはワードクラウドなんてものが流行りました マーケティング界隈などでは特に色々ありそう キーワード検索のパンくずリストとかリスティング広告とか 文脈に適さない、や、そもそも企業として使用すべきでない単語など、使っちゃってるかもしれない。なん ならデプロイ済みかもしれない 思い当たる節があっても優先順位問題の関係でやれてないケースも多そう コストが低くなったので、思い当たる節のある人は今すぐチェック！ １件でも見つかれば儲けもの。これで見落としたとしてもやらないよりマシ 品質要件が十分低い。他のLLMの出力のダブルチェックにもいいかも
31. 今日の発表の趣旨 実際の課題の特性を見ながら、ちゃんと技術選定しましょう！ ↑当たり前の話でした！ なんでGPT4 じゃないの？
32. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
33. GPT-3.5による大規模なテキストデータ 変換を200並列のバッチ処理で実施した 話 (株)リクルート 大杉直也
34. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
35. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
36. 今回の案件 「共通求人票フォーマット」を 作成し、リクルートの多種多様 な求人サイトに対してまとめて 掲載できるようにする 共通求人票フォーマット
37. 「データ連携」がやってきた 「共通」から「個別」の流れは比較的スムーズ 比較的構造化されたテキストから、比較的構造化されていないテキストへの変換 新規の求人票はこの流れを取る 一方で、「個別」から「共通」の流れ。。。 自由記述の中から、共通フォーマットにふさわしい表現を抽出 既存の求人票（大量にある）を対応させるニーズがある場合、この逆流が発生する この種のニーズは何度も発生しない代わりに「短期間に大量に実施したい」となりやすい しかも求人メディアは複数ある さらに、1レコードの単位が下の方が粗いケースも存在する 例：共通フォーマットでは募集職種単位だが、サービスによっては店舗単位(複数職種を募集)の場合も
38. 求人票の例 ※これはダミーデータですが実際の求 人票もこのようになっています 単位が「事業所」になっているため、 一つの求人票に、職種も雇用形態も給 与も勤務時間もバラバラの内容が複数 混ざる これを職種単位の世界に持っていきた い 職種 【キレイなオフィス】[A](1)フロアレディー [社](2)ホール[A](3)ドライバー 給与 (1)時給5000円〜(2)月給35万円(3)時給1300円 勤務時間 (1) 19:00〜1:00 週1日・1日4h〜OK (2) 18:00〜3:00 [正]実8h、週休２日制 (3) 17:00〜19:00、1:00~04:00 職種じゃない 数字・雇用形態の順番でない 月給時給がまざる 以上の意味 柔軟な記述方法 勤務時間じゃない 表記揺れ
39. 何をやったか 下の既存原稿を上のフォーマットにあわせた変換処理を実施 正規表現などのルールベースでは困難なケースがあまりに多く、大規模言語モデルを利用 求人メディアの数も多く、ルールの作り込みでカバーするのが非常に困難 大規模言語モデルのいわゆるZero-Shot promptingのおかげでなんとかした 実施した2023年8月当時はAzure OpenAI Service 一択だった 今でも最有力候補のひとつ 人間がチェックするフローがまずあり、それのリードタイム改善を目標 人間がやる処理をGPT-3.5によって自動化したのではない 人間の作業をサポートするための原案出し(下書き)をGPT-3.5で実施 AIの品質面の問題だけでなく、職安法の観点から。勝手な求人内容の書き換えはNG 最終チェックを行う現場担当の方からの評判は上々
40. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
41. チャットでの利用とシステムでの利用 チャットでの利用 ChatGPTのユースケースがあまりに目立ったため、LLMをチャット目的で利用する発想に偏りやすい GPTシリーズもチャットで利用できるような事後学習が行われている模様 ユーザーからの自然文をベースとした入力をLLMに行い、LLMからの出力をベースとしたものをユーザーに返す システムでの利用 一方、コンピュータの情報の流れの大半はユーザーとのチャット形式ではない 入力がユーザーからの自然文ではない or 出力はユーザーに直接返さないケース 今まで機械的に扱いにくかった自然言語を非常に扱いやすくなったのが、この観点からみた生成AIの革命 LLMの出力形式をjsonなどのシステムで扱いやすい形式で指定すれば、自然言語 (非構造化データ)を構造化データにできる
42. GPTをバッチ処理で動かすときに特に気をつけ ること システムパフォーマンス観点 だいたいのLLM系のPaaSは1分間にさばけるアクセス (とtoken量)に制約がかかっている 1リクエストあたりにかかる時間も（普通のAPIと比較して）遅い バッチ処理は実行時間にXXX時間以内、といったサービスレベルをもちがち →現実的に要件に見合わない可能性大 それでも人が作業するよりかは早い（はず） コスト観点 LLM系のPaaSはtoken量(または文字数)に比例する費用が発生する 少量なら非常に安価だが、大規模なデータ変換ではバカにならないコストがかかってくる・・・ →費用対効果が見合わない可能性あり それでも人を雇うよりははるかに安い（はず）
43. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
44. これで課題を緩和 https://learn.microsoft.com/ja- jp/azure/ai- services/openai/concepts/provisioned- throughput#what-does-the- provisioned-deployment-type-provide
45. 300 PTU (GPT-3.5 turbo)を契約 システムパフォーマンス観点 Requests per minute (RPM)は最大で1450〜1580 (実測) 同時並列実行数は最大で200 (実測) →今回の要件では十分な性能であった コスト観点 当時とは円相場も異なり、Azure側の値段設定も異なる なによりも GPT-3.5 turbo が値下げされている →当時は従量課金よりも安かった。ただし、今はコストメリットが出るかは不明 →コスト予測が容易 & バッチ処理のサービスレベルを満たすためのパフォーマンスを買う、くらいの考えがよさそう
46. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
47. アーキテクチャ • リクルートではデータ基盤に BigQueryを採用している • 担当組織では運用監視をAWS によせている • その前提条件のもと、無理に Azureによせることをせず、IP 制限をかけたAOAIにGCP環境 からアクセスした • 処理時間の大半はデータ転送 関連ではなく、AOAI内部の処 理
48. LLMで行ったおおまかな処理 ※JD→Job Description (求人票) 独自色が強く、LangChainなどのフレームワーク を採用せず、GCP Dataflow上のPythonで実装
49. プロンプト例 職種抽出実施後のプロンプ ト {extraction_target}: 求人票の テキスト {occupations}: 前段の処理で LLMにより抽出した職種名 {example_for_each_occupati on}: 職種ごとに抽出する項 目の例。Json形式。各項目 の書きっぷりや粒度感を細 かく指定するのが大変だっ たので、例示をする形式を とった 当時はjsonモードもなかっ たが、この書き方で安定し た出力形式が得られた Prompt sample 「{extraction_target}」 related texts extraction for {occupations}. 職種の違いを反映。 {additional_description} output example (JSON keys must be same as this example, if there is no relevant information, just write "N/A" as the value.) {example_for_each_occupation} Adhere to the format Think it step by step
50. 品質評価の考え方 リリース前にエンジニアが実行する小規模なもの 求人票分割・固有表現抽出系の課題は、評価観点が明確なのでエンジニアで試行錯誤が容易 プロンプト開発時は手元での試行錯誤が非常に重要なのでエンジニアが評価できる状態を絶対に作るべき 手元のサンプルでプロンプトを調整した後、いくつかの条件別に100程度抽出した求人票でテスト この100という数字が統計的にどこまで妥当かは確認せず 定性的なテストになるため、なかなかしんどいが必要な作業 一部、文章作成系の課題も存在。エンジニア側での評価は困難 規約があり、この規約を遵守するようにプロンプトは書いた。規約NGかどうかの評価は可能 文章の質、は評価困難 リリース後に現場担当者の行動から推定 定性的な評判(上々)だけでなく、定量的な効果測定も実施 費用対効果の観点からLLMの採用が妥当だったのか (1)どれだけLLMの原案を利用したか、(2)LLMの原案に修正はどのくらい必要だったか、(3)LLMの原案利用で どれだけ作業スピードは向上したか (2)は人間がチェックしないケースも考慮必要。後工程に人間がいるからといってそれだけで品質が担保できるわけではない 具体の数字は内緒。良い結果であった、とだけ共有
51. Agenda  実施したことの概要  GPTをバッチ処理で利用する、とは  300 PTUの契約とそのパフォーマンス  なにをどう作ったか  今後の展望
52. システムでの利用の社内ユースケースの探 索 チャットでの利用よりも、システムでの利用のユースケースが多いのではないか？ ChatGPTのユースケースがあまりに目立ったため、LLMをチャット目的で利用する発想に偏りやすい →研修や勉強会、実際に動くPoCを作って宣伝活動を実施 まだまだ「できることを知らない」人が多い印象 最近は画像も扱えるようになった プロンプトの改修だけでできる範囲が広いため、PoCが作りやすい点は推進する上で役にたつ とはいえシステムでの利用で考えるべきことは多い 特にコスト観点の試算は重要 大規模なケースでもPTUを買えば性能は出るが、費用対効果が全ての場合ででるか、は怪しい 今回の例がわかりやすいユースケースだったため、これを軸に布教していきたい 世の中的にもまだまだ良い事例は眠っているはず。特に今までできなかったことができるようになる系で何かないか？
53. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
54. 検索エンジニアが考える、 生成AI時代の人間の付加価値とは 株式会社リクルート データ推進室 大杉 直也
55. 大杉 直也 ボードゲーム 経歴 / Career 2014年にリクルート新卒入社。 2017年、N高等学校に3年次編入（社会人高校生）。 2020年、同高校卒業。 現在は、シニアサーチエンジニアとして働く傍ら、プロ ンプトエンジニアリングの社内研修や事業現場へのヒア リングを踏まえた大規模言語モデルの利活用推進を実施 している。 現在、デジタル庁でもAI部門 担当者として兼業中。 趣味 / Hobbies データ推進室 データプロダクトユニット アジリティテクノロジー部 A/Bテスト実践ガイド（翻訳） Apache Solr 入門（第3版） 出版物 / Publications
56. 2023/02/10 2023/10/18 2023/03/03
57. 2023/03/04 このあと、世の中的にはChatGPTプラグインが出たり、RAGという言葉が流行ったり、生 成AIと組み合わせる汎用ベクターサーチを各クラウドサービスで発表されたり、ChatGPT にweb browsingの機能がついたりと色々おきました 大規模言語モデルは万能ではない。それを活用（既存手法を強化）＆補助（既存手法で強 化）はまだまだやることが大量にある→おかげで仕事が増えた 今日はその辺の話をします
58. 今日の話の流れ • 大規模言語モデルで既存手法を強化する話（活用） ◦ 検索エンジンを強化する ◦ ヒトを強化する • 大規模言語モデルを既存手法で強化する話（補助） ◦ 検索エンジンで強化する ◦ ヒトで強化する • リクルートx生成AIで作られる世界の方向性（予想）
59. b 大規模言語モデルで 既存手法を強化する話（活用） 検索編 検索エンジニアが考える、生成AI時代の人間の付加価値とは
60. 検索エンジンを大規模言語モデルで強化する 検索エンジン データ 分析レポート フォーマット変換 ラベリング データクレンジング 文章生成・要約 など 集計結果の解釈 インサイトの提案 など 更新処理・データ分析 検索エンジン 検索 クエリ 検索結果 固有表現抽出 クエリ意図推定 など 再フィルタリング 検索結果の解釈 など オレンジ色が大規模言語 モデルで実現可能な処理
61. 前述の処理のほとんどは大規模言語モデル以前の自然言語処理の手法でも実現可 能 大規模言語モデル以降では何が変わったか？ →汎用的なモデルに対してのプロンプトの工夫だけで多種多様な処理が実装可能 →→品質と開発リードタイムの大幅な削減 さらに →該当処理の開発に必要なスキルが大きく変わった →→いわゆるプロンプトデザイン →→従来のデータサイエンス能力は品質評価の観点で依然重要 このことから「より多くの人」で「多種多様な試行錯誤」を「迅速」に行えるよ うになった 理想は要件定義時点で企画者が「このプロンプトでいける！」と正しく言える状 態 そのための環境整備と教育をどうすべきかを社内で検証中
62. b 大規模言語モデルを 既存手法で強化する話（補助） 検索編 検索エンジニアが考える、生成AI時代の人間の付加価値とは
63. 検索エンジンで大規模言語モデルを強化する 大規模言語モデルの弱点である 1. 知識のアップデートを大量・高速に実施 a. プロンプトに知識埋め込みはtoken数制約にひっかかる b. 追加学習は計算時間がかかる 2. 大量のデータを解釈性高く制御 a. 中身の処理がブラックボックス は検索エンジンが得意とするところなので、検索エンジンと組み合わせることが 有効 リクルートではこの検索エンジンを高品質にするための条件が揃っている
64. 検索エンジンで大規模言語モデルを強化するために重要なもの 検索対象のアイテム - リクルートでは全国の営業網からファクトチェックされた信頼のおけるアイテムが登録される 検索のアルゴリズム - 流行りの汎用型の埋め込み表現はドメイン特化の検索では品質いまいち。教師付き学習によるファインチューニング が必要 - リクルートでは複数のドメインでシェア率業界トップクラスのWebサービスがあり、そこの検索関連ログが優良なシ グナルになる 検索のシステム基盤 - リクルートでは検索システムを、(1)汎用的なもの(2)特化型のものをそれぞれ提供する専門のエンジニア組織が存在 （いわばスタートアップからエンタープライズまで） 検索の評価 - データ基盤が整備されており、社内にA/Bテストの専門家もいる
65. b 大規模言語モデルで 既存手法を強化する話（活用） ヒト編 検索エンジニアが考える、生成AI時代の人間の付加価値とは
66. ヒトを大規模言語モデルで強化する いわゆる生成AIによるDX案件 リクルートだと「記事作成」「校閲」などが比重高そう 記事作成 取材した内容メモから記事タイトル案の提案 →きちんとファクトチェックしている 校閲 広告表示のガイドラインなどに抵触していないかの確認 →法律で明確に定められたルールを遵守する リクルートのメディアとして「品質」を担保する活動を強化できる
67. ヒトを大規模言語モデルで強化する 記事テーマ キーワード 取材メモ など 記事作成補助 校閲補助 記事原稿 入稿情報 など この記事原案を元に記事を作れる 必要なら大規模言語モデルとチャットしながら整えてい く 作家性が重要でない箇所（例：アクセス情報）の文章作 成を省エネ化し、「どんなテーマ」で「どんな見出し」 で「どんな構成にするか」といった拘りポイントにヒト は注力できるようになる 過去の良い記事例 記事作成のコツ など 法令ガイドライン 社内表記ルール など ＋ ＋ オレンジ色が大規模言語モデル で実現可能な処理 固有のルール 記事原案 社内限定の知識 修正案 リクルートでは実際に記事がリリースされる前の品質担 保を重要視している この品質担保に必要な知識はかなり多く、レビューでき る人材が希少リソースになりがち 固有のルールによる判定を大規模言語モデルで行うこと で (1)希少リソース人材の作文工数の削減 (2)希少リソー ス人材に頼らない初心者育成ができる
68. b 大規模言語モデルを 既存手法で強化する話（補助） ヒト編 検索エンジニアが考える、生成AI時代の人間の付加価値とは
69. ヒトで大規模言語モデルを強化する 供給側の情報 宿や飲食店や物 件など ヒトが介在しない場合 ヒトが介在する場合 生成AIだけでも、消費者像に合わせた加工は十分 可能 しかし、 (1) そもそも供給側の情報は本当か (2) 文言が法律要件などに合うか (3) 本当に消費者に好ましいものか などに不安が残る オレンジ色が大規模言語モ デルで実現可能な処理 ヒトが介在することで、上述の不安は解消され、 以下のように付加価値をつけられる • 特に重要なのは、供給側(クライアント)と 直接接点を持っていることで、消費者から のフィードバックを伝えることができる点 • これにより、需要と供給のバランスがより 取りやすくなり、ムダの少ない効率的な市 場経済が実現されやすくなる • また消費者の潜在的なニーズを顕在化する ドライバーを作ることで (例：見出し文言) 供給側(クライアントの種類)もより多様に なっていく 供給側の情報 宿や飲食店や物 件など 消費者 原案 加工後 情報 消費者 加工後 情報 校正 ファクトチェック 編集 フィードバック
70. ヒトで大規模言語モデルを強化する 現状の大規模言語モデルは (1)現実世界のファクトチェック (2)何が良いものかの価値の最終判断の2つができない 価値向上には編集組織と営業組織との協業が不可欠 • 企画立案だけでなく、綿密な取材や実際にお客さんのところまで足を運び、 意思決定できる人材がいる • クローリングなどのよる「質より量の世界観」ではこれらは高コスト体質と 見なされがちだったが、生成AI時代では「量」は誰でもできるようになり、 「質」が重要になるはず • そしてこの「質」を組織的に得られるようになるには一朝一夕ではなかなか 難しいのではないか？
71. サービス ヒト 検索エンジン 生成AI 不足を補う 不足を補う 機能強化 生産性向上 機能提供 利便性向上 価値向上 生成AI時代はこの世界観でより良いものが作られていく（はず）
72. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例（一部のみ公開） • GPT-4以外を使うべき事例 • BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
73. チャットbotを今後作る時のジレンマ • ChatGPT以降、チャットインターフェースでの期待値が爆上がりしている • 先ほどの事例 • 一方で、無邪気に生成AIベースにすると • １リクエストあたりのコストが高い • 不正確な回答を許容する仕掛けが必要になる • 利用規約での免責 • 利用者の期待値調整 • が、ダメな時はダメ（世の中的に失敗事例は多々ある） • そもそもChatGPTを上手に使える人が限定的なのでチャットインターフェース自 体が人類には早い説 • 応答を繰り返すことで回答精度を上げる！みたいなムーブがまだ定着しきっていない • とはいえ「自然文で雑に検索できる」は利便性が一定あるため、そのような情報 検索システムをどのように作ればいいかを考察する
74. 生成AIを自然文検索で利用する場合の重要な観点 •できる限りリアルタイムで生成AIを使わない • コストと回答品質とレスポンスタイムの観点全てから •事前に解答例を大量作成し、それに対して検索をかける仕組みを原則とする • リクルート提供の情報検索サービスは用途が限定されるものが中心になるはず • 想定用途以外の場合の品質が保証できないことは利用規約に明記する • ChatGPT的な汎用モデルは想定していない • 従来からのチャットbotの延長線上にある • いわゆる事前準備した回答に該当しない場合に、生成AIの結果を返す形式がありうる • これをやるメリットがコスト見合いであるかは要検討 • 初期スコープからは基本外す • 解答例を大量作成しながら論点出しも行う • 「答えてほしくない種類の質問の特定」など • 仮にこれがあるならキャッシュヒットの前段に「答えてほしくない質問か」を判定する仕組みを導入 • LLMでもいいし、もっと小さいtransformerのfine tuningでもいい
75. •PoC開発時は生成AIの結果を返し、本番運用するさいに本仕組みを開発する 生成AI関連でよく言及されるがさほど重要でない観点 •プロンプトインジェクション対策 • 機密をプロンプトに書かない • 回答結果のフォーマットを指定し、フォーマット通りだった場合に一部だけをユーザーに返却するようにし、 プロンプトインジェクションにロバストにする • 回答精度向上のためにChain of Thoughtを導入するときにも重要 •機密性 • 重要だが生成AI固有ではない。普通のシステム開発と一緒 • 後述
76. 生成AIをクラウドサービスのAPI経由で利用する場合の想定リスク
77. 処理フロー別の気にするべきポイント
78. 処理フロー別の気にするべきポイント •テストデータの充実 • これが十分ならキャッシュヒットの仕組みは作り込ま なくてもいい • ただし1回も使われない回答結果はコストでしか ないので無限に作ればいいものでもない • 費用対効果の計算がむずい・・・ • 手順 • 想定質問リストの準備 • LLMベースで作成（論点あり） • 想定質問に対する回答の準備 • バッチで生成AIに想定質問を大量に投げる • 大量に投げる前に一部の質問だけで回答 品質を確かめる • 回答結果の品質の確認 • 人力がベースで、一部LLMでサポートする • 人力でやる場合、評価観点を明確にして おく
79. 処理フロー別の気にするべきポイント •キャッシュヒットの仕組み • 検索エンジンを利用する場合、製品を利用するか、内製でつくるか • 製品例 • Vertex AI Search, AWS Kendra, Azure CosmosDB • 判断軸 • 検索機能。特に絞り込み条件 • 内製有利。ここで有利になる転置インデックスが内製の最有力候補 • 開発・運用コスト • 製品有利 • リクエストの処理性能 • 内製有利 • 検索品質 • ケースバイケース • 本ユースケースで判断軸にならないもの • 機密性 • 内製有利 • 更新性能 • 内製有利 • 多様なデータソース対応 • 製品有利 • 内製で作る場合の観点 • クエリと検索アルゴリズム • 埋め込み表現 (similarity search) • 汎用的なものだとコンテキストが入りきらない • キーワード検索 • 固有名詞や重要ワードなどの対応 • 形態素解析 • 知識グラフの利用 • ユーザーのコンテキスト理解 • 検索時刻や過去のユーザ行動やプロフィールなどの利用 • インデックス • ラベル付や更新時刻などのメタデータ • 埋め込み表現 • 検索エンジンを利用しないセマンティックキャッシュの仕組みも提案されているが、自前での改 善を前提とした運用を考えるとPaaSで使える or 運用にノウハウが溜まっている検索エンジンの 利用を推奨したい •精度の評価 • 原則再現率と適合率で判断だが、用途を考えると top 1の再現率だけで良い •ヒット判定 • relevancyの閾値が一定以上のものをヒット扱いにする • ここのrelevancyは用途やテストケースの充実度やリクエストの多様性によってかわる。 • 定性で見ながら「えいや」で決める • Ground Truthのラベル付ができているならROCを見て決める
80. 処理フロー別の気にするべきポイント •リリース前 • 負荷のプランニング • 1分あたりのtoken数とリクエス ト数 • キャパシティプランニング • コストプランニング • 対策の実施 • 入出力token数の抑止 • PTU契約 • アクセスジャムフィルター •リリース後 • 死活監視 • コストモニタリング • 入出力token数のモニタリング • リクエスト数のモニタリング •副系 • ユーザーのコンテキスト情報から定 型句をルールベースで作成など（生 成AI以前の手法を採用）
81. 処理フロー別の気にするべきポイント リリース前 • どのような内容が無難かの言語化 • メディアの規定類などの調査 • 汎用的なものはAIモデル開発者で対応。基本これを信じる • テストケースの作成と生成結果の目件 • テストケースの作成は人手とLLMで実施 • 生成結果の目件はチェック観点を明確化 • 例: 引用先が妥当。引用先を正しく引用。表現が自 然。規定に抵触しない等 • コンテンツフィルターの導入の検討 • CSPで汎用的なものを準備 • 独自実装は基本的にフィルター性能と開発や運用工数が見 合わないはず • 回答形式の指定の検討 • Chain of thought的に回答性能を上げるためにも重要 • 回答形式でない結果はnoに判定 •リリース後 • コンテンツフィルターに引っかかった内容の確認 • 回答形式が守られなかったケースの確認 • 変な質問の可能性大（aaa としか書いてないとか） • エンドユーザからのこっそりフィードバックを可能にする • 内容が十分に妥当な場合、キャッシュに追加 • ここを自動化するかは案件ごとに個別判断
82. 生成AIを自然文検索で利用する場合の重要な観点 •できる限りリアルタイムで生成AIを使わない • コストと回答品質とレスポンスタイムの観点全てから •事前に解答例を大量作成し、それに対して検索をかける仕組みを原則とする • リクルート提供の情報検索サービスは用途が限定されるものが中心になるはず • 想定用途以外の場合の品質が保証できないことは利用規約に明記する • ChatGPT的な汎用モデルは想定していない • 従来からのチャットbotの延長線上にある • いわゆる事前準備した回答に該当しない場合に、生成AIの結果を返す形式がありうる • これをやるメリットがコスト見合いであるかは要検討 • 初期スコープからは基本外す • 解答例を大量作成しながら論点出しも行う • 「答えてほしくない種類の質問の特定」など • 仮にこれがあるならキャッシュヒットの前段に「答えてほしくない質問か」を判定する仕組みを導入 • LLMでもいいし、もっと小さいtransformerのfine tuningでもいい 確認。この話をしました