Apple Cardの性別バイアス問題とAI倫理

https://wired.jp/2019/11/22/the-apple-card-didnt-see-genderand-thats-the-problem で記されている古い問題ではあるが、今にもつながる問題を提起している。たしか、記憶してる限りだと、Apple Cardの極度額がある夫婦で夫と妻とで極端な差があったので問題になったはずです。同じ家計の夫婦であれば、リスクはほぼ同じになるはずが、そうなっていなかったというので問題になったはずです。

そして、これが性別を与信モデルに含んでいれば、ある種単純だったんですが、この事業では性別を見ていなかったのです。したがって、逆に、性別で差別をしていないという立証が困難になりました。

性別に限りませんが、ある変数が別の変数に関連しているのはよくある話です。例えば、今回の話でならば、女性の身長の平均が男性のそれより低いというのは、事実であり、身長というフィールドがあったならば性別を書いているのと同じことです。

そして、OECD AI五原則と言うルールがあります。

1. AIは持続可能な成長や開発、幸福促進に利益をもたらすべき。
(以下省略)

また、個人情報についてOECDには以下の八原則があります。

1. 個人データの収集目的を明確にし、データ利用は収集目的に合致するべきである。
(以下省略)

この二つを鑑みると、モデルを作るにあたっては収集目的に見合ったデータを集めモデルを作るべきとなります。
つまり、与信であれば、貸し倒れ等のリスクを見るのに、見合った項目によりモデルを作るべきということになります。

従って、これらの原則を援用すれば、適当にデータセットを作って、後はStep-wiseを含め機械に変数選択をやらせてなんとなく、精度高めのモデルできましたはOECDの各種原則に従ってるかと考えればかなり微妙となります。

実際、産総研の高木さんなんかは、OECDの原則に照らせば、こういう安易なモデルはもってのほかと考えているのは、Twitterでの発言を考えればわかる感じです。

LLM技術の革新とその課題

https://gigazine.net/news/20241224-openai-gpt5-orion-delays/ でGPT-5が苦戦中というのが出ているが。

僕の理解では、現状のLLMは古典的な自然言語処理では字句解析、構文解析、意味解析と下から順に階層的に処理して最終的にある問題の回答を求めようとしていたのを、LLMの隠れ層に中間的な工程を委ねていると思っている。古典的な自然言語処理がうまくいかなかったのは階層的な処理だと、例えば字句解析が90%の精度で、構文解析が80%の精度だと仮定すると、構文解析のところで実際の精度は72%になる。そして、工程を経るごとに精度は下がり続け決して上がることはない。

故に実際の問題のところに至るまでに実用的なラインを割り込んでしまう、実際、LLMの登極前の時点で、字句解析、構文解析、意味解析を実用的な精度できちんとやり切っているシステムを私は聞いたことがない。多くの場合は、Eliza的なパターンマッチングなどで動いていたと思う。


LLMはEnd to endで入力されたものと、出力とを完全に結びつけることで初めて、一つのブレイクスルーを得たと思う。途中を隠れ層に押し込むことで、精度低下を不可視化したと思う。勿論、技術的には活性化関数などや、もちろん計算機の進化によって、深層学習が実用になったこと、そして、Attention機構のようにRNN的な成果を実用的なパフォーマンスで得られるようになったことが大きい。

しかし、根本的には、人間はLLM内で何が起きているかを理解できていないし、結果的にフレーム問題なども前進したかどうかすらわからない。この辺に今のLLMを考える難しさがある。

重みが跳ね上がる:Fooocusのバグ解析

最近、Fooocusでもa1111と同じバグがあることに気づきました。この問題は、patch_clip.py内のpatched_encode_token_weightsの実装に起因しています。

z = z * (original_mean / new_mean)

上記のコードで、時折 new_mean が非常に小さい値を取るため、重みが跳ね上がり、正常な描画ができなくなっています。

