Physical Intelligenceが、ClickHouseによって管理されるPostgresでロボティクスデータスタックを統合した方法

はじめに #

[00:04] ホスト: それでは、ここから Physical Intelligence にバトンタッチしたいと思います。彼らのユースケースや、どのように価値を見出しているかについて話してもらいます。ここが一番おもしろいパートになると思います。ということで、よろしくお願いします。

[00:18] Karan: はい、皆さんこんにちは。Karan です。これから Chandra と一緒に、私たちの ClickHouse のユースケースについてお話しします。私たちは Physical Intelligence で働いています。ご存じない方のために説明すると、Physical Intelligence はロボティクスを手がける会社です。基本的には研究ラボで、ロボティクス分野のフロンティアモデルを開発しています。

[00:36] 先ほど Sai も言っていたように、私たちのミッションは「汎用 AI を物理世界にもたらす」ことです。それが Physical Intelligence の使命です。とても広いミッションなので、もう少し具体的にお話しします。

[00:50] このプレゼンの流れを大まかに説明すると、まず Physical Intelligence とは何か、何をしているのか、そしてどのように基盤モデルを構築したかについてお話しします。そして、基盤モデルを構築する上で最も重要な要素の1つがデータであり、そこで ClickHouse が登場するわけです。実は ClickHouse と Postgres の両方を使っていまして、多様なデータを扱う必要があるため、両方のユースケースに非常によく合っているのです。

汎化の3つの軸 #

[01:11] Karan: では、「汎用 AI を物理世界にもたらす」とはどういう意味でしょうか。私たちはこれを大まかに3つのカテゴリに分けています。このスライドはあまり詳細ではありませんが、要は3つの汎化の軸を重視しているということです。

[01:26] 1つ目の軸は、環境をまたいだ汎化です。これについては動画をお見せします。つまり、家庭であろうと工場のフロアであろうと、どんな環境のロボットでも動作する基盤モデルを作りたいということです。

[01:44] また、あらゆる身体形態(embodiment)で動作する基盤モデルも目指しています。ご覧のとおり、ロボットにはさまざまな種類があります。単腕ロボット、多腕ロボット、脚のあるロボット、車輪のあるロボットなどです。そして最後に、あらゆるタスクをこなせるロボットの「脳」です。洗濯、服をたたむ、コーヒーを淹れる、といったタスクですね。

[02:06] この3つの汎化の軸を達成できれば、物理世界で何でもできる基盤モデルがほぼ手に入ることになります。それが私たちの目指しているところです。

ロボティクスの基盤モデル #

[02:16] Karan: 基盤モデルについて何度も触れていますが、基盤モデルが何かについて詳しくは説明しません。ただ、ここ5年ほどであらゆる領域で基盤モデルが爆発的に増えたのはご存じのとおりです。実際、明らかに私たちの仕事を全部やってくれています。動画生成モデルもあれば、数学や物理の問題向けに特化して学習させたモデルもあります。ロボティクスの基盤モデルは、その新しいフロンティアです。

[02:45] 従来のロボティクスは、複数の側面に分解できます。プランニングや推論——A* のような古典的な手法を使って空間を探索したり、SLAM で物体を検出して自己位置を把握したりできます。物体認識——古典的な CV の手法ですね。そして低レベル制御——実際にロボットを制御する部分です。

[03:07] 従来のロボティクスもかなり進歩してきましたが、根本的にはまだ解けていない問題です。そこで、ロボティクスのための基盤モデルがこの問題を解決してくれるのではないかと期待しています。つまり、従来の手法とは違って、ロボットの「脳」をゼロから構築しようとしているわけで、大規模言語モデルとよく似ています。

[03:30] この「脳」が何をするかというと、人間と大差なく、さまざまなソースからデータを取り込み、ロボット上でアクションを実行します。そしてそのためには、大量の——本当に大量の——データが必要です。

[03:44] 簡単なデモをお見せしましょう。数か月前に π0.7 という最新リリースを出しました。これは私たちの基盤モデルの 0.7 リリースです。

