今日は実験についての方法について書きます。
実験は研究者だけがするものと思ってはいませんか？
または、実験デザインなんて面倒なこと考えなくてもいいんじゃない？という意見もあるかもしれません。もちろん、何かを可能な限り実験で試すというのは重要で、やってみるべきと思います。
しかし実験には「落とし穴」があります。
その落とし穴にはまり、意味のなさそうな実験が世の中にはたくさんありふれています。
最近、業務で実地検証を行う機会がありました。その際に実験の注意点を考えたので書き留めておきます。
実験デザインのすすめ
何か新しいことを考えたとき、実際に試してみて効果を検証するというのは、机上の空論となることを防ぐので有効と思います。
実地検証をする状況としては例えば：
- 手法（製品・立地）の比較を実地検証する
- 製品の使い勝手についてユーザ評価をする
- 市場調査をする
- 手法Aと手法Bのどちらがよいか既存の統計結果から比較する
といった場合です。つまり手法を決めるためやリリースするか否か何か決めるための根拠になるようなものです。
実験をデザインするのは結構楽しいです。
危険な罠もたくさんあるのでどうやったら安全に結果を出せるかということを考えるのは開発によく似ています。条件がコントロールできない場合や、実験対象者の負荷が高い場合など考えることは多く、実験条件がうまくはまる場合もあればはまらない場合もあり、パズルです。
しかも、実験の結果が実際こうなのだからと説得力が高いのです。
どんな人も事実を覆すことはできません。
「水には感情があるんだ」といわれたら何言ってんだこの○○って思いますが、
「この実験結果からみても水には感情があると言わざるを得ない」とか言われたら、私でもすぐには反論できません。
といっても実験を行うにあたって注意点はたくさんあります。
注意するべき点は下のようなものです。
- どうやって評価するか
- どんな結果がありうるか？
- うまくいかなかった場合、どのような原因が考えられるか
最近業務で実地検証を行う機会があったので、まとめておこうと思います。
具体例で
概念的な話をしてもイメージがわかないと思うので、具体例で説明します。
「社内でAIによるVibeコーディングを行う際に、どういう方法を使ったらよいか」
という問題があったとします。
もっと具体的に比較対象を絞り込みます。
ありうる例を考えるとすると、例えばLLMの比較です。GPTとcopilotのどちらを使ったらいいかを評価するとします。
実際に比較した論文があります。
- SÁGODI, Zoltán; SIKET, István; FERENC, Rudolf. Methodology for code synthesis evaluation of LLMs presented by a case study of ChatGPT and copilot. Ieee Access, 2024. https://ieeexplore.ieee.org/abstract/document/10535504
仮想敵をつくれ！
まず批判してくる側の気持ちを考えることが重要です。
実験者となると自分に都合のいい解釈をしがちです。
開発でも、エラーが出たら「そういう使い方は想定していない」っていうエンジニアがいますよね。まあ、私もそうなんですが。
ツールというものはユーザーの立場からどういう使い方をするのかと考えるべきで、多くのユーザを相手にした場合どんなことが起こるかという考えで設計されるべきです。
そのために開発の段階でも異常系テストとか境界値データテストをせよと言われるわけです。
実験デザインの話に戻ると、
冷静に実験結果を見るとどう見えるのかという視点が重要です。
とはいえ、客観的に見るのは難しいので、敵対的に批判するとしたらどういう観点かと考えることで、問題をつぶしていくことができます。
とはいえ、人に批判されたら立ち直れないというトウフメンタルの人は、
GPTとかに「論理的に」批判してもらうといいです。
どうやって評価するか？
つまり良し悪しを数値化する方法が重要です。
例の場合のねらいとしてはコーディングの質やスピードが向上するなどかと思います。
なので、例えば２グループに分けて、普通にコーディングしたときの時間とAIアシストコーディングしたときにかかった時間の比較や、それぞれのLLM別に時間の比較を行うことになるかと思います。
コーディングの質を評価するのは難しそうですが、バグの数や修正回数とか、人の「専門家」による判定などの手段がありえます。
人による評価もちょっと工夫が必要です。
人は「空気」を読んだ行動をする可能性があったり、わざと意図と逆の反応をしたり、特別なことをしたら特別な効果があると信じてしまうプラシーボ効果のようなものが有ったりするので、公平におこなうなら条件を伏せてブラインドで評価をする必要があります。
こういうのは研究論文を読むと参考になります。
研究論文はほとんどが実験に基づいた議論をしているので、評価値が存在します（稀にないものもあります）。
論文でも数値化に困ったら最後は人によるアンケートになるようです。
最近は言語の類似性をLLMやBERTなどの言語モデルでおこなったり、VLMでおこなったりという指標も出てきています。ぜひ論文をチェックしてみてください。
どんな結果がありうるか
どういう結果が理想的でしょうか？
人のコーディングとAIアシストのコーディングであればAIを使った方が開発時間が効率化されるといった効果が出てほしいと思います。
つまり、上の例でいうとグループAは普通のコーディング、グループBはGPTによるAIアシストコーディングで、グループBの開発時間平均がグループAの開発時間平均に比べて１時間少なくなったなどです。
そんな理想的な結果が出た場合、結論は「AIアシストコーディングを使うべき」となります。
覚えておいてほしいのは 実験は結論を導くためにある のだということです。
結論を導くためにはリサーチクエスチョンが必要で、この例でいうと「AIアシストは開発の効率化に寄与するか？」とかもっと踏み込んで言うと「AIアシストコーディングを使うべきか？」です。
製品の評価でいうと、例えば
「従来製品と開発した製品の比較で、改善しているか？」
がリサーチクエスチョンで、結論は「改善した」、または「改善とまでは言えない」、とか「悪化した」となります。
うまくいかない場合は？
今度はうまくいかない場合です。エラー処理みたいなものかもしれません。
上の例でいうと、２つあると思います
- グループAとグループBで開発時間に大きな違いがなかった（効果が同程度）
- グループAよりグループBのほうが開発時間が長かった（逆転してしまった）
そもそも違いがある無しはどう判断するべきかという話は統計の話なので、そのうち別にブログ記事を書きます。
どう判断するかの例
→ 違いが無かったけれど出そうという場合
頑張ってもう少しデータを取る
→ いくらやっても違いがでそうにない、むしろ予想に反して逆転してしまった😢
実験自体を見直した方がいい
→ 逆にとてもうまくいった！差が出た！すごい発見をしてしまった。学会発表しちゃおうかな
よかったですね。でもまず、落ち着いて実験データを可視化して細かく確認してみましょう。
全体の結果ではなく、実験でコントロールできていなかった個体差・個人差の影響の結果の可能性もあります。
なぜうまくいかないの？そもそも開発時間に個人差がありすぎる
うまくいかない場合、原因を考えてみます。開発における異常系処理のようなものです。
初心者がやったら１週間ぐらいかかっているものが、熟練開発者が３０分でできたなんてことはよくあります。得手不得手はかなり時間に影響するので例でいうとグループの選び方を公平になるように見直した方がいいです。もしくは大量に実験するとか。
一般化して言うと、個体差、試行による誤差の影響が大きいと結果も不安定になりがちです。
特に医療の統計ではよく有り得ます。ある病状のひとと、健康な人の比較をすることを考えます。
一般に病気の人は希少性が高く健康な人の平均より年齢が高めとなるのではないでしょうか。つまり、グループの選び方にすでにバイアスが載っている場合がありうるということです。
条件が違っていた
例えばグループAとグループBに与えていた課題の難易度が違っていたとか、
課題に取り組んでいた部屋の温度が一方は快適温度でもう一方はクーラーが壊れた部屋で取り組んでいたとか。
同じ人が入っていて先にやっていたので２回目は速くできたとか。
二つのグループを同時で進行していたとして、片方のグループが速く終わったのでもう一方も焦ってやったら速くできてしまったとか。
実験順序による違いはよくあります。
心理実験でも最初はやる気があってやっていても１００回やると最後の方は飽きて集中力も落ちてくるけど、最後の方に重要な条件の実験が割り当てられている場合など。そんなことやるわけないと思っていても、忙しかったり考えることが多いと十分に有り得ます。
これを避けるための方法としては実験の際の順番はランダムに行うことです。
上のコーディング実験の例でいうならグループA、グループBの被験者をバラバラにランダムな順番で課題に取り組んでもらうとかですかね。
また実験の際の条件は詳細に記録しておくことです。
問題がありそうな場合は分析から除外するためです。
それでも意図しない結果はありうる
学生の頃大学の研究室でよくあったことですが、
数値実験をしているとデータを学習用とテスト用に分けますが、ある条件の時にテスト用まで学習してしまって性能が群を抜いて良くなったということがありました。
その人は「すごい技術を発見してしまった」と強気で主張していましたが、
その後、学習していない簡単なデータで試してみたら全く逆の結果が出てしまいました。そこでコードを見直してバグが見つかったようで落ち込んでいました。
意図しない結果というのはよくあります。
開発でも、開発者はいつも同じ順番でテストして問題がないことを確認しますが、ユーザは開発者と違う順番で行うことがあるので、使う段階でバグに気づくとかよくありました。（経験談です）
最後に
実験をする前に対象者（被験者）の気持ちになって考えてみることを勧めます。
結局、このブログは実験の心構え的な話になってしまいました。
実験組み合わせの方法とか統計分析の方法とか、実験について語ることはたくさんありますので、そっちは次の機会に書きます。
Discussion