※本記事は、Jan Van den Bussche氏(ハッセルト大学)によるPODS 2026基調講演「Models are data too: Towards expressive querying of machine-learning models」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=xA8_kvfJRKk でご覧いただけます。本記事では、講演および質疑応答の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. 開会・導入と「モデル」概念の整理
1.1 講演者紹介と講演テーマの提示
Geerts： 皆さん、これからPODSのプレナリー基調講演に移りたいと思います。本日の講演者はYan Van den Busscheさんです。この基調講演はPODS実行委員会によって選定されました。Yanのことは私自身よく存じ上げているのですが、それでも携帯電話の原稿を読み上げる形で紹介させていただきます。Yanはベルギー・ハッセルト大学のデータサイエンス研究所の教授で、1989年からデータベース理論の研究に従事しており、1993年にアントワープ大学で博士号を取得しています。彼はいわゆる「ベルギー学派」のデータベース理論を確立するのに貢献した一人であり、Jan Paredaens(既に退職)、Stijn Vansummeren、Frank Neven、Wim Martensをはじめ、私自身も含め、この学派に連なる研究者は少なくありません。YanはこれまでにICDTおよびPODSのプログラム委員長、ICDT評議会議長、PODS実行委員会議長、ジェネラルチェアを歴任し、ACMの特別会員(Distinguished Member)でもあります。彼の研究関心は、多様なデータおよび計算設定に対するデータモデルとクエリ言語の設計と解析にあります。個人的なことを申し上げますと、Yanは25年ほど前に私の博士課程の指導教員でした。信じがたいかもしれませんが本当です。そして彼から学んだ重要なことが少なくとも4つあります。第一に、問題を本質に到達するまで抽象化し、そこから初めて解決に取り組めるということ。第二に、物事を簡潔に書けるのであればそうすべきだということ、たとえそれが物事を単純に見せてしまうとしても、これは非常に重要な教訓です。第三に、カンファレンスのレセプションで食事にありつく確率を最大化するにはどこに立てばよいか、ということ。これはYanの身長のおかげでウェイターがどこから来るかを見渡せたので大いに役立ちました。そして最後に、おそらく最も重要なこととして、自分自身が本当に興味を持てる研究の方向性、そして分野に新しい問いを開くような方向性を追求すべきだということです。本日の基調講演はまさにその精神を体現するものです。Yanは、機械学習によって学習されたモデルを、表現力の高いデータベースクエリ言語を用いてデータのように管理・クエリする方法を探求するとともに、この分野で新たに浮かび上がりつつある研究課題を明らかにしてくれることと思います。それでは、Yan Van den Busscheさんをお迎えしましょう。
Van den Bussche： ご紹介いただきありがとうございます、Florisさん。本日お話ししたいのは、「モデルもまたデータである(models are data too)」という発想についてです。これは私自身のオリジナルのアイデアというわけではなく、多くの人が同じような考えを持っていることを最初にお断りしておきます。私はこの考えのもとで、機械学習モデルを表現力豊かにクエリするという概念を皆さんと一緒に検討していきたいと思います。ご存じの通り、私たちは現在機械学習の時代の只中にいて、機械学習モデルの洪水に直面しています。機械学習は科学、工学、社会一般において世界中で当たり前の存在になっており、世界中で何百万ものモデルが生成されています。これはただ人々が世界中のグローバルなリポジトリでモデルを共有しているというだけでなく、企業内やデータサイエンスの研究プロジェクトにおいても、大量のモデルが訓練され、テストされ、デプロイされ、アーカイブされているということです。本題に入る前に、皆さんにお願いしたいことがあります。私が「モデル」と言うとき、大規模言語モデルや生成AIのモデルをすぐに思い浮かべるのではなく、むしろ明確に限定されたタスクのために訓練されたモデルを念頭に置いていただきたいのです。もちろん現在はゼロショット学習の時代であり、こうした基盤モデルも限定されたタスクのために用いられていますが、従来型の手法で個別タスク向けに訓練されたモデルは今なお非常に重要であり、広く使われ続けています。それらは小さく、効率的で、信頼性が高いために人々に頼りにされているのであり、本日私が主にお話しするのはこの種のモデルです。こうしたモデルは重要な知識を凝縮しており、あらゆる場所に存在し、私たちにとって非常に価値のあるものですから、他の貴重なデータと同様にデータシステムの中で管理すべきだと考えています。そして、そもそも私たちがデータシステムを使う主な理由の一つは、強力なクエリ機能を持っているからだということには皆さんも同意していただけると思います。データベースシステムを使う中核的な目的の一つがクエリを可能にすることである以上、モデルをデータとみなすならば、私たちが普段データをクエリしているのと同様に、モデルもクエリできるべきだというのが論理的な帰結です。この「クエリする」とはそもそも何を意味するのか、これを皆さんと一緒に考えていきたいと思います。私がモデルのクエリについて人に話すと、必ず「それは具体的にどういう意味なのか」と聞かれるので、今日はそれを一緒に見ていきたいと思います。本日の講演の構成は次の通りです。まず少し歴史を振り返り、モデルのクエリに関する初期の経緯をお話しします。次に、モデルクエリのさまざまな側面についての簡単な分類(タクソノミー)を提示します。第三部では、私自身がこの分野で行った最近の研究にズームインします。そして最後に結論を述べます。
1.2 「モデル」という語の多義性
Van den Bussche： さて、まず少し話を戻したいと思います。最初に取り上げたいのは、私自身の一種のこだわりでもあるのですが、「モデル」という言葉は科学において最も過剰に使われている用語の一つだということです。この言葉が使われているいくつかの意味を順に見ていきましょう。例えば統計学では、「モデル」という言葉は、あるパラメータ化された確率分布のクラスによって母集団を数学的に記述するために使われます。これは本日私たちが使う意味ではありません。また、例えばコンピュータグラフィックスでは「3Dモデル」という全く異なる意味で使われます。これは基本的に単なるデータ構造にすぎません。私たちの分野に近いところでは、20年以上前にPhil Bernsteinが「モデル管理」という研究領域全体を立ち上げましたが、そこでの「モデル」とは実質的にデータベーススキーマを意味していました。そこでは人々はスキーマ間のマッピング、そのようなマッピングの合成、逆変換などに関心を持っていました。これも本日私たちが扱うものとは違います。また科学一般でよく耳にする意味として、ある問題に対する「モデル」とは基本的にその問題への解決策であり、多くの場合プログラムやコードとして実装されたものを指します。つまり「モデル」はプログラムコードという意味でもしばしば使われるのです。もちろん最初のスライドで申し上げた通り、本日私たちは、機械学習の手法によって学習された関数の表現としてモデルを捉えます。これが本日使う意味です。しかしまだ他にも意味があります。例えば数理論理学、これは私にとって身近で大切な分野ですが、そこでは「モデル」という言葉は単に関係構造、つまり(場合によっては無限の)データベースインスタンスを指す言葉としても使われます。これは興味深いことです、というのも私はモデルをデータとして見たい、言い換えれば「モデルをモデルとして見たい」からです。これは一種の駄洒落ですね。そして最後に、データベースの分野では「データモデル」という意味でも「モデル」という言葉を使います。データモデルとは何かというと、それはデータを論理的に整理するためのスキーマ言語とクエリ言語の設計のことです。これもまた「モデル」という言葉です。ここまでの整理で確認しておきたいのは、これらの意味のうちいくつかは本日の話には関係がありませんが、少なくとも4つか5つの意味は、実はすべて本日の話に関連してくるということです。もし言い換えるなら、私たちが本当に問いたいのは、モデルのための論理的なデータモデルを何らかの形で構築できるだろうか、ということなのです。
2. 歴史的背景:コードをクエリするという発想
2.1 Jim Grayの提起とStonebrakerの初期実装
Van den Bussche： 私は少し歴史を振り返ってみたいと思います。先ほど整理した「モデル」の意味のうち、4番目、すなわちプログラムコードとしての意味に沿ってお話ししたいと思います。ポインターを使わせていただきますね、後で必要になりますので。この4番目の意味について申し上げますと、実は20年以上前にJim Grayがすでにこの点を強調していました。例えば2005年に発表されたLowellのデータベース研究自己評価報告書から引用させていただきますと、これは文字通りの引用なのですが、私たちはコードをDBMSの第一級市民にしたいと望んでいる、と書かれています。当時Jim Grayがパネルの場で繰り返しこの点を強調していたことを、その場にいた方々は覚えていらっしゃると思います。正直に申し上げると、これは実際にはあまり実現しませんでした。私たちのコードリポジトリは今もデータシステムの中には入っていません。それでも私はこれを興味深く、面白いと思っています。同時に、さらに20年遡ってMichael Stonebrakerまで戻りますと、最初期のリレーショナルデータベースシステムの設計の中に、すでにコードが存在していました。1984年の「QUEL as a Data Type」という古い論文があります。この論文自体を読んでいただく必要はありません、単に例として示しているだけです。しかしそこには実際にそれがシステムの中にありました。これは初期のPostgresの設計に関するもので、QUELはそのクエリ言語だったのですが、その初期の設計の中で、すでにQUELはデータ型として扱われていたのです。つまり、例えば従業員テーブルの中にhobbies(趣味)という列を格納でき、そのタプルの内容がコードだったのです。ではデータベースシステムの中で最も重要なコードとは何でしょうか。それは私たちのクエリ式そのものです。それもまたコードなのです。つまりテーブルの中にコードがあったということです。そしてクエリの中では、そのコードを自動的に実行できました。列を取得する際に、その列を取り出すと、クエリが自動的に実行されるのです。これはすでに40年前に存在していたことであり、単なる歴史的背景としてお話ししました。
2.2 講演者自身の博士研究時代の経験
Van den Bussche： 私自身もかつては若かったわけでして、ここにご覧いただいているのは35年以上前の私の写真です。私はこの発想、つまりコードをクエリするという発想、データベースの中でクエリやクエリ式を管理するという発想に本当に触発されました。これは私の共同指導教員であったDirk Van Guchtとともに取り組んだものです。博士課程の間にもPODSの論文がいくつかありましたが、その後、博士課程修了後の若手研究者として最初に取り組んだテーマがこれでした。私が覚えている限り、これが博士号取得後最初のPODS論文だったと思います。そこで私たちが取り組んだのは、データベースの中にリレーショナル代数の式があるとき、それをリレーショナル代数自体を使ってどのように操作できるかを形式化することでした。私たちはこれを「reflective relational algebra(反射的関係代数)」と呼びました。さらにその後、私の最初の学生のうち2人、実際には3人になりますが、ここにいらっしゃるFrank Nevenと、Stijn Vansummeren、そして当時の私のもう一人のメンターであったGodfried Vossenとともに、この続きの研究にも取り組みました。ですから、これが私が今なおこのテーマに興奮している理由をよく説明していると思います。今日における新しい「コード」とは何かと言えば、それはまさにモデルなのです。そして私は今もこのモデルのクエリという発想に関心を持ち続けており、それこそがまさに私がこの場に立ってこの関心を再び呼び起こそうとしている理由なのです。
3. モデルクエリのタクソノミー(前半):管理的クエリと適用的クエリ
3.1 管理的クエリ(Administrative Querying)
Van den Bussche： それでは本題に取り組んでいきましょう。まずはタクソノミーの提示から始めたいと思います。あまり厳密に受け止めないでいただきたいのですが、これはモデルのクエリという言葉が何を意味するのかを理解する助けになると思います。私は4つのカテゴリーを設けました。管理的クエリ(administrative querying)、適用的クエリ(applicative querying)、行動的クエリ(behavioral querying)、そして最後にモデルの内部を見るクエリです。この4つが、本日皆さんと一緒に見ていきたいモデルクエリの分類です。まず管理的クエリから始めましょう。これは私たちがすでによく知っている領域です。大規模なデータサイエンスプロジェクトに携わる人々は、MLflowのような一般的なMLプラットフォームを日常的に利用しています。こうしたシステムは、モデルの追跡を助けてくれます。訓練データの追跡、モデルの追跡、いつデプロイしたか、いつ訓練したかといった日付やその他多くのメタデータを記録してくれます。これが私の言う「管理」です。自分の持ち物がどこにあるのかを把握しなければならず、そのための優れたプラットフォームはすでに存在しています。そしてこれを企業規模ではなく、いわば世界規模で見た場合、いわゆるモデル動物園(model zoo)と呼ばれるものがあります。人々が世界中でモデルを共有する場です。例えばHugging Faceはその中でも最も重要で最もよく知られた存在であり、何百万ものモデルを抱える公開リポジトリです。人によってはこれをモデルレイク(model lake)と呼ぶこともあります。少し格好をつけた言い方かもしれません。こうしたプラットフォームやモデル動物園も、ある種のクエリをサポートしていますが、そこでのクエリとは、属性に基づくフィルタリングによる検索として理解する必要があります。どのモデルをデプロイしたか、いつこのデータで訓練したモデルか、あるいはFlorisが開発したモデルはどれか、といったふうに、たくさんのメタデータが付与されており、それを取得できます。これは単純な検索とフィルタリングであり、期待通りの機能です。これが私の言う管理的モデルクエリです。これは何も問題がありません。私たちはこれをどうやればよいかよく知っています。興味深いことに、モデル動物園は機械学習コミュニティにおいても取り上げられていて、彼ら独自の視点でこれを捉えています。私たちのモットーは「モデルもデータである」ですが、機械学習コミュニティもこれを真剣に受け止めています。ただし彼らは自分たち独自の視点からこれにアプローチしています。ここで一つ簡単な補足をしたいと思います。1枚だけスライドがあるのですが、興味深いと思うので触れておきます。機械学習コミュニティには「モデルアトラス(model atlas)」と呼ばれるものがあります。これはIlia Horvitzのウェブサイトから取った画像なのですが、彼は膨大なモデルのグラフを可視化しようとしています。見えている点の一つひとつがモデル全体、それも大規模言語モデルのような大きなモデル全体を表しています。人々はこれを画像認識モデルなど他のモデルにも応用しています。点の一つひとつがモデルであり、点と点の間にはエッジが存在します。これは例えばモデルの重み間の距離に基づいて決められています。すべてのモデルは基本的に一つの巨大な重みベクトルとして扱われ、それが管理されています。機械学習の人々が典型的に関心を持っているのは、この中で構造的パターンをマイニングしたり、重みに基づいてモデルの性質を予測したりすることです。例えばこのモデルが過剰特化(over-specialize)しないかどうかを予測できるか、といったことです。さらに驚くべきことに、彼らはこのデータの上でモデルを訓練することさえしています。データポイント自体がモデルであるようなデータの上で、モデルを訓練するのです。そしてついには生成モデルまで持っています。つまりゼロショット学習の延長線上のような発想で、いくつかの例を与えるだけで、基盤モデルからではなく、これら多数のモデルから直接訓練されたモデルを生成できるのです。これは機械学習の人々がこの問題をどう捉えているかを示すもので、私自身これを知ったときに非常に興奮したので、皆さんにも紹介したいと思いました。
3.2 適用的クエリ(Applicative Querying)
Van den Bussche： さて、本筋に戻りましょう。タクソノミーの話をしていました。管理的クエリについてお話ししましたので、次は適用的クエリに移ります。適用的クエリとは、まさにコードをデータ型として扱うという発想を、今度はクエリ式ではなくモデルに適用したものです。基本的な考え方は、クエリの中からモデルを呼び出せるということです。これも現在多くの注目を集めている領域であり、私はこれを適用的モデルクエリと呼んでいます。ちなみに、モデルをデータベースの中で管理すること、それを呼び出すことだけでなく、訓練すること、そしてそれをクエリに統合することは、私たちのコミュニティがすでにかなり以前から関心を持ってきたテーマでもあります。例えば、本会議でちょうど10周年を迎える「Data Management for End-to-End Machine Learning」というワークショップがあります。こうしたシステムが実現しているのは、データベースの内部でモデルを呼び出すことです。時にはモデルの推論そのものをSQLにコンパイルすることさえあります。また、テンソルエンジンによる計算グラフを利用してこのSQLを実行する場合もあります。このように、この領域では実に多くの研究が行われています。ここで私が触れているのは、モデルの推論をSQLにコンパイルするという話です。多くの場合行われているのは、特定のモデルを取り上げて、それを推論のための特定のSQL式にコンパイルするというやり方です。しかし実はもう一つ別のアプローチがあります。それは私が「一様なアプローチ(uniform approach)」と呼んでいるもので、推論を一様にSQLで表現できるというものです。これがどういう意味か、もう少し詳しく説明したいと思います。というのも、これは後ほどより詳しく説明する内容につながっているからです。例えば、隠れ層を一つ持つ非常に単純なニューラルネットワークがあるとします。人々が行っているのは、重みをテーブルに格納するということです。重みとネットワークのトポロジーを、すべての重みとともにテーブルに格納します。そうするとモデルは他のデータと一緒にデータベースの中に存在することになり、それに対して簡単に行えること、そしてこれは実はSQLで非常に容易に表現でき、そのまま動作するのですが、モデルの束をデータベースに格納し、入力の束もデータベースに格納できます。多くのこうしたテーブルがあり、あるテーブルにはモデルが、あるテーブルにはデータが入っています。そして推論を行うことは、単にSQLクエリを実行するだけであり、それほど複雑なものではありません。層の数が分かっていれば単純なクエリで済みますし、層の数が分からない場合には、私がお見せしたように再帰的なSQLを使うこともできます。私たちは、そして他の研究者による論文でも指摘されていますが、これが実際にかなりうまく機能することに気づきました。昨年のPODS、正確には昨年のSIGMODでベルリンで開催された会議において、Alsatianという非常に興味深いシステムが発表されました。これはまさに、データベースに格納された多数のモデルを、データベースに格納された多数のデータに対して大規模に実行するというタスクに対して、最適化手法と実行実装戦略を導入したものです。ここでもすでに活発な活動があり、これはクエリ処理の改善や拡張によって支えられています。ですから、タクソノミーの最初の2つの階層、すなわち管理的クエリと適用的クエリについては、よく理解が進んでおり、多くのシステム構築の取り組みが進行していると言えると思います。私たちはデータベースコミュニティとして、この部分についてはきちんと仕事をしていると言えるでしょう。
4. モデルクエリのタクソノミー(後半):行動的クエリとモデル内部を見るクエリ
4.1 行動的クエリ(Behavioral Querying)
Van den Bussche： それでは、タクソノミーの第三の階層、行動的クエリに移りたいと思います。ここでは、もう少し高次のクエリ、と言ってよいものを扱います。私たちはもはや単にモデルをデータに対して呼び出す、つまり推論を行うということだけでなく、このモデルの意味論そのものを本当に検査したいのです。機械学習モデルというのは結局のところ、データから学習された関数を表現しているものです。ここでは単純化のために、それをd次元ベクトルからp次元ベクトルへの数値関数だと考えましょう。dは入力次元、pは出力次元です。例えば、この関数について問える質問の一つに、ロバスト性(robustness)として知られる性質があります。ある入力があったときに、それに近いすべての入力が似たような出力を持つかどうかを知りたい、というものです。つまり、xがaに近ければ、f(x)はf(a)に近いはずだ、という性質です。これはモデルにとって成り立つかもしれないし、成り立たないかもしれない性質であり、いわばイエス・ノーのクエリです。多くの方がご存じかと思いますが、このロバスト性という概念は、およそ15年前のある論文がきっかけで注目されるようになりました。その論文で人々は、初期の画像認識モデルが全くロバストでないことに気づきました。例えば、スクールバスの画像に非常に近い入力を与えると、その近い画像が突然「オーストリッチ」として分類されてしまう、という現象が観察されたのです。これは明らかにロバストではありません。ロバスト性の反例です。そして、原著者たちはこうした性質を「興味深い性質(intriguing properties)」と呼びました。ニューラルネットワークのこうした性質が明らかになると、人々はモデルについて尋ねたりチェックしたりできる他の性質についても考え始めました。そうした性質は数多くあります。ロバスト性についてはお話ししましたが、もう一つ非常によく知られている性質として、説明可能AI(explainable AI)の分野で人気のある反実仮想説明(counterfactual explanations)があります。ある入力aとその出力f(a)があるとき、aにできるだけ近く、かつ異なる出力を持つxが存在するかどうかを知りたい、というものです。今度は不等号の向きを反転させているわけです。これは、aがなぜその出力を持つのかについて、ある種の説明を与えてくれます。というのも、あまり離れていないxが異なる出力を持つのであれば、そのxとaを比較することで、モデルが何をしているのかについての理解が得られるかもしれないからです。他にも性質があります。例えば、モデルにある種の安全性のしきい値を設定しているとしましょう。モデルがある閾値を超えてほしくない場合、f(x)は常に120未満でなければならない、といった性質です。これも適当な例ですが、これもモデルについて真か偽かを知りたい性質、つまりクエリです。それから単調性(monotonicity)です。例えば非常に単純な1次元関数があるとき、データから学習されたこのモデルが表現する関数が実際に単調であるかどうかをチェックしたい、ということもあるでしょう。最後にもう一つ、感度(sensitivity)についての例です。二つの入力を持つ非常に単純な関数を考えてみましょう。もしこの性質が真であれば、実際には第二引数は関数にとって全く関係がないということになります。第一引数さえ同じであれば、f(x, y)とf(x)は近い値になる、というものです。これもチェックしたい性質の一つです。このように、性質のリストは無限に挙げることができます。人々はこうした問題に取り組んできましたが、それはデータベースの分野ではなく、ニューラルネットワーク検証(neural network verification)という分野で行われてきました。そこには活発なコミュニティが存在し、主にロバスト性に焦点を当てていますが、他の性質についても検討が進められています。しかし私たちのモットーは「モデルもデータである」ということです。つまり私が申し上げたいのは、モデルがデータシステムの中に存在するようになったとき、これを全く別の切り離された検証作業に任せきりにすべきではない、ということです。これらは単に、私たちがすでに慣れ親しんでいる分析的な決定支援クエリ、複雑なデータに関する複雑なクエリと同じように、分析的なクエリになるだけなのです。通常の分析クエリとそれほど違いはないと言えると思います。仮に私の「モデルをデータシステムの中で管理し、モデルもデータである」という提案を受け入れないとしても、モデルの振る舞いをクエリするということ自体には興味を持っていただけるはずです。というのも、簡単な例を考えてみましょう。あるデータで訓練された分類器モデルがあるとして、これがある顧客のプロファイルに対してローンを承認すべきかどうかを分類するとします。これは古典的な機械学習の例です。この分類器を訓練データで訓練し、その後、他の入力に適用していくと、与えたそれぞれの入力に対して真か偽かの答えが返ってきます。つまりこれは基本的に無限のテーブルなのです。真と分類されるすべての入力ベクトルからなるテーブルであり、無限のテーブルです。d列を持つ単なるリレーションです。もう一つ例を挙げますと、ソーシャルネットワークのリンク予測を考えてみましょう。話を単純にするため、ネットワークの各ノードが4次元のベクトルで表現されているとしましょう。すると、リンク予測を行う分類器は二つのノード、つまり8次元のベクトルを受け取り、0か1を出力します。リンクがあるべきかないべきかを判定するわけです。この例ではdは8になります。そしてこれもまた無限のテーブルです。これをあたかも有限のテーブルであるかのようにクエリしてはいけない理由はありません。例えば、二つのノードAとBが与えられたとき、一つの中間ホップを経由してAとBがつながっているかどうかを確認したいとしましょう。これは古典的な、共通の友人を介してAとBがつながっているかというクエリであり、この無限のテーブルに対する単純な自己結合にすぎません。AからXへ、そしてXからBへ到達できるようなXが存在するか、という非常に単純な連言クエリです。このように、データベースの観点から考えると、モデルの振る舞いをクエリするという発想は非常に自然に出てくるものだと思います。これが行動的クエリです。私が言いたいことがある程度伝わっていればよいのですが。
4.2 モデル内部を見るクエリと4分類のまとめ
Van den Bussche： タクソノミーにはもう一つカテゴリーがあります。ちなみに、これらのカテゴリーは厳密に段階的に増加していくものではありません。一般的には、この4つのカテゴリーすべてを組み合わせたクエリも考えられます。しかし最後のカテゴリーは、モデルの内部を実際に見てみたい、というものです。ここまで行動的クエリとしてお話しした性質は、機械学習では「モデル非依存(model agnostic)」として知られているものばかりでした。つまり、モデルを単に関数の表現として見て、その関数についての質問をしているだけです。しかし時には、その表現の内部を本当に見てみたいことがあります。モデルの内部を見るのです。例えば、人々はニューラルネットワークの枝刈り(pruning)を行います。モデルの中に無用な結合や、無用な層、無用なニューロンがあるかどうかを知りたいのです。ある意味でこれも複雑なデータベースクエリと言えます。モデルがデータであるならば、これも単なるクエリの一つにすぎません。この訓練データに対して、あるいは一般的に、無用なニューロンを教えてほしい、というクエリです。同様に、機械学習における行列、重み行列に対する基本的な操作、例えば逆伝播(back propagation)の操作もまたクエリです。実際にこれを行っている研究があり、私たちのコミュニティでもデータベースシステムの内部で逆伝播を行う研究がなされてきました。先ほどモデルアトラスについて触れましたが、あの巨大なグラフでは各点がモデルを表しているのでした。例えば、二つのノード、二つの点の間にエッジがあるべきかどうかを、重み間の距離などに基づいて判定する場合、これもモデルの内部、つまり重みを見なければなりません。先ほど、機械学習の分野ではこのモデル動物園、モデルグラフに対するデータマイニング的なクエリへの関心があると申し上げましたが、こうしたものも典型的にはモデルの内部、例えば重みの中にどのような構造が存在するかを判定するために内部を見る必要があるものです。これが最後のカテゴリーであり、先ほども申し上げた通り、これらのカテゴリーは典型的にはお互いに流れ込み合うものです。つまり実際のクエリは、これら4つすべての側面を併せ持つこともあり得るのです。これでタクソノミーの説明は締めくくりということになりますが、ここまでのメッセージ、少なくとも私自身の見方を申し上げますと、最初の2つのカテゴリーについては、データベースの観点から見て多くの研究が存在しています。しかし後半の2つのカテゴリーについては、私たちの観点からの研究がはるかに少ないのが実情です。ここには大きな可能性があると思います。ここに小さなアスタリスクを付けたのは、少なくとも私が知る限り、行動的クエリやモデル内部を見るクエリに関する研究論文が非常に少ないからです。数少ない例外の一つが、Arenasらによる、ブール型モデルを対象とした研究です。これは脚注どころではなく、それ自体が基調講演に値する内容であり、実際に2年前のPODSの基調講演はMarcelo Arenasによってまさにその研究について行われました。ですのでその話はそちらに譲り、本日は取り上げません。現時点でPODSコミュニティにおいてはこれが数少ない論文の一つだと思いますが、SIGMODとPODSがここで力を合わせて取り組むべきだと思います。モデルをデータとして扱い、その行動的クエリやモデル内部を見るクエリを支援していくべきだということです。このタクソノミーの説明の後、私自身がこの分野で行った研究についても、少し時間を取ってご紹介したいと思います。
5. 自身の研究:SQLによるニューラルネットワーク検証(理論)
5.1 ベンチマーク論理と計算可能性
Van den Bussche： これまでのタクソノミーの説明を踏まえて、私たち自身がこの分野で行った研究の一部をご紹介したいと思います。これを一言でまとめると、「SQLはニューラルネットワークを検証できる」ということになります。これは昨年得られた成果ですが、ここでも非常に高いレベルでの説明を試みたいと思います。まず、私が「ベンチマーク論理(benchmark logic)」と呼んでいるものを導入したいと思います。これは関数についての性質を表現するためのクエリ言語です。この論理は「線形算術と関数記号を伴う実数上の一階述語論理(first order logic over the reals with linear arithmetic and a function symbol)」と呼ばれます。長い名前ですが、実際にはとても単純なものです。これは、SMTソルビングやSATソルビングでよく使われる線形実数算術制約から構成される論理です。そこに関数記号を一つ加えます。これが私たちが話題にしたい関数記号です。それに加えて論理演算子、すなわちand、or、notを持ちます。そして量化子も持ちます。ただし注意していただきたいのは、この量化子は数値の入力にわたるということです。任意の数値入力について語りたいので、この量化子は実数全体、あるいは有理数全体にわたるものだと考えてください。この論理の具体例については、実はすでにお示ししています。行動的クエリのところで挙げた性質の例は、すべてこのベンチマーク論理で書かれた式の例だったのです。ご覧の通り、私はここで論理結合子、線形算術、そして話題にしている関数記号、そして量化子を持っています。このように、私たちはもはや検証したい性質を4つ、5つ、6つに絞り込む必要はなく、多くの望ましい性質を表現できる一般的な論理を手にしたことになります。これを私は「ブラックボックス論理(blackbox logic)」と呼んでいます。なぜなら、そこにあるのは関数記号fだけで、それはブラックボックスだからです。しかし、あらゆる可能な入力について量化できるので、いくらでもそれをクエリして多くの性質を表現できます。だからこそブラックボックス論理と呼んでいるのです。これがベンチマーク論理です。これを最初から実際のクエリ言語として提案したいわけではありません。それができれば素晴らしいのですが、いくつか注意点があります。少し説明させてください、何が可能で何が可能でないかについてです。原理的には、このブラックボックス論理は実効的(effective)です。つまり、原理的にはこれを使って関数をクエリすることができます。もちろんこれは、関数自体が線形実数算術で定義可能であることを前提としています。そしてブラックボックスのクエリがあれば、その答えを実効的に計算できます。これは線形実数算術の制約充足問題に帰着させることができ、これは原理的には可能であり、実際にZ3のような非常に有名なSMTソルバーにも実装されています。例えば、ReLU活性化を持つフィードフォワード型ニューラルネットワークに興味がある場合、そうしたネットワークが表現する関数は線形実数算術で定義可能ですので、この文脈にも適用できます。つまり原理的にはブラックボックスクエリは計算可能なのです。しかしここには注意点があります。まず複雑性の問題です。ReLU活性化を使うと、これは基本的に何かが正であるかどうかを判定して二つの異なる処理を行うものですが、これをブラックボックス論理で表現しようとすると、二つのケースが生じ、ネストした値がある場合には式が爆発的に増大し、非常に大きな式になってしまいます。人々はこのことを認識しており、線形実数算術ソルビングのコミュニティでは、線形計画法の実行可能性判定とほとんど同じ問題に近いアルゴリズムを持っています。例えばこの分野で非常に有名なGuy Katzは、このReLUの問題に対処するためにシンプレックス法を適応させたアルゴリズムを開発し、それをReluplexと呼びました。これはZ3のようなSMTソルバーに実装されている非常に有名なシステムです。しかしそれでも、これはおそらく存在量化子のみに対してのことです。いくつか改善はあるものの、ReLUがなかったとしても、一般的には存在量化子と全称量化子が任意に交代するブラックボックス論理を解くことは、本質的に指数時間問題のままです。ですから一般には、これは大きな注意点となります。しかし私たちはこうした注意点に怯まず、それでもこのブラックボックス論理で原理的に何が可能かを理解したいと考えました。
5.2 主要な理論的成果と証明の概要
Van den Bussche： そこで、先ほど申し上げた通り、モデルをデータベースに格納することにします。テーブルに格納するのです。重みだけをテーブルに格納します。結局のところ、フィードフォワードニューラルネットワークとは単に行列の有限の列にすぎません。行列はデータベースに簡単に格納できます。行、列、重みというリレーションに格納すればよいのです。行列をテーブルに格納するわけです。そしてこれによってSQLを使えるようになります。モデルは単なるテーブルであり、それをクエリしたいので、SQLを使うことができます。私たちの問いは、このブラックボックス論理が、いわば「ホワイトボックス論理」と呼べるSQLとどう関係するか、というものでした。なぜホワイトボックスかと言えば、モデルはあなたの目の前にあり、すべての重み、すべての結合がテーブルに格納されているからです。これは全くブラックボックスな論理ではなく、ホワイトボックスな論理なのです。そして私たちはSQLをよく知っています。ではこの二つの論理はどう関係するのでしょうか。私たちの主結果は、昨年国際データベース理論会議(ICDT)で発表したものですが、こうしたフィードフォワードニューラルネットワークに対するあらゆるブラックボックスクエリが、実際にSQLで表現できる、というものです。つまりSQLはニューラルネットワークを検証できるのです。ここで一つ注意点があります。私たちはニューラルネットワークの深さ、すなわち層の数が固定されていることを仮定しています。ただし各層のサイズについては全く仮定していません。つまり、どの層にもいくらでも多くの隠れユニットを持たせることができます。ここで言うSQLとは何を意味するかですが、もちろんSQLは大きな言語ですので、私が本当に意味しているのは、集約と算術演算、初等的な算術演算を伴う関係代数だけです。それだけで十分なのです。これは、少なくとも原理的にはニューラルネットワークの複雑な性質検証をSQLがサポートできることを示す、良い結果だと思っています。それがメッセージです。それではどのようにこれを証明したかについて、ごく簡単にお話ししたいと思います。これは実は非常に興味深いと思っていますし、また私自身の若い頃の研究とも関連しているからです。関係代数の式を関係の中に符号化し、reflective relational algebraの中で何ができるかを見ていた頃の経験と、非常に似たことがここでも起きています。私たちは、線形実数算術の制約、すなわち論理式を関係の中に符号化するために関係を使うのです。そしてそれをSQLで操作します。それが基本的な発想です。証明には主に3つのステップがあります。非常に高いレベルの説明ですのでご心配なく。まず、ネットワークを含む関係があるとします。通常は複数の関係になりますが、ここでは一つの関係Mと呼びましょう。最初に理解しなければならないのは、このニューラルネットワークの中の各ユニットが、区分線形関数(piecewise linear function)を表しているということです。区分線形関数とは何かというと、基本的にこの線形実数算術で定義可能な関数です。そして私たちは、データベースの中にあるモデル、それがどんなものかは分からなくても、この関数を定義する論理式を実際に符号化することができます。これを関係として符号化し、SQLのビューとして定義できるのです。つまり、この区分線形関数を定義する制約を、関係として符号化された形で取得できるわけです。次に行うべきことは、ブラックボックスクエリがあったとして、これをSQLにコンパイルしたいわけですが、そのブラックボックスクエリには呼び出しのようなものが含まれていますが、これらは変数に対する呼び出しであり、実際の呼び出しではありません。変数vやuを含むアトムが含まれているのです。ですから今行うべきことは、この符号化の中に入り込み、それらのアトムを、線形実数算術制約の実際の表現、つまり私のSQLビューの結果に置き換えることです。そして最終的には、量化された線形実数算術の論理式の表現が得られます。この種の量化された制約を解くための非常に有名なアルゴリズムがFerrante–Rackoffアルゴリズムです。これは古典的なアルゴリズムであり、もうかなり以前から存在しています。そして実際に、このアルゴリズムを完全にSQLの中でシミュレートできることを確認しました。これが基本的な証明の流れです。ここでいくつかコメントを述べたいと思います。一つの小さなコメントは、私たちがモデルと論理式を関係構造の中に符号化しているという点です。これは私自身、ある意味で非常に興味深いと思っています。私たちは数理論理学における「ある構造を別の構造の中に解釈する(interpreting one structure in another)」という技法を拡張し、それをSQLに適応させたのです。この技法は数理論理学の中でモデル理論(model theory)と呼ばれる分野に属します。つまりこれは、モデル理論についてのモデル理論、いわば「モデル理論の二乗」だと言えるわけです。この駄洒落は我慢できませんでした。
6. 実用化への課題と展望、結論
6.1 実用化への課題と展望
Van den Bussche： さて、これが実際に実用上機能するかどうかを、皆さんは当然お尋ねになると思います。答えはノーです。正直に申し上げると、この分野に関してシステム面の研究はほとんど行われていません。これはあくまで原理的な問いなのです。しかし、可能性の一端をお見せしたいと思います。理論的な構成は、当然のことながら、途方もなく巨大なSQL式を生成してしまいます。とはいえ、ここには多くの機会があると思っています。その中の一つとして簡単にご説明したいのが、モデルを単に重み行列としてテーブルに格納しなければならないわけではない、という発想です。データシステムの中で、モデルをもっと巧妙に表現することができるのです。例えば、先ほどの区分線形関数のビューについて言えば、これをもっと使い勝手のよい形式で実体化(materialize)することができます。結局のところ、区分線形関数とは基本的にポリトープ(多面体)上の単純な算術関数にすぎません。つまり、空間はポリトープに分割されており、それぞれのポリトープ上では非常に単純な線形関数になっているのです。ですから私たちはこれを活用し、計算幾何学(computational geometry)のアルゴリズムを使って、それをクエリ処理系に統合することができるはずです。これは十分に実現可能で、実行可能なことだと思います。調査する価値があります。これを1次元の場合で説明できます、というのもこれは非常に単純だからです。この場合はそのままうまくいきます。非常に単純だからそのままうまくいくのです。もちろん1次元関数、つまり実数から実数への1入力1出力の関数であれば、非常に単純です。そうすると区分線形関数は、まさにこのような、区分的に線形な関数のように見えます。そしてこの重み行列から、非常に簡単なSQLクエリによって、こうした各区分の折れ点(break point)と傾き(slope)をすべて容易に取得できます。これは非常に単純であり、そのままうまく機能し、こうした単純なネットワークの場合には効率よく動作します。そして、これによってさまざまな検証を行うことができます。例えば、関数が単調(monotone)かどうかを確認したい場合、この折れ点と傾きのビューに対する非常に単純なクエリで済みます。些細なSQLです。もう一つの例は有界性(boundedness)という性質です。私の関数がある一定の範囲内に収まっているか、安全かどうか、閾値の範囲内にあるかどうかを確認したい場合も、それほど複雑ではない決定支援クエリで済みます。もちろん、繰り返しになりますが、これは非常に単純なケースですが、ここに大きな可能性があることを示していると思います。
6.2 結論
Van den Bussche： さて、そろそろ結論に入ります。私は本日、新しい種類の複雑な分析的クエリのクラスを皆さんにご紹介しました。ここには多くの課題、多くの未解決の問題があります。良いアルゴリズムを設計しなければなりませんし、クエリ言語を設計しなければなりません。しかし何より、システム面の仕事、つまり良い実装戦略について考えなければなりません。もちろん、他のモデルクラス、例えばTransformerアーキテクチャなどにも目を向けるべきなのは明らかです。表現力についても考えることができます。つまりどのようなクエリを実際に表現できて、どのようなクエリは表現できないのか、ということです。これはまさにPODSで私たちが普段行っていることであり、自分たちの言語の力を理解したいということです。そしてこれは実は、今世紀の変わり目あたりに非常に活発だった分野、すなわち制約クエリ言語(constraint query languages)という、この種の無限のテーブルをクエリすることに関する分野に話がつながります。それが今、この機械学習の文脈の中で戻ってきているのがお分かりいただけると思います。ですから、当時の技術を見直す価値は十分にあると思います。というのも、その種の研究はこれといった理由もなく突然止まってしまったからです。ご存じの通り、研究には流行があります。5年経つと突然みんな別のことを始めるのです。だからといって、すべてが解決されたわけでは全くありません。ですから、この文脈でそれを見直すことには確かに価値があると思います。そしてもちろん、クエリ処理と最適化の課題もあります。最後に、私が最初にお話ししたビジョンに立ち返って締めくくりたいと思います。Jim Grayのこの夢、コードをクエリし、データベースの中でコードを管理するというこの夢を、私たちはもう一度復活させられるかもしれません。これは今も非常に自然な発想だと思っています。例えば、ソフトウェア工学のコミュニティでは、コードをクエリすることに関心を持つ人々がいて、彼らは彼ら自身のアプローチを持っています。しかし彼らは本当に私たちの助けを必要としているのです。というのも、彼らはクエリシステムの設計の仕方をあまりよく分かっていないのに対し、私たちはそれをどうすればよいか完璧に理解しているからです。以上で講演を締めくくらせていただきます。ご清聴ありがとうございました。
7. 質疑応答
7.1 応用面に関する質問
Geerts： Yan、素晴らしい基調講演をありがとうございました。ご質問がある方は、廊下にあるマイクをお使いください。それでは質問を受け付けたいと思います。
質問者1： こんにちは。素晴らしい講演をありがとうございました。大規模言語モデルや基盤モデルの推論について、多くの研究や競争が行われていますが、こうした実行エンジンを置き換えられるようなデータベース管理システムを構築できると思いますか。より効率的で、安価で、高速なものを。
Van den Bussche： 大規模言語モデルについておっしゃっているのですね。もし単純にデータシステムの中での推論についておっしゃっているのであれば、それは適用的モデルクエリのカテゴリーに属する話だと思います。すでにかなり活発な取り組みがあり、この会場にも私よりずっとそのことに詳しい方が大勢いらっしゃると思います。すでにその方面での活動はたくさんあります。
質問者1： つまり、誰かが推論を行いたいときの第一の選択肢になり得るとお考えですか。
Van den Bussche： うーん、私は数年後にシステムが実際にどうなっているか、その課題に応えられるかどうかを予測できる立場にはありません。ただ、確実に人々はそれを望んでいますし、そのために取り組んでいます。実際、ちょうど昨日、少し違う話ではありますが関連する話として、Yannis Papakonstantinouもまさにそうした取り組みについて主張していました。ですから人々はそこに非常に関心を持っています。しかし私はどちらかというと理論家なので、5年後にシステムがこれを解決するかどうかを断言できる立場にはありません。分かりません。ただ、人々は非常に関心を持っていることは確かです。
質問者2： こんにちは。私の質問はこうです、聞こえていますか。機械学習において、モデルは通常テンソルとして保存され、推論や訓練時に行う演算のほとんどは、テンソルの形の方がずっと簡単で速く行えます。もしデータをリレーショナルデータベースやテーブル形式のデータとして保存すると、まず一つ目の問題として、演算がそれほど速くならないのではないかということ、そして二つ目の問題として、単に答えを保存するのではなく、行や列に関する追加情報、つまりこの重みがどの層に属するかといった情報も保存しなければならなくなり、スケーラビリティの点で問題になるのではないでしょうか。
Van den Bussche： はい、もし私が正しく理解しているなら、あなたのご質問は、SQLシステムのアーキテクチャと、TensorFlowやONNXなどで使われる計算グラフのアーキテクチャをどう橋渡しするか、ということですね。これについては人々が非常に活発に取り組んでおり、実際その架け橋を作ろうとしています。そして確かに類似点は明らかです。両者ともクエリプランを基本的に使いますし、両者とも最適化を行います。私はこの二つが結婚できるし、実際にすでに結婚しつつあると思っています。実際のシステムの中で、すでにそうした統合が進んでいるのです。
質問者3： 発表ありがとうございました。重みとバイアスをデータベースに格納するというのは私にとって理にかなっていますし、データベースコミュニティにとっても興味深いことだと思います。新しくやるべきことができますね。私の質問は、データベースコミュニティの外側にインパクトを与えるための次のステップは何か、ということです。単にクエリするだけでは私たちは満足しますが、そうではなくて、クエリ言語がうまく機能すると仮定した場合、機械学習モデルをより良くするために何ができるか考えたことはありますか。つまり、最終的には何かを分類したいわけで、クエリできるかどうかを見たい、どの重みがうまく機能しないか、どちらの方法が良いか、ドロップアウトはあなたのクエリ言語と組み合わせた方が良いのか、推論をより良くできるか、モデルをより小さく、よりコンパクトにできるか、そうすればより小さなモデルになり、大きなモデルも私たちのマシンに収まるようになる、といったことです。データベースコミュニティへのインパクトではなく、機械学習コミュニティへのインパクト、つまり私たちのクエリ言語が彼らに何を与え、機械学習モデルをどうより良く、より効率的に、より頑健に、より洞察力のあるものにできるか、そういったことを考えたことはありますか。
Van den Bussche： はい、それがまさにビジョンだと思います。これは私たち自身のためだけではありません。機械学習モデルを検証可能にし、そして改善可能にすることです。もし私たちのツールが訓練されたモデルを検証するために使われ、そして間違いなく時にはそのモデルが私たちの望む制約を満たさないことが分かれば、それがフィードバックになるわけです。
質問者3： それがうまくいくことを示す具体例はすでにありますか、それとも今はまだ始まりの段階ですか。
Van den Bussche： いや、これはまだ非常に初期の段階です。
Geerts： つまりこれは歴史的な瞬間というわけですね。
Van den Bussche： はい、正直にそう申し上げています。
質問者8： 発表ありがとうございました。転移学習に興味があります。というのも、モデル動物園というのは事前訓練済みモデルのリポジトリですが、モデルレイクの中にはデータセットもあれば訓練済みモデルもたくさんある、ということですね。しかし多くの場合、モデルを持つ理由は転移学習をしたいからです。例えば新しいデータセットがあるとき、どの事前訓練済みモデルをファインチューニングすべきかを知りたいわけです。そこで私の質問は、こうしたことを考えたことがあるかということです。つまり、異なるモデルをこの言語で表現することで、どの二つのモデルが転移学習にとってより似ているかを言えるような言語を開発するといったことです。機械学習では単に転移スコアを計算するだけですので。
Van den Bussche： ええ、それは興味深い提案ですね。もし言い換えさせていただくなら、あなたが提案しているのは、転移学習を導くための宣言的な言語だということですね。まだそこにない性質を与えて、モデルを何らかの形で変形できるようにする、ということですね。
質問者8： はい。
Van den Bussche： ええ、それは非常に興味深い提案です。ありがとうございます。
7.2 理論面・その他の質問
質問者4： こんにちは、Yan。素晴らしい視点をありがとうございました。私にとって「モデル」という言葉にはもう一つ意味があります。多くの統計モデルは因果関係(causality)についての前提もエンコードしています。そのことについてどうお考えか伺いたいです。
Van den Bussche： ええ、因果モデルについておっしゃっているのですね。はい、それは確かに私のリストから抜け落ちていたものです。私が本日お話ししてきた内容に関して言えば、因果モデルはそれほど関連していないと思います。ただ、例えば私たちのコミュニティで尊敬されているメンバーの一人であるAngela Bonifatiは、実際にまさに因果モデルをクエリするという研究プログラム全体を展開しています。ですからそれも、モデルをクエリするという広い意味での同じプログラムに収まるものだとは思います。しかしこれらはやはりまた別の種類のものです。因果モデルは機械学習モデルとあまり比較可能ではありません。もちろん、可能なつながりはあるかもしれません。結局のところすべてはつながっていますから。ですが、ご提案ありがとうございます。
質問者5： 発表ありがとうございました。最終的に純粋なSQLで全部できるとおっしゃっていたのが本当に良いと思ったのですが、モデルを符号化する方法について、SQLを拡張して新しい演算子や、これをよりスムーズに、そして最適化しやすくするための新しい仕組みを加えるようなアイデアはありますか。
Van den Bussche： はい、それはおそらく、これを実用化する上で必要になってくる部分だと思います。原理的には生の関係代数と集約だけでも実現可能ですが、典型的にやりたいことは、クエリ式の中の特定のパターンを検出し、それを最適化することです。そのためには、そうした専用の構文を追加した方がずっとやりやすくなるでしょう。ただ、今すぐに具体的な構文の提案があるわけではありません。しかしこれは間違いなく取り組むべきことだと思います。
Geerts： あちらのマイクも待っていたようですね、そこにマイクがあるとは知りませんでした、すみません。
質問者6： おはようございます。講演、本当に素晴らしかったです。モデルたちを巨大なグラフとして表現するという話について質問があります。各データポイントがモデルであり、エッジはモデル同士の重みなどの関係に基づいて決められています。私の質問は、モデルは非常に速く進化していくので、エッジが継続的に削除されたり追加されたりする状況があるのか、また新しいモデルが継続的に追加されていく状況があるのかということです。もし新しいデータポイント、つまり新しいモデルが追加されたら、どのエッジを張るべきかを決めなければなりませんが、そのときスケーラビリティはどのように影響を受けるのでしょうか。
Van den Bussche： ええ、それは興味深い質問ですね。実は、このモデルアトラスの話は少し余談として触れただけだったのですが、確かにデータベースコミュニティと機械学習コミュニティの間にはもっと多くの相互作用があり得ると思います。そしてあなたが基本的に尋ねているのは、こうしたモデルアトラスの増分的な保守(incremental maintenance)についてだと思います。ええ、確かに私たちはそこで力になれると思いますし、これは取り組むべき実在の問題だという、非常に良い指摘だと思います。ですから、これは取り組む価値のある良いテーマだと思います。
質問者7： 「モデル」という言葉について、私もまさに質問しようと思っていました。これはこの発表について最も興味深いことの一つだと思うからです。一方であなたは、この「モデル」という言葉が10種類もの異なるものを指しうるということが自分の大きなこだわり(pet peeve)だとおっしゃいました。他方で、この発表自体はこの言葉なしには成立しなかったとも思います。「モデルをクエリするためのモデル」といった具合に、これほど多くのことを指し示せなければ、あなたはこの話をできなかったはずです。ですから、こうした多義的な概念を持っていることはむしろ良いことで、それによってこのような形で探求できるとお考えですか、それとも今後、コミュニティとして「モデル」という用語をもっと専門化していくべきだとお考えですか。
Van den Bussche： そうですね、私たちはこうしたさまざまな定義と共存していけると思います。私たちは五つの意味を頭の中に保持できるくらい賢いはずです。ただそういうものなのだと思います。新しい語彙を提案したわけではありませんので、それは興味深い考えではありますが、ありがとうございます。