Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Recruit
August 29, 2024

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

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

Recruit

August 29, 2024
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  2. 大杉 直也 ボードゲーム 経歴 / Career 2014年にリクルート新卒入社。 2017年、N高等学校に3年次編入(社会人高校生)。 2020年、同高校卒業。 現在は、シニアサーチエンジニアとして働く傍ら、プロ

    ンプトエンジニアリングの社内研修や事業現場へのヒア リングを踏まえた大規模言語モデルの利活用推進を実施 している。 現在、デジタル庁でもAI部門 担当者として兼業中。 趣味 / Hobbies データ推進室 データプロダクトユニット アジリティテクノロジー部 A/Bテスト実践ガイド(翻訳) Apache Solr 入門(第3版) 出版物 / Publications
  3. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  4. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  5. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  6. 求人票の例 ※これはダミーデータですが実際の求 人票もこのようになっています 単位が「事業所」になっているため、 一つの求人票に、職種も雇用形態も給 与も勤務時間もバラバラの内容が複数 混ざる これを職種単位の世界に持っていきた い 職種

    【キレイなオフィス】[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、週休2日制 (3) 17:00〜19:00、1:00~04:00 職種じゃない 数字・雇用形態の順番でない 月給時給がまざる 以上の意味 柔軟な記述方法 勤務時間じゃない 表記揺れ
  7. 何をやったか 下の既存原稿を上のフォーマットにあわせた変換処理を実施 正規表現などのルールベースでは困難なケースがあまりに多く、大規模言語モデルを利用 求人メディアの数も多く、ルールの作り込みでカバーするのが非常に困難 大規模言語モデルのいわゆるZero-Shot promptingのおかげでなんとかした 実施した2023年8月当時はAzure OpenAI Service 一択だった

    今でも最有力候補のひとつ 人間がチェックするフローがまずあり、それのリードタイム改善を目標 人間がやる処理をGPT-3.5によって自動化したのではない 人間の作業をサポートするための原案出し(下書き)をGPT-3.5で実施 AIの品質面の問題だけでなく、職安法の観点から。勝手な求人内容の書き換えはNG 最終チェックを行う現場担当の方からの評判は上々
  8. 300 PTU (GPT-3.5 turbo)を契約 システムパフォーマンス観点 Requests per minute (RPM)は最大で1450〜1580 (実測)

    同時並列実行数は最大で200 (実測) →今回の要件では十分な性能であった コスト観点 当時とは円相場も異なり、Azure側の値段設定も異なる なによりも GPT-3.5 turbo が値下げされている →当時は従量課金よりも安かった。ただし、今はコストメリットが出るかは不明 →コスト予測が容易 & バッチ処理のサービスレベルを満たすためのパフォーマンスを買う、くらいの考えがよさそう
  9. プロンプト例 職種抽出実施後のプロンプ ト {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
  10. 品質評価の考え方 リリース前にエンジニアが実行する小規模なもの 求人票分割・固有表現抽出系の課題は、評価観点が明確なのでエンジニアで試行錯誤が容易 プロンプト開発時は手元での試行錯誤が非常に重要なのでエンジニアが評価できる状態を絶対に作るべき 手元のサンプルでプロンプトを調整した後、いくつかの条件別に100程度抽出した求人票でテスト この100という数字が統計的にどこまで妥当かは確認せず 定性的なテストになるため、なかなかしんどいが必要な作業 一部、文章作成系の課題も存在。エンジニア側での評価は困難 規約があり、この規約を遵守するようにプロンプトは書いた。規約NGかどうかの評価は可能 文章の質、は評価困難

    リリース後に現場担当者の行動から推定 定性的な評判(上々)だけでなく、定量的な効果測定も実施 費用対効果の観点からLLMの採用が妥当だったのか (1)どれだけLLMの原案を利用したか、(2)LLMの原案に修正はどのくらい必要だったか、(3)LLMの原案利用で どれだけ作業スピードは向上したか (2)は人間がチェックしないケースも考慮必要。後工程に人間がいるからといってそれだけで品質が担保できるわけではない 具体の数字は内緒。良い結果であった、とだけ共有
  11. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  12. 大杉 直也 ボードゲーム 経歴 / Career 2014年にリクルート新卒入社。 2017年、N高等学校に3年次編入(社会人高校生)。 2020年、同高校卒業。 現在は、シニアサーチエンジニアとして働く傍ら、プロ

    ンプトエンジニアリングの社内研修や事業現場へのヒア リングを踏まえた大規模言語モデルの利活用推進を実施 している。 現在、デジタル庁でもAI部門 担当者として兼業中。 趣味 / Hobbies データ推進室 データプロダクトユニット アジリティテクノロジー部 A/Bテスト実践ガイド(翻訳) Apache Solr 入門(第3版) 出版物 / Publications
  13. 検索エンジンを大規模言語モデルで強化する 検索エンジン データ 分析レポート フォーマット変換 ラベリング データクレンジング 文章生成・要約 など 集計結果の解釈

    インサイトの提案 など 更新処理・データ分析 検索エンジン 検索 クエリ 検索結果 固有表現抽出 クエリ意図推定 など 再フィルタリング 検索結果の解釈 など オレンジ色が大規模言語 モデルで実現可能な処理
  14. 検索エンジンで大規模言語モデルを強化する 大規模言語モデルの弱点である 1. 知識のアップデートを大量・高速に実施 a. プロンプトに知識埋め込みはtoken数制約にひっかかる b. 追加学習は計算時間がかかる 2. 大量のデータを解釈性高く制御

    a. 中身の処理がブラックボックス は検索エンジンが得意とするところなので、検索エンジンと組み合わせることが 有効 リクルートではこの検索エンジンを高品質にするための条件が揃っている
  15. ヒトを大規模言語モデルで強化する 記事テーマ キーワード 取材メモ など 記事作成補助 校閲補助 記事原稿 入稿情報 など

    この記事原案を元に記事を作れる 必要なら大規模言語モデルとチャットしながら整えてい く 作家性が重要でない箇所(例:アクセス情報)の文章作 成を省エネ化し、「どんなテーマ」で「どんな見出し」 で「どんな構成にするか」といった拘りポイントにヒト は注力できるようになる 過去の良い記事例 記事作成のコツ など 法令ガイドライン 社内表記ルール など + + オレンジ色が大規模言語モデル で実現可能な処理 固有のルール 記事原案 社内限定の知識 修正案 リクルートでは実際に記事がリリースされる前の品質担 保を重要視している この品質担保に必要な知識はかなり多く、レビューでき る人材が希少リソースになりがち 固有のルールによる判定を大規模言語モデルで行うこと で (1)希少リソース人材の作文工数の削減 (2)希少リソー ス人材に頼らない初心者育成ができる
  16. ヒトで大規模言語モデルを強化する 供給側の情報 宿や飲食店や物 件など ヒトが介在しない場合 ヒトが介在する場合 生成AIだけでも、消費者像に合わせた加工は十分 可能 しかし、 (1)

    そもそも供給側の情報は本当か (2) 文言が法律要件などに合うか (3) 本当に消費者に好ましいものか などに不安が残る オレンジ色が大規模言語モ デルで実現可能な処理 ヒトが介在することで、上述の不安は解消され、 以下のように付加価値をつけられる • 特に重要なのは、供給側(クライアント)と 直接接点を持っていることで、消費者から のフィードバックを伝えることができる点 • これにより、需要と供給のバランスがより 取りやすくなり、ムダの少ない効率的な市 場経済が実現されやすくなる • また消費者の潜在的なニーズを顕在化する ドライバーを作ることで (例:見出し文言) 供給側(クライアントの種類)もより多様に なっていく 供給側の情報 宿や飲食店や物 件など 消費者 原案 加工後 情報 消費者 加工後 情報 校正 ファクトチェック 編集 フィードバック
  17. サービス ヒト 検索エンジン 生成AI 不足を補う 不足を補う 機能強化 生産性向上 機能提供 利便性向上

    価値向上 生成AI時代はこの世界観でより良いものが作られていく(はず)
  18. 目次 • 自己紹介 + 講義の狙い • 生産性改善系事例(一部のみ公開) • GPT-4以外を使うべき事例 •

    BigQuery MLからの利用 • 大規模バッチ処理で使う話 • 今後の展望的な話 • これからのチャットbot開発
  19. チャットbotを今後作る時のジレンマ • ChatGPT以降、チャットインターフェースでの期待値が爆上がりしている • 先ほどの事例 • 一方で、無邪気に生成AIベースにすると • 1リクエストあたりのコストが高い •

    不正確な回答を許容する仕掛けが必要になる • 利用規約での免責 • 利用者の期待値調整 • が、ダメな時はダメ(世の中的に失敗事例は多々ある) • そもそもChatGPTを上手に使える人が限定的なのでチャットインターフェース自 体が人類には早い説 • 応答を繰り返すことで回答精度を上げる!みたいなムーブがまだ定着しきっていない • とはいえ「自然文で雑に検索できる」は利便性が一定あるため、そのような情報 検索システムをどのように作ればいいかを考察する
  20. 生成AIを自然文検索で利用する場合の重要な観点 •できる限りリアルタイムで生成AIを使わない • コストと回答品質とレスポンスタイムの観点全てから •事前に解答例を大量作成し、それに対して検索をかける仕組みを原則とする • リクルート提供の情報検索サービスは用途が限定されるものが中心になるはず • 想定用途以外の場合の品質が保証できないことは利用規約に明記する •

    ChatGPT的な汎用モデルは想定していない • 従来からのチャットbotの延長線上にある • いわゆる事前準備した回答に該当しない場合に、生成AIの結果を返す形式がありうる • これをやるメリットがコスト見合いであるかは要検討 • 初期スコープからは基本外す • 解答例を大量作成しながら論点出しも行う • 「答えてほしくない種類の質問の特定」など • 仮にこれがあるならキャッシュヒットの前段に「答えてほしくない質問か」を判定する仕組みを導入 • LLMでもいいし、もっと小さいtransformerのfine tuningでもいい
  21. 処理フロー別の気にするべきポイント •テストデータの充実 • これが十分ならキャッシュヒットの仕組みは作り込ま なくてもいい • ただし1回も使われない回答結果はコストでしか ないので無限に作ればいいものでもない • 費用対効果の計算がむずい・・・

    • 手順 • 想定質問リストの準備 • LLMベースで作成(論点あり) • 想定質問に対する回答の準備 • バッチで生成AIに想定質問を大量に投げる • 大量に投げる前に一部の質問だけで回答 品質を確かめる • 回答結果の品質の確認 • 人力がベースで、一部LLMでサポートする • 人力でやる場合、評価観点を明確にして おく
  22. 処理フロー別の気にするべきポイント •キャッシュヒットの仕組み • 検索エンジンを利用する場合、製品を利用するか、内製でつくるか • 製品例 • Vertex AI Search,

    AWS Kendra, Azure CosmosDB • 判断軸 • 検索機能。特に絞り込み条件 • 内製有利。ここで有利になる転置インデックスが内製の最有力候補 • 開発・運用コスト • 製品有利 • リクエストの処理性能 • 内製有利 • 検索品質 • ケースバイケース • 本ユースケースで判断軸にならないもの • 機密性 • 内製有利 • 更新性能 • 内製有利 • 多様なデータソース対応 • 製品有利 • 内製で作る場合の観点 • クエリと検索アルゴリズム • 埋め込み表現 (similarity search) • 汎用的なものだとコンテキストが入りきらない • キーワード検索 • 固有名詞や重要ワードなどの対応 • 形態素解析 • 知識グラフの利用 • ユーザーのコンテキスト理解 • 検索時刻や過去のユーザ行動やプロフィールなどの利用 • インデックス • ラベル付や更新時刻などのメタデータ • 埋め込み表現 • 検索エンジンを利用しないセマンティックキャッシュの仕組みも提案されているが、自前での改 善を前提とした運用を考えるとPaaSで使える or 運用にノウハウが溜まっている検索エンジンの 利用を推奨したい •精度の評価 • 原則再現率と適合率で判断だが、用途を考えると top 1の再現率だけで良い •ヒット判定 • relevancyの閾値が一定以上のものをヒット扱いにする • ここのrelevancyは用途やテストケースの充実度やリクエストの多様性によってかわる。 • 定性で見ながら「えいや」で決める • Ground Truthのラベル付ができているならROCを見て決める
  23. 処理フロー別の気にするべきポイント •リリース前 • 負荷のプランニング • 1分あたりのtoken数とリクエス ト数 • キャパシティプランニング •

    コストプランニング • 対策の実施 • 入出力token数の抑止 • PTU契約 • アクセスジャムフィルター •リリース後 • 死活監視 • コストモニタリング • 入出力token数のモニタリング • リクエスト数のモニタリング •副系 • ユーザーのコンテキスト情報から定 型句をルールベースで作成など(生 成AI以前の手法を採用)
  24. 処理フロー別の気にするべきポイント リリース前 • どのような内容が無難かの言語化 • メディアの規定類などの調査 • 汎用的なものはAIモデル開発者で対応。基本これを信じる • テストケースの作成と生成結果の目件

    • テストケースの作成は人手とLLMで実施 • 生成結果の目件はチェック観点を明確化 • 例: 引用先が妥当。引用先を正しく引用。表現が自 然。規定に抵触しない等 • コンテンツフィルターの導入の検討 • CSPで汎用的なものを準備 • 独自実装は基本的にフィルター性能と開発や運用工数が見 合わないはず • 回答形式の指定の検討 • Chain of thought的に回答性能を上げるためにも重要 • 回答形式でない結果はnoに判定 •リリース後 • コンテンツフィルターに引っかかった内容の確認 • 回答形式が守られなかったケースの確認 • 変な質問の可能性大(aaa としか書いてないとか) • エンドユーザからのこっそりフィードバックを可能にする • 内容が十分に妥当な場合、キャッシュに追加 • ここを自動化するかは案件ごとに個別判断
  25. 生成AIを自然文検索で利用する場合の重要な観点 •できる限りリアルタイムで生成AIを使わない • コストと回答品質とレスポンスタイムの観点全てから •事前に解答例を大量作成し、それに対して検索をかける仕組みを原則とする • リクルート提供の情報検索サービスは用途が限定されるものが中心になるはず • 想定用途以外の場合の品質が保証できないことは利用規約に明記する •

    ChatGPT的な汎用モデルは想定していない • 従来からのチャットbotの延長線上にある • いわゆる事前準備した回答に該当しない場合に、生成AIの結果を返す形式がありうる • これをやるメリットがコスト見合いであるかは要検討 • 初期スコープからは基本外す • 解答例を大量作成しながら論点出しも行う • 「答えてほしくない種類の質問の特定」など • 仮にこれがあるならキャッシュヒットの前段に「答えてほしくない質問か」を判定する仕組みを導入 • LLMでもいいし、もっと小さいtransformerのfine tuningでもいい 確認。この話をしました