AI

ReviewOps — AI コードレビューを「見て終わり」にしない OSS を公開しました

AI のコードレビューが指摘するだけで終わる問題を解決するために、ReviewOps という OSS を作りました——レビュー結果をカンバンで管理し、人間のトリアージと AI の実行を分担するコントロールループを実現します。

• #OSS
• #AIコーディング
• #開発ツール
• #コードレビュー
• #AI

LLM 評価のブレを多層的に抑える ── スコアが信頼できる数字になるまで

AI に採点させるとき、1 回の採点では誤差か実差か区別できない。繰り返し採点・G-Eval 確率加重・ペアワイズ順序反転・ブートストラップ信頼区間・BH 多重比較補正を組み合わせ、LLM 評価のブレを多層的に抑える設計を整理します。

• #LLM
• #AI
• #Python

3 シグナルで「リリースしてよいか」を判定する ── LLM パイプラインの最終ゲート

Stage 1/Stage 2 の品質ゲートを通過しても、それだけではリリース判断に足りない。ハルシネーション・法的配慮・品質改善の 3 シグナルを統合し、LLM を呼ばずに最終判定する上位ゲートの設計を整理します。

• #LLM
• #AI
• #Python

LLM 出力を AI が採点する ── 絶対評価・ペアワイズと統計的有意性

「前より良くなったか」を人手に頼らず AI に採点させるとき、一回の採点では誤差か実差か区別できない。絶対評価とペアワイズを組み合わせ、繰り返し採点で信頼区間を出す設計を整理します。

• #LLM
• #AI
• #Python

Stage 1 / Stage 2 二段品質ゲート ── LLM の「合格」を 2 種類に分ける

LLM 出力の品質基準には「絶対に許せない最低条件」と「以前より悪くなっていないか」の二種類がある。この二つを分離した品質ゲートを設計し、CI に組み込む方法を整理します。

• #LLM
• #AI
• #Python

テスト結果に「出自ハッシュ」を埋める ── LLM パイプラインの STALE 検出

先週のプロンプトで生成した結果を今日の基準で評価しても意味がない。入力とプロンプトのハッシュを結果ファイルに埋め込み「この結果は今のコードで作られたか」を機械的に判定する手法を解説します。

• #LLM
• #AI
• #Python

3 種の Judge で LLM 出力を立体的に検証する

LLM 出力の評価を「LLM による意味判定」「定量メトリクス」「ドメイン分類器」の三軸に分け、統一インターフェースで束ねる設計パターン。preference leakage を避けるモデル分離の話も含めて整理します。

• #LLM
• #AI
• #Python

テストシナリオを LLM で量産する ── カバレッジマトリクスという考え方

LLM アプリのテストケースを手書きするとすぐ頭打ちになる。入力条件の組み合わせをマトリクスで定義し、LLM にテストデータを生成させてカバレッジを体系的に管理する方法を整理します。

• #LLM
• #AI
• #Python

LLM の出力に「ゴールデンデータ」で回帰テストを仕込む

LLM の出力は非決定的でユニットテストが刺さらない。承認済み出力を「ゴールデンデータ」として git 管理し、プロンプト変更による意図しない出力変化を検出する設計パターンを方法論として整理します。

• #LLM
• #AI
• #Python

プロンプトは書くな、最適化させろ――DSPy/GEPA で何が変わるか

手動プロンプトエンジニアリングの試行錯誤をアルゴリズムに委ねる――DSPy と GEPA が示す自動プロンプト最適化の実力と、その先に変わるエンジニアの役割を整理します。

• #LLM
• #AI

TextGradとDSPyの違いを一言で言うと

どちらも「プロンプトを自動で改善する」ツールだが、その思想はまったく異なる。TextGradは損失を言語で逆伝播させ、DSPyはプロンプトをコンパイルする。

• #LLM
• #AI

LLM でデータセットを作る際の落とし穴とマトリクス設計

LLM による合成データ生成には世代崩壊やバイアス増幅といった構造的な落とし穴がある——その根本には Chat 形式の連続生成という設計ミスがあり、マトリクス×ステートレス単一 API 呼び出しに切り替えることで解決できます。

• #LLM
• #AI