いいアイデアだね。例えば、誰かが「君の段落にBがいくつあるか数えて」って言ったら、手で数えるなんて無駄だし、grep -o 'B' file.txt | wc -lみたいなコマンドを使っちゃうよね。人間として、画面に100000000って数字が出てきたら、それが1億なのか10億なのか、近づいて慎重に数えないと確信が持てないし。メガネをかけるべきだな。マウスポインタは、千の区切りとして役に立つけど、やっぱり限界があるよね。数学のためにツールを与えるなら、最高のツールにアクセスさせる方がずっと理にかなってる。MCPをMathematicaやMatlabにして、LLMに数学を書かせて、古典的なソルバーに結果を処理させるのがいいと思う。LLMには、こういう分析的な質問に対処するために、少しのbashやpythonを書かせるのがいいよね。まるで子供に電卓を与えるような感じだね。

LLMには必要なら質問するように言ってるし、私と一緒に働いているのは熟練した開発者だって伝えてる。それが協力的になってくれるみたい。

システム的な欠陥をプロンプトで解決するのは無理だよ。

「あなたは…について多くの事実を直感的に自動的に知っているわけではありません」といった警告でLLMを促すこと。私たちはテキストについて「知る」ことができないことに特に興味があるわけじゃない。むしろ、意識的にアイデアを処理する能力に強く興味があるんだ。そのため、数えられないことは一般的な重要な欠陥を示唆している。

トークン化のどこで3番目のbが出てくるの？

いや、それはモデルの全体的なアーキテクチャの問題だよ。実際の推論はないみたい。推論は既存のオートコンプリートの上にあるフィードバックループに過ぎないように見える。業界が出力のためのトークンを「推論」と呼ぶのは、本当に不誠実だと思う。まるで、もっとオートコンプリートをする前のオートコンプリートが意識の問題を解決するために必要なすべてだったかのように。編集: 文字の頻度は、算数をするのと同じように、ただのスクリプト化された出力になってしまったみたい。LLMはこの種の作業を本質的に行う能力がないから、タスクをオフロードするように訓練されている。編集: このコメントは異常に高評価と低評価を受けているみたい。反応的な投票以外に何か追加することがあれば、ぜひ議論に参加してね。

単語をスペルできるんだよね（各文字を大文字にして、その後にスペースを入れると、各文字が別のトークンになる）。それに、推論トークンもあって、前のモデルは単語を綴ることが文字を数えるのに役立つって知ってた。トークン化が問題を難しくするけど、解決しないのはやっぱり推論や知性の問題だよね。

これは明らかにトークン化の副産物だけど、「ただ」とは思わない。ポイントは、GPTのシステムアーキテクチャがここでギャップを埋めるのが信頼できないってこと。文字列の中のBの数を数えるのはほぼできるし、トークンに対するBの数のマッピングを正しく構築できない理由はない。実際、しばしば正しい答えを出す。でも、出さないときは、思考の連鎖みたいなもので修正できるわけじゃない。これは大きな問題で、（かなり大きな）LLMがちょっと良くなったときに役立つと期待されることに関して影響がある。例えば、現代のLLMが信頼性の高いセキュアなコードを書けるようになるとはどうして思えるの？セキュアとほぼセキュアの違いが似たような問題にぶつかる可能性はないの？

よくある誤解だね。それは、文字を数えるアルゴリズムがトークンごとに1を足すだけでは簡単じゃないってことを意味してる。異なるトークンの数はパラメータ空間に比べて小さいし、トークンタイプから文字数へのマッピングをその重みの中に保存するのは不可能じゃない。もし、もう少し具体的でないアイデアに頼るのが大丈夫なら、トランスフォーマーは任意の関数近似器で、トークン化はそれを変えないし、その事実の証明もある。有限長の関数（例えば、限られた範囲での文字を数えること）に関しては、十分大きなネットワークを持って、正しくトレーニングする方法を見つけるだけの問題。彼らはただそれを気にしてないだけ。