再帰化への認知的転回/the-turn-to-recursive-system

2022.03.11 ペパボテックカンファレンス

Transcript

1. 再帰化への認知的転回
   三宅 悠介 / GMO PEPABO inc.
   2022.03.11 ペパボテックカンファレンス
   1
   

   View Slide

2. 1. 再帰化の定義
   2. 関数の設計から系の設計へ
   3. 多様かつ継続的に変化する系の設計の難しさ
   4. 複雑な系の導入における機会損失の考慮
   5. そして再帰化へ
   6. まとめ: 再帰化となめらかなシステム・個人的考察
   2
   アジェンダ
   

   View Slide

3. 1. 再帰化の定義
   3
   

   View Slide

4. 「再帰化」とは、構造化・自動化されたサービ
   スが、ユーザとのインタラクションの結果を取
   り込んで、システムを自らより良いものへと改
   修していくプロセスのことをいいます。[*]
   4
   再帰化
   [*] CTOメモ: 2022年のテクノロジー方針（社内資料より）
   

   View Slide

5. 2. 関数の設計から系の設計へ
   5
   

   View Slide

6. 従来のシステム開発では、利用者からの入力
   xに対してシステムの出力yを決定する関数fを設
   計している。
   = 再帰化の定義における「構造化・自動化されたサービス」に該当する部分に該当
   関数の設計から系の設計へ
   6
   従来のシステム開発を「関数の設計」として捉える
   

   View Slide

7. 運用者の経験に基づく設計は、必ずしも利用者の要望を反映しているとは限らない。
   また、認知負荷の観点から利用者の要望に対する
   最大公約数的な振る舞いを選定しがちであ
   る。
   加えて、実装面では、要望の反映までに
   時間がかかるという課題もある。
   関数の設計から系の設計へ
   7
   人手による「関数の設計」の課題
   

   View Slide

8. 関数の設計から系の設計へ
   8
   機械学習は「関数の設計」を自動化する（データからパラメータを求める）
   ① 入出力の対応関係を定義 ② 予測に対するズレを定義
   ③ 学習データに対する予
   測のズレを最小化する
   ④ パラメータが決まる
   （データから関数の設計ができた）
   

   View Slide

9. ● 機械学習を用いたデータに基づく設計は（モデリングが正しければ）利用者の要望を正しく、か
   つ、個別的に反映している（可能性が高い）
   ● 一方で、（機械学習に限らず）設計された関数は、ある時点までのデータに基づく振る舞いを行う
   （内挿性）
   ● サービスを取り巻く環境は継続的に変化していると考えられるため、関数の継続的な再設計が必
   要（外挿の考慮）
   関数の設計から系の設計へ
   9
   機械学習による「関数の設計」の課題
   

   View Slide

10. ● ある時点で有効な関数をサービスや利用者の環境の変化に応じて継続的に再設計（あるいは別
    関数への置き換え）を行う系全体の仕組みを設計する
    ○ 再帰化の定義における「ユーザーとのインタラクションの結果を取り込んで、システムを自らより良い
    ものへと改修していくプロセス」の部分に該当
    関数の設計から系の設計へ
    10
    「関数の継続的な再設計」を可能とする「系の設計」へ（メタァ〜）
    Activity
    Controller
    

    View Slide

11. ● 従来のサービス運用維持はこのサイクルを人手で回していた
    ○ 経験から関数の設計 （適切性の課題）
    ○ エンジニアによる関数の再実装 （追従性の課題）
    ● 再帰化では、フィードバックとシステムの挙動変更をシステム総体のうちに組み込む
    関数の設計から系の設計へ
    11
    「関数の継続的な再設計」を可能とする「系の設計」へ（メタァ〜）
    Activity
    Controller
    

    View Slide

12. 「再帰化」とは、構造化・自動化されたサー
    ビスが、ユーザとのインタラクションの結
    果を取り込んで、システムを自らより良い
    ものへと改修していくプロセスのことをいいま
    す。[*]
    12
    再帰化
    つまりそういうことな
    んですよ

    [*] CTOメモ: 2022年のテクノロジー方針（社内資料より）
    

    View Slide

13. 3. 多様かつ継続的に変化する系の
    設計の難しさ
    13
    

    View Slide

14. • この系における最大の困難は、
    限られたインタラクションから利用者の背景や要求を類
    推しなければならない点である。
    • 閲覧、コンバージョン、利用者の基本属性、文脈、アップロードした商品データ等々
    • 1. インタラクションの保存
    • インタラクションが保存されていることが系の前提。
    • 2. インタラクションの解釈
    • 背景や要求は利用者ごとに 多様である
    • この系の導入前提から 時間的な変化を考慮する必要がある
    多様かつ継続的に変化する系の設計の難しさ
    14
    1. インタラクションの解釈
    

    View Slide

15. • データ基盤Bigfoot[*]のススメ
    • インタラクションの保存と解釈のシステム基盤としては Bigfootが良いと思います（宣伝）
    • Google BigQueryにより、サービスの膨大な履歴を格納、検索が可能
    • Google Vertex AIにより、集計や機械学習モデリングが実現可能
    • データ処理パイプラインによりこれらの継続的な更新が実現可能
    • インタラクションの個別かつ最適な解釈には機械学習の導入が有用
    • 必ずしも機械学習を用いなくとも、平均のようなシンプルな集計や既知のグルーピングによる粒度
    の大きい個別化から始めても大丈夫です
    • 最適な機械学習モデルの検討はペパ研とデータ基盤チームでもガンガンやっていきます
    • 興味ある方、一緒にやりましょう
    多様かつ継続的に変化する系の設計の難しさ
    15
    1. インタラクションの解釈
    [*] GMOペパボのサービスと研究開発を支えるデータ基盤の裏側
    

    View Slide

