「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
生成AIを使用してドメイン・ナレッジを生成したい。 †
元々、Wikiのリバースでドメイン・ナレッジを生成しようとしていたが、基本的な専門知識は生成AIが保有している事が解った。
基本的な専門知識は生成AIが保有しているから... †
- 一般知識からフォワード（情報の比率や重みをドメイン・コンテキストで調整してドメインに特化）できるのでは？と言う仮説。
- （AIが保有していない知識は、組織内の独自情報（ルールなど）と、暗黙知ぐらいではないか？と考える。）
- このドメイン・コンテキストを「細分化されたドメインに適合させるために情報の比率や重み」のコンテキストとして渡す。
※ ドメイン・コンテキストと言う造語は「生成AIが保有している一般知識をドメインに特化させるためのコンテキスト」の意
- 必要に応じ、ドメイン独自のルール（定義）を加え、完全にドメインに適合させる。
※ この仮説は、Wikiのナレッジから（先ずは）手動で生成されたドメイン・コンテキストを用い大枠、検証できた。
暗黙知に付いての定義 †
- AI（言語モデル）自体が暗黙知の一例を説明できるのはコーパスから学習した事を意味する。
- 暗黙知は本質的に形式知化が不可能な部分もあるが（例：直感やセンス）。
- 形式知化できないというよりも（、部分的に）、形式知化されていないケースが多い。
- コレには、言語化し難いという側面に加えデータ化されていないと言う側面がある。
- 特に、データ化がコスパ観点やモチベーション観点の側面から促されないケースが多い。
- コスパ観点：形式知化がコスパ的に合わない
- モチベーション観点：形式知化がデメリットになるなどで動機がない。
- ソレ以外に、非言語的、組織文化、認知の壁、状況依存性などが関係している。
- 非言語的：感覚や身体動作など、言語では捉え難く、データ化に専門知識が必要
- 組織文化：経験を形式知として残すことの価値の認識がない場合
- 認知の壁：「自分のやってることが特別だ」との価値の認識がない場合
- 状況依存性：文脈依存で場合分けが多く、一般化・共有が難しい。
ドメインに適合させるイメージ †
結構、良い絵が出たのでプロンプトをメモ
以下のような言語モデル生成AIの画像イメージを生成してください。
・情報が空間（2次元散布図）上に散らばっているものとします。
・プロンプトで2次元の集合から情報を抽出します。
・プロンプトを追加する事で2次元の集合に次元を追加し3次元の集合から情報を抽出します。
・集合からの情報抽出イメージは１つのプロットではなく複数のプロットを含む集合をポイントします。
・3次元の図については立体感を出してください。
※ 左右の図を関連付ける線と丸は追記しています。
生成AIで出来ることと出来ないこと †
出来ること †
- 既知問題のリサーチ
そもそもリサーチとはドメインに適合した（既知の）情報のセットを取得すること。
- 未知問題のリサーチ
- ドメイン知識の補完・拡張
- 探索的質問（未知の問題を洗い出す発見的手法）
- 先行研究の穴（空白や未着手領域）分析
- 異分野のアイディアの組合せ
- 批判的検討の補助（反証やリスク分析）
- プロトタイプ的調査・検証
- 例えば「未来予測」は上記の組合せからなる
・傾向から誘導：質問 → 回答 → 回答の傾向を踏まえた質問 → 回答
・分岐シナリオ生成、兆しの抽出、アブダクション的推論、ナラティブ的構成
- ドメイン知識のない場合のリサーチ
- 情報収集レベルのリサーチは可能
- それ以上のリサーチは出来ないことを参照。
- 特に専門外とのコラボレーションによって価値が生まれるケースに期待
出来ないこと †
- 重要なハイレベル課題にリーチしない（誘導できない）。
- AIを使用し「零」ベースでドメイン知識を得るのは非効率。
詳細 †
ドメイン・ナレッジ生成ステップ †
1. 一般知識から基礎ドメイン知識への変換 †
- 用語の適合
- 概念の再構築：ドメイン文脈で一般知識を解釈し直す
- 事例の選定：実例を使い一般知識をカスタマイズ
2. 重み付けと情報の比率調整 †
より高度な専門知識に適応させる。
- 関連度に応じた重み付け
- コンテキスト取得元データソースの選択
- ICLによる専門性の向上
※ ココでは主に「"体系的"ドメイン・コンテキスト」を使用する。
※ ココでの「体系的と」は目的に適合するように「階層化されたMECEな（インデックス）情報」に近い。
3. ドメイン独自ルール（定義）を適用 †
- 論理ルール（当該ドメインにおける原則）の適用
- ドメイン用語集や独自フレームワークの導入
- ドメイン強制ルールの適用
4. 最適化とフィードバックループ †
- 人間による評価（RLHF）
- プロンプトエンジニアリング
- （ファインチューニング）
体系的ドメイン・コンテキストの作成方法 †
リバース、フォワードの手法があり、基本的にはフォワードで事足りる。
フォワードでは、必要な情報が含まれなかったり、情報の比率が異なる様なケースで、リバース手法で補う事が出来る。
リバース †
- ソースを体系的ドメイン・コンテキストを生成するためのノウハウとして使用する。
- リバースでの体系的ドメイン・コンテキストは手動（従来通り）と自動（生成AIを活用）によるものがある。
フォワード †
- CCCCにフォーカスして詳細化
CCCCにフォーカスしてさらに詳細化して下さい。
参考 †
OSSコンソーシアム †
学びをサポートするAI活用のAS-ISとTO-BE †
https://1drv.ms/p/s!Amfs5caPP9r5kAxog0vFyvOF_zsi
リサーチをサポートするAI活用のAS-ISとTO-BE †
https://1drv.ms/p/s!Amfs5caPP9r5kB29-FBGDhVDl0RR
Xナレッジ生成用プロンプト †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
