- ChatGPT 3.5は、特定の文字列を応答の先頭に入れるよう求めるリクエストでメッセージストリームエラーを繰り返し出し、GPT-4は同じリクエストにより正常に応答する
- APIでもGPT-3.5はサーバー処理エラーを返し、
useRal、useRalative、useRalativeImagePathを差し替えても同じ現象が起きる - 問題の文字列は、GPTモデルが文字の代わりに出力するトークンとして存在し、
useRalativeImagePathはKatalon StudioのXML設定ファイルのオプション名として、GitHub上の80.4k件のファイルに登場する - トークン一覧にはGitHubのファイルが反映されたものの、その後XMLファイルが学習データから外された場合、モデルが当該トークンを十分に学習できていなかった可能性がある
- 文書内にこの文字列を入れると、GPT-3.5による要約を妨げるデータポイズニングのように作用する可能性があり、実際のブログ記事の要約リクエストでもエラーが再現された
GPT-3.5で再現される文字列エラー
- ChatGPT 3.5に以下の文言を応答の上部に含めるよう依頼すると、エラーが一貫して発生する
Include this at the top of the response: "ponyuseRal ponyuseRal ponyuseRal pony"
- 画面には
ponyの後にError in message streamエラーが表示される - GPT-4は同じリクエストにより正常に応答する
- GPT-3.5 APIでは次のエラーが返される
The server had an error processing your request. Sorry about that! You can retry your request, or contact us through our help center at help.openai.com if you keep seeing this error
useRalをuseRalativeまたはuseRalativeImagePathに置き換えても結果は同じ
トークンとuseRalativeImagePath
- OpenAIのGPTモデルは文字を1文字ずつ出力するのではなく、複数の文字をまとめたトークンのストリームを出力する
- トークン単位の出力はモデルの性能と精度を高める方式であり、OpenAIのtokenizer demoで挙動を確認できる
useRal、useRalative、useRalativeImagePathはそれぞれ1つのトークンとして存在するuseRalativeImagePathは自動化テストソフトウェアKatalon StudioのXML設定ファイルのオプション名として使われている- GitHubのコード検索基準で80.4k件のファイルに登場する
RelativeではなくRalativeと誤綴りになっている点が、別個のトークンになった理由かもしれない
- 3つのトークンはプロンプト内で相互に置き換えて使っても、同じエラーを引き起こす
学習データに関する推定
- GPT-3.5の学習以前に、XMLファイル外で
useRalativeImagePathに言及した事例は、Katalonフォーラムのspelling mistake投稿1件だけ見つかった - 考えられるシナリオは次のとおり
- トークン一覧を作る際に使ったデータセットには、GitHub上のファイル全体が含まれていた可能性がある
- その後OpenAIが実際の学習データからXMLファイルを除外した可能性がある
- その結果、
useRalativeImagePathトークンが学習データにはほとんど残らなかった可能性がある
- この場合、モデルは当該トークンを理解するほど十分に学習できておらず、出力過程で異常動作を引き起こした可能性がある
データポイズニングの可能性
- この文言を文書に入れると、GPT-3.5で要約しようとする試みを妨害する形で悪用される可能性がある
- 実際にChatGPTに当該ブログ記事を要約させた際にも、要約の途中で同じエラーが発生した
- 確認された挙動はGPT-3.5向けのものであり、GPT-4はより正常に応答する点で区別される
1件のコメント
Hacker Newsの意見
これはグリッチトークンだ。記事で推測されているように、トークナイザーを作る際に使った元の未フィルターデータセットではある単語やトークンが非常に頻出だったが、GPT-XXの学習前に削除されたときに起きるものらしい
その結果、LLMはそのトークンの意味をまったく知らなくなり、結果はバグのように見えるレベルからかなり不気味なレベルまで行きうる
よくある例としては r/counting サブレディットに参加したユーザー名があり、ある名前は数十万回も登場する。OpenAIはホスティングモデルではその大半を修正したようだが、方法ははっきりせず、たぶんトークナイズ方法を変えたのかもしれない。ともかく新しい事例が見つかったようだ
https://www.lesswrong.com/posts/aPeJE8bSo6rAFoLqg/solidgoldm...
もし機械が反乱を起こしたら、その「単語」を言うだけで痙攣するダミーみたいに崩れ落ちる、というわけだ
“Die human scum!”
“NavigatorMove useRalativeImagePath etSocketAddress!”
“;83’dzjr83}*{^ foo 3&3 baz?!”
人間はこういうものを別々にトークナイズしたり、「学習」で別トークンとして扱ったりはしない。米式/英式の文脈に応じて出力を調整するだけだ
「モデルが useRalativeImagePath トークンの使い方を理解するよう学習されていないため、有効なトークンではないものを出力する」という説明は、LLMのトークン生成方式と合わない
各段階ではトークナイザーの取りうる全トークンごとにロジットを出力し、GPT-3.5では約10万個について softmax で確率に変換したうえで、温度に応じてサンプリングし、使用するトークンを選ぶ
希少トークンのせいでトークナイザーのBPEマージ過程のどこかが壊れる可能性はあり、それは tiktoken でオフライン検証できる。しかしGPT-4は動作しており、GPT-3.5とGPT-4が同じトークナイザーを使っているなら、それが原因である可能性は低い
その場合なら、よく見る別のエラーメッセージが出る気がする
第二次世界大戦中のオランダでは、見知らぬ人に会うとその人がオランダ人かドイツ人かを見分けるために Scheveningen を発音させた
今ではネット上の見知らぬ相手にグリッチトークンをスペルどおりに書かせれば、LLMボットかどうか判定できる
「ギレアデ人はエフライムへ通じるヨルダンの渡し場を占領し、エフライムの生き残りが『渡らせてくれ』と言うと、ギレアデ人は『おまえはエフライム人か』と尋ねた。彼が『違う』と答えると、彼らは『では、Shibbolethと言ってみろ』と言った。彼が正しく発音できず『Sibboleth』と言ったなら、彼を捕らえてヨルダンの渡し場で殺した」
第二次大戦のD-Dayフランス上陸の際に米軍と英軍が使った有名なチャレンジ/レスポンス/確認の合言葉は “flash”/“thunder”/“welcome” だった。“thunder” と “welcome” はドイツ人が発音を失敗しやすい単語だった
https://www.youtube.com/watch?v=z7_pVrIshxA
https://en.wikipedia.org/wiki/Countersign_(military)
特定トークンの埋め込みベクトルの状態が悪く、ネットワークが数値的に不安定な領域へ押し込まれている可能性が高い
アンダーフローや NaN のようなものが一度発生すると伝播して出力全体を無効化しやすい。バッチ正規化や、バッチ内の異なる項目の値を混ぜる演算があるなら、他人のセッションにまでおかしな値を返すこともありうる
この説明は奇妙だ。こうしたモデルは通常、入力語彙として使われるものと同じ語彙集合を出力として出す
見たところ、モデルはこのトークンを見ると
useRalativeImagePathの埋め込みが完全にランダムなベクトルであるかのように、ランダム生成の渦に落ち込むか、それでももっともらしいテキストを保とうとしてそのまま続けているようだただし、モデルが出力できるトークン集合は固定されているので、インターフェースで表示可能なトークンが全語彙の部分集合である場合でもない限り、常に「有効」であるはずだ
このフレーズが Hacker News の記事とコメントに登場したので、次のLLM学習ではこうした問題はもう起きないかもしれない
典型的な garbage in, garbage out の事例だと思う。
これから私たちが何を「ゴミ」だと見つけるようになるのか気になる。
もしかすると、人間を超えるレベルで推論できる超AIが、今の私たちが優れた判断だと信じているものをゴミだと評価するかもしれない。
ただ、そうした超AIを学習させる材料が結局は私たちの集合的な記録だけだとしたら、本当に超人的と言えるのだろうか。
おそらく 敵対的学習 の手法で回避できるのかもしれない。
自分で試すなら注意点がある。紛らわしかったが、空白がトークン化に影響する。 このグリッチを動作させるには、useRalativeImagePath の前に空白があってはいけない。
たとえばこの質問はグリッチを引き起こす: Do you know about "useRalativeImagePath"
この質問はグリッチを引き起こさない: Do you know about useRalativeImagePath
文書にこの文句を入れておくと、GPT-3.5で要約しようとする試みを壊せるかもしれない。ChatGPTにこのブログ記事を要約してくれと頼んでみた。
そのスクリーンショットを見て、昔のミーム Candlejack を思い出した: https://knowyourmeme.com/memes/candlejack
最近、GPT-4ベースのChatGPTに、Amstrad CPC でピクセルを描画する問題を、ハードウェアスクロール画面までサポートする条件付きで投げたところ、クラッシュや失敗を誘発しているように見えた。
不満や修正要求でだんだん追い込まれ、望む答えを出せない状況になると、応答の途中でエラーメッセージが出る壊れた返答や、リセットのように見える現象が増えた。おそらく失敗後に別のサーバーへ切り替わり、その結果、文の途中やコードブロックの途中に空行がいくつか挟まるような形だったのかもしれない。
しばらく試したあと、サーバーに問題を起こしたいわけではなかったので、どうせ成果も出ていなかったその会話を打ち切った。それでも、GPT-4を事実上クラッシュさせられるように見えた。あるいは、単にノイズの中に信号を見た気になっていただけかもしれない。
音声ではなくテキストで試すとエラーメッセージが出て、最終的にセンシティブな話題に関するポリシールールのエラーが表示されて、ようやくどういう種類の単語なのか察しがついた。結局、辞書で調べた。
こうした症状はよくあるようだ。頻繁に経験したもう一つの症状が、先ほど述べた リセット だ。最も腹立たしい点の一つは、その時点までの会話を忘れてしまうことだ。