はじめに
こんにちは、『ゼクシィ』・『カーセンサー』・『じゃらん』に従事するデータエンジニア・機械学習エンジニア組織のマネージャーをしている田村真一です。
私の仕事のひとつは、中長期を見据えた技術的な意思決定や戦略策定をすること。そのためには、各事業のコンディションや戦略と同時に、世の中の技術的な隆盛も身体に染み込ませる必要があります。
本記事では、そんな私が「世の中の技術的な隆盛」を知るための営みの一環として QCon San Francisco 2024 に聴講参加したレポートをお送りします。
本記事は、データ推進室 Advent Calendar 2024 20日目の記事です
QCon とは
QCon は、ソフトウェアエンジニアリングに関するメディア・コミュニティである InfoQ が主催するテックカンファレンスです。 過去には東京で開催されたこともあるようですがここ数年ではありません。直近では英語圏での開催が主のようですね。
私自身は初参加ですが当社(特にデータ推進室)からは何年かおきに参加しており、前述のとおり技術トレンドを捉える場のひとつにしています。たとえば2022年に参加した際のレポートも本ブログに投稿されています
Recruit Data Blog | QCon SFに見る、MLOpsとアーキテクチャの最前線
話される内容の特徴は下記のとおり。
- トピックとしては個別の技術的な取り組みから組織・キャリア論まで幅広い
- 技術面ではアーキテクチャのレイヤーに関する話が多め
- 基本的にコミュニティドリブンでスピーカーが選定されている
- スポンサーセッションもあるが、それは明示的に区別されており、ステルスマーケティングにならないようになっている
- イノベーター理論でいうイノベーター・アーリーアダプター・アーリーマジョリティ対象である
- カンファレンスのイントロダクションでは “leading edge of enterprise” というフレーズも使用されていた
特に4点目が、当社にフィットしているポイントだなと感じました。 リクルートはベンチャー的精神を大事にする企業ですが、同時に安全性を重視した意思決定が求められる大企業でもあります。 新しい技術を積極的に採用することも好きですが、枯れた技術で解決できるシンプルな課題設定も多数抱えています。 そんな私たちだからこそ、本カンファレンスから得るものは多かったです。
トラックの紹介
QConでは日ごとにトピックテーマを4つ定め、そのそれぞれが1つのトラックとなるマルチトラック制で開催されています。(別途スポンサーセッション専用トラックもあります) 1つのトラックは5〜6セッションあり、3日間で合計約90のセッションがあります。
トピックテーマ(トラック)のいくつかは例年定番化していそうなものもあるのですが、一方で時流を組んだ「今」ならではのテーマもありました。たとえば:
-
Generative AI in Production & Advancements
- 猫も杓子も生成AI……と辟易したくもなりますが、さすがと言うべきか、いかにして実サービスの中で活用するかのプラクティスが語られていました
- ちなみに生成AI以外のMLシステムのセッションも多く、別日に “AI and ML for Software Engineers: Foundational Insights” というトラックがありました
- 昨年は “Modern ML: GenAI, Trust, & Path2Prod” というトラックでこれらの両方をカバーしていたようですが、生成AIの本番活用の事例はそれほど多くなかったようです
-
Rust [in Production]
- なぜこのタイミングで Rust?とも思いましたが、私含め周りも「Rust 製ツールはそれなりに使ってるけど、自分たちが Rust で開発はしていない。興味はある」という声は多く、意外と良いタイミングを捉えているのかも知れないと感心しました
- ちなみに去年は “JVM Trends: Charting the Future of Productivity & Performance” というトラックがあったようです。セッションの中身は見れないのですが、これもなかなか絶妙なテーマ設定ですね
-
Hardware Architectures You Need To Know
- QCon は基本的にソフトウェアエンジニアリングに関するカンファレンスですが、今回はそれを支えるハードウェア面を深堀りするセッションがいくつもありました。特に行列演算を酷使する機械学習系ワークロードの高速化・大規模化は、CPU・アクセラレーターのアーキテクチャや命令セットの進化と表裏一体で進んできた側面もあり、その詳細を学べるよい機会になりました
セッションの紹介
それでは、ここから印象に残った具体的なセッションをいくつかご紹介していきます。
ただしここで紹介するセッションは、抽象的な学びにつながるなと思ったものに絞ってピックアップしたものであることをご了承ください。実際のカンファレンスではもっともっと具体的な課題感や取り組みの工夫について詳細に語られるセッションが多数ありますので、現場のエンジニアにこそ参加して欲しいイベントです。
① Pinterest のマルチモーダル検索
タイトル | Search: from Linear to Multiverse |
発表者 | Faye Zhang(Pinterest スタッフソフトウェアエンジニア) |
トラック | Generative AI in Production & Advancements |
URL | https://qconsf.com/presentation/nov2024/search-linear-multiverse |
内容
Pinterest で開発されているマルチモーダルかつユーザーインタラクションありの検索システムの具体的なアーキテクチャと、さらにそこに AI エージェントを組み込んだ際の発展的なビジョンについて紹介するセッションでした。
Pinterest はインターネット上の画像を「ピン(お気に入り)」してコレクションすることで、画像ベースでアイデアを収集・発見できるサービスです。 たとえばファッションやインテリアのアイデアを考えるときに非常に便利なのですが、実は事業者は Pinterest 上でピンされた商品の画像から直接購入動線に流入してもらうことができます。 そういったサービスの性質上、画像を中心とした、かつインタラクティブな検索体験は Pinterest の重要機能のひとつで、約10年前に発表された Guided Search 機能を始めとしてこれまでもさまざまな検索のUXや内部アーキテクチャが模索されてきたようです。
残念ながら動画・スライドともに非公開で私自身も復習できないのが悲しいところなのですが、いくつかポイントを押さえると
- 自然言語クエリ・画像クエリの Transformer による組み合わせ方
- 本番システムにおけるリアルタイム性の高いユーザーシグナルを反映するためのシステム構成
- AI エージェントを導入した検索システムのハイレベルアーキテクチャ
などをかなりの具体感を伴って紹介していました。
所感
個々の内容は「超絶技巧」というほど高度な技術選定がされているわけではないのですが、実現したい UX のビジョンを現場の専門家がしっかりと理解してデータサイエンス・機械学習から分散システムに至るまで具体的な検討を重ねてきたことが端々からうかがえる内容で、素直に見習いたいなと思いました。
当社のサービスでもユーザーの検討過程に寄り添ったインタラクティブな検索体験は実現してみたいことのひとつなので、本発表の内容を参考実装としてさらなる検討を重ねていきたいと思います。
② LLM システムの評価フレームワーク
タイトル | A Framework for Building Micro Metrics for LLM System Evaluation |
発表者 | Denys Linkov(Voiceflow Head of ML) |
トラック | Generative AI in Production & Advancements |
URL | https://qconsf.com/presentation/nov2024/framework-building-micro-metrics-llm-system-evaluation |
内容
このセッションでは、LLM のテスト・評価の方法論を紹介するものでした。ただし具体的なメトリクスの比較一覧があって……というよりは、そもそも評価方法・指標をどう作っていくかの考え方のフレームワークを示すものです。
具体的には
- 単一の指標で評価しても十分に品質を捉えられないので、複合的に見ること
- モデル単体の振る舞いだけを評価せず、システムとしてモニタリング・評価を実施すること
- ユーザー体験やビジネスゴールに影響があるかどうかを考えてメトリクスを選定すること
などが語られていました。
所感
従来の ML システムも実サービスで適切にテスト・評価するのは難易度が高いものでしたが、生成 AI を組み込んだシステムではそれがさらに悩ましいものになります。
このセッションを聞いて、改めてその悩ましさを簡単に解決する銀の弾丸などなく、避けて通れないものであることを認識しました。その上で、その悩ましさをどう分解して考えていけばいいかのガイドラインが頭に入ったことは、今後取り組んでいくための強力な武器になりそうな予感がしています。
③ 生成AIシステム開発のためのプラットフォーム
2つまとめてご紹介します。
タイトル | Balancing Act - Enabling Innovation and Scale for Responsible Generative AI |
発表者 | Michael “Kaz” Kazmier(McKinsey パートナー) |
トラック | Sponsored Solution |
URL | https://qconsf.com/presentation/nov2024/balancing-act-enabling-innovation-and-scale-responsible-generative-ai |
タイトル | From Hype to Large-Scale Production: How LATAM’s Largest Company Leveraged Platform Engineering to Build a GenAI Development Platform for 60K+ Employees |
発表者 | Oscar Mullin(Mercado Libre VPoT)、Sebastian Barrios(同シニアVPoT) |
トラック | Sponsored Solution |
URL | https://qconsf.com/presentation/nov2024/hype-large-scale-production-how-latams-largest-company-leveraged-platform |
内容
いずれもトラックとしてはスポンサートラックですが、またしても生成AI系に関するトピックです。ただし先ほどと違い、今度は platform engineering 観点からの発表になります。
1つ目の発表は、言わずと知れたコンサルティング会社マッキンゼーからの発表です。マッキンゼーが様々な企業と生成 AI システムの開発を行った経験から、そのためのプラットフォームには何が必要か、注意を払うべきポイントが何かを紹介するセッションでした。
もう一つは、Mercado Libre という南米最大の越境EC事業者からの発表です。タイトルに「60K+ Employees(6万人以上の従業員)」とありますが、エンジニアに絞っても約2万人いるそうです。 そんな Mercado Libre で生成 AI を使ったシステム開発をより高速・高度に実現するためのプラットフォームを開発し、具体的な事例としてカスタマー問い合わせ対応チャットのLLM化を実現した事例が紹介されていました。
所感
プラットフォームとして提供している機能のうち、次の2点が個人的には印象に残りました。
1つ目はテスト・評価の仕組みです。前節でも触れた通り LLM システムの評価は簡単ではありません。紹介されたプラットフォームではそこも共通化しているよ……ということで素晴らしいなと思ったのですが、実は共通化されているのはあくまでシステム的な側面にとどまり、「どうやって評価データセットを準備するか?」「どういう問題設定にはどういう指標で評価すべきか」といった一番悩ましい部分はまだノウハウが貯まりきっていないとのことでした。これだけ高度なプラットフォームを展開している企業でもそこにたどり着けていないと聞き、少し親近感を感じつつ、課題の難しさを改めて認識しました。
2つ目は AI gateway と呼ばれる、ML(LLM)モデルの手前に設定されるゲートウェイの存在です。一般的な platform engineering においても、セキュリティやコスト最適化のためにマイクロサービスに gateway を噛ませるのはよくあるプラクティスかと思います。しかしLLMシステムにおいては、倫理観点や説明性向上のためのモニタリング、激化するモデル開発競争に追従するためのモデルやそのバージョンごとのIF差異の吸収などの観点で、ますますそれが重要になるということです。
④ Amazon スケールでの内部ツール開発の重要性
タイトル | Inflection Points in Engineering Productivity as Amazon Grew 30x |
発表者 | Carlos Arguelles(Amazon シニアプリンシパルエンジニア) |
トラック | Engineering Productivity |
URL | https://qconsf.com/presentation/nov2024/inflection-points-engineering-productivity-amazon-grew-30x |
内容
この発表はエンジニアの生産性に関するトラックのもので、Amazon のような大企業で内部ツール開発がどのように行われているか、それが組織環境の変化によってどう変わるかを俯瞰的にたどるセッションでした。
発表者の方は、Microsoft に12年→Amazonに11年→Googleに4年→Amazonに出戻りという経歴を持っている方です。 この方が最初に Amazon に在籍していた2009年頃はエンジニア数が3000人程度だったのが今では約8万人ということで、タイトルにもあるように30倍の組織に拡大しました。 この変化の前後で作るべきものがどう変わったか、あるいは Google と比較して Amazon はどういうポリシーで内部ツール開発をしているのか……等が触れられていました。
所感
最初はなんといっても規模感に圧倒されるところから始まりました。たとえば、数万人規模の組織が対象なら内部ツールのちょっとした改善も積もり積もって大きなROIが達成できるという話や、それどころか3rdパーティのOSSツールなどで想定されている負荷を超えているから内製するしかないという話などは、理論的には理解できるものの今の自組織には関係ない話として聞いていたのです。
一方で少し時間が経ってから腑に落ちたのは、タイトルにもある通り「8万人」という絶対値ではなく「30倍」という変化を捉えて意思決定をしましょうというポイントでした。また発表中では組織の規模以外にも、その成熟度やマーケット状況などを含めて「変節点」を捉えましょうという話がされていました。
「30倍」とは言わないまでも、当社でもここ数年で大きな組織状況の変化がありましたし、その中での組織の規模・成熟度も向き合っている市況や事業課題も世の技術的進歩も大きく変わってきました。 今この瞬間に組織やシステムがどうあるべきかというだけでなく、将来どうなっていくかを上記のような変節点を捉えながらビジョンを描くこと、同時にそれに固執せず時々刻々軌道修正していくことの大切さを改めて認識しました。
⑤ Slack のリアーキテクチャの歴史
タイトル | Changing the Model: Why and How We Re-Architected Slack |
発表者 | Ian Hoffman(Slack スタッフソフトウェアエンジニア) |
トラック | Architectures You’ve Always Wondered About |
URL | https://qconsf.com/presentation/nov2024/changing-model-why-and-how-we-re-architected-slack |
内容
Slack は当初「ワークスペース」を中心にアーキテクチャが考えられていました。 その後複数ワークスペースに対するニーズが増えたことに伴い「Enterprise Grid(v2 アーキテクチャ)」として、ワークスペースの切り替えができるようになりました。 ところがこのバージョンでも「ワークスペース」という概念がアーキテクチャを規定する強い存在になっており、UX にはじまり認可の仕組みやデータベース上のシャードの分割方法などもそれに引っ張られたものになっていました。
これに対し、初心に立ち帰って「今のアーキテクチャはユースケースにとってあるべき形なのか?」という “big question” を考えて大規模なリアーキテクチャを行ったとのことです。これが最近リリースされた「Unified Grid(v3 アーキテクチャ)」です。
ただしこれは根本からのリアーキテクチャであり、変更量も膨大になります。セッションでは、プロトタイピングからテストまでどう進めたかのノウハウについても触れられていました。
なお、本発表の内容は Slack 公式のエンジニアブログでも紹介されていますので、興味があればご参照ください。
Unified Grid: How We Re-Architected Slack for Our Largest Customers - Engineering at Slack
所感
システム開発においては、ビジネスやプロダクトのあり方から変わりやすいポイント変わりにくいポイントがなにかを考えて、それを反映して変わりやすいポイントを変えやすく、変わりにくいポイントを変えにくく設計をすると思います。
ところが現実世界で多くのユーザーに長く使われるサービスでは、当初「本質的」と思っていたポイントすら大きく変わってしまうんだなという実感を持つことができました。もちろんそれは頻繁に起こるものでもないでしょうし、場合によってはゆっくりとしか起こらないものだと思います。でもだからこそ、折に触れて自分たちに “big question” を問いかけることを忘れないようにしたいと思います。
最後に
以上、今年の QCon San Francisco について、会の趣旨といくつかのセッションを紹介してきました。 生成 AI の活用などはまさに「今のトレンド」という感じだったかと思いますが、一方でアーキテクチャをどう考えて設計するのか、その時節をどう捉えるのかといった話は不変の話ですね。 本記事がどなたかの刺激になれば幸いです。
こぼれ話:自動運転タクシー体験
さて、本文は上記で終わりですが、せっかくなのでサンフランシスコでの自動運転タクシー体験についても触れたいと思います。
自動運転タクシーは Alphabet 傘下の Waymo が2018年に世界ではじめて商用化に成功しました。自動運転レベルは、限定されたルートやエリア上で(異常時含め)システムがすべて運転するレベル4です。レベル4自動運転自体は事例も多いですがルートの決まったバス等での運用が多く、2024年12月現在では行き先を自由に指定できるようなタクシーの形では世界でもまだほとんど(おそらくアメリカ・中国以外では)乗れるところがありません。
その貴重なチャンスということで、サンフランシスコで Waymo One を利用してきました。
左上の写真は、Waymo One のタクシーの外観です。この画像ではちょっと分かりづらいのですが、車体上部や四隅にゴツいセンサーが多数設置されており、遠目に見ても「あ、Waymo だ!」と判別できるフォルムをしています。 一般的なタクシーアプリや Uber 同様アプリ上で行き先を指定して車を呼ぶと、数分でこの車が来ます。そしてアプリから自動車のロックを解除することで搭乗できます。(ただし運転席には乗れません)
右上の写真は、助手席から見た自動運転が行われている様子です。誰もハンドルを触っていないのに右折しています。走行中はナビ画面(画像下)に車両が認識している周辺環境が表示されています。(画像の上と下で撮影タイミングは違います)
乗ってみた体感としては、アクセル・ブレーキやハンドル捌きは硬いところがあるものの、安全性に関わる周辺認識性能はそれほど悪くないなと思いました。 数台先や遠方の車両の認識が怪しいなと思う瞬間はありますが、正直な体感として、免許取って1〜2年だったり気が短かったりする人間のドライバーよりは遥かに安心できます。
ただし夜間や悪天候でどうなるか、周囲の運転が荒かったらどうなるか、等は分かりません。 そういう意味では、レベル5の自動運転は、近いようで遠いのかも知れないなと思いました。
ゼクシィ・カーセンサー・じゃらんのデータエンジニア・機械学習エンジニア組織のマネージャー
田村真一
コログを訪ねてハイラル全国を行脚しつづけ早幾年