AI製品を迅速に改善するための実践ガイド

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ほとんどのAIチームは間違ったことに集中している。私のコンサルティングの仕事でよく見かける光景を紹介しよう：

AIチーム："これが我々のエージェントアーキテクチャだ。ここにRAGがあり、そこにルーターがあり、そしてこの新しいフレームワークを使って..."

私:[熱狂的な技術リーダーを一時停止させるために手を挙げる] "このどれかが実際に機能するかどうか、どうやって測定しているのか見せてもらえますか？" ... 部屋は静まり返った。

...部屋は静まり返る。

このシーンは、この2年間で何十回も繰り返されてきた。チームは何週間もかけて複雑なAIシステムを構築するが、その変更が役に立っているのか、それとも害になっているのか、私にはわからない。

これは驚くべきことではない。毎週のように新しいツールやフレームワークが登場する中、どのベクトルデータベースを使うか、どの大規模言語モデル（LLM）プロバイダーを選ぶか、どのエージェントフレームワークを採用するかなど、コントロールできる具体的なことに集中するのは自然なことだ。しかし、30社以上のAI製品の開発を支援してきた結果、成功するチームはツールの話をほとんどしないことがわかった。その代わりに、彼らは測定と反復にこだわる。

このレポートでは、成功しているチームがどのように演算子を使っているのかを紹介する。学ぶことができる：

• エラー分析が最も投資収益率（ROI）の高いエラーを常に明らかにする方法

• シンプルなデータビューアーが最も重要なAI投資である理由

• AIを改善するために、（エンジニアだけでなく）ドメインのエキスパートに力を与える方法

• 合成データが思った以上に効果的な理由

• 評価システムの信頼を維持する方法

• なぜAIのロードマップは機能ではなく実験をカウントすべきなのか

それぞれのトピックについて、実際の例を挙げて説明する。状況はそれぞれ異なるが、ドメインやチームの規模に関係なく当てはまるパターンを見ることができるだろう。

まずは、AIプロジェクトが始まる前に頓挫してしまう、チームが犯しがちな間違いから見ていこう。

最もよくある間違い：エラー分析をスキップする

ツールファースト」の考え方は、AI開発における最も一般的な間違いである。チームはアーキテクチャ図やフレームワーク、ダッシュボードにとらわれ、何がうまくいっていて何がうまくいっていないのかを実際に理解するプロセスをおろそかにしてしまう。

あるクライアントは、評価ダッシュボードを誇らしげに見せてくれた（図1参照）。

図1. 失敗を予感させるダッシュボード

これは「ツールの罠」であり、適切なツールやフレームワーク（この場合は一般的なメトリック）を採用すればAIの問題を解決できると思い込むことである。一般的なメトリックは役に立たないどころか、2つの点で積極的に進歩を妨げる：

• 第一に、ダッシュボードは誤った測定と進捗の感覚を作成する。チームはダッシュボードがあるからデータドリブンだと思っているが、実際のユーザの問題とは関連性のない虚栄心の強いメトリックを追跡しているのだ。私は、実際のユーザがまだ基本的なタスクで苦労しているにもかかわらず、チームが「お役立ち度スコア」を10％向上させたと喜んでいるのを見たことがある。これは、Webサイトのロード時間を最適化する一方で、チェックアウトプロセスが破綻しているようなものだ。 ...