※本記事は、Tel Aviv大学のTova Milo教授によるSIGMOD 2026基調講演「SIGMOD 2026 Keynote talk by Tova Milo (Tel Aviv University)」の内容を基に作成されています。Tova Milo氏は、Tel Aviv大学コンピュータサイエンス学部教授であり、同大学Exact Sciences学部長、Information Management寄付講座教授を務めています。ウェブデータ、XML、半構造化データ、グラフデータ、ビジネスプロセス、データ統合、プロヴェナンス、プライバシー、説明可能性など、現代のデータ管理の基礎を形作る幅広い分野で貢献してきました。Wiseman Prize for Exact Sciences、VLDB Women in Database Research Award、ICDE Impact Award、チューリッヒ大学名誉博士号など数々の賞を受賞しており、ACMフェロー、Academia Europaeaメンバーであるほか、女性の理系分野における過小評価に取り組むメンター制度Exactの創設者でもあります。動画の詳細情報は https://www.youtube.com/watch?v=Q-iA8W0-fzw でご覧いただけます。本記事では、講演内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. 導入:講演者紹介と問題提起
1.1 講演者紹介
Sudipa: 本日のキーノートセッションにおいて、Tel Aviv大学のTova Milo教授をご紹介できますことを、大変光栄に思います。Tovaは同大学のコンピュータサイエンス学部教授であり、Exact Sciences学部の学部長、そしてInformation Managementの寄付講座教授を務めています。彼女は私たちデータベースコミュニティの出身であり、数多くの会議でプログラム委員長をはじめとする指導的役割を担ってきました。彼女の業績は、ウェブデータ、XML、半構造化データ、グラフデータ、ビジネスプロセス、データ統合、プロヴェナンス、プライバシー、説明可能性といった分野にわたり、現代のデータ管理の基礎を形作ってきました。受賞歴としては、Wiseman Prize for Exact Sciences、VLDB Women in Database Research Award、ICDE Impact Award、そしてチューリッヒ大学からの名誉博士号などがあります。彼女はACMフェローであり、Academia Europaeaのメンバーでもあり、また女性の理系分野における過小評価に取り組むメンター制度Exactの創設者でもあります。ERC Advanced GrantやISF Breakthrough Research Grantといった名だたる助成金も受けています。個人的な話になりますが、私は博士課程の学生だった頃、PODSでの最初の論文の一つをTovaと共に執筆する機会に恵まれました。Tovaと研究をともにすると、楽しいミーティングが待っていて、彼女は思いもよらなかった方向性や解決策を示してくれます。会場にいる学生の皆さんも、機会があればぜひTovaと話してみてください。本日Tovaは、データ管理の数十年にわたる進歩が、現代のAIシステムが抱える喫緊の課題の解決にどう役立つかについてお話しくださいます。それでは、Tova Milo教授を温かい拍手でお迎えください。
Tova: 温かいご紹介をありがとうございます、Sudipa。そして今回お招きいただいたSudipaとKarsten、SIGMODの運営の皆様にも感謝申し上げます。ここに立ち、皆様にお話しできることを大変光栄に思います。
1.2 危機感の背景:データ管理分野が経験してきた技術の波
Tova: 本日お話ししたいのは、ここ数年、私たちが皆感じているであろうある種の感覚についてです。私たちは何十年もの間、データ管理に関わる問題に取り組み、情報の問い合わせ、分析、統合、クレンジングといった、あらゆる素晴らしいことを実現するためのツール群を開発してきました。ところがここ数年、これらの問題はすべてLLMに話しかけるだけで解決できてしまうように見えます。これは正直なところ不安を感じさせるものです。私が本日論じたいのは、私たちが考案し発展させてきたこれらのアイデアは、実は今なお極めて有用であり、AIの世界をより良くするために活用できるということです。
私自身は、幸運にも、あるいは単に年を重ねただけかもしれませんが、データ管理コミュニティが経験してきた数々の波を実際に経験してきました。オブジェクト指向データベース、半構造化データ、データ統合、XML、ワークフロー、クラウドソーシング、データ探索、そして最近ではXMLと、次々と新しいトピックが登場するたびに、私たちはこれが世界を変えると考えてきました。実際にそうなることもありますが、より頻繁に起きているのは、過去のトピックについて考えてきたことが、その後の期間を通じて何らかの形で生き残り、新しいトピックを理解する助けになるという現象です。そして私が思うに、あるいは少なくとも私が信じているのは、機械学習についても同じことが言えるということです。機械学習はあらゆる場所に存在しています。車の運転の仕方、お金の投資の仕方、新薬の設計の仕方など、私たちの生活のあらゆる側面が機械学習によって制御されている、あるいは少なくとも強化されています。そしてこれは、データ管理や、私たちが情報とやり取りする新しい方法についても、間違いなく当てはまります。
1.3 転機となった論文とLLMの限界
Tova: 私にとって目を開かされる契機となったのは、2022年に発表された「Can Foundation Models Wrangle Your Data」という論文でした。皆様の中にお読みになった方がいるかどうかわかりませんが、私はVLDBでChris Ré氏によるこの論文についての講演を聞いたのが最初でした。この時初めて、モデルを訓練する必要はなく、この非常に汎用的な基盤モデルを取り出し、いくつかの短い例とともにプロンプトを試すだけで、データのクレンジングや統合など、多くのことができるということを理解しました。しかも多くの場合、その領域における最先端のアルゴリズムよりもうまくいくのです。それを目の当たりにして以来、コミュニティ全体がこのアプローチに注目するようになったと思います。私たちはクエリ言語の代わりに基盤モデルを使って問い合わせを行い、半構造化データを扱い、データクレンジングを行うようになり、それらなしでどうやって物事をこなしていたのか半ば忘れてしまいました。問題は、私たちがLLMにすべてをやらせるだけで済むのか、そして私たちが開発してきた古いアイデアや概念、基礎はもう必要ないのか、あるいは新しい仕事を探すべきなのか、ということです。私の答えは、むしろ今こそこれまで以上にそれらが必要とされているというものです。というのも、基盤モデルやLLM全般は確かに素晴らしいものですが、いくつかの欠点があることも私たちは知っているからです。
例えばハルシネーションです。これは減少傾向にあり、以前よりずっと少なくなってきていますが、それでも依然として存在します。私たちはなぜある回答が得られるのかを正確には理解していませんし、正確性、完全性、再現性についての保証もありません。これらはすべて、私たちのコミュニティが慣れ親しんできたものであり、データを見て利用する人々が当てにしているものです。これらは非常に重要な欠点です。問題は、私たちが知っているツールを使ってこれらの問題への対処を助けられるかということですが、それらをそのままの形で使うことはできません。多くの場合、新しい形、新しいアイデアが必要になります。しかしこれからお示しし、主張していくように、それは実現可能だと考えています。
そこでまず、私の研究グループで最近取り組んだ、探索的データ分析(exploratory data analysis)の文脈における2つの事例をお見せしたいと思います。この文脈におけるあらゆる問題に対して、新しい視点から見る新鮮な方法があることを皆様に納得していただき、その後、この2つの事例から一般的なAIとデータ管理技術の話へと発展させ、最後に未来のエージェンティックAIについて少しお話しして締めくくりたいと思います。
2. 事例1:データ探索エージェントと半構造化データのクエリ言語
2.1 探索的データ分析とツリーパターンクエリの基礎
Tova: それでは事例に入りましょう。探索的データ管理とは何でしょうか。データセットを与えられたとき、その中で何が起きているのかを理解したい、データやパターンを理解したいというときに行うものです。これは単一のクエリを書くことではなく、設定を理解するために役立つ一連のクエリを書くことを意味します。私たちが自問してきたのは、この作業を人間の代わりに行う機械やエージェントを構築できるかということです。データサイエンティストが座ってクエリを書く代わりに、機械にそれをやらせることができるのか。重要なのは、このようなエージェントに求められるのは、データの中で興味深いもの、多様なもの、そして人がそれを見たときに自然に理解できるようなものを見つけ出す能力だということです。そしてこの問題に対して私たちが採用した抽象化は、意外性はないかもしれませんが、深層強化学習でした。これは比較的シンプルな考え方です。構築したいのは、状態を見るエージェントです。状態とはデータセット、あるいは直前のクエリの結果のことです。エージェントはアクションを発行します。この設定ではこれはクエリに相当します。そして結果を得て、あるスコア、つまり報酬を得ます。発行したクエリが理にかなっていて興味深いものであれば報酬が得られる、というものです。目標は通常通り、期待報酬を最大化することです。ここで重要なのは強化学習を使っているという事実そのものではなく、エージェントをどう方向づけるか、つまりエージェントが求めているものを見つけられるよう、探索空間をいかに理にかなった形で探索させるかという点です。この一般的な設定のもとで、私たちが本来意図されていたのとはまったく異なる形で、2つの古い技術をこの新しい設定でどう活用したかをお見せしたいと思います。1つ目はクエリ言語です。半構造化データのためのものです。2つ目はクラウドソーシングです。
まず1つ目から始めましょう。半構造化データのクエリ言語とは何でしょうか。会場で半構造化データに取り組んだことがある方はいらっしゃいますか。何のことか分からない方はいますか。なるほど、年配の方が結構いて、若い方は少ないようですね。半構造化データという発想が生まれたのは、あるときデータベースコミュニティがテキストを問い合わせたいと考えたことがきっかけでした。当時はLLMがなかったので、テキストに意味的なタグを埋め込むという方法を取りました。よくある論文で使われる例で言えば、書籍を含むライブラリがあり、ライブラリの始まりにlibraryというタグを付け、各書籍にはbookの開始と終了のタグを付け、その中にauthorなどを入れるというものです。この情報を抽象化する方法はツリーです。ルートがライブラリで、その子がbook、さらにその子がtitleやauthorといったものになります。この情報を問い合わせるために私たちが使っていたのはツリーパターンクエリです。例えば、2人の異なる著者を持つ出版物を見つけるクエリがその一例です。ライブラリの中の何かを探しているのであって、それがbookかどうかは気にしません。2人の著者がいて、それぞれ異なる名前を持っている、というものです。
2.2 実験結果とシステムアーキテクチャ
Tova: それでは、データ探索の話に戻りましょう。先ほど述べたように、重要なのはエージェントに、あなたが関心を持っているものを探させることです。典型的には、何らかのゴールを念頭に置いてデータセットを探索したいと考えます。例えば、世界の他の国々とは異なる視聴習慣を持つ国を見つけたい、というゴールがあり、与えられたデータセットがNetflixのテレビ番組と映画のデータセットだとします。このゴールを念頭に置いて、エージェントにデータを探索させ、例えばインドが評価やジャンルの点で世界の他の地域とは異なる、興味深い国であることを教えてほしいわけです。実際、このデータセットでは、インド国内のコンテンツの半数以上がTV14のレーティングを持つ一方で、世界の他の地域ではその割合ははるかに低く、また93%がムービーである一方、世界の他の地域では半分以下しかムービーではない、といった具体的な違いが見られます。これは半構造化データとは一見まったく関係がないように思えるかもしれませんが、実はそうではありません。ポイントは、探索パスをツリーとして捉えられるということです。これはどういう意味かというと、実際にツリーの中に現れるのは、データを探索する際にたどる異なるパスだということです。Netflixのデータベースから出発し、興味深い国を見つけるために、レーティングでグループ化してインドと世界の他の地域の番組数を比較したり、あるいはタイプでグループ化して同様に結果を比較したりする、といった具合です。つまり、関連する国を見つけるためには、このようなツリー状の探索パスを持ちたいわけです。言い換えれば、探しているゴールのタイプを、まさにツリーパターンクエリのように見えるもので表現できるということです。これは、何らかの基準に基づいてグループ化を行い、集約関数を適用し、ある国と世界の他の地域の結果を比較する、というパターンを探している、と言っているのです。これができれば、この意味で理にかなったパターンを自動的にエージェントに探させることができます。システム全体のアーキテクチャを見ると、詳細をすべて理解する必要はありませんが、重要なのは、ユーザーが求めているものをおおまかに述べるところから始まり、LLMなどを使って自動的にこのパターンが生成され、それが強化学習エンジンに投入されるという流れです。図の下部にある赤い部分がまさにこれで、これが報酬関数の構築に使われ、エージェントがデータベースを探索し、最終的に結果を生成するのを導きます。
ここで言いたいのは、私たちが行ったのは、データ管理における一つの技術、すなわち半構造化データのアイデアを、まったく別の文脈でまったく異なる形で用いたということです。言い換えれば、私たちが生成したのは、AIの探索を制約し導く形式的な仕様です。これは一つの事例に過ぎませんが、本講演の残りの部分でも繰り返し登場するテーマとなります。すなわち、データ管理のアイデアを何か形式的なものに使う方法、例えばここではクエリ最適化技術のすべてを使って探索パスを高速に枝刈りしたり、行っていることを説明したりできるということです。これが1つ目の事例でした。皆様にご理解いただけたことを願いつつ、2つ目の事例、クラウドソーシングに関連するものに移りたいと思います。
3. 事例2:クラウドソーシングとLLMオーケストレーション
3.1 クラウドソーシングの基礎
Tova: クラウドソーシングもまた、2010年から2020年頃にかけて非常にホットなトピックでした。ここでクラウドソーシングに取り組んだことがある方はいらっしゃいますか。先ほどより少ないですね。では、クラウドソーシングが何か分からない方はいますか。こちらもごくわずかです。つまり、ちょうど中間くらいの年齢層の方が多いということでしょう。それでは簡単に説明します。ポイントは、私たちデータベースコミュニティが、データベースに保存している情報以外にも、人々の頭の中には多くの知識があることに気づいたということです。何かを分析したいときには、人に尋ねる、つまり群衆に尋ねて答えを得て、それを使って何かをすることができます。重要なのは、すべての回答が等しく価値があるわけではないという点です。答えを知らない人もいれば、間違える人もいます。より専門性の高い人もいれば、そうでない人もいます。また、報酬を求める人もいれば、あまり求めない人もいます。そのため、群衆は異なる正確性レベルと異なるコストで回答するという設定が存在し、この計算をどうにか最適化したいという課題があります。例えば、ニューデリーの新しい空港の名前を知りたいという例では、多くの人に尋ね、多数決によって決定するというやり方があり、これによってIndira Gandhiという空港名を学ぶことができます。しかし一般には、群衆をオーケストレーションして質問に答えさせるための、もっとずっと複雑で洗練されたアルゴリズムが存在していました。これがクラウドソーシングです。
3.2 LLMオーケストレーションへの応用
Tova: では、これが私たちの今の話とどう関係するのでしょうか。先ほどのデータ分析の例に戻りましょう。今日、典型的に情報を集める方法は、群衆に尋ねることではなく、LLMとやり取りすることです。しかし私たちが認識すべきなのは、LLMも群衆と同じように、時には正しく、時には正しくないということです。あるものはより高価で、あるものはより安価です。それぞれに固有の専門性があり、それらとどう付き合っていくかをどうにか学ぶ必要があります。ここでもまた、車輪の再発明をするのではなく、クラウドソーシングのアイデアに立ち戻り、賢く規律立った形で情報を得るために活用することができます。例えば、ある関係において、いくつかの属性の値が分からない、あるいは列や行が欠落しているとします。LLMに尋ねることができます。GPT-4を使うこともできますし、Claudeを使うことも、あるいは専門特化型のLLMを使うこともできます。それぞれに固有の性質と専門性があります。そして、コストと精度のトレードオフを最適化するために、クラウドソーシングで使われていたのと非常によく似たアルゴリズムを使って、クリーンなデータセットを生成することができます。
さて、ここまで何をお示ししてきたでしょうか。私がお見せしたのは、そのエンジンが実際にはデータ管理における従来のアイデアを、まったく異なる形で使用しているエージェントベースのシステムでした。つまり、これは古い解決策をそのまま使っているのではなく、その解決策の原理を使って新しい問題を解決しているのです。そして本講演の残りの部分で論じたいのは、これがこの特定の事例やこの特定のシステムだけに当てはまるのではなく、一般にAIシステム全般に当てはまるということです。ですので、ここから議論を一般化し、データ管理の一般的なツールボックス全体を見渡して、それを使って何ができるかを考えていきたいと思います。
4. 一般化とRAGの限界
4.1 データ管理とAIシステムの対応関係
Tova: 私たちの古いシステムには、明示的なクエリ、オペレータ、スキーマ、ワークフローがありました。そしてAIシステムにおいては、これらすべてが姿を変えています。自然言語があり、プロンプトがあり、埋め込みがあり、エージェントがあります。これは一対一の対応ではありません。まったく異なるものです。ですので、一見しただけでは、これらの新しい設定と旧来のものとの間にある共通点を見出すのは難しいでしょう。しかし実際のところ、AIシステムが扱っている中核的な問題は、私たちがこれまで取り組んできた問題と、ある意味で非常によく似ています。AIシステムは関連情報を検索する必要があり、自らが行っていることを説明するよう求められ、結果を検証しなければならず、それを最適化された形で行う必要があり、さまざまなサービスをオーケストレーションする必要があります。これらすべては、私たちがこれまで取り組んできた問題であり、今それがAIシステムの内部で再び姿を現しているのです。そして私たちが取り組んできたツールボックス、すべての解決策は、非常に有用であるように見えます。クエリ言語、制約、プロヴェナンス、グラフデータ、最適化、説明、クラウドソーシングについてお話ししていきます。この中で、これらのうち少なくとも一つに取り組んだことがない人はいますか。誰もいませんね。素晴らしい。つまり皆さんは、新しいAI時代における仕事をすでに持っているということです。なぜなら、これらすべての事柄は、AIシステムのあらゆる層に極めて関連しているからです。そして、本講演から一つだけポイントを持ち帰っていただくとすれば、それはこうです。私たちがこれまで開発してきたツールは、人々のために、そして人々がデータとやり取りするために開発されたものでしたが、今後はもはや人間ではなく、人々とやり取りするAIシステム自身によって使われることになります。ですから私たちは、これらに新しい形を与える必要がありますが、その根底にある原理そのものは今なお重要なのです。
4.2 RAGの限界とナレッジグラフへの回帰
Tova: それでは検索(retrieval)から始めましょう。LLMを除けば、この文脈における2番目に優れた発明は、RAG、すなわちretrieval augmented generationだったと思います。最初のシステムが登場したのはおよそ2020年頃だったと記憶しています。RAGが何か分からない方はいますか。怖がらなくて大丈夫です。あるいはRAGが何か知っている方はいますか。知っているかどうか自分でも分からないという方もいるようですが、それで構いません。皆で理解を共有するために、ごく手短におさらいします。ポイントは、LLMがあり、それに自身の一般知識だけでなく、データベースシステムやファイルシステム、あるいはその他の外部情報を使わせたいということです。下部で行うのは、情報を取り込んで小さな断片に分割することです。データベースのタプルであったり、テキストや動画の一部であったりします。そして各断片について埋め込みを構築し、その埋め込みを情報とともにデータベースに保存します。そしてユーザーからクエリやプロンプトが来たら、そのユーザークエリも埋め込みに変換し、ベクトルデータベース上で類似検索を行って最も類似した断片を見つけ出します。それらを取り出し、ユーザークエリとともにLLMに与えて、そこから回答を生成させます。非常にシンプルで素晴らしいアイデアであり、極めて有用ですが、これだけでは不十分だということがすぐに明らかになりました。多くの場合これはうまくいきません。理由はすでに私たちがデータ管理で知っているものです。多くの場合、単一の小さな情報の断片だけでは答えられないことがあります。データベースにおけるjoinのようなマルチホップの関係を扱う必要があります。矛盾する情報を扱わなければならないこともあります。また、意味的には類似していて埋め込み空間上では近いものの、実際にはまったく関連性のないものが存在することもあります。AI業界の人々もこれに非常に早く気づき、その対応は私から見て興味深く、魅力的なものでした。彼らが実際に行ったのは、構造を取り戻すことでした。すなわち、RAGシステムの上にナレッジグラフを構築したのです。エッジを持ち、パス推論を伴い、構造化された検索を備えたナレッジグラフです。検索は一種の組み合わせ型になりました。埋め込みも使いますが、情報を見つけるためにグラフのトラバーサルも使うのです。これを見ると、私たちは以前にもこれを見たことがあります。まさに半構造化データ、XML、グラフクエリ、セマンティックウェブで行ってきたことそのものが、RAGなどを行うシステムの中に再び現れているのです。しかし重要な違いは、私たちはこれらのシステムを人間のために構築していたということです。人間がSPARQLクエリなどを書いていました。今ではそれを使っているのはAIシステム自身です。しかし研究という観点では、私たちが行ってきたことはすべてここに関連しています。この組み合わされた構造の上でクエリプランニングをどう行うか、それは私たちのコミュニティが行ってきたことに着想を得たものかもしれません。制約を考慮した検索を行う必要がありますし、プロヴェナンスやプライバシーへの対応も必要です。これらすべて私たちが知っていることであり、AIの人々はこの点において私たちほど専門的ではありません。これらすべては極めて重要であり、更新への対応を含むシステム最適化についても同様で、私たちは知っていますが、この分野ではまったくと言っていいほど扱われていません。少なくとも私たちが研究してきた程度には扱われていません。これらすべては、私たちにとってAI領域における素晴らしい研究機会なのです。
5. 説明可能性と検証
5.1 データに根ざした説明
Tova: さて、検索について論じましたので、次に劣らず重要な別のトピック、すなわち説明(explanation)についてお話ししたいと思います。言語モデルは答えを与えてくれます。それを説明するよう求めると、非常に滑らかで見事な説明を返してくれます。しかし問題は、データ分析においては、それらしい物語だけでは不十分だということです。私たちは、説明が本当にデータに根ざしており、検証可能な状態であってほしいのです。この2つの違いを説明するために、Spotifyのデータセットについて何かを尋ねる場面を考えてみましょう。LLMが「新しい曲の方がSpotifyで人気がある」と教えてくれたとします。私たちはなぜそうなのかを理解したいわけです。システムはどうやってこの結論を導いたのか、なぜそれが正しいと考えているのか。言語モデルに尋ねれば、次のような説明が得られるでしょう。「新しい曲がより人気なのは、リスナーが新しいリリースを好む傾向にあり、レコメンデーションアルゴリズムが最近のコンテンツを推奨するからです」と。これは非常にもっともらしい説明ですが、実際にSpotifyのデータセットに見られる内容とは何の関係もありません。私たちデータベースの人間からすると、データに根ざした説明は次のようになります。ナイーブなユーザーにとってはこちらの方が読みにくいのですが、実際に言っているのは次のようなことです。データセット全体を見て、年ごとの人気度の分布を見ると、おおむねどの年も同じです。一方で、人気のある曲、つまりデータのサブセットだけを見ると、2015年から2021年の間にスパイクが見られます。つまりデータセットの中では、確かに新しい曲の方が人気であることが分かりますが、ここでいう「人気」とはpopularityが65を超えるものを指し、「新しい」には明確な意味があります。これは普通の人々にとっては読みやすいものではないかもしれませんが、これを踏まえてテキストで説明を書くことはできます。そして、これはデータに根ざしたものになります。この2種類の説明、つまりLLMの一般知識に由来する説明と、手元にあるデータセットに根ざした説明は、非常によく見られるものですが、LLMはこの2つを区別する術を知りません。AIコミュニティに教えなければならないのは、まさにこの種の説明を処理の中に組み込むことです。私たちにとって、そして情報を扱うすべての人にとって、説明を信頼できるものにするのは、それがデータに根ざしていること、比較可能であること、証拠に基づいていることです。これはクエリの結果だけに関係するものではありません。ニューラルな表現そのものにとっても非常に重要です。LLMやニューラルネットワークを見ると、埋め込みがあり、LLMの異なる層があり、多くの場合、それらが何をしているのか私たちにはまったく分かりません。使っている埋め込みが良いのか悪いのか分かりません。さまざまなベンチマークは存在しますが、それらは埋め込みや異なる層の何が正しくて何が間違っているのかを本当には説明してくれません。私が主張したいのは、私たちの領域における、データに根ざした説明を、このニューラルな表現に対しても使えるということです。例えば、ある埋め込みが良いか悪いかを理解したいとします。それをクラスタリングし、データベースに基づく表現や説明をクラスタに対して使うことができます。例えば、クラスタ1はよりテンポの値が高いものをグループ化している、あるいはクラスタ3は他の曲よりも長さ(duration)がミリ秒単位で長い、といった具合です。こうして各クラスタについて表現や説明を持つことができ、もし分析の中で、これらのクラスタに表現されていない何かが必要だと分かれば、その埋め込みは自分の目的には合わないと分かります。求めている特徴に対して感度のある埋め込みを見つける必要がある、ということです。これは埋め込みの例ですが、ニューラルネットワークの異なる層についても同じことができ、それが自分にとって機能するかどうかを本当に理解することができます。
5.2 推論プロセスに組み込む検証
Tova: 説明とともに重要になるのが検証(validation)です。LLMは、回答や事実を膨大な速度で生成します。事後的な検証を行うのは非常に困難です。単に数が多すぎて検証に時間がかかってしまうからです。私が主張したいのは、検証は推論プロセスの一部として組み込まれなければならないということであり、これもまた、私たちがデータ管理においてすでにやり方を知っていることです。検証にはさまざまな方法があります。ここでは2つの例だけご紹介します。一つは、リファインメントと反例による検証です。「新しい曲の方がSpotifyで人気がある」という主張について、あらゆるジャンル、あらゆる国について本当にそうかを確認することができ、それがクラシック音楽には当てはまらない、あるいは主にトップアーティストにのみ当てはまる、といったことが分かります。私が主張したいのは、古典的な検証メカニズムをAIの推論やパイプラインの機構の内部に組み込むべきであり、事後的に行うべきではないということです。これは検証メカニズムの一つのタイプに過ぎない一例です。
6. 最適化とエージェンティックAIの将来像
6.1 最適化技術の再発明
Tova: 説明と検証について論じましたので、次に最適化(optimization)についてお話ししたいと思います。ここまで論じてきたのは、AIシステムとやり取りする上での論理層についてでしたが、ご存知の通り、ニューラルネットワークを構築し、訓練し、その後推論を行い、それを利用するのは非常にコストがかかります。私たちはデータベースにおいて、長年にわたり最適化に取り組んできました。論理レベルではjoinの順序付けのようなものがあり、物理レベルではキャッシング、マテリアライゼーション、スケジューリング、リソース割り当てがあります。AIシステムを見ると、ある意味でそれらと似たものが存在します。推論のルーティングがあり、KVキャッシュの管理があり、バッチングがあり、検索のプランニングがあり、ツールのモデリングやルーティングがあります。これらの人々が書いている論文を見ると、私たちがデータベースシステムで取り組んできたアイデアの多くを、実質的に再発明していると言えます。実際、AIシステムを見ると、それらは本質的に分散データシステムになりつつあります。この点については明日のキーノートなどでさらに詳しく学べると思いますが、重要なのは、抽象化は変化していても、最適化の原理はそこに存在しているということであり、私たちがこれまで行ってきたことから多くのものを取り込み、こうしたシステムに移していくことができるということです。
6.2 エージェントによる原理の自動学習
Tova: 最後にお話ししたいのは、エージェンティックAIについてです。世界中がエージェントやエージェントの合成について語っている今、私の見方は少し異なります。ここまでお見せしたすべての例、私が主張してきたのは、私たち研究者がアイデアや原理をどう考え、それをAIシステムの内部に組み込むかということでした。しかし、実際にはあらゆることをこなせるこれらの賢いエージェントに、これを自動的にやらせてはどうでしょうか。あるいは、それは自動的に可能なのでしょうか。エージェントは本当に、私たちがデータベースコミュニティで取り組んできたすべての技術、アイデア、原理を学び、それらを構築されているシステムの中に自動的に組み込むことができるのでしょうか。例えば、サービス選択について、どのツールやどのモデルを使うべきかを自ら判断できるのでしょうか。ツールの合成について、私たちが持っていたこれらの素晴らしいアイデアをどの順序で組み合わせて、より良いものにするかを自ら判断できるのでしょうか。ワークフローを改善できるのでしょうか。これらすべてのツールを使って自律的な検証を行えるのでしょうか。そのために何が必要でしょうか。エージェントには、ツールが何をするのかについての仕様が必要です。できれば形式的で宣言的な形が望ましいですが、テキストでも構いません。ただし、入力が何で、出力が何で、サービスが何をするのかを記述できる方法が必要であり、それらを合成し、フローについて、データに何が起こるのか、どのような性質があるのかを推論できる必要があります。ここで、ワークフローやビジネスプロセスに取り組んだことがある方はいますか。まさにそれです。私たちはこうしたことすべてに取り組んできました。入力と出力のテキストによる記述という形ではなかったかもしれませんが、私たちはこの分野に携わってきており、多くのことを知っています。私の主張は、座って待っているのではなく、そこに取り組みに行くべきだということです。まさにこれこそ、私たちが貢献できることなのですから。
7. 結論:テルアビブ大学の実例と総括
7.1 バーチャルチューターの実例と総括
Tova: このような話をしてきましたので、そろそろ結論に入りたいと思います。私たちは新しい犬に古い芸を教えられるのだということを、皆様に納得していただけたのではないかと思います。私たちはこの数十年、人間がデータについて推論するのを助ける方法を学ぶことに本当に多くの時間を費やしてきました。そして今、AIシステムにも同じことを教える必要があります。それは後戻りするためではなく、むしろ改善するためです。最後に、Tel Aviv大学で実際に起きている一つの実例、実生活における具体的な事例をご紹介して締めくくりたいと思います。私たちはここ数年、学生向けのバーチャルチューターの構築に取り組んできました。これは、コースの教材を取り込み、学生を助けるチャットボットのようなものです。学生は教材について質問することができ、他の製品でご存知のようなものと概ね同じように回答を得られますが、違いは、それがそのコースのスライドや動画、講義ノートといった教材そのものに焦点を当てているという点です。このシステムを開発する中で分かったのは、人々に実際にこのシステムを使ってもらうため、そして何より教授陣が学生にこのシステムの利用を許可するために、最も差し迫って対処すべき問題は、まさに説明と検証の問題だったということです。ボットが一般知識から答えているのか、それともコース教材から答えているのかを理解できるようにすること、そして回答を検証し確認できるようにすることが重要でした。昨日のキーノートでも、数学的証明においてどれほど検証が重要かについて伺いましたが、私たちの領域では、データに関する検証は、それよりも単純な問題です。私たちはそれをどう扱えばよいかを知っていますし、対処する方法を分かっています。これまでお話ししてきたツールが、ここで本当に役立つのです。以上が、この問題に対する私の見解です。最後になりましたが、私の学生たち、共同研究者たち、そして助成機関の皆様、そして今回お招きいただいたSudipaとKarstenに感謝を申し上げたいと思います。ご質問があれば喜んでお答えします。
8. 質疑応答(前半):人間の役割とシステム最適化
8.1 人間中心データ管理と人間の役割
Angela: 素晴らしい講演をありがとうございました、Tova。データ管理がこれまで何を成し遂げてきたかという視点、そしてエージェンティックAIからの入力を私たちのあらゆる問題の中でどう考慮すべきかという視点、大変興味深く伺いました。私からも一点申し上げたいことがあり、それが質問にもつながります。人間の役割についてです。多くの場合、クラウドソーシングやデータ探索についても、その背後には人間がいます。一連のクエリがあり、それらはおそらく人間によって定式化される必要があります。LLMを使うとしても、どこかに人間が必要です。また申し上げておきたいのですが、SIGMODは数年前から、human centric data managementという新しい主要研究領域を実際に先駆けてきました。これには本日議論されたすべてのトピック、データ探索やクラウドソーシングなどが含まれます。そこで人間の役割は何でしょうか。
Tova: 現在の役割がどうなっているかはお伝えできますが、10年後にどうなっているかは予測できません。今日、そして昨日のキーノートでも見たように、人間はシステムを正しい方向に導き、時には多く、時には少なく制御するという役割を担っています。人間の入力やアイデアが多く入ってきています。それが今後も続くかどうかは分かりません。AIが世界を引き受けて、私たちはビーチに行って何もしなくてよくなる、楽しむだけになる、と言う人もいます。しかし、たとえそうなったとしても、最終的にはAIやマシンの出力は人間に提示されることになると思います。そして私たちは好奇心を持つ生き物ですから、なぜこの答えを得たのか、他のことをしていたらどうなっていたのか、これは信頼できるのか、といったことを理解したいと思うはずです。システムは「私を信じてください、大丈夫です」と言うことはできますが、私は誰も完全には信じません。ですから、私が申し上げた構造や正確性の保証、検証といったものは、すべて残り続けると思います。それらが内側にあるか外側にあるかは分かりませんが、私たちはそれらを必要とし続けるでしょう。ですからこれは不要になるものではなく、どの時点においてもそうはならないと思います。以上が、この質問に対する私の見解です。
8.2 エージェンティックワークロードと最適化技術の統合
質問者: 素晴らしい講演をありがとうございました。データシステムがエージェンティックなワークロードをより最適化された形でサポートするために、どう進化する必要があるかについて伺いたいです。これまで私たちはさまざまな種類のワークロードに対してデータシステムを最適化してきましたが、これは新しいワークロードです。例えば、同時実行クエリがより多くなるでしょう。どのような方向性を考えるべきでしょうか。
Tova: 昨日語られた賢明な指摘を繰り返すことになりますが、ワークロードははるかに大きくなると思います。人間が質問をする際には、ある意味で限界があります。考える速度、タイプする速度、システムで行うあらゆることの速度に制約されるからです。しかしLLMはすごい速さです。ですから、はるかに重いワークロードというのが差し迫った課題だと思います。それが私にとっての最優先事項だと言えるでしょう。
質問者(別の方): おはようございます。素晴らしい講演をありがとうございました。私の質問は、古い最適化技術をLLMに統合できれば、LLMはより優れた性能を発揮できると理解しています。では、もし誰かが何らかの最適化技術に取り組もうとするとき、その技術がLLMに容易に統合できるかどうかをどれくらい重視すべきでしょうか。もし容易に統合できないのであれば、それはあまり意味をなさない、あるいは受け入れられないものになってしまうのでしょうか。
Tova: それは難しい質問であり、非常に興味深い質問でもあります。すべてがLLMベースになる、あるいはなっていくと考えるべきなのか、私には分かりません。もしLLMがまだ征服していない応用分野を見つけられるのであれば、それに関連しない事柄に取り組むこともできるでしょう。ただ、5年後にはそれもLLMに取って代わられるだろうと私は予想します。ですから、あなたの研究をどれだけ長期的なものにしたいかによると思います。
9. 質疑応答(後半):検証・信頼・将来像
9.1 グラウンドトゥルースと責任の所在
質問者: 素晴らしい講演をありがとうございました、Tova。示唆に富むコメントの数々を残してくださったと思います。検証(validation)についてお話しされた点について質問があります。検証は推論などのプロセスに統合されるべきだという説得力のある主張をされたと思いますが、私が悩んでいるのは、今やグラウンドトゥルースというもの自体が非常に曖昧になっている、というよりグラウンドトゥルースが存在しないように思えるということです。決定論的なデータベースにおいてグラウンドトゥルースにたどり着く古典的な方法はもはや存在しないように見えます。では、グラウンドトゥルースが得にくい、あるいはもはや存在しないLLMの領域において、検証をどう行えばよいのでしょうか。それは常に確率的推論になるのでしょうか。そうであれば、私たちは決定論的なデータベースの結果を出すという古典的なやり方から離れつつあるのでしょうか。
Tova: 検証を2つの部分に分けて考えたいと思います。今日、LLMと仕事をするとき、多くの場合、LLMの一般知識と、私たちがグラウンドトゥルースとみなすデータセットの両方を使っています。これらは補完的なものです。グラウンドトゥルースとみなす部分、つまり自分たちが扱っているデータベースなどについての検証は、以前私たちが測定し実行していた検証と比較的近いものになると予想しています。一方で、一般知識、つまりLLMが訓練されたデータについては、おっしゃる通りだと思います。これは非常にノイズの多いグラウンドトゥルースです。私にとって検証とは、このノイズをユーザーに提示することを意味します。結果がデータ全体とどの程度整合しているのか、部分的にしか整合していないのか、どれくらい信頼できるのかをユーザーに伝えるということです。そして確率的な結果が、そこで役割を果たすようになる可能性は非常に高いでしょう。これが、私が考える2つのものの間の区別です。
質問者(別の方): ありがとうございます。もう一つ質問があるのですが、列に戻ろうと思います。あまり長居したくないので。
質問者(次の方): 今、マイクが動いているようですね、ありがとうございます。すべての洞察に感謝します。特に将来についてお話しされた最後の部分について伺いたいのですが、私が正しく理解していれば、そのアイデアは、私たちがこの数十年で生み出してきた文献と、それに伴うツールのすべてを、LLMに選択させ組み合わせさせて、データ管理の問題を解決させる、というものだったと思います。これは興味深い一方で、2つのシナリオがあると思います。一つは、私たちが不要になるというシナリオです。LLMが適切なツールを選び、昨日の講演を見ても分かるように、私たちの文献に基づいてさらに優れたツールを生み出すようになるかもしれません。もう一つは、完全に失敗するというシナリオです。ツールが何であるか、データ変換の効果が何であるかを理解できないからです。2つ目のシナリオについて伺いたいのですが、もしこの明るい未来を信じるとして、LLMにデータ管理ツールが何を意味し、何ができるのかをもう少し教える必要があるとすれば、この未来において想定される大きな課題は何でしょうか。
Tova: それは、LLMに何かを教えることと同じです。医学であれ、文学であれ、何であってもです。世の中には大量のくだらないものがあり、その一方で興味深いものもあります。少なくとも第一段階として私が考えるのは、LLMを助けること、つまりコミュニティを作り、ツールの断片やコミュニティの重要な側面を選び出し、そのインターフェースを記述する、あるいはLLMを使ってそのインターフェースを書くという作業を助けることです。これはオープンソースコミュニティに少し似ています。有用かもしれないものの仕様を書き、条件などを添えて、LLMがそれらの使い方を学ぶのを助けるということです。それが私の第一段階の考えです。次の段階では、LLMはもっと賢くなり、データ管理の講義を受けた学部生のようになって、自分たちである程度のことができるようになるかもしれません。最終的には不要になるかもしれません。それは分かりません。予測できる最良のものは過去だけです。未来を予測するのは少し難しいのです。分かりませんが、第一段階はやらなければなりません。それは私たちコミュニティとして重要なことだと思います。
質問者(別の方): ありがとうございます。素晴らしい講演をありがとうございました。前向きな精神をとても評価しています。教育への影響について伺いたいのですが、私たちは学生に古いテクニックを教え続けるべきなのでしょうか、それともデータベース、データベースシステムのカリキュラムを適応させる必要があるのでしょうか。今、何らかのトレンドを取り入れるべき部分はあるのでしょうか。
Tova: それは数学を教えるときと少し似ていると思います。電卓などがあっても、学生には数の掛け算や足し算のやり方を教え続けます。そうすれば、あとは自動化されたものを使えるようになります。データ管理を含むあらゆるトピックについても同じだと思います。基礎を教え、それから、より発展的な内容を教える必要があります。ですから、これは一種の組み合わせなのです。水が何であるかを少し教えないまま、泳がせるわけにはいきません。
質問者(別の方): こんにちは、素晴らしい講演をありがとうございました。エージェンティックなクラウドソーシングに向かっているというお話でしたが、LLMが生成したデータを訓練データセットに組み込んでいくにつれて、信頼をどう構築していくのでしょうか。人間によるクラウドソーシングでは非常に多様な視点がありますが、LLMは訓練データに偏っているように見え、それを続けていけばシステム全体にそれが伝播してしまいます。これに対してどう信頼を構築すればよいのでしょうか。
Tova: それも私たちのコミュニティでバイアスなどについて多くの研究がなされてきたトピックの一つです。一つの方向性は、これらの優れたアイデアをすべて取り入れて、LLMが生成したデータがバイアスを持っているケースを特定しようとすることだと思います。ここでもまた、コミュニティに優れたアイデアがあるトピックだと思います。そのまま使うことはできないでしょうが、何らかの適応を経る必要があり、私たちはその方法を知っています。ですから、私たちがこの種の問題に対処するのに最適な候補者だと思います。
質問者(別の方): 似たような流れで伺いたいのですが、もし何かがうまくいかなかった場合、今、誰を責めればよいのでしょうか。人間であれば、その人を見つければよいだけですが、エージェントやLLMに何かを教えている場合、何かが良くない、あるいは公正でないとき、誰を責めるべきなのでしょうか。教えた人でしょうか、推論したモデルでしょうか。このあたりも考えるべきことだと思います。
Tova: それは非常に良い質問です。ここでもまた、私たちのコミュニティはプロヴェナンスについて多くの研究をしてきており、問題の原因を追跡することはそれに関連していると思います。私に答えがあるわけではありませんが、そこからいくつかのアイデアや考え方が役立つと思います。ただ、これも素晴らしい研究テーマですので、誰かが取り組むべきだと思います。
9.2 データベースとLLMの主従関係
Natasha: Tova、素晴らしい講演をありがとうございます。この質問を組み立てるのに少し時間がかかりました、うまくいっているかどうか見てみたいと思います。ここには、データベースがいつの間にかLLMのアドバイザーになっているという認識があります。そういう認識を持っている人が実際にいるようなのですが、私は少し違う見方を提示したいと思います。ここ数年、データベースというのは真実を見つける場所であり、データベースがそう言っているのなら、それはそうである、というのが、それが持っているデータそのままにおいて成り立つ、という考え方があります。もしLLMがそう言っているのなら、私たちはそれが本当にそうであることを確認する必要があります。これはデータベースが持つ大きな力です。そしてLLMはRAGシステムを通じてデータベースを利用し、その信頼性を高めています。私が思うに、データベースが存在してから、私たちがあまり注意を払ってこなかったことの一つは、どうやってエンドユーザーにたどり着くか、どうすればもっと人間に近づけるか、ということです。私たちはそのためにSQLを使いました。それは明らかに正しいやり方ではありませんでした。しかしLLMは、自然言語を使うため、最初から人間に近い存在でした。ですから、私たちのコミュニティや他のコミュニティの多くの人々がtext to SQLを使っています。彼らはそれを実現しようとしています。そして私が思うに、これからの未来は、人間がLLMを使い、そのLLMがデータベースを使う、というものではなく、むしろ人間がtext to SQLを通じてデータベースを使い、そのデータベースが、データの豊かさのためにLLMを使う、というものになるのではないでしょうか。なぜなら、私たちを制約しているのは、アクセスできるデータからの閉世界仮説であり、それは決してすべてではないからです。このあたり、いかがでしょうか。
Tova: それは良い質問ですね。私たちがそちらのようになるのか、こちらのようになるのか。正直なところ、はっきりとは分かりません。ただ、正直に申し上げると、LLMにはできて、データベースにはできないことがたくさんあります。クエリ言語がSQLであろうと自然言語であろうと関係なく、です。例えば昨日見たようなことなど、私が知る限り、それができるデータベースはありません。ですから私はLLMに敬意を持っています。しかし、あなたのおっしゃったことは正しいです。データに関して言えば、少なくとも私たちの認識では、データベースの中にあるものは黄金であり、それ以外はもしかしたら黄金かもしれないし、偽物の黄金かもしれない、分からない、というのが真実です。そして私が思うに、これこそが構築されるべき、あるいは対処されるべき橋であり、そうすることで一方ではLLMの美しさと力をすべて活用でき、他方ではそれをデータに強く根ざすことができるのです。LLMがデータベースを使うのか、データベースがLLMを使うのか、私自身はどちらでもあまり気にしていません。それは統合の問題であり、私にとってアーキテクチャの問題ではありません。本当に問われるべきは原理の問題です。このハイブリッドな計算の根底にある原理とは何か、これがLLM自身にとっても、そして私たち自身にとっても解決すべきことなのです。良い説明とは何か、この設定において良い説明であるとはどういうことか、良い答えとはどういうことか、どうやって制限をかけて「これが私の答えです」と言えるのか。私が思うに、欠けているのはこうした明確で優れた基礎であり、それは私たちが定義の仕方を知っているタイプのものです。少しでも答えになっていれば幸いです。
質問者(別の方): こんにちは、探索的データ分析(EDA)を使ってグラウンディングのための証拠を生成するLLMの素晴らしい例をありがとうございました。とても興味深いのですが、それはLLMが自身の一般的な能力を使って探索的な計画を考え出すことを前提としているように思います。そこで伺いたいのですが、LLMの一般的な知性や能力を活用することと、厳密にグラウンディングされた回答との間の境界線を、私たちはどこに引けばよいのでしょうか。
Tova: それは私が答えを持っていない、とても良い質問です。常にその中間のどこかにあるのだと思います。今日私たちがどうやってこの講演を準備したかを考えてみてください。実際、良い例をお話しできます。私も他の皆さんと同じように、ChatGPTに相談しながら講演を準備しました。アーキテクチャの層ごとに構成するというアイデアを持っていました。それをLLMに渡したところ、驚いたことに、まったく好意的な反応ではありませんでした。それは良い提示の仕方ではない、問題ごとに構成すべきだ、と言われたのです。私はそれについて考え、それが正しいと思いました。そして最終的に、皆様がご覧になった通り、そのように構成しました。つまり、LLMがすべてをやったわけではありませんし、私がすべてをやったわけでもありません。一種の対話だったのです。私がアイデアを出し、いくつか返ってきて、それを改善する、というプロセスです。これが今日の私たちのLLMとの向き合い方だと思います。5年後には、私がここに立つ代わりに、私のホログラム、あるいはもっと感じの良い誰かが講演をしているかもしれません。分かりませんが、今のところはこれが現状です。
9.3 バイアス・UI・教育をめぐる議論
Norman: 最後の質問になりますが、Normanからです。ユーザーインターフェースのレベルについて質問があります。一部の人々は、大規模言語モデルの将来のユーザーインターフェースはテキストプロンプトだと言います。一方でデータベースコミュニティでは、良いクエリ言語には形式的な意味論があるクエリ言語を使ってきました。あなたは出力についても示されましたね、テキストであることが多いですが、もっと構造化された結果が欲しいという例も示されました。ユーザーインターフェースのレベルについて、お考えを伺えますか。
Tova: ユーザーは均一な分布に従っているわけではないと思います。つまり、さまざまなタイプのユーザーが存在するということです。テキストだけで作業できる人もいますし、今日ではそれすらなく、短い動画やTikTokのようなものを好む人もいます。そして、本当にグラフを見たい人、つまり私たちが呼ぶところの科学的あるいは数学的な形式で物事を見る方がずっと自然だと感じる人もいます。ですから、もし推測させていただくなら、将来的にはさまざまなユーザー向けに設計された多様なインターフェースが存在するようになり、自分に合ったものを選べるようになるのではないかと思います。それが私の予想です。10年後にまた会って、私が正しかったかどうか確認しましょう。
Norman: ありがとうございます。皆さん、聞いてくださってありがとうございました。
Tova: ありがとうございました。