はじめに
R&D戦略部 社会実装推進担当の天沼です！普段はLLMに関連した技術調査やプロダクト化、社内適用PoCなどを担当しています。 最近の取り組みとしてLLMによって施策立案を自動化するという取り組みを行っていたのですが、自分自身でもしっくりくるアウトプットが生成できないなと感じました。
上記の悩みを考えているうちに、LLMを活用した案件でもデータ分析でよく使われるDIKWピラミッドを基にプロジェクトやプロダクトの設計を考えるのが有効なのではと感じました。ということで今回はDIKWピラミッドを基にLLMプロダクト、プロジェクトを設計していくときのポイントを考えてみたいと思います。
DIKWピラミッドとは
DIKWピラミッドは、Data(データ)、Information(情報)、Knowledge(知識)、Wisdom(知恵)の4つの階層でできている概念モデルです。生のデータから、実際に使える知恵へと変わっていくプロセスを表しています。 それぞれの層について、ざっくり説明していきます。
Data(データ)層
ピラミッドの一番下にあるのがデータ層です。これは加工されていない生の事実そのものを指し、POSシステムの購買記録とか、センサーの数値、RAGで検索された雑多なドキュメント情報の集合などです。 この段階ではデータ単体だと解釈や理解が難しく、ただの数字や記号の羅列でしかありません。
Information(情報)層
データに意味や文脈をつけて、何かの目的に使えるように整理したのが情報です。例えば「商品Aの売上が前月比20%アップした」のようなものを言います。データから情報にするには生のPOSデータを時系列で商品別に集計する、雑多なデータをラベル付、カテゴリー分けするといった「構造化」を行うことでデータを情報に変換できます。この辺りはLLMで実施してもかなり安定して変換が可能な領域だと感じています。
Knowledge(知識)層
情報を統合して解釈したりさらに深掘りをすることで、因果関係や法則に落とし込まれたものが知識です。例えば「商品Aの売上が伸びたのは、競合の商品Bが品切れしてたからだと考えられる」のようなものです。
知識のレベルまでくると、情報同士の繋がりや事象のメカニズムが見えてくるため、再現性のある説明ができたり、予測もできるようになります。情報から知識への変換には、分析や考察が必要になり、操作的には複数の「情報」を組み合わせて考える、過去の事例と「情報」を紐づける などの操作が求められます。
Wisdom(知恵)層
知識を実際の意思決定やアクションに繋げる力です。「同じカテゴリの商品の総和で在庫を一定確保しておくことで購買機会の損失を減らすことができるのではないか」のようなものが該当します。
情報や知識から知恵に変換するには仮説の洗い出しや取り組む際のステップを考えるなどの操作が必要になります。このあたりは会社の文化などの影響も入ってきやすい領域になり、「意思決定の力学」を抑える ことが重要になってくると個人的には考えています。
用語の定義
このブログ上ではデータや情報などの単語を用いると階層の話をしているのか一般的なデータ、情報を指すのか混乱するので以下のように用語を定義しておきます。
- 要素: データ、情報、知識、知恵のいずれか、もしくはそれらの組み合わせで構成されるもの.
- アウトプット: LLMやプロダクト、プロジェクトの最終的な出力.
- 出力: LLMの生の出力や中間生成物など、アウトプットに至るまでの途中の生成物.
DIKWピラミッドが重要な理由
このピラミッドはデータ分析やデータ基盤の設計において重要視されているものになります。 例えばデータ分析の推論を例にとって考えてみます。「小売系のPOSデータで商品Aの売り上げを伸ばす」というプロジェクトの担当になりました。
それに対し顧客の属性情報で商品Aを購入しそうな顧客を推定し、広告を打つというアプローチをとりテストデータでも非常に良い精度でターゲティングができたとします。 しかし実際にこのモデルでターゲティングしましょうと提案すると、「結局どんな顧客にアプローチすることになるの?」などの解釈性の問題が発生したり、「なぜこのモデルは当たるの?」という説明責任の問題が発生したりします。 この要因というのはData層からWisdom層までの階層を無視して、いきなりData層からWisdom層を目指そうとした点にあります。
このような問題は機械学習系のプロジェクトだとよくあることだと思うのですが、LLM関連の話でも同様だと考えられます。特に人がプロダクトやプロジェクトのアウトプットに対して納得感を持てるようにするという観点においては、DIKWピラミッドの各層から必要な要素を取り入れてアウトプットを構成するという点が重要になると考えています。
普段私たちが上司にプロジェクトの提案をするときなどでも、無意識的に各層の要素を組み合わせて説明していると思います。特に施策検討の自動化やデザイン生成など創造的なアウトプットの生成を自動化しようとする時ほど、この階層を意識した設計が重要になってきます。
LLMの社内適用とDIKWピラミッド
ここまでの話を踏まえて、LLMプロダクト、プロジェクトを設計について考えてみます。 まず単一のLLMでの変換(プロンプトを入れて出力を取得する)はある自然言語情報から別の自然言語情報に変換する処理に過ぎません。一方で先ほどのDIKWピラミッドの層間での変換は、注目する層によって入力に必要になる情報が異なります。そのため基本的にはchain of thought(段階的に思考を深める)的なアプローチで各層間の変換を明示的に分けて考えることが重要になると考えられます。
加えてプロダクト、プロジェクトのアウトプットがどの層をターゲットにしているのかを明確にすることも重要と言えます。例えば、単に情報を提供するチャットボットを作るのであればLLMの最終的な出力はInformation層までで十分ですし、意思決定やアクションプランを自動生成するプロダクトを作る場合のLLMの最終的な出力はWisdom層を目指すことになります。
現状の私の業務での工夫
先にも述べた通り私自身現在LLMを用いた施策立案の自動化を行っているのですが、どうしても研究開発的な試行錯誤が必要になります。そこで以下のような工夫をしてみており体感的には良い点があるかなと感じています。
- Data→Information、Information→Knowledge、Knowledge→Wisdomの各変換ステップを明示的に分けて機能やPoCを設計する。
- 各層の変換で必要な要素が異なるので、分けて考えることでLLMに与える入力の設計方針が考えやすくなります。
- 各層で出てきて欲しい情報や知識, 知恵を事前に定義しておき、変換過程をチェックすることでどこまでできそうで、どこから危うい出力が出るかが考察しやすくなります。
- スコープや目的設計に活用できる
- wisdomレベルまで行きつかなくても意外とinformation層やknowledge層まで作れれば十分価値があると判断できるケースもあります。
その他の効用
加えて上記のような階層を意識した設計を行うことで、他にも精度などの品質保証設計でも効用が見込めると考えています。
- LLMの精度検証設計の緻密化
- 各層間の入出力の品質が明確になることで、精度の判定基準やSLAのようなものが設計できる
- LLM as a judgeでの判定用のプロンプトが構築できる
まとめ
今回はDIKWピラミッドという概念を通じて、LLMプロダクト、プロジェクトを設計について考えてきました。 今後もLLMを社会実装することの重要性は増していくと思うので、継続してより良いプロダクト、プロジェクト設計の方法論を模索していきながら様々な課題解決に取り組んでいきたいと思います。
最後まで読んでいただき、ありがとうございました!