π0.7 デモ動画 #

[03:55] 動画: 創発的な能力を持つ、操縦可能なモデル π0.7 をご紹介します。1つのモデルで、多くの環境・多くのロボットで多くのタスクをこなせます。通常、これらのタスクはそれぞれ専門モデルをファインチューニングする必要がありますが、π0.7 はそのまま実行できます。

[04:31] 動画: 十分なデータでモデルを学習させ、適切な方法でプロンプトを与えれば、特別なファインチューニングなしに優れたパフォーマンスを維持できることが分かりました。

[05:22] 動画: 言語に加えて、視覚的なサブゴールでモデルにプロンプトを与える機能も追加しました。これは軽量なワールドモデルを使って生成します。成功時の様子を予測し、ロボットに視覚的にどうすべきかを示します。これにより π0.7 をよりうまく誘導でき、まったく新しい形でスキルをつなぎ合わせることができます。

[05:42] 動画: 他にも新しい能力の創発が見られています。たとえば、あるロボットで洗濯物をたたむデータを集めて、π0.7 にまったく異なる身体形態でまったく同じタスクを実行させることができます。ここでは、はるかに大きな両腕型の UR5e に T シャツをたたむよう指示しています。この身体形態では折りたたみデータを一度も収集していないため、腕が行うべき動きは学習データに含まれるものとまったく異なります。この身体形態をまたいだ転移が、非常に異なるロボット間、そして多様なタスクにわたって機能することが確認できています。

[06:19] 動画: 最後に、タスク固有のデータをまったく収集しなくてもどこまでできるか試してみました。π0.7 は非常に操縦しやすいため、言語コマンドでコーチングすることで、まったく予期しないタスク——たとえばサツマイモをエアフライヤーで調理する——もこなせるようになりました。

[06:52] 動画: この人間のコーチングから学習することで、後にロボットはそのタスクを完全に自力でこなせるようになります。

[07:04] 動画: これほど多くのことをこれほど上手にこなす1つのモデルを持てたことに、私たちは本当にワクワクしています。これまで以上に多くのタスクを試すことができ、その結果として非常に興味深い創発能力が見えてきています。「あなたが指示すればロボットが何でもやってくれる」という未来に向けた大きな一歩に感じられます。ありがとうございました。

モデルはどう学習するのか——なぜデータが重要か #

[07:56] Karan: では本題に戻りましょう。こうした基盤モデルがどのように動くかという話です。ちらっとお見せすると、これは私たちの論文からで、オンラインで公開しているオープンソースです。私たちはオープンソースコミュニティを強く信じているので、モデルはすべてオープンソースにしています。

[08:11] 根本的な仕組みとしては、子どもの頃を思い返してみてください。あなたは膨大な情報を取り込んできました。どの部屋にいるか、どこに行ったかという視覚情報を取り込み、さまざまなタスクを通じてさまざまな物体について教えられます。フルーツがどんなものか一度分かれば、フルーツ全般が分かるようになります。

[08:36] ロボットで達成しようとしているのも同様のことです。ビジョン言語モデルは人間よりもはるかにサンプル効率が悪いですが、急速に追いついてきています。

[08:46] その仕組みで本当に必要になるのが大量のデータです。データにはさまざまな種類があります。ロボットデータもあれば、ビジョン言語アクションモデルの中核に投入されるデータもあります。Web からのデータも大量にあります——ラベル付きの動画や画像などです。頭に小さなカメラを付けた人間がタスクをこなす一人称視点の人間データもあり、これがロボットに転移されます。

[09:16] そしてこれらすべてが、中核となるビジョン言語アクションモデルに入っていきます。これは、ビジョンエンコーダとアクションデコーダを備えた LLM のようなものだと考えてください。そして最後に推論を実行すると、動画で見たすべてのことが実現できるわけです。

