データサイエンティストの逆襲
(hamel.dev)- LLM APIの登場により、データサイエンティストやMLEはAIリリースの中核経路から外されたが、実務の本質である 実験設計、指標測定、確率的システムのデバッグ は消えていない
- OpenAIのCodex事例とKarpathyのauto-researchプロジェクトはいずれも、テスト・指標・観測スタックで構成されたハーネス(harness) が中核であることを示しており、このハーネスのかなりの部分がデータサイエンスである
- 現場で繰り返し現れる 5つのevalの落とし穴 ― 汎用指標、未検証のジャッジモデル、誤った実験設計、不良データ・ラベル、過度な自動化 ― がAIシステムの品質を損なっている
- 各落とし穴に共通する原因は データサイエンスの基礎不足 であり、探索的データ分析・モデル評価・実験設計・データ収集・本番MLなど既存の方法論がそのまま解決策になる
- 「データを直接見ること」 が最もROIの高い活動であるにもかかわらず最も頻繁に省略されており、データサイエンティストの役割はLLM時代でも依然として中核である
データサイエンティストの復活
- データサイエンティストはかつて 「21世紀で最もセクシーな職業」 と呼ばれ、高い報酬を得ていた
- 予測モデリング、因果関係の測定、データパターンの探索など複合的なスキルが求められた
- その後、予測モデリング業務は Machine Learning Engineer(MLE) として分離された
- LLM(大規模言語モデル) の登場により、企業がAIをデプロイする際にデータサイエンティストやMLEが必須経路から外れる変化が起きた
- Foundation Model APIを通じて、チームが独立してAIを統合できる
- しかし、モデル学習がデータサイエンティストの仕事のすべてではなく、実験設計・デバッグ・指標設計 は依然として中核業務として残っている
- LLM APIを呼び出すだけでは、こうした作業はなくならない
- PyAI Confの「The Revenge of the Data Scientist」発表はこの点を事例中心に扱い、データサイエンスの役割が依然として重要であること を強調している
ハーネス(Harness)の本質はデータサイエンス
- OpenAIの Harness Engineering という概念は、エージェントがテストと仕様に囲まれた環境で自律的にコードを開発する構造を説明している
- ハーネスには ログ、メトリクス、トレース などの可観測性スタックが含まれ、エージェントが自ら異常動作を検知できる
- Andrej Karpathyの auto-researchプロジェクト も、検証損失(validation loss)メトリクスを基準に反復最適化する同じパターンを示している
- 「LLMをAPIとして呼び出すこと」が実験設計・デバッグ・指標設計の仕事をなくすわけではなく、ハーネスのかなりの部分がデータサイエンス である
- 過去にはデータ点検、ラベル整合性の確認、メトリクス設計に多くの時間を使っていたが
- 現在はモデルの「勘(Vibes)」に頼ったり、オープンソースのメトリクスライブラリをそのまま使う傾向がある
- 特に RAG(Retrieval-Augmented Generation) や Evals(評価) の領域では、データ理解不足による誤解が多い
- RAG is dead, evals are dead のような主張も出ているが、そう主張するチーム自身も実際にはその概念に依存したシステムを構築している
- データのバックグラウンドがないエンジニアが、理解できないものを恐れて回避する現象がretrievalとevalsの領域で目立っている
- 「LLMをAPIとして呼び出すこと」が実験設計・デバッグ・指標設計の仕事をなくすわけではなく、ハーネスのかなりの部分がデータサイエンス である
5つのEvalの落とし穴
-
落とし穴1: 汎用指標(Generic Metrics)
- Helpfulness score、coherence score、hallucination scoreのような 汎用指標 は、アプリケーションの実際の障害を診断するには包括的すぎる
- データサイエンティストであれば指標をそのまま採用せず、まずデータやトレースを直接探索して「実際に何が壊れているのか」を把握する
- 「データを見る」 とは、トレースを直接読み、カスタムトレースビューアを作り、失敗を分類するエラー分析(error analysis)を行うことを意味する
- ROUGEやBLEUのような汎用類似度指標はLLM出力にはほとんど適しておらず、「Calendar Scheduling Failure」 や 「Failure to Escalate To Human」 のようなアプリケーション特化指標が必要である
- データを見ることが最もROIの高い活動であり、同時に最も頻繁に省略される
-
落とし穴2: 未検証のジャッジモデル(Unverified Judges)
- LLMをジャッジとして使うチームの大半は、「そのジャッジをどう信頼するのか」 という問いへの答えを持っていない
- データサイエンティストはジャッジを 分類器(classifier) のように扱い、人手ラベルを確保してtrain/dev/testに分割し、信頼性を測定する
- Few-shot例は学習セットから取り、dev setでジャッジ用プロンプトを改善し、test setは過学習確認用に保持する
- 結果を報告する際には単純な accuracy ではなく precisionとrecall を使うべきである — 失敗モードが5%しかなくても、accuracyは実際の性能を隠してしまう
- 分類器の検証は現代AIにおいて 失われた技術 になってしまった
-
落とし穴3: 誤った実験設計(Bad Experimental Design)
- テストセット構成: 多くのチームはLLMに「テストクエリを50個生成してほしい」と依頼するが、この方法では 代表性のない汎用データ が生成される
- データサイエンティストなら、まず実際の本番データを見て重要な次元(dimensions)を把握し、その次元に合わせた合成例を生成する
- 実際のログやトレースに基づいて合成データを生成し、エッジケースを注入すべきである
- 指標設計: ルーブリック全体を単一のLLM呼び出しに詰め込み、1〜5点の Likert尺度 をデフォルトに使うやり方は、曖昧さを隠し、システム性能についての難しい判断を先送りしているにすぎない
- 範囲の狭い基準に対する 二値(pass/fail)判定 に置き換えるべきである
- テストセット構成: 多くのチームはLLMに「テストクエリを50個生成してほしい」と依頼するが、この方法では 代表性のない汎用データ が生成される
-
落とし穴4: 不良データ・ラベル(Bad Data and Labels)
- ラベリングは華やかでないという理由で開発チームに委ねられたり外注されたりしがちだが、データサイエンティストは ドメイン専門家 が直接ラベリングすることを求める
- ラベル品質以外にも、より深い理由がある: Shreya Shankarらの論文で検証された 「criteria drift」 という概念 — ユーザーは出力を評価するために基準を必要とするが、出力を評価する過程でその基準自体を定義していく。つまり、LLMの出力を見るまで自分が何を望んでいるのかわからない のである
- ドメイン専門家やPMを、要約スコアではなく 生データ の前に立たせるべきである
-
落とし穴5: 過度な自動化(Automating Too Much)
- LLMは配管コード(plumbing)の作成、ボイラープレート生成、評価の接続作業を助けられる
- しかし データを直接見る作業は自動化できない — 「出力を見るまで何を望んでいるかわからない」からである
- そのほかに挙げられている追加の落とし穴には、類似度スコアの誤用、「役に立つか?」のような曖昧な質問をジャッジに投げること、アノテータにraw JSONを読ませること、信頼区間なしの未補正スコア報告、データドリフト、過学習、誤ったサンプリング、理解しにくいダッシュボードなどがある
データサイエンス基礎との対応付け
- 5つの落とし穴はすべて、データサイエンスの基礎不足 という同じ根本原因を持っている
- 各落とし穴と既存方法論の対応関係:
- トレースを読む・失敗を分類する → 探索的データ分析(EDA)
- 人手ラベルでLLMジャッジを検証する → モデル評価(Model Evaluation)
- 本番データに基づいて代表的なテストセットを構築する → 実験設計(Experimental Design)
- ドメイン専門家によるラベリング → データ収集(Data Collection)
- 本番環境で製品の動作を監視する → 本番ML(Production ML)
- 名前は変わっても、仕事そのものは同じである
- Pythonはデータを探索し扱うための 最適なツールセット であり続けている
- オープンソースプラグイン(evals-skills) を通じて、evalパイプラインを分析し問題箇所を診断するツールが公開されている
2件のコメント
Hacker Newsの意見
GenAIソリューションを構築する際の良い実践ではあるが、この変化がデータサイエンティストという職種の持続可能性を保証するわけではないと思う
以前は、モデルを自ら作ってビジネス価値を創出する能力があるため、データサイエンティストは注目されていた
しかし今では、LLMプロバイダーとAPIを呼び出すエンジニアがその役割を代替している。LLMの挙動を調整するのは一種のブラックマジックだが、数学的知識が必須というわけではない
今残る仕事は評価とモニタリングだが、これはビジネスの観点では『中核的価値』には見えない。素早くプロトタイプを配布したい組織では、むしろ障害要因とみなされる
結局のところ「データサイエンティストがLLM構築のゲートキーパーになるべきだ」と説得しなければならない状況だが、その論理がどれほど説得力を持つのかは疑問だ
ただ、LLM以外にも依然としてカスタムMLモデルが必要な領域は多いと思う。たとえばAirBnBの検索ランキングやUberのマッチングアルゴリズムはLLMでは置き換えられない
結局、市場が縮小したのは確かだが、完全に消えたわけではない
しかしこのプロセスは、「何を解決しようとしているのか」を明確に定義させてくれる。時にはその答えが「この製品は作る価値がない」かもしれない
ただ、こういう話を聞きたがる人はほとんどいない
SWE出身のAIエンジニアのほうが、むしろ適している場合が多い。「評価 = 自動化テスト」という発想が自然だからだ
実際、多くのエージェントプロジェクトでDSの役割はほとんど消えつつある
データサイエンティストによくする助言だ
LLMを判定者として使うなら、そのモデルも結局は良いサンプルデータを通じてインコンテキスト学習をしなければならない
関連内容は私の本にまとめてある
ただし、あるモデルが別のモデルの出力を評価しなければならない場合、メタ的な構造になってしまい、結局どこかでは「本当の正解」を固定しなければならない
私はデータサイエンス/エンジニアリングのバックグラウンドを持っている
AIを使うのは、まるで解空間を探索するようなものだ。数十億ものパラメータ組み合わせの中から最適点を探す過程だ
プロンプトで探索空間を絞り、意味ベースのヒューリスティクスでより良い解を探そうとする
しばしば局所最適に閉じ込められたり、完全に間違った方向へ進んだりもする。だから毎週コードベースを作り直し、単純化したり機能を追加したりする。そうすることで、より良い解を見つけられる
最近言及されていたpg_textsearchのような事例は、こうした開発手法がうまく合う例だと思う
明確なテストケースとベンチマークがあるときは、成功の可能性が高い
しかし、グリーンフィールド開発では、テストケースを定義することがコードを書くのと同じくらい難しいか、あるいはそれ以上に難しい
また、LLMはしばしばローカルミニマに陥る傾向がある。コード構造が固まると、大規模なリファクタリングをほとんど試みない。ある種のオーバーフィッティングに似た現象だ
AI実験の核心は、モデルが新しいデータにどれだけ汎化するかを検証することだと言われるが、実際には「データが何であるか」を明確に確認するプロセスが抜けている
人々が想定しているデータと、実際のデータが違うことがしばしばあるからだ
私は複雑なLLM判定者ワークフローを作るより、エージェントの挙動を直接観察するほうが、はるかに多くのインサイトを得られる
昨日、KarpathyのautoresearchアプローチをML問題に適用してみた
何度も実験した末に、モデルが見せた結果に驚いた。Kaggleがまだ活発だったなら、AIがほとんどの問題に勝っていたと思う
しかし現実のデータサイエンス業務では、基本的なツールすらきちんと知らない人たちが大半だ。AIを与えたからといって、彼らが突然優秀になるとは思えない
結局、専門家は依然としてジュニアを使って仕事を進め、非専門家は雑な成果物の中で右往左往することになる
だが実際のDS業務は、不完全なデータと曖昧な目標を扱うことがほとんどだ
優れたDSは「これは無理です」と言える必要がある。一方、LLMはいつでも「いいですね、素晴らしいアイデアです！」としか言わない
結局、AI開発も似たようなループだ — 「良い結果が何かを定義し、それとの差を測定し、反復的に改善する」というプロセスだ
ただ、こうした考え方を長くやってきた人たちは、プロンプトエンジニアよりはるかに先を行っている
ここでDSの方々がコメントしてくださったのか分かりません。みんな開発者目線のようなので..