タグ・15本
ベンチマーク
XGBoostとLightGBMの比較はseedで変わるか—評価件数と順位の安定性を検証
モデル比較で出た僅差を、1回の結果だけで判断してよいのでしょうか。Adultデータで分割を120回変え、訓練件数と評価件数を分けて比較しました。評価だけを減らすとLightGBMの勝率は99.2%から66.7%へ低下。AUC差のばらつきと逆転割合を確認する方法を紹介します。
Claude Codeのトークン消費は何で変わる？節約術とBash実行を88回比較
Claude Codeのトークン消費を抑えるための/clearや出力指定を同条件で比較しました。個別の削減効果を確認できなかった一方、Bash実行を許可しない条件では推定コストの最大値と最小値が10倍以上開きました。手元の環境で消費のばらつきと生成物の品質を確かめる手順も示します。
変化点検知はペナルティ次第でF1が3倍変わる—手法を選ぶより先に決める設定
変化点検知のライブラリ ruptures で、手法とペナルティのどちらが結果を左右するかを実測しました。同じ Pelt でも F1 は 0.275 から 0.931 まで動き、真の変化点が平均4.4本のところ平均37.0本を検出した条件もありました。位置が分かっている合成信号で3手法とペナルティ4水準を採点し、自分のデータで値を決める手順までまとめました。
ARIMA・指数平滑はナイーブ予測に勝てるか—平均では勝ち、週次では4割の系列で勝てなかった
ARIMAや指数平滑が「前の値をコピーするだけ」のナイーブ予測に勝てているかをM4データの859系列で実測しました。平均誤差では古典手法が勝ちますが、系列ごとに見ると週次では4割で勝てていません。月次で最下位だったのは季節ナイーブでした。
正解率99%でも少数派recallは0—不均衡データで何を見るか
少数派が1%のデータでは、多数派を出すだけのダミー分類器でも正解率は99%に届き、少数派を1件も当てられません。実力差はPR-AUCと少数派recallに現れますが、学習済みモデルでも少数派を全件見逃す回があり、1回の測定では優劣を決められないことも分かりました。3つの不均衡度×20シードで実測しています。
不均衡データにSMOTEやクラス重みを最初から入れるべきか、LightGBMの無処置を基準に測りました。合成データ4水準でも実データ1件でも、4つの対策は無処置の平均PR-AUCを一度も上回れません。少数派1%では無処置0.558に対しSMOTE 0.494で、差は不均衡が強いほど広がりました。
LIMEの結果が実行ごとに変わるときの確認方法｜kernel_widthとnum_samplesを比較
LIMEの結果が実行ごとに変わるとき、kernel_widthとnum_samplesのどちらを見直すべきか。近傍幅5水準とサンプル数2水準を比較し、連続値の離散化を切った10特徴の実験結果と確認手順を紹介します。既定幅の4分の1では、上位3の一致率が平均0.34まで低下しました。
Claude Codeのeffortは上げるべきか。120回のコードレビューで比べた
Claude Codeのeffortをlowからmaxへ上げると、出力トークンは16.6倍・所要時間は6.9倍になりました。バグ検出率の測定値は上向いたものの、8タスクでは差を確定できません。仕込んだ30個のうち7個は、どの段階でも一度も指摘されませんでした。
CLAUDE.mdは短いほど守られる？ 8条件・計96回で検証
同じ7つのコーディング規約を7通りのCLAUDE.mdに書き分け、ファイルなしの対照条件と合わせて、Claude Code（Haiku 4.5）で96回実行しました。40行版が最も高かったものの、196行から779行へ増やしても遵守率は下がりませんでした。長さ、置き場所、命令形、反復、許可リストの違いを実測結果から見ていきます。
日本語RAGのHyDE・マルチクエリを実測—正解順位はむしろ下がった
日本語RAGへHyDEとマルチクエリを足し、JSQuAD 500問で比較しました。どちらもdense単体よりnDCG@10・MRR@10が低下し、生成には数秒から数十秒かかりました。悪化した実例と、手元で動くHyDE実装を掲載します。
XGBoost・LightGBM・CatBoost比較—精度と学習時間で選ぶ
既定設定ではCatBoostのROC-AUCが最も高いものの、その差は学習データが数万件まで増えるとほぼ消えました。学習時間はCatBoostが全条件で最も遅く、最速ライブラリの16〜40倍。二値分類3データセット計10条件の実測から、データ規模と学習回数に応じた選び方を整理します。
RAGのハイブリッド検索を実測比較—BM25・dense・RRFの選び方
BM25・dense・RRF融合を日本語500問で比較しました。単体同士の検索精度は区別できませんでしたが、RRF融合はnDCG@10・MRR@10を改善。個別クエリ、速度、手元で動く実装例まで掲載します。
日本語RAGリランカー5種を実測—取りこぼしの改善は確認できず、正解順位は上がった
日本語RAGのリランカー5種を500問で比較しました。Recall@5は改善を確認できませんでしたが、4種でnDCG@10・MRR@10が上昇。精度と追加レイテンシの実測、手元で動く実装例を掲載します。
RAGのチャンク分割は段落で切るか文字数で切るか—100文字・重なりなしでは正解が境界で消えた
日本語RAGでチャンクの区切り方を8構成で比べたところ、元の段落境界を使う構成の順位品質が最も高く、100文字・オーバーラップなしでは500問中20問の正解が境界で分断されていました。段落構造を使えない文書での起点は200〜400文字・オーバーラップ20%。100〜800文字の実測と、手元で動く実装例を掲載します。
日本語RAGの埋め込みモデル9種比較—大きいほど検索精度が上がるとは限らない
ruri-v3・multilingual-e5・static-embedding-japaneseなど日本語の埋め込みモデル9種をApple M1で比較しました。検索3指標の測定値はruri-v3-130mが最も高く、310mへ大きくしても上がりませんでした。JSTS・JSQuADによる精度・速度・サイズの実測から、用途別の選び方と注意点を整理します。