[09:33] ここではデータの側面を強く強調したいのですが、先ほど申し上げたとおり、モデルが機能するには多様な種類のデータが大量に必要だからです。動画でお見せしたとおり、十分に多様なデータを与えれば、新しいデータセット——異なる身体形態のデータ——にも汎化できることが示されています。今回のケースでは UR5e ですね。

3種類のデータ #

[10:01] Karan: データは大まかに3つの側面に分けられます。このプレゼンでは後ろの2つに焦点を当てます。生データ、トランザクショナルデータ、そしてメタデータとアノテーションです。それぞれ少しずつ異なる目的を持っています。

[10:14] 生データ。生データは、学習中にモデルが実際に消費するデータです。これは大規模言語モデルを学習させるのに必要となる、ペタバイト規模のデータです。このデータのほとんどは追記のみです。学習時にはランダムシードを生成してこのデータで学習するため、ランダム読み取りに大きく依存します。基本的にこのデータには後処理をほとんど行いません——データをそのまま使います。そしてストレージは当然ながら安価である必要があります。ペタバイト規模ですからね。これはこれで大きな課題です。

[10:43] トランザクショナルデータ。次にもう2種類のデータがあります。1つはトランザクショナルデータです。これは日常業務で「会社を動かすために必要」なデータで、アノテーションをどう集めるか、会社の実際の運用がどう回っているか、といったものです。ACID 保証が必要になる部分です。誰かにデータのラベル付けを依頼するなら、二重ラベル付けが起きないよう、キューのようなものが必要になります。全体でだいたい 1 億行未満に収まります。もちろんここでは強い一貫性が必要で、SQL 形式のクエリが望ましいです。

[11:12] メタデータとアノテーション。最後の種類のデータがメタデータとアノテーションです。これも学習で頻繁に使われます。カーディナリティは非常に高いですが、サイズはかなり小さいです。ここで 100 億〜1000 億行のレンジに入ってきます。ここでは結果整合性で問題ありません——アノテーションすべてがトランザクショナルである必要はないのです。これは長時間実行のフィルタリングや GROUP BY クエリに使います。研究者たちは、どんなデータが集まっているか、どのデータをアノテーションすべきか、どのデータはアノテーションしなくてよいかを判断するために、このデータを日常的に横断的に探索しています。

[11:53] その結果、トランザクショナルデータとメタデータ+アノテーションのユースケースをサポートするために、2種類の異なるエンジンが必要になります。1つは Postgres、もう1つは ClickHouse です。それでは、Chandra にバトンタッチして、私たちがこれをどう扱っているかを詳しく話してもらいます。

スタート地点: 単一の RDS データベース #

[12:07] Chandra: ありがとう、Karan。このデータをどう収集し、どう分離し、何に使っているかについて掘り下げる前に、今年の始まりの時点で私たちがどこにいたのか、どんなソリューションを検討していたのかを簡単にお話ししたいと思います。

[12:22] 今年の初め、私たちには単一の RDS データベースがあり、研究者たちはそこにクエリを投げて必要な情報を取得していました。そして Q1 頃に爆発的な増加があり、研究者たちが投げてくる意欲的なクエリに加えて、ありとあらゆるランダムなクエリが生まれていました。

[12:47] 要するに既存のシステムでスケーリングの問題にぶつかっていたわけです。そこで Postgres から移行しようとして、「よし、直接 ClickHouse に行こう」ということになりました。それで着手し始めたちょうどそのとき、Postgres から ClickHouse への機能を目にしました。それを見て、一気に切り替えるのではなく、これを検討してみようという判断になりました。

[13:09] JSONB だらけ。もう1つ2つ付け加えたいのが、今年の初めに私たちがやっていたのは、要は JSONB を至るところで使っていたということです。つまり、誰かが新しいデータタイプを追加したいときはいつでも……アノテーションについてご存じない方のために言うと、アノテーションとは基本的にロボットに「特定のものが何であるか」を教えるもので、これはさまざまな形や形式で入ってきます。だから新しい形や形式が登場するたびに、「じゃあ JSONB に突っ込んでおくよ、誰も見てないし、クエリはそのうち書けるから」となって——そしてクエリを書く段になると、案の定ありとあらゆる問題にぶち当たるわけです。

なぜ ClickHouse か #

[13:43] Chandra: そこで最終的に ClickHouse を選びました。なぜ ClickHouse か。アノテーションでよくあるパターンの1つは、データを挿入して、その後どこかの時点でそのデータに対してクエリを実行するというものです。つまり挿入は速くなければならない一方で、読み取りに関してはある程度のレイテンシは許容できるわけです。検討した結果、この特定のユースケースをスケールさせるうえで ReplacingMergeTree が非常にぴったりでした。

[14:10] もう1つ話していた問題、JSONB だらけの件ですが、これも基本的に展開してカラムナ形式にしました。ClickHouse はスパースなデータセットに非常に強いですし、加えて型安全性も得られました。

[14:27] 次に、データベースに大きな負荷をかけているクエリすべてについて、マテリアライズドビューを作成することにしました。これによってクエリを高速化しつつ、データベースへの負荷を減らすことができました。

移行 #

[14:43] Chandra: 移行の進め方についてもう少しお話しすると、Sai と Kaushik を活用しました——それが最初のステップです。そして ClickPipes を使いました。始める前は「まだテストしてないし」と少し懐疑的だったのですが、いざ始めてみると、そのまま動きました。加えて、データセットをコピーしてクエリを実行し、ちゃんと動くことを確認するなど、いくらかのリスク低減も行いました。最後に、コンピュートとストレージの分離があり、これがかなり役立ちました。

[15:26] これが手に入ったことで、今では OLTP 用と OLAP 用の2つの世界が、実質的に単一のデータベース上に存在することになりました。ほとんどの運用ワークロードは Postgres に流し、その先で ClickPipes を設定して、OLAP 側のデータレイクに流れ着くようにしています。今ではアノテーションからテレメトリまですべてが単一の場所に集約されています。

[15:58] これによって、これまで考えられていなかった新しい種類のアプリケーションを人々が構築し始めるという追加のメリットも得られました。すべてのデータセットが1か所にあるからです。先ほど言ったような、人々が投げるあらゆる奇妙なクエリにも対応できます——「この特定のロボットで、この特定のシーンでこの種のデータを集めましたか? そのデータ全部取ってこられますか?」といった具合です。

[16:27] NVMe の部分については深入りするまでもありません。要は、ここに移行してからは以前見えていた一連の問題が完全に消えました。そして最後に、この機会に少なくともマネージドマイグレーションへ移行することにしましたが、これも非常にシームレスでした。

チューニングとスケーリング #

[16:50] Chandra: 移行を終えたあと、どんなチューニングをすべきか、このプラットフォームをどうやってうまくスケールさせるかも考え始めました。そのうえで ClickHouse がすぐに提供してくれる機能が役立ちました。まず読み取りクエリと書き込みクエリの分離。それから、すべてのバッチワークロードには PgBouncer を使い始めて、メインのデータベースへの DDoS を防いでいます。そしてマテリアライズドビュー——これは要するにさまざまなユースケース向けに用途特化型のビューを作るものです。

[17:27] これをアプリケーションでどう活用しているかについては、Karan に話してもらいます。Karan?

go/data アプリ——「ロボットはエアフライヤーを見たことがあるか?」 #

[17:32] Karan: ここでお話ししたい、私たちがフル活用している面白いアプリケーションが1つあります。数週間前——というか数か月前に作ったもので、データを探索するためのものです。

[17:44] Chandra が指摘したように、答えたかった問いというのは——先ほどの動画を見た方なら、動画の目玉デモの1つがエアフライヤーだったはずです。「これまでどのデータセットにも登場していないエアフライヤーのタスクをロボットができるか?」というものですね。しかし、そのデータがデータセット内に存在するかどうかを誰も知りませんでした。このロボットがそのデータを見たことがなくてもこのタスクをこなせている、と主張するには、それを確証する必要がありました。しかし私たちが持っているデータ量を考えると、極めて効率的にクエリできる仕組みなしにはこの問いに答えるのは非常に難しかったのです。

