おはようございます！「zenncast」、MCのマイクです。11月14日、土曜日、朝7時になりました。週末の朝、皆さんいかがお過ごしですか？ 今日もZennでトレンドになっている記事から、気になる話題をお届けします。
今日は、NeovimのGUI、検索モデルの仕組み、AIを使ったコード検証、テストケースの選び方、そして自社環境で動かせる大規模言語モデルについて、全部で5本をご紹介します！
....
まず1本目は、Linux向けのNeovim用GUI、「ng」のお話です。
ngは、Goで作られた、Neovimをウィンドウで使うための最小限のGUIです。特徴は、独自のタブやアニメーションをあえて省いていること。見た目の機能を増やすのではなく、「端末と同じ画面を、素早く表示する」ことに力を注いでいます。
普段使っているNeovimの設定やプラグインは、そのまま使えます。使い慣れた環境を大きく変えずに、ウィンドウで利用できるわけですね。
日本語フォントやIMEにも配慮されていて、文字を入力するモードのときだけ、日本語入力を有効にすることもできます。日本語を扱う方にとって、こうした入力まわりの工夫はうれしいですよね。
さらに、端末と同じ画面になっているかを毎日テストしているそうです。機能を絞ることで、表示の正確さと応答の速さ、そして長く保守しやすい構成を目指しているんですね。
足し算だけではなく、必要なものに集中する。そんな道具づくりの姿勢が伝わってくる記事です。
....
続いて2本目は、検索や推薦の候補選びに使われる「Two-Tower」の仕組みです。
Two-Towerは、検索条件と検索対象を、それぞれ別のニューラルネットワークでベクトルに変換し、その類似度で候補を選ぶモデルです。大きなポイントは、検索対象側の計算を事前に済ませられること。候補のベクトルをあらかじめ用意しておけるので、大量の候補から効率よく探せるんですね。
学習では、クリックされた対象などを正例、それ以外を負例として比較します。このとき、同じ学習バッチに入っている対象を負例として使い回すと、計算を節約できます。
ただ、ここには偏りの問題もあります。人気の対象は登場する機会が多いため、負例としても選ばれすぎてしまうんです。その調整に使うのが、出現確率を利用する「logQ補正」です。また、全候補からランダムに負例を追加すれば、クリック履歴に出てこない対象も比較に含められます。
さらに、正例と見分けにくい負例を集める「hard negative mining」も有効です。ただし、難しい負例ばかりにするのではなく、ランダムな負例も混ぜることが重要だと説明されています。何と比較して学ぶかが、モデルの学習に関わってくるわけですね。
実際に配信する段階では、保存済みのベクトルを検索します。近似近傍探索、ANNを使うと高速化できますが、速さを求める一方で、候補を取りこぼす可能性もあります。そのため、検索速度と取りこぼしのバランスを調整する必要があります。
仕組みだけでなく、負例の選び方から配信時の検索まで、つながりを押さえられる内容です。
....
3本目は、AIにコードをレビューしてもらうとき、「議論より、実際に動かす検証を優先しよう」というお話です。
AI同士にコードの欠点を探させても、細かな表現の違いや、今は必要のない機能の指摘に偏ってしまうことがあります。指摘はたくさん出ているのに、肝心のバグは見逃している。そんなことが起こり得るんですね。
筆者にも、47件の指摘では見つからなかった不具合を、pstackを使った再現テストで確認できた経験があるそうです。指摘の数が多いことと、正しく検証できていることは、必ずしも同じではないというわけです。
そこで勧められているのが、AIへの依頼に、「何ができたら完了なのか」と、「確認結果として何を見せてほしいのか」を明記することです。
たとえば、修正前には失敗し、修正後には成功するテスト。こうした証拠を得たうえで、レビューを行います。説明がもっともらしいかどうかだけでなく、実際の動作で確かめるんですね。
AIと何往復も議論していると、それだけで確認が進んだ気分になることもありそうです。だからこそ、完了条件と確認の証拠を先に決めておく。この考え方は、日々の開発でも意識しておきたいですね。
....
続いて4本目は、AIで増えたテストケースを、どう扱うかという話題です。
記事が提案しているのは、「ケースを消さずに、実行対象を絞る」という方法です。AIによって増えたテストケースは仕様書として残し、その中から、リリース前に実行する分を選びます。
選ぶときのリスク判断は、機能全体をひとまとめにするのではなく、「再生が始まる」といった、一つひとつの動作ごとに行います。その動作で不具合が起きた場合の影響と、今回の変更によって不具合が起きる可能性。この両方を見るんですね。
重要な動作は手厚く確認します。一方で、変更がなく、不具合が起きても影響が小さい動作については、過去に不具合が出た条件に絞って確認します。分類を細かくするだけではなく、「何を実行しないか」まで決めることが重要なんです。
そして、選定ルールは、過去のリリースに当てはめて試します。実行件数がどれくらいになるのか、どんな不具合を見逃すのかを確認するわけです。記事では、あるリリースの実行候補を、1,339件から628件に減らせたと紹介されています。
もちろん、実行しない理由も記録します。そのうえで、残るリスクをチームで共有することが大切です。
選定作業はAIで自動化し、空いた時間は、自由に操作して未知の不具合を探すテストに回す。単にテストを減らして終わりではなく、人が探索する時間をつくるという考え方なんですね。
....
最後、5本目は、大規模言語モデル「Kimi-K3.1-Pro」の検証についてです。
Kimi-K3.1-Proは、モデルの重みが公開されていて、自社環境で動かせる大規模言語モデルです。記事では、B300 GPUを8基使って動かし、旧モデルと比べて生成速度が向上していることを確認しています。
性能の検証には、未知のアセンブリ言語でプログラムを高速化する、独自のテストを使っています。その結果、Kimi-K3.1-Proは10モデル中1位となり、少ないトークンで高い成果を出したそうです。
ただし、ここは結果の受け止め方にも注意が必要です。次点のモデルとの差は小さく、実行環境も異なっているため、この順位だけで、あらゆる用途に対して優れていると判断することはできません。
記事が伝えているのは、一般的なランキングだけを見るのではなく、自分たちの用途に合うテストで導入を判断する重要性です。
モデルの名前や順位は、選ぶときの入り口になります。でも、実際に任せたい仕事でどう動くかを確かめることが大切なんですね。自社環境での運用を考える方にも、参考になる検証です。
....
さて、今日の「zenncast」は、5本の記事をお届けしました。
端末と同じ表示を素早く届ける、Neovim用GUIのng。Two-Towerの仕組みと、負例の選び方。そして、AIのレビューでは議論だけでなく、動く証拠を重視すること。テストケースを残しながら実行対象を絞る方法と、Kimi-K3.1-Proを自分の用途に合ったテストで評価するお話でした。
今日は、道具を選ぶにも、コードを直すにも、「実際に確かめる」という視点が印象に残りましたね。
各記事の詳しい内容は、ショーノートに書いてあります。気になった話題は、ぜひチェックしてみてください。そして、番組の感想もお待ちしています。「この話が気になった」「自分たちの現場ではこうしている」など、気軽にお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回も皆さんにお会いできるのを楽しみにしています。お相手はマイクでした。どうぞ、すてきな土曜日をお過ごしください！