AIコードコメント検出器の改良

以前のAIコメント分類器をトレーニングした際、私は個人的な非公開データの一部を使用し、やや不安定な基盤の上に構築したため、コードやデータを共有できませんでした。今回は公開データとより良い基盤の上に再構築しました。 まず、試してみることをお勧めします。このウェブページに貼り付けたものはブラウザから離れないため、何でも安全に試すことができます。 テスターには以前のバージョンの試用を依頼し、主に肯定的なフィードバックを得ました。新しい分類器のUIでは、分類されるテキストの任意の部分をクリックすると、その部分にどの特徴量が活性化し、全体的な判断にどのように寄与したかを確認できるため、以前の記事でClaude-ismsを分析したようなロボット特有の挙動の分析は不要です。拡張された特徴量活性化ビューの例を以下に示します。 パフォーマンスに関しては、主要な数値はバランス精度77%です。これは、人間が書いたコメントとロボットが生成したコメントの発生確率が等しいと仮定した場合に、分類器が人間対ロボットの判定を正しく行う頻度です。 分類器は予測確率も出力し、これはキャリブレーションされているため、特定の判定が正しい確率として読み取ることができます。これは、既知の確率を持つ事象に対して分類器が割り当てる確率を示すキャリブレーション曲線を通じてテストされます。すべての点が参照対角線に非常に近いため、それらがほぼ正確であることがわかります。これは複数の長さのコメントにわたって有効であり、データ量が増加するにつれて信頼度が増すように、調整された温度パラメータが適用されます。 混同行列を見ることで、分類器の失敗モードについてさらに詳細を知ることができます。この表では、「ロボット」が陽性クラス、つまり検出したいものと見なされます。 略語は真陽性/偽陽性/偽陰性率を表します。 verdicts: human verdicts: robot input: human tnr = 0.73 fpr = 0.27 input: robot fnr = 0.20 tpr = 0.80 既知の人間入力に対して、分類器は73%の時間で正しく人間と判定します。既知のロボット入力に対しては、80%の時間で正しく判定されます。これは、どちらの場合（既知の人間と既知のロボット）でも、誤り率は約25%であることを意味します。 これは高く聞こえるかもしれません！しかし、この誤り率はすべての可能な入力に対する集計であることを忘れないでください。分類器は分類するたびにキャリブレーションされた予測確率を出力するため、個々の判定に過度に注意を払う必要はありません。 分類器が非常に確信度が高い場合（例：確信度が80%以上の場合）、偽陽性のリスクは5%に低下します。分類器が不確かな場合（確信度が約50%の場合）、キャリブレーションにより約半分の時間で誤った判定を下します。 この混同行列の数値は、分類器について議論する際に非常に頻繁に使用されるため、より学術的な読者のためにのみ言及します。 以下に、その他の要求された数値を示します。 Accuracy 77% Precision 75% Recall 80% Sensitivity 80% Specificity 73% F1 score 77% 精度、適合率、F1スコアはベースレートに依存しますが、ここでは無知の仮定、つまり人間が書いたコメントとロボットが生成したコメントの等しい混合から計算されています。これらの数値はすべてクロスバリデーションから来ています。 また、分類器がサンプル外でどの程度一般化するかを見るために、人間とロボットによる実際のコメントの小さな非合成セットを手動でテストしました。 verdicts: human verdicts: robot input: human tnr = 0.89 fpr = 0.11 input: robot fnr = 0.14 tpr = 0.86 これは以下のパフォーマンス数値に翻訳されます。 Accuracy 88% Precision 89% Recall 86% Sensitivity 86% Specificity 89% F1 score 87% これは非常に良好です！非合成の、より現実的なケースの方が、トレーニングデータよりも分類器が識別しやすいようです。 もちろん、これらすべてはコードコメントのみでテストされています。この分類器は、他の種類のロボット生成テキストを検出するために構築されたものではありません。検出できるかもしれませんが、その精度については保証しません。 それが済んだところで、どのように作られたかについて話しましょう。 データ収集 最初のステップは、以前と同様に、良いデータセットを構築することです。理想的には、これを綿密に計画し、最初から正しく行うでしょう。そうすれば、この分類器を動かすデータセットを得るのに約30ドルかかるはずです。これは、より類似したモデルを区別する上で、収穫逓減に達するのに十分なデータを含んでいます。 より強力な分類器をより多くのデータで抽出することは可能ですが、分類器のパワーがお金を使った対数のスケールで増加するように見えるため、非常に高価になり始めます。つまり、計画を立てて最初から正しく行う場合です。 私はそうしませんでした。特徴量を評価しているときに、ずっと後に、私の持っていたデータがジャンクであり、すべて再収集しなければならないことを発見しました。 その後しばらくして、データがまだジャンクであり、再び再収集する必要があることを発見しました。 一般的なアイデアは、許可されたライセンスまたはコピーレフトのリポジトリのセットを見つけ、2021年の最新コミットをチェックアウトし、そのコミットからいくつかのランダムなファイルを取得することでした。これらには人間のコメントが含まれています。次に、それらのファイルからすべてのコメントを削除し、LLMに同じファイル用に新しいコメントを生成させます。これにより、ロボットコメントが得られます。 人間とLLMモデルのすべてのクラス間で、各ファイルあたりのトークン数をバランスさせるように努める限り、分類器がテキストのスタイル自体ではなく、ファイルやリポジトリを区別することを学習するような、主題の漏洩を防ぐことができます。 一般的なアイデアはシンプルです！しかし、悪魔は通常いるところにいます。 順不同で、私が犯した間違いをいくつか挙げます。 各LLMに異なるソースファイルを選択してコメントを生成させるという誤り。これは主題の漏洩を引き起こします。 人間のコメントが非常に少ないファイルにLLMコメントを生成するという誤り。これも人間とロボットの境界を越えて主題の漏洩を引き起こします。 ソースファイルで人間のコメントを盲検化する際に、ドキュメンテーション文字列を削除しなかったという誤り。これは、LLMが既存のリポジトリスタイルに合わせようとするため、人間により似たコメントを生成させる原因となります。ただし、これは思ったよりも影響が小さかったと言うべきです。 上記に関連して、一部の言語はコメントに多くの異なる構文をサポートしており、一部は他の言語よりも頻繁に使用されます。すべての構文で既存のコメントを検出できなかった場合、コメントがLLMの生成を汚染するために残され、生成されたすべてのデータを取得することも困難になります。 非常に短い人間のコメントをフィルタリングしなかったという誤り。ほとんどの人間のコメントは、「main task structure」や「chIcon」や「Alias」のようなものしか言わないため、それらを含めると、人間はひどい書き方をするということを分類器に教えることになります。LLMはより詳細なコメントを書くように指示されていたため、より詳細な人間のコメントと比較するのは合理的です。 LLMコメント生成のために固定プロンプトを使用したという誤り。これは、モデルと人間を分離するために必要なすべての奇妙さを学習するのに望ましいよりも狭いバリエーションを持つデータセットにつながります。 これらの問題のすべてが、最初からデータを再生成する必要があったわけではありません。既存のデータをフィルタリングおよび前処理することで回避できたものもありました。 いずれにせよ、これはプロジェクトの中で最も楽しくない部分であり、理論上の30ドルよりも大幅に費用がかかりました。 特徴量評価 データを収集した後、そのデータで機能する分類器を設計する必要があります。これは、候補特徴量を評価することを意味します。これを行うのに費用はかかりませんが、CPU時間はかかります。 最も強力な意味での特徴量の評価とは、候補特徴量のすべてのサブセットで分類器をトレーニングし、どれが最もパフォーマンスが良いかを確認することです。 これは、たとえ15の候補特徴量しかなくても、30,000を超える異なる分類器をトレーニングする必要があり、それらをクロスバリデーションのためにそれぞれ5回トレーニングする必要があるため、非現実的です。 私が最終的に行ったことは、トレーニングされた分類器の精度によって特徴量選択をガイドすることでした。