Googleのチーフサイエンティストであるジェフ・ディーン氏が、AIの未来と計算基盤の進化について語る。LLMの学習データ枯渇問題に対する見解や、データセンターにおけるインファレンス（推論）処理へのシフトがもたらすハードウェア設計の変革を解説する。さらに、FP4のような超低精度量子化の可能性、プレトレーニングとポストトレーニングの融合、そして計算資源が100万倍になった未来に実現する自律的な科学・工学設計の世界について展望を示す。後半では、大規模データセンターで実際に起きる宇宙線によるビット反転の逸話や、システム開発における未解決の難題である「継続学習」への挑戦について、ユーモアを交えながら明かす。
データ枯渇の懸念と合成データの可能性
みなさん、こんにちは。今日ここに座っていられるなんて、本当に信じられないほど光栄なことです。今回は歴史上最も伝説的なAI研究所の一つであるGoogle Brainを率い、MapReduceやTensorFlowの共同開発者でもある、計算機科学界のレジェンド、ジェフ・ディーン氏にお話を伺うことができました。
ジェフ、今日はお時間をいただき本当にありがとうございます。昨年お話しした際にも多くのことを学ばせていただきましたが、またこうして知識を共有していただける機会を得られて、本当に嬉しく思っています。
こちらこそ、昨年お話しできて楽しかったですし、今回も楽しみに高評価していました。
さっそくですが、世間ではLLMの学習データが底を突きかけているとよく言われています。しかし、ジェフは「データはまだ大量にある」とおっしゃっていました。その真意について教えていただけますか。
そうですね、世の中の公開されているテキストデータの多くをすでに使い切ってしまったというのは事実です。そのため、データが足りなくなっているという見方が大勢を占めるのも理解できます。しかし、私たちはまだ動画データを本格的には学習に活用できていません。ここには非常に興味深いデータが大量に眠っています。
また、高品質な合成データを生成してそれを学習に活用するという、非常に面白いアプローチも存在します。さらに、すでに手元にあるデータに対してアプローチを工夫し、より何度も繰り返し処理を行うことでモデルの能力をさらに高めたり、1つのデータからより多くの情報を引き出すアルゴリズム技術を開発したりすることも可能です。ですから、データの枯渇が進歩の妨げになるとはそれほど心配していません。私たちができることは、まだまだ数多く残されています。
シミュレーションデータや合成データが増えていくと、遅かれ早かれデータの大部分がAI製になり、それを別のAIの学習に使うことで、誰もが同じデータから学習するようになってしまうのではないかとも指摘されています。ですが、ジェフは「それでも効果はある」とおっしゃっていました。計算資源が十分に高ければ、膨大なデータから役立つわずかな情報をシステムが自ら見つけ出して学習できる、という主張だったかと思います。これは本当なのでしょうか。私が以前試した小さな実験では、まったく上手くいかなかったので、データの選別にはかなり慎重になる必要があると感じていたのですが。
一般論としては、その主張は正しいと言えます。ただ、それを実際に機能させるためには、クリアしなければならない細かい技術的なディテールが山ほどあります。
たとえば、かなり抽象的な指示のコーディング課題を解決するために、強化学習のトレーニングとロールアウトを行うケースを考えてみてください。この場合、問題の解決策を生成するために100通り、あるいは1000通りもの異なる方法を探索することになります。その際、そもそもコードがコンパイルできるかといったフィルターをかけることで、最初の段階で800個ほどを即座に排除できます。
さらに、ユニットテストをパスするか、パフォーマンスは優れているか、といった絞り込みを行います。こうすることで、数ある潜在的な解決策の中から、私たちが求めている報酬や特性を最も高く満たすものへと確実に肉薄していくことができるのです。
このように計算資源を投入すれば、より興味深い解決策を生み出すことができ、それらを再び学習データへと組み込むことが可能になります。さらにデータ拡張技術を使ってそれを強化することもできます。たとえばPythonで生成した解決策をもとに、今度はGo言語でコードを生成すれば、Go言語の学習データを大幅に増強できます。
それは素晴らしいデータ拡張ですね。かつて畳み込みニューラルネットワークで行われていたデータ拡張といえば、画像を数ピクセルずらすといった程度のものでした。それに比べれば、完全に異なるプログラミング言語へ変換するというのは、まったく別次元の拡張です。
ええ、私たちはコーディングの問題を考えるとき、自然言語からプログラムへの変換を想定しがちです。しかし、自然言語による指示は、たとえば「面白いインベーダーゲームを作って」というように、詳細が曖昧なことがよくあります。一方で、すでに意図通りに動作するプログラムが存在し、それを別の言語に翻訳したいという場合、そのソースコード自体がシステムの挙動を完全に定義した完璧なプロンプトになります。パフォーマンスの向上や安全性の強化など、目的の言語に変えるだけでいいのです。
実際に社内でも、Pythonで書かれた社内ツールのテストコードと実際のコードベースをすべて読み込ませ、別の言語のバージョンを作成したところ、はるかに高速に動作するソリューションが得られたという事例があります。
つまり、同じデータ量から突然、劇的に多くの成果を引き出せるようになるわけですね。だからデータの心配をしていないのですね。よくわかりました。
推論へのシフトとハードウェア設計の最前線
ところで、バハ・デリ氏が「現代のデータセンターで行われている処理の約90%は、もはや学習ではなく推論である」と発言しており、非常に驚きました。相対的に学習の割合が減り、モデルを利用する推論の割合が増えているということですが、この変化はGoogleにおけるハードウェアの設計思想にどのような影響を与えていますか。
まず前提として、データセンターでは推論や学習のほかにも、検索やGmailなど、私たちが提供するあらゆるアプリケーションの実行に多大な処理が割かれています。それを踏まえた上で、機械学習のワークロードに絞って話をすると、全体に占める学習の割合が相対的に低下しているのは事実です。それだけ推論のワークロードが膨大になっているからです。
この推論ワークロードには、オフラインでの推論や、強化学習のプロセス中に行われるロールアウト、そしてユーザーからのリクエスト処理やエージェントとしての自律的な振る舞いを支えるオンライン推論のすべてが含まれます。
このように推論へのシフトが進み、学習とは異なる計算特性が求められるようになったため、ハードウェアを推論ワークロードにより特化させる重要性が大幅に増しました。要求される計算の性質が大きく異なるからです。推論においては、それほど高い精度は必要なく、より低い精度が求められます。また、特定のモデルに対して非常に大量のリクエストを処理することになりますが、推論時にモデルの重み自体が変わることはありません。
これらの特性を考慮すると、ハードウェアの設計アプローチは学習用とは全く異なるものになり、特化させることでエネルギー効率を劇的に向上させることができます。現在、そして将来的にも、この分野の特化型チップはさらに増えていくでしょう。私たちはすでに、先月発表したTPUのv8iやv8eチップでこのアプローチを具現化していますが、今後はさらに特化が進むと考えています。
FP4のような、わずか4ビットの浮動小数点数でも十分に機能するというのは驚くべきことです。最初に聞いたときは、そんな極端に低い精度で意味のある処理ができるわけがないと思ったのですが、実際に動いてしまうのですね。
15年前の計算機科学者にそんな話をしたら、数値の表現幅が圧倒的に足りなすぎる、と言われるでしょうね。
本当にそうですよね。私も時折論文を読みますが、ドット間の距離を維持する変換や回転、あらゆる種類の圧縮技術が駆使されているのを目にします。それにしてもFP4で、符号や指数、仮数に割り当てられるビット数がこれほど少ないにもかかわらず、そこから高品質な知能が生み出されるというのは信じがたいことです。これが機能しているという事実自体が、素晴らしい兆候ですね。
そうですね。
ただ、これ以上精度を下げることができるのでしょうか。さらに下を目指すことは可能だと思われますか。
可能性はあると思います。すでに研究や実験が行われているアプローチとして、ベースとなる精度をさらに下げつつ、一定数の重みごとにスケーリングファクター（拡大縮小係数）を設けるという手法があります。これにより、2ビット整数や1ビット整数といった超低ビット形式の重み全体で、少し高精度な係数を共有する形でカバーできるようになります。これによって、かなり実用的なレベルまで精度を維持できることが分かってきています。さすがに2ビットの浮動小数点数という話は、それが何を意味するのか定義が難しいため耳にしませんが、低ビット形式とスケーリングファクターの組み合わせは非常に有望です。
問題は、そのスケーリングファクターをどれくらいの頻度で挿入する必要があるかという点です。重み64個ごと、128個ごと、あるいは256個ごとなのか、という最適化の議論になります。
プレトレーニングとポストトレーニングの融合
現在、プレトレーニング（事前学習）とポストトレーニング（事後学習）は通常、別々のステップとして分かれています。能力が向上していくにつれて、この分離は維持されると思いますか、それとも2つのステップは統合されていくとお考えですか。
概念として、これらが完全に独立したフェーズになっていて、一方を終えてからもう一方を行うという現状は、学術的には少し物足りなさを感じています。本来あるべき理想的なアプローチは、データをパッシブに観察する期間と、そのデータから得た新しい知識を実際に活用しようとする期間が、交互に織り交ぜられている状態です。
まるでDQNの経験再生（エクスペリエンス・リプレイ）のような仕組みですね。
ええ、そしてシミュレーション環境や、あるいはロボットを用いた現実世界といった何らかの環境の中で実際にアクションを起こし、その結果から学ぶというプロセスが必要です。単にトークンが目の前を流れていくのをパッシブに眺めているだけの、現在の一般的なプレトレーニングに比べ、自らアクションを起こしてその結末を観察したり、実際にコードを書いて動くかどうかを確かめたりする方が、モデルにとって遥かに大きな恩恵をもたらすと考えています。
それを段階的に織り交ぜて行うというのは非常に興味深い視点です。というのも、2つの融合と聞いたときに、私が真っ先に思い浮かべたのは「継続学習」のことだったからです。
しかし同時に、企業はモデルをテストしなければなりません。学習を終え、ポストトレーニングを行い、レッドチームによる検証や安全性の確認といったステップを経て初めて、パッケージ化してリリースできるわけです。もし常に継続学習を行っている状態だと、その中間状態のモデルが本当に安全であるかどうかをどうやって保証すればいいのかという課題が生じます。このあたりには、まだ多くの研究が必要になりそうです。
そうですね。ただ、たとえばこの一連のプロセスを100回、1000回と細かく区切って離散的なステップとして繰り返していけば、それは次第に「離散的な足し算」から「連続的な積分」へと近づいていき、融合の形に近づいていきます。
そのため、そのような形での織り込みは十分に理にかなっていると思います。ですが、ご指摘の通り、ユーザーのリクエストを処理する本番環境のモデルには、超えなければならないハードルが多数あります。安全性の確保は絶対条件です。
ですから、バックグラウンドで継続学習を行い、一定のサイクルが回ったところで安全プロトコルの適用やレッドチームによる検証を行い、新しいバージョンとしてリリースする、という形になるかもしれません。モデルは裏側で常に学び続け、ユーザーに最新のバージョンを提供する直前に、最終的な安全性テストと検証を改めて実施する、という運用です。
計算資源が100万倍になった未来
ジェンスン・フアン氏は、過去10年間で計算能力が100万倍に進歩したとよく言っています。もし次の10年間で、さらに100万倍の進化を遂げたと仮定すると、現在私たちができないことで、何ができるようになるでしょうか。
未来を想像するのは常に難しいことです。この分野の進化のスピードはあまりにも速いですからね。
10年前を振り返ってみてください。当時は配列から配列への変換を扱う「Sequence to Sequence」の論文が出たばかりで、言語モデルの黎明期でした。トランスフォーマーが登場する直前です。
LSTMなどが主流だった頃ですね。
ええ、LSTMが広く使われていました。当時のモデルと比べると、現在のモデルは比べものにならないほど高い能力を持っています。その進化のペースをそのまま次の10年間に当てはめて考えると、新しいアーキテクチャのハードウェアや、新しい研究手法に対して、文字通り巨額の投資が行われることになるでしょう。この分野への注目度は高まる一方です。
そのため、進歩のペースが今後10年間で減速することはないと見ています。そうなると、信じられないような世界が待っています。現在でも、複数のエージェントを連携させたマルチエージェントのワークロードによって、非常に複雑なタスクをこなせるようになりつつあります。先日のGoogle I/Oの基調講演でもご覧いただいた通り、比較的シンプルなプロンプトから自律的にオペレーティングシステムを構築するようなデモンストレーションが可能になっています。
信じられないような話です。もちろん、学習データの中にOS開発に類するデータが大量に含まれているため、完全に未知の領域のタスクというわけではありませんが、それでも実際に「Doom」を正常に実行できるOSをゼロから構築できるというのは驚異的です。
私も目を疑いました。昨年、LambdaのCEOであるスティーブン・バラバン氏の講演で、UIやドライバーのことは一旦忘れて、モデルそのものを「ニューラルOS」として機能させるというアイデアを聞いたとき、私は「素晴らしいSFのアイデアだし、ぜひ見てみたいけれど、実現はずっと先の話だろう」と思っていました。ところがわずか1年後には、形は違えどそれに近いものが提示されたわけです。この時間経過に対する進化の傾きは凄まじいものがあります。
私が特に期待しているのは、こうしたツールを活用することで、科学の発展や、通常であれば多くの人員と何年もの歳月を要する複雑なエンジニアリングタスクを大幅に加速できるのではないか、という点です。デミス・ハサビスも基調講演で言及していましたが、適切なシミュレーション環境へのアクセス権を持ち、タスクを小さなサブタスクに分解して自律的に実行するエージェントの学習システムがあれば、従来なら何年もかかっていた飛行機の設計を、たとえば5日間で完了できるようになるかもしれません。そのような未来が来れば素晴らしいことです。
100万倍の計算資源があれば、そうした挑戦も可能になりますね。
ええ。まだその領域には達していませんが、実現すればとてつもない能力になります。新しいコンピュータチップやコンピュータシステム、新しいハードウェアの設計自体をAIが行うという未来には、非常にワクワクしています。
蒸留技術とオープンモデルの力
現在、オープンモデルは「巨人の肩の上に立っている」状態なのでしょうか。つまり、もしフロンティアモデル（最先端の商用モデル）の開発や公開が突然ストップしたとしたら、オープンモデルは現在のようなスピードで進化を続けられるのでしょうか。それとも、現在の進歩の大部分は最先端モデルからの「蒸留」によってもたらされているものなのでしょうか。
確かに、現在の進歩のかなりの部分が蒸留によって支えられているのは事実です。たとえば、私たちのGemmaモデルも、より高品質で大規模なモデルから蒸留されて作られています。他の多くのオープンソースモデルも、蒸留データから多大な恩恵を受けています。
蒸留は、非常に高い能力を持つモデルの知識を、よりコンパクトで軽量なフットプリントのモデルへと移植するための極めて優れた手法です。私たちの「Flash」モデルが、そのサイズに対して「Pro」モデルに匹敵するほどの高い能力を持っているのも、Proモデルを教師役としてFlashモデルを教育しているからです。
ですから、本質的な問いは「クローズドかオープンか」という対立ではなく、私たちが小さくとも極めて有能なモデルを必要とする限り、まずは推論効率が低くても圧倒的に高性能な大規模フロンティアモデルを構築し続け、そこから蒸留によって知識を小規模モデルへと移転させていく必要がある、という点にあります。それがオープンモデルであれクローズドモデルであれ、このサイクルは変わりません。
その点について、まさにジェフにしか答えられないのではないかと思う質問があります。各社はフラッグシップモデルを擁し、それを蒸留した軽量モデルを階層（ティア）ごとに用意しています。通常、軽量で高速なモデルの性能はフロンティアモデルを大きく下回るものでした。しかし、あるモデルのバージョン、確か3.1の時だったと思いますが、軽量モデルの性能がフロンティアモデルに異常なほど肉薄し、難解なベンチマークでもわずか3%ほどの差しか出なかったことがありました。その際、ある人が「これは単なる蒸留の成果ではなく、何年も前から開発されてきた秘密のソース（特製の手法）が投入されているからだ」と言っていたのを目にしました。そのあたりについて、少し伺うことはできますか。
なるほど。詳細をすべて明かすわけにはいきませんが、お話しできる範囲で。
確かに、外部には公開していない独自の技術やノウハウは常に存在します。しかし、それほど小さなモデルを、低コストかつ高速で、誰もが利用しやすい価格帯に抑えながらフロンティアモデルに近い性能まで引き上げている最大のコア技術が、蒸留であることは間違いありません。
そして私たちは、さらにその先を行く、より強力なフロンティアモデルの開発へと突き進みます。新しいフロンティアモデルが完成すれば、再びその進化した知識をより軽量なモデルへと落とし込むプロセスを繰り返すことになります。
このサイクルは非常に重要です。なぜなら、実際に人々がメインで活用したいのは、コストパフォーマンスが高く、それでいて十分に有能な軽量モデルだからです。その性能がフロンティアモデルに極めて近いところまで到達できているというのは、開発の現場から見ても本当に素晴らしいことです。
以前では考えられなかったほどの肉薄ぶりですね。
コンテキストウィンドウの進化と lifetime AI の展望
現在、機械学習のトレンドの中で、ジェフが最も注目しているものは何ですか。以前、注目すべきトレンドについて講演されていたかと思いますが、その最新版を教えてください。
いくつか非常にエキサイティングなトレンドがあります。1つは、先ほども触れた「継続学習」です。まだ初期段階ではありますが、受動的にデータを観察するだけでなく、自発的にアクションを起こしてそこから学ぶという、より相互に織り交ぜられたモデルの構築は極めて重要な領域です。また、エージェントや、複数のエージェントを協調させるマルチエージェントシステムの活用も、外せない大きなトレンドです。
このエージェントのトレンドに伴い、今後はさらに膨大な推論用のハードウェアと処理能力が必要とされるようになります。バックグラウンドで自律的に動作するシステムは、与えられた重要なタスクを遂行するために、裏側で非常に多くのトークンを消費するからです。
そのため、極めて効率的な推論ハードウェアを構築することが、あらゆる可能性を切り拓く鍵になります。モデルのアーキテクチャとハードウェアのアーキテクチャを協調設計（コ・デザイン）し、非常に低いレイテンシ、優れたワットパフォーマンス、そして高いコストパフォーマンスを実現することに、私たちは強い関心を持っています。
もう1つの重要な特性は、モデルの「コンテキストウィンドウ」の拡張です。これに関しては、あたかもすべての情報がコンテキストウィンドウ内に収まっているかのような錯覚を与える、階層的なメカニズムの構築に大きな可能性があります。
たとえば、インターネット全体の情報をモデルが即座に参照できるようにしたり、あるいは個人レベルで許可を得た上で、その人の過去のメール、写真、視聴した動画などのすべてをモデルの記憶に定着させたりしたいと考えたとします。しかし、トランスフォーマーの標準的なアテンションメカニズムでは、計算量が入力長の2乗（オー・エヌ二乗）で増えてしまうため、それをそのまま実現することは不可能です。
ですが、情報検索（リトリーバル）と軽量なメカニズムを組み合わせた階層的なアプローチを構築することは可能です。たとえば、100億もの文書の中から最も関連性の高そうな3万件を絞り込み、次に軽量なモデルがそれらを精査して、真に重要な117件を特定します。そして最終的に、その117件だけを、より大規模で計算コストの高いモデルのコンテキストウィンドウに投入する、というカスケード（段階的）な仕組みです。
こうした一連の処理を裏側でオーケストレーションし、ユーザーにストレスや意識をさせることなく、あたかも無限のコンテキストがあるかのように見せる技術の進化は、非常にエキサイティングです。
なるほど、コンテキストウィンドウの計算コストは非常に高いですから、それをいかに賢くハックするかという高度な戦いが行われているわけですね。アテンションの計算量が2乗で増えるという課題に対して、現在はまだその制限の中にいるのでしょうか、それとも、より計算量の低い新しいアプローチが生まれているのでしょうか。
当然、より低い計算量を目指すアプローチは存在しますが、問題は常にトレードオフ、つまりその代償として何を失うかという点にあります。
その研究は現在、どのあたりまで進んでいるのでしょうか。
実際、この分野には非常に膨大な研究の蓄積があり、2乗の壁を超える効率的なコンテキストアルゴリズムに関する論文は優に100本以上出ています。標準的な2乗のアテンションメカニズムは非常に強力に機能するため、それを超えるためのハードルはかなり高いです。
しかし、アルゴリズム的な要因を削減したり、ベースとなる計算の非常に大きな定数項を減らしたりすることで、コストを大幅に下げるアプローチには着実な進展が見られます。さらに、これらの複数のアプローチを組み合わせることで、より多くのトークンに対して、遥かに低コストでアテンションを適用できるようになりつつあります。
コストを抑えつつ、極めて長いコンテキストの中から「干し草の山から針を探す」ようにピンポイントで情報を検出できるようになれば、人間の人生に寄り添うような「lifetime AI」の実現も見えてきますね。
まさにその通りです。自分がこれまでの人生で目にしてきたすべてのデジタルデータをそこに収めたいですよね。Googleの社内開発者の視点で言えば、Googleの全コードベース、おそらく100億行、トークン数にして1000億トークンに及ぶすべてのコードをコンテキストに叩き込みたいところです。
私はお気に入りのワインのリストが入るだけでも満足ですが。
私は1000億トークンのコンテキストウィンドウが欲しいですね。それさえあれば十分です。
大規模データセンターの裏話と宇宙線の脅威
次のテーマに移りましょう。Googleのデータセンターでは、天文学的な数のマシンが稼働しています。それほどの規模になると、「起こり得るトラブルはすべて起こる」というマーフィーの法則の世界になるかと思います。ケーブルの劣化、ハードディスクの故障、マザーボードの過熱など、こうしたトラブルは実際に日々起きているのでしょうか。何か面白いエピソードはありますか。
間違いなく日々起きています。私個人の突飛なエピソードというのはそれほど多くありませんが、社内にはかつて「Data Centers on Fire（データセンター炎上）」と呼ばれるチャットグループが存在していました。そこでは日々、エキサイティングなトラブルや、時には衝撃的な動画が共有されていました。
あの規模になると、想定を遥かに超える事態が頻発します。大抵の場合、1つの障害が発生したのと同時に別の障害が重なったり、あるいは連鎖的（カスケード）に障害が拡大していくことで深刻な事態に発展します。
ソフトウェアシステムが突然停止することもあれば、ごく稀にですが、バスバー（導電バー）が過熱してラックに過剰な電力が供給され、物理的に火の手が上がるようなケースもあります。そのため、私たちは常にこうした事態に備えておく必要があります。Googleの極めて初期の時代から一貫している設計思想は、「信頼性の低いパーツを使って、いかに信頼性の高いシステムを構築するか」という点にあります。
初期のGoogleでは、コストを抑えるために、ECCメモリ（エラー訂正メモリ）すら搭載されていない一般消費者向けのマシンを大量に購入していました。ECCどころか、パリティチェックすらついていないものです。冗長電源もないような民生用のマザーボードを使っていましたが、それが可能なのは、ハードウェアの欠陥を上位のソフトウェアレイヤーでカバーするシステムを構築していたからです。
そのメモリのエラーに関連して、ぜひ伺いたかった都市伝説のような話があります。遠く離れた宇宙で超新星爆発が起き、そこから放たれた宇宙線がメモリセルに衝突することで、データの「0」が「1」へと反転するビット反転（シングルイベントアップセット）が起きるというのは、本当に現実にあることなのでしょうか。
ええ、完全に本当のことです。アルファ粒子や宇宙線によってDRAMの状態が反転する現象は、確実に存在します。私たちはこれを実際に観測しています。すべてのマシンにおいて、ECCによって修正されたシングルビットエラーの発生数や、修正不可能なデュアルビットエラーの発生データをすべてロギングし、監視しているからです。
データを分析すると、地球上の特定の方向を向いているクラスタにおいて、わずか10分間ほどの短い時間だけエラーの発生率が急激に跳ね上がるといった現象が確認できます。その裏側にある、地球の反対側を向いているクラスタではその現象は起きません。ですから、これは間違いなく現実に起きている現象です。
一般のユーザーはどれくらいそれを心配すべきでしょうか。たとえばMacBook Proなどには、私の知る限りECCメモリは搭載されていません。個人のマシンが1台だけの場合、発生確率は無視できるほど天文学的に低いので気にしなくていいレベルなのか、それともデータセンター規模だからこそ対策が必要な話なのでしょうか。
個人のマシンが1台だけであれば、通常はそれほど深刻に心配する必要はありません。一般的な民生品にはパリティチェックくらいはついていることが多いので、シングルビットエラーが発生したこと自体の検出は可能です。
検出はできても、自動での修正はできないわけですね。
その通りです。一方でECCメモリであれば、シングルビットエラーの自動訂正と、デュアルビットエラーの検出が可能です。これがあれば、単一マシンのレベルではエラーをほぼ気にする必要はなくなります。しかし、マシンの数が数万台という規模になってくると、対策を講じなければシステムが崩壊します。
先ほどお話しした通り、初期のGoogleではパリティチェックすら付いていないマシンを使っていたため、私たちはデータの大部分に対して、ソフトウェアベースのチェックサム（誤り検出）システムを独自に構築しました。
すべて手動のソフトウェア処理で解決したのですね。
実質的にそうです。たとえばウェブページをクロールしてインデックスに格納する際、特定のレコードに破損が検出された場合、システム側で「そのレコードを単に無視してスキップする」という処理を行っていました。その程度の割り切りが許されるシステム設計にしていたのです。
一問一答：ライトニングラウンド
ここからは「ライトニングラウンド」として、短い一問一答をお願いします。できれば1文、あるいは一言でテンポよくお答えください。
1文ですね。接続詞で引き延ばした長い1文でもセーフですか。
様子を見て判断します。
では最初の質問です。ネット上の噂で「ジェフ・ディーンの暗証番号は、円周率の末尾の4桁である」というジョークを見つけました。個人的にはこのジョークに10点満点中8点を付けたいと思います。こうした、自身に関する「チャック・ノリス風のジェフ・ディーン・ファクト」のジョークについては、楽しんでいらっしゃいますか。
本当にそうだったら面白いですね。楽しんでいますよ。2009年に社内の同僚たちがエイプリルフールの悪ふざけで始めたものが、いつの間にか独り歩きして広がってしまったのですが、とても光栄に思う反面、少し気恥ずかしさもあります。
チャック・ノリス本人も、自分に関するジョークを同じように楽しんでいたと聞きます。まさにレジェンドですね。
次の質問です。「過去に自分が完全に間違っていたと認め、考えを改めた最大の出来事」は何ですか。
AIが医療の分野に劇的な変革をもたらすという点について、少し見通しが甘かったことです。技術的な難しさというよりも、規制の厳しい業界特有のハードル、極めて厳格なプライバシーの制約、安全性の懸念など、実社会に組み込むためのプロセスが予想以上に複雑でした。最終的には必ず実現すると信じていますが、私が当初期待していたよりも時間がかかっています。医療への応用は人類にとって計り知れない利益をもたらすものだからこそ、慎重かつ安全に進める必要があります。
「Vim」か「Emacs」か、あるいはそれ以外か。ヒントを言うと、正しい答えは1つしかありません。
Emacsです。
違いましたか。私はVim派なのですが、両方を完璧に使いこなすほどの時間は投資できなかったので、Emacsの奥深さも認めつつ、Vimに落ち着きました。
確かに、Emacsのカスタマイズには無限に時間を吸い取られますからね。設定ファイルの書き込みを始めると終わりがありません。
「これまで何度も挑戦し、解決しようと試みたものの、未だに突破口を開けていない課題」は何でしょうか。
やはり、適切な形での「継続学習」をいかに実現するか、という問いに対しては、まだ明確な答えを出せていません。これまで同僚たちといくつかの手法を試みたり、少し手を付けたりはしているのですが、この課題を完全にクリアできれば、AIの能力は文字通り一変するはずです。しかし、まだそこには到達していません。
最後の質問です。お気に入りの「Two-Minute Papers」のエピソードは何ですか。
やはり、「Transformer（トランスフォーマー）」を取り上げた回は素晴らしかったですね。
見事な選定です。ジェフ、今日は本当に多くのことを学ぶことができました。再びこうしてお話しできて嬉しかったです。本当にありがとうございました。
こちらこそ、ありがとうございました。
コメント