米OpenAIは6月5日（現地時間）、米The New York Timesによる著作権訴訟で、ユーザーが削除したChatGPTとの会話期限に」保存するよう裁判所から命令されたと発表した。同社は控訴するとしている。
この訴訟は、2023年12月にThe New York Times（以下、NYT）が、OpenAIと米MicrosoftがNYTの記事を「数百万件コピー」してAIモデルをトレーニングした結果、同メディアと読者との関係が損なわれ、購読料や広告などによる収入も奪われるとしてニューヨーク州南部地区連邦地裁に提訴したものだ。
裁判所は5月にOpenAIに対し、ユーザーがチャットの削除を要求した場合やプライバシー法に基づいてOpenAIがデータを削除する義務がある場合でも、「本来であれば削除されるはずのすべての出力ログデータ」を保存するよう命じた。
⇧ 主張は、「AIモデル」の学習で「The New York Times」の記事が無断使用されたことに対する「著作権」の問題であると思うのだが、「一般ユーザー」が「AI」を利用する時に「「The New York Times」」の記事を使用すると、「AIモデル」が学習してしまうからということなんですかね？
保存期限が明示されていないのが気になりますな...
「The New York Times」としては、
AIのトレーニングに使用されるデータをインターネット上からかき集めるために使用されるのがクローラーです。
AIトレーニング用のデータをかき集めるクローラーを無限生成される迷路に閉じ込める「Nepenthes」が開発される - GIGAZINE
自身のウェブサイト上のデータをAIのトレーニングに利用されないようにするためのオプションを大手AI企業は提供していますが、この種のブロックを迂回してクローラーがウェブサイトから情報を抜き出していることも問題視されています。
AIトレーニング用のデータをかき集めるクローラーを無限生成される迷路に閉じ込める「Nepenthes」が開発される - GIGAZINE
そんなクローラーを無限に生成される迷路に閉じ込めることができるのが「Nepenthes」です。
AIトレーニング用のデータをかき集めるクローラーを無限生成される迷路に閉じ込める「Nepenthes」が開発される - GIGAZINE
⇧ 上記のような仕組みを導入するしか無さそうね。
勿論、「Microsoft」や「OpenAI」など「AIモデル」を「学習」させるために「情報」を無断利用している企業が、損害を与えた企業の導入費用を全額負担するようにするべきだとは思いますが...
いずれにしろ、「犯罪行為」をしているのは、今回の訴訟ケースだと、「Microsoft」や「OpenAI」に該当することになると思われるわけだが...
それにしても、
『自身のウェブサイト上のデータをAIのトレーニングに利用されないようにするためのオプションを大手AI企業は提供していますが、この種のブロックを迂回してクローラーがウェブサイトから情報を抜き出していることも問題視されています。』
は「マッチポンプ」が甚だしいですな...
日本の「自民党」の「マッチポンプ」だらけの「施策」を彷彿とさせますな...
JVMのOOMはJVMのheapサイズで防げるがJava以外のプロセス起因のOOMは別の要因がプラスαされてる説
とりあえず、
⇧ 上記のイベントに参加してきました。
で、面白いセッションが多かったのですが、
『Java's OOM and Kubernetes' OOM - 遭遇した2つのOOMと対策 ~ Launchableでの事例 ~』
のセッションの話を聞いて、「Java」の「アプリケーション」の「メモリ」使用率って結局のところ、よく分かっていないんだなぁと思うなどした。
今回の話で行くと、「OOM（OutOfMemory）」が発生し得るのは、
| No | 領域 | 起因 |
|---|---|---|
| 1 | Javaアプリケーションのプロセス | JVMのheapサイズ上限を超えた場合に発生。 |
| 2 | Kubernetesのプロセス | Pod内のプロセスのメモリ使用量がKubernetesの設定で指定した閾値を超えた場合に発生。 |
| 3 | OSのプロセス | シェルスクリプトの変数に大容量のデータを格納するなどした場合に発生。 |
と言った感じになりそうだ。
「Javaアプリケーションのプロセス」で「OOM（OutOfMemory）」が発生した場合は、「OOME（OutOfMemoryError）」となってプロセスが終了すると思うのだが、「Kubernetesのプロセス」や「OSのプロセス」で「OOM（OutOfMemory）」が発生した場合は「OOM Killer（OutOfMemory Killer）」でプロセスが終了させられると思われる。（環境は「Linux」である前提だが）
で、このセッションで初めて存在を知ったのだが、
「Off heap」なるものが起因で、「Kubernetes」側で「OOME（OutOfMemoryError）」が発生したのではないかという仮説。
そもそも、「Off heap」とは？
オンヒープおよびオフヒープ・メモリー
オンヒープ・メモリーは、ガベージ・コレクタによって管理されるメモリーの領域であるJavaヒープ内のメモリーです。Javaオブジェクトはヒープ内に常駐します。ヒープは、アプリケーションの実行中に拡大または縮小することがあります。ヒープが一杯になると、ガベージ・コレクションが実行されます。JVMは、使用されなくなったオブジェクト(到達不可能なオブジェクト)を識別し、メモリーをリサイクルして、新しい割当て用の領域を作成します。
https://docs.oracle.com/javase/jp/21/core/heap-and-heap-memory.html
オフヒープ・メモリーは、Javaヒープ外のメモリーです。JavaアプリケーションでCなど異なる言語の関数やメソッドを呼び出すには、その引数がオフヒープ・メモリー内にある必要があります。ヒープ・メモリーとは異なり、オフヒープ・メモリーは不要になった際にガベージ・コレクションの対象になりません。オフヒープ・メモリーの割当て解除の方法とタイミングを制御できます。
https://docs.oracle.com/javase/jp/21/core/heap-and-heap-memory.html
⇧ とありますと。
英語版のドキュメントは以下。
で、上記の説明が正しいとすると、「Off heap memoery」は、「ガベージ・コレクション（GC：Gabage Collection）」の対象にならないとのことなのだが、「Off heap memoery」が解放されるデフォルトの振る舞いが分からない...
で、そもそも、「Java 仮想マシン（JVM：Java Virtual Machine）」の「メモリ構成」が公式のドキュメントだとハッキリしない...
4. Sizing the Generations
A number of parameters affect generation size. The following diagram illustrates the difference between committed space and virtual space in the heap. At initialization of the virtual machine, the entire space for the heap is reserved. The size of the space reserved can be specified with the -Xmx option. If the value of the -Xms parameter is smaller than the value of the -Xmx parameter, not all of the space that is reserved is immediately committed to the virtual machine. The uncommitted space is labeled "virtual" in this figure. The different parts of the heap (permanent generation, tenured generation and young generation) can grow to the limit of the virtual space as needed.
https://www.oracle.com/java/technologies/javase/gc-tuning-6.html
Some of the parameters are ratios of one part of the heap to another. For example the parameter NewRatio denotes the relative size of the tenured generation to the young generation. These parameters are discussed below.
https://www.oracle.com/java/technologies/javase/gc-tuning-6.html
⇧ 上図だと、
が図のどの部分に該当するのかがサッパリ分からない...
相も変わらず「Java」は「ブラックボックス」な部分が多いですな...
いつまで経っても「我々は雰囲気でJavaを扱っている」から脱却する日は来そうにないですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
