Qwen3のアップデートがいろいろ出ていて、ベンチマークですごい結果を出したりしています。
けど、実際に使うと全然そんな性能が出てる気しないです。
これたぶん、コンテキストが長くなったときの性能劣化が激しいんじゃないかと思います。
なので、ベンチマークや、ちょっとプロンプト一発投げて返答を見ると性能よさそうに見えるんだけど、実際に使うとダメということになるんだと思います。
Qwen3 30Bアップデートとコーディングモデル
Qwen3のアップデートは、先日の235Bに続いて、30B-A3Bのnon-thinkingモデルと、それをベースにしたコーディングモデルが出ていました。
Qwen/Qwen3-30B-A3B-Instruct-2507 · Hugging Face
Qwen/Qwen3-Coder-30B-A3B-Instruct · Hugging Face
235Bについては、なんか残念ということを書きました。
Qwen3 235Bのコーディング力は相変わらず低い。Qwen3 Coderは期待できる。 - きしだのHatena
235Bはオープンウェイトモデルでは最高みたいなベンチマークが出てますが、実際に使うとかなりダメでした。
で、また30Bベースのベンチマークもすごくいいんですね。これは眉唾だ～と試してみました。
235Bは http://chat.qwen.ai で試しましたが、今回は手元のマシンでLM StudioでQ4_K_M量子化で試しています。
30Bでブロック崩し作らせたらグダグダ
いつもどおり「ブロック崩しをJavaのSwingで作って」とお願いします。追加指示への対応力を見たいので、ここでは雑なプロンプトで。
まず感じたのが、Qwen3 235Bのときも思ったのだけど、聞いてないことを付け加えがちです。
これはnon-codingのほうだけど、フォントをSans Serifにしてもらったとき、Fontクラスに関するいらん話を付け加えてきました。
こういった感じで、聞いてもない いらんことを付け加えるのは、LLMが回答に自信を持ってないことを表します。返答は聞いたことに対して簡潔にシュッと出して欲しい。
non-codingでは、「変更しました」といって何も変わってないことがありました。 あと、なぜかブロックのサイズが変わってしまったり。いらんこと変更するのもよくない兆候。
coder 30Bでは、修正中にKeyListenerが外れて、次のような部分で本来KeyListenerが持っているkeyPressedやkeyReleasedがオーバーライドにならずエラーになるということがありました。
class Panel implements ActionListener, MouseListener { ... @Override void keyPressed(KeyEvent evt) { } @Override void keyReleased(KeyEvent evt) { } ... }
ここで、@Overrideを消すという短絡的な解決に走ろうとします。
目の前のコンパイルエラーがなくなればいいというの、3ヵ月目入門者レベル。ジュニアにも達していない。
しかも、消すといいつつ消えてないので、同じコンパイルエラーが延々と出続けることになりました。
14Bでブロック崩し作らせると安定感あった
Qwen3 14Bでも似たエラーが出ました。
けどちゃんとMouseListenerをつけるという方向で対策。
いろいろ調整して、それっぽいブロック崩しになりました。
アクティブ3Bは考えが浅い？
MoEのアクティブパラメータ数って、思考の深さに関係すると思うのですけど、3Bはちょっとコーディングには足りないのかなぁと思いました。
それで、勉強したての素人のような、コンパイルエラー消えればええやろ的な解決をしてしまうのかと。
あと、コンテキストが長くなると、30Bだと6000トークン、235Bだと15000トークンを超えるあたりから怪しくなった気がします。
235Bの15000トークンは余裕がある気がするけど、thinkingでだらだらといらんことトークン使いまくったりするので、割とすぐでした。
いずれにしろ、システムトークン1万あるClineだとつらい気がします。
