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では格納される構造です。ここは文字の羅列で引数の配列ではない。