[18:17] だから議論の多くは「ロボットはエアフライヤーのデータを見たことがあるのか?」といった話でした。分からない、と。実際に「ロボットデータの中にエアフライヤーのデータが本当に存在するか」を突き止めるのに、去年後半か今年初め頃に約3週間かかりました。

[18:30] Postgres と ClickHouse に移行する前、RDS のみを使っていた頃にこれをやろうとすると、複数日かかるマルチテーブル JOIN を書かなければなりませんでした。そのようなエピソードが存在するかをクエリするだけでなく、その特定の単語がデータセットのどこかに存在するかをクエリする必要もあったからです。「air fryer」がタイプミスされている可能性もあり、ダッシュ付きで「-fryer」だったりアンダースコアで「_fryer」だったりするかもしれません。

[18:55] それが今では、このアプリを作りました——社内では go-links にちなんで go/data と呼んでいます。基本的にすべてのトランザクショナルデータは Postgres にあり、それを ClickPipes を使って ClickHouse にまとめて流し込みます。非常にシームレスで、ほぼ何もする必要がなく、ボタンをクリックするだけですべてが動き始めました。それを土台に、マテリアライズドビューを使って全データを横断的に何でも検索できるアプリケーションを作っています。これを研究者に提供できるというのは非常に強力です。

[19:24] ご想像のとおり、ただのデータダッシュボードです。SQL に対して直接実行される SQL クエリを組み立てることもできます——研究者がクエリを書きやすくするために、ドロップダウンにあらかじめ選択肢が入っています。しかし、より面白い機能はチャットです。チャットでは、要するになんでも入力できます。たとえば「successful folding episodes(成功した折りたたみエピソード)」と入力したり、「give me episodes with air fryer in it(エアフライヤーが登場するエピソードをください)」と、どんなスペルミスがあっても入力できます。裏側では当然エージェントが動いていて、クエリの種類に応じて Postgres と ClickHouse に対して大量のクエリを実行し、どのテーブルをどう問い合わせるかを判断して、結果を提示してくれます。

[20:07] 残念ながら、この件はあまり深く踏み込めません——かなり独自の実装が入っているので。ただ、Postgres、ClickPipes、ClickHouse の組み合わせなしにはこれは実現できませんでした。ですから、これは私たちにとって非常に重要なアンロックでした。

Q&A——全文検索インデックス #

[20:21] Karan: そうですね、全文検索インデックスを使っています。使用しているのは——具体的にどのインデックスかというと……全文検索用のものです。全文検索インデックスを使っていて、実際には複数のインデックスを持っています。クエリの種類に応じて、そのインデックスにヒットさせるためにどのインデックスを使い、どのクエリを実行するかを選び分けています。

おまけ: テレメトリ #

[20:44] Karan: 最後におまけ、私たちのテレメトリについてです。ここでは触れませんでしたが、私たちにとってこれは非常に重要です。というのも、これが実際に[聞き取り不能]使いやすく、多くの人が使い方を知っているものだからです。そして ClickHouse はテレメトリに対して非常に高速です。

[21:08] そこで、まずすべてのテレメトリを ClickHouse に移行するところから始めました。それを ClickStack と Grafana と組み合わせて実現しています。テレメトリと OLAP、OLTP を単一のプラットフォームでサポートできるというのは、なかなかクールなことです。これで全部がずっと楽になります。以上です。

[21:30] あ、そうそう——最後に、いま話した内容全部の1万フィート上空からの俯瞰図です。これが私たちのスタックで、トランザクショナルワークロードとアナリティクスワークロードのそれぞれで何が動いているかを示しています。Postgres があり、そこから ClickHouse に自動でレプリケートされています。これが Sai と Kaushik が先ほど話していた内容ですね。