実際に確認された値は以下の通りです:

original mean0.0004
new mean3.7944e-05

この場合、z は約10.54倍されることになり、結果として描画が大きく乱れる可能性があります。

以下の画像は、実際に乱れた描画結果の一例です:

GitHubのissueにもこの不具合を報告しましたが、Fooocus の issues は現在あまり動いていないようです。open な issue が積み上がる一方なので、自分でフォークした mashb1t 版のベースで対応を進める予定です。ただし、z の計算ロジックの適切な修正方法についてはまだ結論が出ていません。

元々のコードの出所はこちらです:Stable Diffusion XLで生成画像の破綻が起きる問題の解析と対策

AWS S3を悪用したLedger詐欺の解析

Ledgerなるおそらくウォレットを騙る、メールが来ました。Ledger Data Breachなるタイトルでアカウントの確認依頼になっていますが、ログイン先と主張しているアドレスがAmazon S3のアドレスでそもそも、私はLedgerなるサービスのアカウントは持っていないので十中十、フィッシングでしょう。

怪しいので、Windows Sandboxを使用し、メールで参照しているAWS S3のアドレスからダウンロードしてみたところ、中身は https://ledgerprotecthub.com/ にリダイレクトしていることがわかりました。 そして、このドメインをwhoisしてみたところ、以下のような内容でした。

Domain Name: LEDGERPROTECTHUB.COM
Registry Domain ID: 2935890219_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.amazon.com
Registrar URL: http://registrar.amazon.com
Updated Date: 2024-11-21T07:05:15Z
Creation Date: 2024-11-20T21:58:13Z
Registry Expiry Date: 2025-11-20T21:58:13Z
Registrar: Amazon Registrar, Inc.
Registrar IANA ID: 468
Registrar Abuse Contact Email: trustandsafety@support.aws.com
Registrar Abuse Contact Phone: +1.2024422253
Domain Status: ok https://icann.org/epp#ok
Name Server: SARAH.NS.CLOUDFLARE.COM
Name Server: YADIEL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
URL of the ICANN Whois
Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2024-11-21T11:57:21Z <<<

まず、真正のドメインと考える理由はゼロです。RegistrarをAmazon Registrarにして、連絡先などを伏せている時点で真っ黒です。

https://ledgerprotecthub.comはWindows Sandbox上から、wgetを使ってアクセスしてみたところ、403ではじかれたので、Windows Sandboxから仕方なくEdgeでアクセスしてみたところ、少なくとも、24語のセキュリティワードを要求しているページと確認が取れたので、黒と判断しました。

OpenSSHのCVE-2024-6409: 任意コード実行の脆弱性を確認しよう

OpenSSHに脆弱性、CVE-2024-6409が発覚しています。

シグナル関連が鬼門となっている印象。脆弱性としては、CVE-2024-6387よりはマシな印象。LoginGraceTime 0による緩和策は有効。-eによる緩和策は本件には無効。UbuntuにおいてはUpstreamには影響。

Rustの脆弱性 CVE-2024-24576

Windowsのこの辺の仕組みは、CP/Mに由来するところが大きいですからね。CP/M→CP/M-86→MS-DOSって流れですね。さすがに、この仕組み自体はベーシックすぎて直すのが困難でしょう。この辺をいじると全ての互換性が損なわれかねないので。参考にあげたように、0ページの後半にCP/Mでは格納される構造です。ここは文字の羅列で引数の配列ではない。

A new way to share files

要は、Near by shareはSamsungのQuick Shareと統合される。Quick ShareはSamsungがWindowsにもアプリを提供しているので。Android、Chromebookだけではなく、Windowsでも利用可能になる。

実際に、Quick Shareは既にMicrosoft Store上でアプリが提供されている。

この件自体は、既に噂としては出ていた。日本語のニューズだと、すまほんさんが、Android Authorityのニューズを伝える形で紹介していました。まあ、公式になったということですね。