ボットを判別するためのシボレスルールの提案
Stanford HAI に以下の記事が公開されていました。
遠隔で医療的なアドバイスを行ったり、子供に勉強を教えたり、借金の回収をしたりといった会話をしているときに、その相手が実は人間ではなくボットだった、ということは近い将来に起こりえます。このような時に、どうやって人間かボットか判別するのか？という話題です。
このようなサービスとしては Google Duplex が既に公開されています。Google の AI が飲食店に電話を掛けて予約してくれるというサービスです。
Google AI Blog: Google Duplex: An AI System for Accomplishing Real-World Tasks Over the Phone
人間の代わりにAIが電話予約。「Google Duplex」は予想を遙かに超えてきた - 価格.comマガジン
特徴として、ただ流暢に話すのではなく、「えーと」「あのー」といった有声休止も使いながら話します。そのため、実際に Google Duplex と話してみるとボットとは気付かなかった、といったことになるようです。より幅広い状況でこのようなサービスが使用されるようになると、自分が会話している相手が本当に実在する人間なのか、全く見分けられなくなります。
そこで、Stanford HAI が提案しているのがシボレスルールになります。
「シボレス」というのは、Wikipedia によると「ある社会集団の構成員と非構成員を見分けるための文化的指標を表す用語」ということです。
このようなボットに AI シボレスを生成するよう実装することで、ボットであることを識別できるようにし、どこで学習を行うか、オーナーシップを誰が持っているかといった情報を取得できるようにします。これにより、人間と話しているということを確かめることや、逆に丁寧に話すのが面倒なときはボットと雑に会話するといった選択もできるようになります。
正直なところ、記事を読んでもシボレスルールが流行るようには思いませんでした。悪意を持って作られたボットの場合、そのボットはシボレスルールを無視してより人間になりきろうとするでしょうから、どこまで意味がある実装なのかよく分かりません。また、逆に信頼しているサービスなのであれば、必要なサービスが提供されている限り相手がボットでも人間でも問題にはならない気がします。実は人間かボットか判別する必要はないかもしれません。
この記事を読んで思い出したのは、NVIDIA の発表会で登場した CEO の映像が一部フル CG だったという記事です。
映像が作り込まれた CG で、音声も AI が出しているという状況になったら、ビデオがリアルかフェイクか全く判別できません。特に昨今のコロナ禍では、転職後に一度も出勤していないみたいな話もたまに聞きます。そうすると、WEB 会議でカメラをオンにして話していた相手は実在しない人間だった、みたいなことも実現するのかもしれません。（メタルギアソリッド2 の大佐みたいな）
そう考えると少し気味が悪くなってきます。twitter でフォローしてくれた相手はボットだった、DM を送ってきたのも実はボットだった、ということは既にありそうです。答えを知らずにいればそれはそれで幸せなのかもと思いましたが、ボットと判断できずにボットから影響を受けて生活が変わっていく、ということが特に政治的な文脈であるかもな、と考えるとやっぱり怖さもあります。ボットを見極めるというのも一つ大事なことだなと感じました。
自然言語からプログラムのコードを生成する OpenAI Codex がリリースされました
OpenAI Codex がアップグレードして自然言語からプログラムのコードを生成できるようになり、この機能を使うための API が private beta という形でリリースされました。
API を使用するには、今のところ Wait list に登録して待つ必要があるようです。
Codex のベースとしては、同じく OpenAI が開発した自然言語処理モデルである GPT-3 が使われています。実は、GPT-3 でも自然言語からコードを生成することは可能でした。
参考：OpenAI’s GPT-3 Can Now Generate The Code For You
しかし、GPT-3 では生成する Python コードに 4KB のメモリしか使えなかったのに対し、今回の Codex では 14KB のメモリが使用できるようです。そのため、より複雑な状況に対するコード生成も可能になったということになっています。
OpenAI Codex については、GitHub Copilot が発表された時にそのエンジンとして紹介されていました。GitHub Copilot ではコメントと関数名からその実装を自動生成するという動作でしたが、OpenAI Codex の API を使用することでより汎用的に使えるということになります。
何を作るか決めた時にプログラマーがやることは、問題をより小さな問題に分割し、単純な問題をコードに置き換えるという作業になります。特に後者のコードの置き換え部分に対して、OpenAI Codex では価値を発揮するということです。
GitHub のパブリックリポジトリからコードを学習しているということで、ライセンスの問題等の議論の余地が存在していますが、OpenAI のサイトで公開されている動画を見ると使ってみたくなります。
pipe の挙動を実装に問題のある Android アプリのために修正する
2019 年に Linux kernel の pipe の再実装が行われ、その際に reader が必要な場合にのみ起動される動作に変更されていました。しかし、一部の Android のライブラリでは epoll の仕様の誤解により、pipe の変更により問題が生じることが確認されました。Android のライブラリ側が仕様に沿っていないことが問題の原因に見えますが、do not break user space (kernel を仕様するアプリケーションに影響を与えない) というルールを優先して、pipe の再実装でリグレッションが生じたと認め修正が行われました。
pipe のコミットメッセージを読むと、realm-core というライブラリが例として挙げられています。
realm-core 側では正しい実装に修正されましたが、モバイル上で動作できるデータベースとして使用されているため、他の多くのアプリケーションにも影響が出る可能性があることを考慮されたようです。
仕様を正しく理解していないアプリケーション側が悪いと判断できそうな事象ではありますが、広範囲に影響が及んでしまうということで、kernel 開発の難しさを感じられます。
Android では長らく Linux 5.5 が使われていたため、この kernel の変更は 2019 年に行われていましたが、影響が確認されたのは最近になってのことになりました。Linux 5.10 は Android 12 以降で使用される場合があります。今回の pipe の修正は Linux 5.14 に対して行われていますが、Linux 5.10 を含む過去のバージョンにもバックポートされるようです。
参考文献：
RAPIDS Accelerator for Apache Spark v21.06 がリリース
RAPIDS Accelerator for Apache Spark v21.06 がリリースされました。
RAPIDS Accelerator for Apache Spark は NVIDIA の GPU を Apache Spark から活用できるようにするためのライブラリになります。大規模なデータセットに対する演算では、GPU を使用することで処理時間の削減が期待されます。Databricks の環境では、GPU を使用することで ETL 処理が 3.8 倍高速化され、コストは 50% 削減されるそうです。 (出典：https://nvidia.github.io/spark-rapids/)
このバージョンでは array や struct タイプに対する機能追加や、lead/lag といったウィンドウ関数に対するサポートが追加されています。
なお、今回のバージョンからカレンダーバージョニングが使用されているため、前回リリースされた v0.5.0 からバージョンが飛んでいます。(21 が年を表し 06 は月を表す)
PyPI から取得したパッケージが開発者のマシンの情報を抜き取る
JFrog の記事によると、PyPI リポジトリから約 30,000 回ダウンロードされたパッケージに悪意のあるコードが含まれており、このパッケージをダウンロードしたマシンからクレジットカード情報やログインの資格情報等が盗まれている可能性があります。
パッケージのコードは base64 等でエンコーディングすることで難読化されています。実行するとウェブブラウザに保存されたクレジットカード情報や Discord の auth token 等の情報を収集されてしまいます。また、パッケージによっては Remote code injection (遠隔地からのコード実行) が行われます。
PyPI のようなパッケージマネージャーでは Supply chain attack が存在し Apple や Microsoft といった企業でも被害が出ていたことが話題になりました。(参考：
New type of supply-chain attack hit Apple, Microsoft and 33 other companies | Ars Technica)
自分で 1 からコーディングする必要が無くなるため、公開されたパッケージを使用することはとても便利です。また、たくさんの人が同じパッケージを利用することで、バグの洗い出し等も進み自分で実装する以上の品質が確保されている場合もあるでしょう。
そのため、リスク管理のために一律で公開パッケージ使用不可とするのは、個人的には開発が非効率なものになってしまうデメリットがあると考えます。しかし、使用にあたりこのようなリスクが存在することは理解しておくことが重要となります。
参考文献：