16. • 利用者の背景や要求を把握するために、利用者から明示的に状態を教えてもらうのは利便性
    の低下につながる
    • 画面遷移ごとに「今、これ買いたい感じ？」とかは聞けない
    • 必要最小限のインタラクションから暗黙的なフィードバックを得ることが望ましい
    • セッションを個別に特定できる仕組み
    • インタラクションに纏わる情報
    • 閲覧時間、スクロール速度、画面内の配置順序、ページング番号など
    多様かつ継続的に変化する系の設計の難しさ
    16
    2. 利便性とのトレードオフ
    

    View Slide

17. • 暗黙的なフィードバックから機械学習などで利用者の背景や要求を解釈した上で、システムは
    振る舞いを変更するところまでが再帰化
    • 再設計した関数に即時切り替え可能か
    • 比較評価と自動かつ継続的な切り替えが必要
    • 突発的な変化を検知可能だったとして、システムが即時振る舞いを変更できるか
    • ホスティングにおけるアクセスの急激な増加
    • ECサイトにおける購買モードの変化
    • オートスケーリングや導線の動的な変更、現状の状況に重み付けした挙動変更の機構が必要
    多様かつ継続的に変化する系の設計の難しさ
    17
    3. 背景や要求にもとづき振る舞い変更する仕組みが必要
    

    View Slide

18. 4. 複雑な系の導入における
    機会損失の考慮
    18
    

    View Slide

19. • 再帰化はあくまで利用者の要求や背景をもとにシステムが動的に変化していくアーキテクチャ
    であり、この上で実行される施策（
    =関数）が全て成功するわけではない
    • 利用者の要求や背景を解釈して最適な挙動に切り替えるってとても難しいことです
    • しかしながら、再帰化の仕組みに乗ることで施策の評価、切り替えが人手を介さずに実行でき
    るため、数多くの施策を比較評価できるという点が重要である
    • 一方で、実環境での施策の評価には
    機会損失が避けられない
    • 短期的には効果の低い施策を使うことによる機会損失
    • 中長期的には、施策の有効性を見誤ることによる機会損失
    複雑な系の導入における機会損失の考慮
    19
    全部の施策が当たると思ってはいけない
    

    View Slide

20. • 複数の施策を正しく無駄なく比較評価するためには
    統計的仮説検定が有用
    • 得られたサンプル数から有用性の差がある（ない）ことを確信できるか
    • A/Bテストと組み合わせると効果的
    • 一方でここに人手が介在すると、切り替えが自動で行われないという問題が発生する
    • 統計的な判断に基づき、良さそうな施策を多く利用しつつ、全体の施策に対して最低限のサン
    プルを収集するような仕組みが求められる
    • 多腕バンディットの利用
    • 導入には、多腕バンディットで始めるデータ駆動（社内資料）を参考のこと
    • データ基盤Bigfootではbigfoot-bandit gemを使うことでサービスへの導入が容易（宣伝）
    • 再帰化の要件を考慮した多腕バンディットのアルゴリズムもペパ研で絶賛研究中です
    複雑な系の導入における機会損失の考慮
    20
    機会損失の低減に向けて
    

    View Slide

21. 5. そして再帰化へ
    21
    

    View Slide

22. Analyzer
    Tokenizer
    22
    検索における再帰化候補の列挙
    minneの検索コンポーネント（現状）
    Index
    Char
    Filter(s)
    Token
    Filter(s)
    Analyzer
    ML Model
    Feature
    Extraction
    Classifier
    Matcher
    Sorter
    Query
    Doc
    Feedback
    Response
    ?
    

    View Slide

23. Analyzer
    Tokenizer
    23
    検索における再帰化候補の列挙
    minneの検索コンポーネント（再帰化）
    Index
    Char
    Filter(s)
    Token
    Filter(s)
    Analyzer
    ML Model
    Feature
    Extraction
    Classifier
    Matcher
    Sorter
    Query
    Doc
    Feedback
    Bigfoot
    Activity
    Controller
    Response
    なお本図は『AIアルゴリズムマーケティング』の「図4-33: マー
    チャンダイジング検索サービスの主要な論理的要素」をもとに
    minne構成ならびに「なめらかなシステム」の要素を踏まえ再構
    成した
    

    View Slide

24. 24
    検索における再帰化候補の列挙
    minne検索システムの再帰化の候補
    • 以下、社内向けの具体的な施策候補（社内資料として省略）
    

    View Slide

25. 6. まとめ
    再帰化となめらかなシステム・
    個人的考察
    25
    

    View Slide

26. • 「再帰化」の取り組みに必要な関数の設計から系の設計へという認知的転回を与えた
    • 「再帰化」の取り組みは、実はペパボ研究所における「
    なめらかなシステム」の実現に向けた
    取り組みに他ならない
    • 本資料の 2. 項と 3. 項は、すべて「なめらかなシステム」の要件にもとづく
    • 「なめらかなシステム」は、利用者と運用者、システムを等価に扱うことが可能
    • また、それらを「自律的」（外部からは入出力の関係性を類推する他ない存在）であることを前
    提に、より挑戦的な課題としてシステムの実現を目指す
    • なめらかなシステムの見据えるもの。個人的考察 - THINKING MEGANE -
    まとめ
    26
    再帰化となめらかなシステム・個人的考察
    

    View Slide

27. 27
    Thank You!
    Thank You!
    

    View Slide