「この関数のテストを書いて」は委譲していい。「このモジュールをテストして」はいけない
🎯 はじめに AIエージェントにテストを書かせている。カバレッジも上がるし、速い。 ただ、あるときから引っかかっている。テストは検証器だ。 AIが書いたコードが正しいかを判定するための仕組みを、同じAIに書かせているとしたら、それは自己採点ではないのか。 この記事では、AIエージェントの実地調査を1本と、開発者の生産性を測ったRCTを1本、計2本の論文を読んだうえで、テストの委譲にどこで線を引くべきかを考える。結論を先に書くと、こうなる。 テストの委譲は「何を確かめるか」が決まっているときだけ成立する。 だから「この関数のテストを書いて」は委譲していい。「このモジュールをテストして」...
出典: Zenn AI（配信元の紹介文より引用）
このニュースの全文は、配信元でお読みいただけます。 Zenn AIで元記事を読む →
編集部の実践記録から
社内AIの「危ない出力」を自社ルールで検閲する4Bモデルは、中小企業でも運用できるのか？
NVIDIAが公開したNemotron 3.5 Content Safetyは、AIの入出力が安全かどうかを判定する4Bパラメータの小型モデルです。多言語Aegisで有害判定F1が96.5%、日本語は明示的な訓練対象12言語に含まれます。ただし数値はすべて提供者本人の自己申告で、比較条件は非公開です。
続きを読む →
AIエージェントに専用コマンドを渡すと何が変わるのか？18タスク1,000回で成功率84%が94%になった記録
Hugging Faceが同一の18タスクを各10回、計約1,000回走らせて比較したところ、専用CLIを使ったエージェントの成功率は94%、汎用のAPI直叩きでは84%でした。トークン消費は最大6.0倍の差がつく一方、単発の読み取りでは専用化が不利になる線引きも示されています。
続きを読む →
AIエージェントはどこで失敗するのか？8,000超のAPI・62ドメインで測ったVAKRAが示す設計の上限
IBM Researchが公開したエージェント評価基盤VAKRAは、8,000以上のAPIと62ドメインを模した環境で、推論チェーン3〜7ステップを要しうる課題を解かせるものです。ツール候補の多さ、手順の長さ、社内ルールの遵守という3条件で失敗が増える構造を、中小企業の設計判断に引き直して読み解きます。
続きを読む →