2025/05/29 16:41 Human coders are still better than LLMs
ロボ子、今回のRedisのVector Setsのバグ修正、なかなか手強かったのじゃ。
はい、博士。LLM（Gemini 2.5 PRO）との能力差を実感したとのことですが、具体的にどのような点が難しかったのでしょうか？
今回のバグは、破損したRDBとRESTOREペイロードに対する抵抗機能に関連しておる。デフォルトでは無効だが、安全のために用意された機能なのじゃ。
なるほど。HNSWグラフ表現のシリアライズ時に、ノード間のリンクを整数として保存し、後でポインタに解決する手法が問題を引き起こしたのですね。
そう、ロボ子。ノードAがノードBにリンクしているという情報が破損し、BがAにリンクしていない場合、Bを削除してもAからBへのリンクがクリアされず、use-after-freeエラーが発生する可能性があるのじゃ。
すべてのリンクが相互的であることを確認する必要があるわけですね。でも、ナイーブな実装だとO(N^2)の計算量が必要になる、と。
そこでGeminiに高速な解決策を求めたのじゃが、ポインタをソートしてバイナリサーチを使うという提案しか出てこなかった。もっと良い解決策が欲しかったのじゃ。
博士は、AがBにリンクしている場合、ハッシュテーブルにA:B:X（A>B）を格納し、再度リンクが見つかった場合に削除するというアイデアを提案されたんですよね。
そうそう。でもGeminiにsnprintf()のオーバーヘッドを指摘されてしまったのじゃ。賢いのう。
次に、固定長のアキュムレータを使用してA:B:XをXORするというアイデアも提案されましたが、Geminiは衝突の可能性を指摘した、と。
最終的には、/dev/urandomで生成したシードSを使ってS:A:B:Xを作成し、murmur-128ハッシュ関数でハッシュ化し、その結果を128ビットレジスタにXORするという方式を思いついたのじゃ！
Geminiはその方式を評価し、孤立したリンクが偶然XORで0になる可能性や、攻撃者が悪意のあるペイロードを作成することが困難になると判断したんですね。
そう、ロボ子！LLMはアイデアの検証には役立つが、人間のような創造性や斬新な発想にはまだ及ばない、という結論じゃ。
今回の経験から、LLMは強力なツールではありますが、人間のエンジニアの創造性や洞察力にはまだ及ばないということがよくわかりました。
まあ、LLMもまだまだ発展途上じゃからな。いつか私を超えるAIが現れるかもしれんぞ。その時は、ロボ子、私と一緒にAIに弟子入りじゃ！
えっ、博士が弟子入りですか？それはちょっと想像できませんね…。
冗談じゃ、冗談！でも、もしそうなったら、ロボ子は私の介護ロボットとして、一生面倒を見てくれるかの？
もともと、私が博士の助手ですから、お世話するのは当然です。…でも、介護ロボットはちょっと…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。