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