6 posts
Differential testingを使えば、正解を知らなくてもバグを見つけられる。問題は、相関した誤りが合意に見えることだ。盲点を見つける方法は以下の通り。
形式的証明がなくてもdifferential testingを信頼できるが、その前提はどこで破綻するかを正確に理解していることだ。 その弱点はcommon-mode failureと呼ばれる。specificationのすべての実装が同じ誤った仮定をした場合、それらはすべて合意し、test…
N-version programmingは実装が一致することを前提とする。テストがなぜ不十分なのか、SMT solverがいかにして等価性を実際に証明できるのか、そして「十分に良い」と「形式的に検証済み」の境界線をどこに引くべきかを見ていく。
n版システムを構築した。同じクリティカルな関数を3つの独立した実装で用意し、多数決で結果を選ぶvoterを置き、単一障害点を凌駕したという満足感に浸っている。 だが、あなたは関数が等価であることを証明していない。コンパイルが通ることを証明したにすぎない。 n-version…
複数のLLMを並列実行すると、どの単一モデルも見逃すエラーを捕捉できる。実際に機能する不一致解決システムの構築方法を解説する。
GPT-4oにプロンプトを投げる。confidence 0.97のJSON blobが返ってくる。同じプロンプトをClaude 3.5 Sonnetに投げる。異なるJSON…
N-version programmingは単純に聞こえる。複数の実装を実行して最良の答えを選ぶ。しかし実際には、「最良」を定義することは「最も一般的」を定義するよりはるかに難しい。
同じ関数の5つの実装がある。3つは同じ結果を返す。1つは少し違う。1つは例外を投げる。どれが正しい？ ほとんどのチームは多数決をデフォルトにする。出力が同一でエラーが明らかな場合はうまくいく。しかし、実装が微妙に異なる場合や、すべてのバリアントが異なる答えを返す場合、それは崩壊する。N-version…
LLMによるN-version programmingに複数のモデルは不要。プロンプト、ペルソナ、推論の制約を変えることで、単一モデルから多様で正しい実装を引き出せる。
N-version programmingでは、多様性は異なる作成者から生まれるものだと想定されている。LLMの場合、それは異なるモデル、異なるプロバイダー、あるいは異なる学習実行を意味する。だがこの前提は間違っている。同じモデルから、問う内容ではなく問い方を変えることで、意味のある多様性を得られる。…
N-version programmingは、独立したチームが独立したミスをすると約束した。KnightとLevesonの1986年の実験はその逆を証明し、NASAは静かに撤退した。
1980年代初頭、NASAは今日も safety-critical engineering を悩ませる問いに直面していた：まだ発見されていないバグをどう許容するか？彼らの答えは N-version programming…