なぜプロダクト開発は生成AIと相性が良いのかをデータ屋の視点から考察した
※この記事は、データ系の人間が書いています
※LLMにはほぼ全部書き直しを推奨されましたが変更してないのでよみづらいかもしれないです
※都度修正を行なっていきます
データ分析に生成AIを適用させる取り組みをしてて思うことは、一発で完了してくれるプロンプトを書くことがめっちゃむずいです
でも、世の中ではDevinやClaude Codeが活躍していて、Issueを書くだけで段取りを決めて自立して改善してテストも終えるところまでの開発をしてくれていたりする。
データ分析に限らず、一般的な開発ほどAIと相性が良いものが何なのか、について考察してみた
現状生成AIが溶け込んでいるもののピックアップと考察
この記事に都合の良いチョイスをしています
- veo3などの動画/画像生成
- これはそれ用にfine tuningされており、それに対するテストも豊富に行われている
- こういったものは、対話形式でdetailを修正することが一定可能なため、そのコストを払ってでも生産性を向上できているため許容されている
- 学術的な方面への適用
- 論文を記載したり、自立して論文を作成することができている
- これは、論文は命題があり、いかにそれが正しいのかを証明するためという明確なGoalが定まっている。さらに、類似論文やreferenceなどを正しく与えることができればGoalに向かって行動ができるから
上記を踏まえ、プロダクト開発になぜ溶け込めたのか
個人的には次の要素がとても大きいと感じています
- GitHub の master branch には常に最新の状態のみが保管されている
- 思考に必要なものがほとんど含まれている(ことが多い)
- 受け入れ条件やテストなどを定義し、コード上で実装することができ、その定義に関して明確に記載することができる
- frontend部分についても、mockやfigmaなどで画像などを含む形式でどのようにしたいのかを先に与えることができる
- TRD(Technical Requirements Document)などである程度細かい要件をあらかじめ記載していることが多い
- 曖昧なビジネス要件を、先にCode上で記載されている表現に用語に変換されている
このように、あらかじめやることが決まっていて、それに対して実行をした時にどういう状態になっているべきなのかがある程度はっきりしている状態であれば、やりなおしなども自立して行えることが必須となっている
データ分析全体にLLMを導入するにあたって目指したい方向性
現在自分の所属している企業では次のように分解して生成AIを取り込むようなロードマップを構築している
- 🔗 データ連携ができている / データ基盤構築
- 🔍 データにアクセスしやすい / 集計作業
- 📊 可視化しやすい / グラフ化したりクラスタリングしたり簡単なデータ操作
- 🧠 意思決定に使われている / 出力されたデータの解釈サポート
- 🤖 AIを活用して高度な分析がしやすい / Data Scientistリプレイス
それぞれにおいてアプローチは異なるが、基本的には次のような戦略を考えている
データ連携
データエンジニアリング領域に関しては、基本的にプロダクト開発と同じ状態を作り出せると考えているため、いわゆるAI駆動開発のいろはをつぎ込んでいる。
ただし、ギャップとしては次の要素があり、それぞれ解決策を検討している
- Sourceデータを生成している部分でのみそれがどのように作られてそれらにどのような値が入っているのかが明らかにされているため、データコントラクトを推進することで一定解消される予定
データにアクセスしやすい
text2sqlを用いて、欲しいデータを自由に抽出する仕組みを構築する
ただ、text2sql自体も正しいデータ抽出をするためのハードルがとても多い。基本的には次のステップを踏んでそれらに対して技術課題があると感じている
ちなみに、text2sql自体は2023年春にはbeta versionを構築し、社内で展開した。精度は悪いが簡単なものは実行できたりクエリの中身を理解したりする用途では活躍をしている。
なお、世の中の進んでいる企業ではどのように実装されているのかは
は大いに参考になるため、読んでおくと良い
- なんの目的で何をするためにデータを抽出するのかの明文化
- 基本的にこの時点でハイコンテキストになっててLLMからするとハルシネーションの温床になっている
- outputイメージの作成
- 目的が明らかであればおそらく作成が可能
- 出力列別に細かい条件が付与されていることが必要
- whereであったりwindow関数をどのように適用させるのかであったりということがわかるように記載されている必要がある
- SQL計画の策定
- outputイメージの作成のために
- table選択(これは各ステップにおいて複数回使われる)
- column選択
- sample queryの取得
- templateSQLや過去作成されたSQLなどの情報を付与することで精度を向上
- SQL計画の再作成
- tableとfield情報を正しく得た上で最適な解を模索する必要がある
- SQL作成
- Query生成を行い
- dry runにてデバッグし
- query resultを得て何かしらの評価を行う
現在の自分の思考だと、上記を構築し、各ステップにおいてレビューを挟むことで一定の精度を保証するものは作成できると踏んでいる
可視化しやすい
こちら、現状でもOpenAIが2024年の夏くらいに公開したData Analystなどでも一定実現できていたため、それを裏で実行し、可視化する環境を作れば基本的にはできると思っています。
工夫する点としては、
- データの渡し方
- データの定義 / description and type
- 過去の同様のデータの加工例
あたりを渡してあげると比較的スムーズに処理を行えるかなと思っています
意思決定に使われている
ここは鬼門だと思っています。
基本的に意思決定は"総合的に鑑みて"という要素が強いと感じています。そのため
- 競合の動向
- 自社(プロダクト)のロードマップやミッションなどの情報
- 自社(プロダクト)の状況
- 自社(プロダクト)の過去の施策の結果とその考察
- 実施中の施策や今回の施策についてのあれこれ
などなどを渡してやっと意思決定をできる土俵に持っていけるのではないかと考えています。
このstep4と2,3を繰り返して意思決定する材料を分析して最終的に示唆を出す、そういうことをやりたいです。
なので、上記の会社に散りばめられている情報をいかに統合し必要な情報を渡せるのか、そういったことをどうすればいいのかを今考えてる最中です
AIを活用して高度な分析がしやすい
すみません、これに関しては全くイメージ湧いてないです
GoogleCloud, AWS, AzureあたりでまるっとできるようになるかDatabricksさんあたりが先に到達するか、くらいです。
ただし
上記のような5ステップをそれぞれ最適化した上で全部を統合してアクセスできる環境を用意してあげないと、たとえば
- どのSourceのどのデータなのか、現状のビジネス状況はどうなっているのか、過去の意思決定はどうしたのか、などを総合的に見て一気通貫して分析業務を行えることはできないだろうなーというのと、会話しながらでないと人間のイメージって結局曖昧なところからスタートするので、アナリストがビジネスと会話しながらGoalを決めてそれのための集計業務をするといったようなコンサルテーションLayerはUI上必須になるんだろうなーというイメージを持っている
全体を通して、
- データ分析プラットフォーム外のデータをどう閲覧してわかりやすくするか
- text2sqlの精度をいかに上げるか
という点がとても難しいなと思っています。まずはその課題を無視して統合する仕組みを簡単に作ってから部分最適化を進めていくのがPMF的によいのかなぁと考えてたりします
ギャップと今後の方向性
データ話が多かったですが、ここまで記載してきた中で、
- 最新の情報かつ、その情報量が答えを出すために必要な情報量であるか
- 求めている回答に対して、曖昧さを回避できているか
この二点が、自立したAIを運用できるかにかかっているのではないかという結論に至った。
ビジネス側やデータ分析の方面では、常に曖昧な中で答えを出すという現状を解消していく方向性が良いと考えている
Discussion