『最速でわかる生成AI実践ガイド』を読んでみた
GW前くらいにXで話題になっていた『最速でわかる生成AI実践ガイド』を読んでみました。
前半は生成AIの基本からうまい使い方、後半はRAGや生成AIシステムの開発方法について書かれていました。
RAGは自PC内で組んでみたのでいいとして、この記事では後半の生成AIシステムの開発について触れてみます。自分用のメモに近いですが、業務で生成AIシステムを触る人には刺さる実践的な内容だと思います。
ここらへんの知識を業務に当てはめて実装してみるのもおもしろそうだと思う。
1. 企画構想フェーズ
主なタスク
- 業務課題と導入目的の整理
- 生成AIを適用する範囲の仮決め
- フィジビリティの確認
次に進むための条件 システム化の目的が整理され、実現可能性があると判断された状態
精度目標は70%から始める
精度テストで高すぎる場合はサンプルを疑う。低すぎる場合は業務効率化が本当にできているのか疑う。
自分もツールとAIの使い分けが重要だと感じる。 100%に近い精度を求めるならAIにツールを使ってもらったほうがいいし、ある程度の誤りを許容できる処理ならAIに直接判断させる方が適している。
また、ハルシネーションによる最悪の事態も想定し、性悪説で考える必要があるという話もあった。開発システムに悪さをしないか、そして入力データには気をつける必要がありますよね。
汎用型 vs 特化型
特化型 であれば、To-Beの業務フロー図に基づいて適用範囲や自動化率を見極める。
汎用型 の場合は、技術的なカバー率を測定する。例えばRAGを使ってAIがファイル内容を回答するときは、ファイル形式ごとに図形・テキストがどれくらい抽出できるかをそれぞれ計測する。
開発コスト・処理時間・運用負荷についても検討する。 AIでのシステム開発って意外と時間がかかることが多い。最初のパッと見では良さげなアウトプットが出るので、簡単に完成できると思いながら泥沼にはまることが多い。
業務フローの見直しが先
As-ISの業務フローからTo-Beの業務フロー図を作成し、自動化範囲を描く
必ずしも現在の業務を単純に置き換えるのが正解とは限りません
これはすごくわかる。目的と手段を分けて考えようということだと理解している。目的を満たせるなら、今のやり方をAIでそのまま置き換える必要はない。
業務が何のためにやられているのかの理解、もしくは業務担当者からのヒアリングが必要になる。To-Beの業務フロー図からどこをAIに任せて自動化するか検討する流れ。
各業務・手順の目的を明文化すること
企業には手順書がないことが多いので、まずはそこを作る（人の作業を蒸留する）必要がある。
フローの中で「人が担当する部分」「AIが担当する部分」「プログラムで処理する部分」を分けて考える。
生成AIシステムの導入で、人間の確認・承認という作業が増えることも記載されていた。 AIが作るアウトプットはなまじクオリティが高いので、何となく良さげに見えてしまい、ガッツリ見ないと誤りを認識できないケースが多い。ここが難しいと感じている。
フィジビリティの確認
フィジビリとよく耳にするが、要するに実現可能性のことだ。プロジェクト開始前に、アイデアや要求が技術的・コスト的・スケジュール的に実現可能かを事前に評価する工程。
企画段階でサンプルデータを使って軽く検証し、AIの能力を把握してフィジビリを確認することが推奨されている。システムを作る前にOSS等でどの程度精度が出るか見ることも提案されていた。
不確実性を排除して手戻りリスクを抑えることの重要性が書かれている。
業務で工数を使う以上、本当に実現できるか、効果はあるかを企画段階で確認し、難しければ中止やスコープ変更を判断することが重要だと改めて感じた。
2. 精度分析・改善フェーズ（PoC）
主なタスク
- 業務効果の概念実証（PoC）
- 精度テストのエラー分析と改善
- 生成AIを適用する範囲の確定
次に進むための条件 生成AIの業務効果を定量化し、実用化の投資価値が見込めた状態
このフェーズはPoCとも呼ばれる。自分はフェーズ1の内容がPoCだと思っていたが、PoCに進む前にもゲートが必要なのだと改めて納得できた。
正答率より「業務効果」を定量化する
ツールを作っているとどうしても精度にこだわりたくなる。エッジケースのサンプルがうまく解析できないことを気にして、無駄に工数をかけることがある。自分もよくやりがちだ。
結局はそのシステムがどれだけ業務の生産性を向上させるか、業務効果を最大化すること が本来の目的だという話だ。
精度が良くても仕事の負荷軽減につながっていなければ意味が薄い。精度の数値だけが一人歩きしないよう、必ず業務効果を定量化して比較する。
精度テストに使うサンプルデータは 実際にシステムを利用する業務担当者を中心に作成する ことが重要とのこと。AI担当者が作成すると、無意識にAIに優しいテストデータを選んでしまうためだ。
回答根拠を確認しやすくする
精度テストを行う上では、回答の根拠を確認しやすくする仕組みも重要だ。根拠が記載されていないと、人が判断するときに時間がかかる。根拠を書かせることでなぜAIが間違えたのかを判断できるので、修正させやすくなる。
他にもこんな記載があり、かなり納得した：
- 実際の作業量・作業時間がどの程度軽減されるかを可能な限り定量化するべき
- 業務担当者とAI担当者が連携して検証・評価に取り組む体制作りが必要
定量分析 + 定性分析の両方を行う
- 定量分析：全体的な傾向を数値から読み取る
- 定性分析：個別の結果を1件ずつ詳しく見て考察する
代表的な出力サンプルを人間が確認する定性分析の重要性が語られており、個別サンプルから重要な気づきを得たり取りこぼしに気づくことが多いとのこと。
精度のボトルネックを見極める
エラーからシステムの処理を追ってボトルネックを洗い出す。優先度の考え方は 業務上の重要度が高く、かつ技術難易度が低いもの から対応すること。
非現実的な取り組みにならないよう、理想的な条件での性能限界を事前に把握しておくことが重要とされていた。
Precision か Recall か
両者はトレードオフの関係にある。
| 指標 | 意味 |
|---|---|
| Precision（適合率） | 誤検知の少なさ |
| Recall（再現率） | 見逃しの少なさ |
本書の推奨はまず Recall を重視 し、多少誤りを含んでいても積極的に回答する方向で進めること。
読んでみて、業務効果にフォーカスするという話と、企画段階でのフィジビリ確認の重要性が特に刺さりましたね…… こりゃOpenAIもFDEしたいよね。
