The Revenge of the Data Scientist｜データサイエンティストの逆襲

img.img-fluid { border: 1px solid rgba(255, 255, 255, 0.25); border-radius: 4px; } データサイエンティストの黄金時代は終わったのでしょうか。ハーバード・ビジネス・レビュー（Harvard Business Review）はかつて、これを「21 世紀で最もセクシーな職業」と呼びました。1 テクノロジー業界では、データサイエンティストの役割はしばしば最高水準の報酬を得るものの一つでした。2 この仕事にはまた、異例とも言えるスキルセットの組み合わせが求められました： データサイエンティスト（名詞）：どのソフトウェアエンジニアよりも統計学に優れ、どの統計学者よりもソフトウェア工学に優れた人物。 — JosH100 (@josh_wills) 2012 年 5 月 3 日 これらのスキルは参入障壁を高めるだけでなく、データサイエンティストが予測モデル（predictive models）の構築や因果関係（casuality）の測定、データ内のパターン発見を可能にしました。このうち、予測モデリングが最も高い報酬をもたらしました。その後、企業はこの業務を切り離し、新しい肩書きである機械学習エンジニア（Machine Learning Engineer、「MLE」）3 を設けました。 長年にわたり、AI の実装とは、データサイエンティストと MLE をクリティカルパスに据えることを意味していました。しかし、大規模言語モデル（LLM）の登場により、これがデフォルトではなくなりました。ファウンデーション・モデル API（Foundation-model APIs）が現在、チームが AI を独自に統合することを可能にしています。 このようにループから外されたことは、私が知るデータサイエンティストや MLE たちを動揺させました。もし企業が AI の実装のためにあなたを必要としなくなったなら、その仕事に以前と同じような upside（将来性）があるかどうか疑問を抱くのは当然です。人々が自分自身に語るより厳しい物語はこうです。「ファウンデーション・モデル研究所で事前学習（pretraining）を行っていない限り、あなたは最も重要な現場にはいない」というのです。 私は逆の視点から読みました。モデルのトレーニングは仕事の大部分ではありません。実際の業務の大半は、AI が未見データにどの程度一般化するかを検証するための実験を設計し、確率的システムのデバッグを行い、適切な指標を策定することです。LLM を API 経由で呼び出すだけでは、こうした作業がなくなるわけではありません。 私はこの主張を実例を挙げて裏付けるために、最近 PyAI Conf で「データサイエンティストの復讐」と題した講演を行いました。以下は、そのプレゼンテーションに注釈を加えたバージョンです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_1.png) ハルネスこそがデータサイエンスである ![image](https://hamel.dev/blog/posts/revenge/images/slide_2.png) OpenAI は、ハルネスエンジニアリングに関するブログ記事を公開しており、そちらも読むことをお勧めします。同記事では、Codex が数ヶ月にわたり自律的にソフトウェアプロジェクトに取り組む様子が記されています。これは、テストと仕様によって制約されたハルネスの中でエージェントがコードを開発する仕組みです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_3.png) そのブログ記事には、見落としやすい重要な詳細があります。ハルネスには観測スタック（observability stack）が含まれており、ログ、メトリクス、トレースがエージェントに公開されています。これにより、エージェントは自分が軌道から外れたことを検知できます。テストと仕様に加えて、メトリクスも存在します。これがシステムの重要な構成要素です。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_4.png) Andrej Karpathy の自動研究プロジェクトでも同様のパターンが見られます：モデルは検証損失（validation loss）という指標に対して反復的に最適化を行います。同じ考え方で、異なるハルネスを採用しているだけです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_5.png) 私が皆さんに納得していただきたいのは、ハルネス（harness）の大部分がデータサイエンスであるという点です。 一歩引いて、現在の状況を振り返ってみましょう。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_6.png) 数年前は、実践者はデータを時間をかけて精査し、ラベル整合性を確認し、指標を設計していました。しかし今日では、「雰囲気」に頼り、モデルがうまくできたかどうかを尋ね、データも確認せずに市販のメトリクスライブラリを利用しています。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_7.png) これは特に検索（retrieval）と評価（evals）の周辺で顕著に現れます。データに関する背景知識がないエンジニアは、理解できないものを恐れます。「RAG は死んだ」「評価は死んだ」と主張しながらも、実際にはそれらの概念に依存するシステムを構築しています。 この投稿の後半では、私が繰り返し目にする5つの評価（eval）の落とし穴と、それぞれのケースでデータサイエンティストがどのように異なるアプローチを取るかを解説します。 汎用的なメトリクス 最初の落とし穴は、汎用的なメトリクスです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_9.png) 評価フレームワークに飛びつき、そのメトリクスをそのまま利用したくなるものです。しかし問題点は、実際に何が壊れているのか全くわからないことです。多くのチームは、有用性スコア、一貫性スコア、ハルシネーション（幻覚）スコアなどを含むダッシュボードを設置します。これらは理にかなって聞こえますが、アプリケーションの失敗を診断するには汎用すぎて役に立ちません。 データサイエンティストは、市販の指標をそのまま採用したりしません。彼らはデータを探索し、トレースを確認し、「ここで実際に何が壊れているのか？」と問いかけ、測定するべき最も価値の高いものを特定します。測定すべきことは無限にあります。仮説を立てて反復することが必要です。 この罠に対する最良の治療法は、データを見ることです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_12.png) 実践において「データを見る」とは何を意味するのでしょうか？それはトレースを読むことを意味します。ドメイン特有の癖に合わせて摩擦を取り除き、表示をカスタマイズできるよう、独自のトレーサービューアーをコードで実装してください。発見した問題についてはメモを取ってください。エラー分析を行い、失敗を分類し、何を優先すべきかを特定し、何に取り組むべきかを決断してください。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_13.png) データを見ていると、最終的にはアプリケーション固有の指標へと向かって進んでいきます。ROUGE や BLEU といった市販の類似度指標は、LLM の出力にはほとんど適合しません。重要となる指標とは、「カレンダースケジュール失敗」や「人間へのエスカレーション失敗」のようなものです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_14.png) この記事から得ておくべきことは一つだけあります：データを見てください。どのように見るかは別の問題であり、練習が必要です。これはあなたが取り組める中で最も高い ROI（投資対効果）をもたらす活動ですが、しばしば省略されてしまいます。 検証されていない判事 2 つ目の落とし穴は、検証されていない審査員です。多くのチームは、AI が機能しているかどうかを判断するために LLM を審査員として使用しています。しかし、「どうやって審査員を信頼すればよいか」という問いに対して、誰も良い答えを持っていないことがほとんどです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_15.png) デフォルトの手法は、LLM に出力物を評価尺度で評価させ、その数値を使用することです。データサイエンティストであれば、審査員を分類器（classifier）として扱います。ブラックボックスが予測結果を返してくる場合、どうやってそれを信頼すればよいでしょうか？人間によるラベル付けを行い、データを訓練用・検証用・テスト用に分割し、分類器が信頼できるかどうかを測定します。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_18.png) トレーニングセットから少数ショット（few-shot）の例を取得します。審査員のプロンプトを検証セットに対してヒルクライム（hill-climb）させます。過学習していないことを確認するために、テストセットを別途確保しておきます。もし機械学習の経験がある方であれば、これは退屈な作業に思えるかもしれません。しかし、実際には誰もこれを行っていません。分類器の検証は、現代の AI において失われつつある芸術となっています。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_19.png) 結果を報告する際も、審査員を分類器として扱うべきです。私が訪れるあらゆる場所で精度（accuracy）が報告されていますが、失敗モードが 5% の頻度で発生する場合、精度はシステムの真のパフォーマンスを隠してしまいます。適合率（precision）と再現率（recall）を使用すべきです。 悪い実験設計 3 つ目の落とし穴は実験設計です。これには多くの次元があります。その中で最も頻繁に現れる 2 つをご紹介します。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_20.png) まず一つ目はテストセットの構築です。多くのチームは、LLM に「テストクエリを 50 個生成してください」とプロンプトして合成データを生成しています。しかし得られるのは一般的で代表性に欠けるデータです。データサイエンティストであれば、まず実稼働中の実際のデータを分析し、仮説を立ててどの次元が重要かを特定した上で、その次元に沿って合成例を生成します。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_23.png) 合成データは実際のログやトレースに基づいて作成すべきです。どの次元を変化させるべきかを見極め、エッジケース（境界条件）を組み込みます。合成データの基礎となるのは実データです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_26.png) 二つ目は指標設計です。チームは評価基準全体を一つの LLM 呼び出しにまとめ、デフォルトで 1 から 5 のリッカート尺度（Likert scale）を採用しがちです。データサイエンティストであれば複雑さを減らし、各指標を実行可能なものにし、ビジネス成果と結びつけます。主観的な尺度は、スコープ内の基準に基づくバイナリの合格/不合格に置き換えるべきです。リッカート尺度は曖昧さを隠し、システムパフォーマンスに関する難しい判断を先送りする結果になります。 Bad Data and Labels（不正確なデータとラベル） 四つ目の落とし穴は、不正確なデータとラベルです。データサイエンティストはデータを信頼しません。ラベルも信頼しません。何もかもが疑わしく見えます。彼らは訓練によって懐疑的になるように鍛えられています。大規模な AI エンジニアリングの現場では、まだこのスキル（マッスル）が確立されていません。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_27.png) ラベリングに関しては、多くのチームがそれを他者の問題にしてしまいます。ラベリングは派手さがないため、開発チームに任せるか外部委託されてしまいがちです。しかしデータサイエンティストは、ドメインの専門家がデータをラベル付けし、ラベルに対して懐疑的であり続け、データそのものを見るべきだと主張します。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_30.png) しかし、ラベリングが重要である理由は、単にラベルの品質だけではありません。データを見てみなければ、自分が何を求めているかを知ることは不可能です。「基準のドリフト（criteria drift）」という概念があり、Shreya Shankar 氏らによる論文で実証されています。ユーザーは出力を評価するための基準が必要ですが、出力を評価するプロセスを通じてこそ、ユーザー自身がその基準を定義できるのです。LLM の出力を見るまで、人々は自分が何を求めているかを知りません。ラベリングのプロセス自体が、何が重要かを浮き彫りにします。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_31.png) データサイエンティストはこれを支持しています：要約スコアではなく、生データにドメインの専門家やプロダクトマネージャーを直接立ち会わせるべきです。 自動化しすぎること 5 つ目の落とし穴は、過度な自動化です。これらすべてが人手による作業であるにもかかわらず、それを自動化してしまおうとする誘惑があります。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_32.png) ![image](https://hamel.dev/blog/posts/revenge/images/slide_33.png) LLM はシステムを接続したり、基盤となるコード（plumbing）を書いたり、評価用の定型文を生成したりするのに役立ちます。しかし、データを見てくれることはできません。先ほど議論したまさにその理由からです：出力を見るまで、自分が何を求めているか分からないのです。 その他の落とし穴 すべての落とし穴を網羅する時間はありませんでした。残りの部分については、スピードラン形式で解説します。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_34.png) 類似度スコアの誤用。「有益か？」といった曖昧な質問を評価者に投げかけること。生 JSON をアノテーターに読ませること。信頼区間なしでキャリブレーションされていないスコアを報告すること。データドリフト、過学習、不適切なサンプリング、意味をなさないダッシュボードなど。 マッピング 少し視点を変えて見ると、上記のすべての落とし穴には共通する根本原因があります。それはデータサイエンスの基本原理を見落としていることです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_35.png) トレースを読み込み、失敗を分類することは探索的データ分析（Exploratory Data Analysis）です。LLM 評価者を人間のラベルに対して検証することはモデル評価（Model Evaluation）です。本番環境のデータから代表的なテストセットを構築することは実験計画（Experimental Design）です。ドメインエキスパートに出力をラベル付けさせることはデータ収集（Data Collection）です。製品が本番環境で機能しているかを監視することはプロダクション ML です。これらすべては新しいことではありません。名称が変わっただけで、仕事の内容自体は変わっていません。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_36.png) これは Python 会議ですので：Python は依然としてデータを閲覧し、データに対処するための最良のツールセットです。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_37.png) より詳細な解説を行うオープンソースプラグインを作成しました。これを評価パイプラインに指し示すだけで、何が間違っているか（あるいはできる限りそれを）教えてくれます。 ![image](https://hamel.dev/blog/posts/revenge/images/slide_38.png) 常にデータを注視してください。 この講演のミームを楽しんでいただけたなら、私のウェブサイトにはさらに多くのミームがあります。 これらのトピックについてより深く学びたい場合は、スライドと動画は以下にあります。 本講演の構成に多大な貢献をされた Shreya Shankar 氏および Bryan Bischof 氏に感謝いたします。 動画とスライド スライドへのリンク 脚注 https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century↩︎ https://www.forbes.com/sites/louiscolumbus/2018/01/29/data-scientist-is-the-best-job-in-america-according-glassdoors-2018-rankings/↩︎ https://www.mckinsey.com/about-us/new-at-mckinsey-blog/ai-reinvents-tech-talent-opportunities↩︎

データサイエンティストの逆襲

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト