Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
再帰化への認知的転回/the-turn-to-recursive-system
Search
monochromegane
April 01, 2022
Research
1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
再帰化への認知的転回/the-turn-to-recursive-system
2022.03.11 ペパボテックカンファレンス
monochromegane
April 01, 2022
More Decks by monochromegane
See All by monochromegane
Go言語とトイモデルで学ぶTransformerの気持ち / fukuokago23-transformer
monochromegane
0
270
適応的スパムフィルタのための軽量な類似メッセージカウンタ / jsai2026-adaptive-spam-filter
monochromegane
0
5.7k
ベクトル検索のフィルタを用いた機械学習モデルとの統合 / python-meetup-fukuoka-06-vector-attr
monochromegane
3
920
Claude Codeセッション現状確認 2026福岡 / fukuoka-aicoding-00-beacon
monochromegane
4
810
Go言語での実装を通して学ぶLLMファインチューニングの仕組み / fukuokago22-llm-peft
monochromegane
0
310
不確実性下における目的と手段の統合的探索に向けた連続腕バンディットの応用 / iot70_gp_rff_mab
monochromegane
2
570
なめらかなシステムと運用維持の終わらぬ未来 / dicomo2025_coherently_fittable_system
monochromegane
0
49k
ベクトル検索システムの気持ち
monochromegane
38
13k
Go言語での実装を通して学ぶ、高速なベクトル検索を支えるクラスタリング技術/fukuokago-kmeans
monochromegane
1
340
Other Decks in Research
See All in Research
生成AIなんでも展示会vol6 LT登壇資料 NexteraBERT
rikkabotan7
0
160
シングルチャネルマルチトーカー音声認識の進展
ryomasumura
0
330
TESSERA: Temporal Embeddings of Surface Spectra for Earth Representation and Analysis
satai
2
100
視覚若手の会LENSって何??
mickey_0226
0
320
医療LLMの現在地〜最新研究から社会実装までを考える〜
kento1109
1
1.8k
敵対生成プロンプト同時探索による内省型プロンプト最適化
kinoue_smarthr
0
430
MIRU2026 チュートリアル講演2:三次元データ処理の動向
nnchiba
6
5k
学術バーQ AI研究最前線:自己教師あり学習による画像モデルの事前学習
naok615
0
120
[最先端NLP勉強会2026] Agentic Rubrics as Contextual Verifiers for SWE Agents
rfujii
1
370
2026年6月_副業コンプライアンス調査_業界別リスク度分析_株式会社フクスケ.pdf
fkske
0
110
超効率化への挑戦:1bit LLMの現状と展望
yumaichikawa
0
770
2025年度秋葉原ウォーカブルプロジェクト調査報告 「アキバらしいウォーカブル」とは何か
izumiyama_lab
1
240
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
528
40k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
1k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.7k
The Curse of the Amulet
leimatthew05
3
15k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
380
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
A designer walks into a library…
pauljervisheath
211
25k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
380
WCS-LA-2024
lcolladotor
0
840
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
530
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
480
Embracing the Ebb and Flow
colly
88
5.2k
Transcript
再帰化への認知的転回 三宅 悠介 / GMO PEPABO inc. 2022.03.11 ペパボテックカンファレンス 1
1. 再帰化の定義 2. 関数の設計から系の設計へ 3. 多様かつ継続的に変化する系の設計の難しさ 4. 複雑な系の導入における機会損失の考慮 5. そして再帰化へ
6. まとめ: 再帰化となめらかなシステム・個人的考察 2 アジェンダ
1. 再帰化の定義 3
「再帰化」とは、構造化・自動化されたサービ スが、ユーザとのインタラクションの結果を取 り込んで、システムを自らより良いものへと改 修していくプロセスのことをいいます。[*] 4 再帰化 [*] CTOメモ: 2022年のテクノロジー方針(社内資料より)
2. 関数の設計から系の設計へ 5
従来のシステム開発では、利用者からの入力 xに対してシステムの出力yを決定する関数fを設 計している。 = 再帰化の定義における「構造化・自動化されたサービス」に該当する部分に該当 関数の設計から系の設計へ 6 従来のシステム開発を「関数の設計」として捉える
運用者の経験に基づく設計は、必ずしも利用者の要望を反映しているとは限らない。 また、認知負荷の観点から利用者の要望に対する 最大公約数的な振る舞いを選定しがちであ る。 加えて、実装面では、要望の反映までに 時間がかかるという課題もある。 関数の設計から系の設計へ 7 人手による「関数の設計」の課題
関数の設計から系の設計へ 8 機械学習は「関数の設計」を自動化する(データからパラメータを求める) ① 入出力の対応関係を定義 ② 予測に対するズレを定義 ③ 学習データに対する予 測のズレを最小化する
④ パラメータが決まる (データから関数の設計ができた)
• 機械学習を用いたデータに基づく設計は(モデリングが正しければ)利用者の要望を正しく、か つ、個別的に反映している(可能性が高い) • 一方で、(機械学習に限らず)設計された関数は、ある時点までのデータに基づく振る舞いを行う (内挿性) • サービスを取り巻く環境は継続的に変化していると考えられるため、関数の継続的な再設計が必 要(外挿の考慮) 関数の設計から系の設計へ
9 機械学習による「関数の設計」の課題
• ある時点で有効な関数をサービスや利用者の環境の変化に応じて継続的に再設計(あるいは別 関数への置き換え)を行う系全体の仕組みを設計する ◦ 再帰化の定義における「ユーザーとのインタラクションの結果を取り込んで、システムを自らより良い ものへと改修していくプロセス」の部分に該当 関数の設計から系の設計へ 10 「関数の継続的な再設計」を可能とする「系の設計」へ(メタァ〜) Activity
Controller
• 従来のサービス運用維持はこのサイクルを人手で回していた ◦ 経験から関数の設計 (適切性の課題) ◦ エンジニアによる関数の再実装 (追従性の課題) • 再帰化では、フィードバックとシステムの挙動変更をシステム総体のうちに組み込む
関数の設計から系の設計へ 11 「関数の継続的な再設計」を可能とする「系の設計」へ(メタァ〜) Activity Controller
「再帰化」とは、構造化・自動化されたサー ビスが、ユーザとのインタラクションの結 果を取り込んで、システムを自らより良い ものへと改修していくプロセスのことをいいま す。[*] 12 再帰化 つまりそういうことな んですよ [*]
CTOメモ: 2022年のテクノロジー方針(社内資料より)
3. 多様かつ継続的に変化する系の 設計の難しさ 13
• この系における最大の困難は、 限られたインタラクションから利用者の背景や要求を類 推しなければならない点である。 • 閲覧、コンバージョン、利用者の基本属性、文脈、アップロードした商品データ等々 • 1. インタラクションの保存 •
インタラクションが保存されていることが系の前提。 • 2. インタラクションの解釈 • 背景や要求は利用者ごとに 多様である • この系の導入前提から 時間的な変化を考慮する必要がある 多様かつ継続的に変化する系の設計の難しさ 14 1. インタラクションの解釈
• データ基盤Bigfoot[*]のススメ • インタラクションの保存と解釈のシステム基盤としては Bigfootが良いと思います(宣伝) • Google BigQueryにより、サービスの膨大な履歴を格納、検索が可能 • Google
Vertex AIにより、集計や機械学習モデリングが実現可能 • データ処理パイプラインによりこれらの継続的な更新が実現可能 • インタラクションの個別かつ最適な解釈には機械学習の導入が有用 • 必ずしも機械学習を用いなくとも、平均のようなシンプルな集計や既知のグルーピングによる粒度 の大きい個別化から始めても大丈夫です • 最適な機械学習モデルの検討はペパ研とデータ基盤チームでもガンガンやっていきます • 興味ある方、一緒にやりましょう 多様かつ継続的に変化する系の設計の難しさ 15 1. インタラクションの解釈 [*] GMOペパボのサービスと研究開発を支えるデータ基盤の裏側
• 利用者の背景や要求を把握するために、利用者から明示的に状態を教えてもらうのは利便性 の低下につながる • 画面遷移ごとに「今、これ買いたい感じ?」とかは聞けない • 必要最小限のインタラクションから暗黙的なフィードバックを得ることが望ましい • セッションを個別に特定できる仕組み •
インタラクションに纏わる情報 • 閲覧時間、スクロール速度、画面内の配置順序、ページング番号など 多様かつ継続的に変化する系の設計の難しさ 16 2. 利便性とのトレードオフ
• 暗黙的なフィードバックから機械学習などで利用者の背景や要求を解釈した上で、システムは 振る舞いを変更するところまでが再帰化 • 再設計した関数に即時切り替え可能か • 比較評価と自動かつ継続的な切り替えが必要 • 突発的な変化を検知可能だったとして、システムが即時振る舞いを変更できるか •
ホスティングにおけるアクセスの急激な増加 • ECサイトにおける購買モードの変化 • オートスケーリングや導線の動的な変更、現状の状況に重み付けした挙動変更の機構が必要 多様かつ継続的に変化する系の設計の難しさ 17 3. 背景や要求にもとづき振る舞い変更する仕組みが必要
4. 複雑な系の導入における 機会損失の考慮 18
• 再帰化はあくまで利用者の要求や背景をもとにシステムが動的に変化していくアーキテクチャ であり、この上で実行される施策( =関数)が全て成功するわけではない • 利用者の要求や背景を解釈して最適な挙動に切り替えるってとても難しいことです • しかしながら、再帰化の仕組みに乗ることで施策の評価、切り替えが人手を介さずに実行でき るため、数多くの施策を比較評価できるという点が重要である •
一方で、実環境での施策の評価には 機会損失が避けられない • 短期的には効果の低い施策を使うことによる機会損失 • 中長期的には、施策の有効性を見誤ることによる機会損失 複雑な系の導入における機会損失の考慮 19 全部の施策が当たると思ってはいけない
• 複数の施策を正しく無駄なく比較評価するためには 統計的仮説検定が有用 • 得られたサンプル数から有用性の差がある(ない)ことを確信できるか • A/Bテストと組み合わせると効果的 • 一方でここに人手が介在すると、切り替えが自動で行われないという問題が発生する •
統計的な判断に基づき、良さそうな施策を多く利用しつつ、全体の施策に対して最低限のサン プルを収集するような仕組みが求められる • 多腕バンディットの利用 • 導入には、多腕バンディットで始めるデータ駆動(社内資料)を参考のこと • データ基盤Bigfootではbigfoot-bandit gemを使うことでサービスへの導入が容易(宣伝) • 再帰化の要件を考慮した多腕バンディットのアルゴリズムもペパ研で絶賛研究中です 複雑な系の導入における機会損失の考慮 20 機会損失の低減に向けて
5. そして再帰化へ 21
Analyzer Tokenizer 22 検索における再帰化候補の列挙 minneの検索コンポーネント(現状) Index Char Filter(s) Token Filter(s)
Analyzer ML Model Feature Extraction Classifier Matcher Sorter Query Doc Feedback Response ?
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構成ならびに「なめらかなシステム」の要素を踏まえ再構 成した
24 検索における再帰化候補の列挙 minne検索システムの再帰化の候補 • 以下、社内向けの具体的な施策候補(社内資料として省略)
6. まとめ 再帰化となめらかなシステム・ 個人的考察 25
• 「再帰化」の取り組みに必要な関数の設計から系の設計へという認知的転回を与えた • 「再帰化」の取り組みは、実はペパボ研究所における「 なめらかなシステム」の実現に向けた 取り組みに他ならない • 本資料の 2. 項と
3. 項は、すべて「なめらかなシステム」の要件にもとづく • 「なめらかなシステム」は、利用者と運用者、システムを等価に扱うことが可能 • また、それらを「自律的」(外部からは入出力の関係性を類推する他ない存在)であることを前 提に、より挑戦的な課題としてシステムの実現を目指す • なめらかなシステムの見据えるもの。個人的考察 - THINKING MEGANE - まとめ 26 再帰化となめらかなシステム・個人的考察
27 Thank You! Thank You!