「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>FrontPage]]
--[[設計のポイント]]
--[[PMのポイント]]
--ナレッジ生成用プロンプト
---[[性能に関するナレッジ生成用プロンプト]]
---[[移行に関するナレッジ生成用プロンプト]]
---[[PMに関するナレッジ生成用プロンプト]]
*目次 [#h8399e37]
#contents
*概要 [#e32a91c8]
生成AIを使用してドメイン・ナレッジを生成したい。
-ドメイン・ナレッジには[[「完全な暗黙知」と「擬似的な暗黙知」>#qb34792a]]がある。
-後者については、生成AIでも、かなりの部分が生成できる。
-元々、Wikiからドメイン・ナレッジを生成しようとしていた（リバース生成）。
-しかし、[[基本的な専門知識は生成AIが保有している>#r9f042ad]]事が解った（フォワード生成）。
**暗黙知に付いての定義 [#qb34792a]
***AIの回答 [#ke2ed307]
AIに質問した所、以下のような回答があった。
-LLMは大量の文章からパターンを学んでいるから、専門書で文書化されていたり、分析結果がデータ化されている「擬似的な暗黙知」は、かなり生成できる。
-しかし、身体感覚に強く依存するもの、非常に狭い界隈に限定されるもの、本人も言語化できていないレベルの直感など「完全な暗黙知」は、かなり生成できない。
***擬似的な暗黙知 [#k5652b74]
-AI（言語モデル）自体が暗黙知を説明できるのはコーパスから学習した事を意味する。
--「完全な暗黙知」は本質的に形式知化が不可能な部分もあるが（例：直感やセンス）。
--「擬似的な暗黙知」は単一のナレッジ・ベースにまとまっていなかったりデータ化されていないケースが多い。
---言語化し難いという側面に加えデータ化されていないと言う側面がある。
---「職人の勘」のようなものも、データ化することで人間以上に再現可能になるものもある。
-しかし、「擬似的な暗黙知」も、コスパ観点やモチベーション観点の側面から「データ化」「情報集約」が促されないケースが多い。
--コスパ観点：形式知化がコスパ的に合わない。
--モチベーション観点：形式知化がデメリットになるなどで動機がない。
***状況を決める因子 [#q419486d]
以下のようなものがある。
-非言語的：感覚や身体動作など言語では捉え難く、また、データ化に専門知識が必要
-組織文化：経験を形式知として残すことの価値の認識がない場合
-認知の壁：そもそも自分のやってることは価値があるとの認識がない場合
-状況依存性：文脈依存での場合が分けが多く、一般化・共有・活用が難しい
**ドメイン・ナレッジの生成 [#r9f042ad]
基本的な専門知識は生成AIが保有しているから...
***仮説：フォワード生成できるのでは？ [#nf56ffd8]
情報の比率や重みを「ドメイン・コンテキスト」「ドメイン独自ルール」で調整してドメインに特化させる。
-AIが保有していない知識は、「組織内の独自情報」（ルールなど）と、[[「完全な暗黙知」>#qb34792a]]ぐらいではないか？と考える。
-このドメイン・コンテキストで「細分化された[[ドメインに適合>#kcc6ed6e]]させるための情報の比率、重み、条件」を調整する。
>※ ドメイン・コンテキストと言う造語は「生成AIが保有している一般知識をドメインに特化させるためのコンテキスト」の意
-必要に応じ、ドメイン独自のルール（定義）を加え、完全に[[ドメインに適合>#kcc6ed6e]]させる。
>※ [[この仮説は、Wikiのナレッジから（先ずは）手動で生成されたドメイン・コンテキストを用い大枠、検証できた。>性能に関するナレッジ生成用プロンプト]]
***ドメインに適合させるイメージ [#kcc6ed6e]
一般的な情報に「XXX（ドメイン）においては？」と言う軸を加え「追加軸での分布（比率、重み、条件）が追加された」情報を取得する。
|#ref(ChatGPT_Image_20250409_1.gif,left,nowrap,集合,30%)|#ref(ChatGPT_Image_20250409_2.gif,left,nowrap,集合,30%)|
|CENTER:イメージA|CENTER:イメージB|
|>|CENTER:イメージA、イメージBとあるが、意味するところは同じ|
結構、良い絵が出たのでプロンプトをメモ
以下のような言語モデル生成AIの画像イメージを生成してください。
・情報が空間（2次元散布図）上に散らばっているものとします。
・プロンプトで2次元の集合から情報を抽出します。
・プロンプトを追加する事で2次元の集合に次元を追加し3次元の集合から情報を抽出します。
・集合からの情報抽出イメージは１つのプロットではなく複数のプロットを含む集合をポイントします。
・3次元の図については立体感を出してください。
※ 左右の図を関連付ける線と丸は、ペイント・ソフトを使用して追記しています。
**生成AIを用いたナレッジ生成で出来ることと出来ないこと [#h81cf3ea]
そもそもナレッジ生成はドメインに適合したナレッジ情報のセットを取得すること。
***出来ること [#wb5dbf37]
生成AIがドメイン知識を学習済みの場合のナレッジ生成（ナレッジのリサーチ）~
ドメインに適合した（既知の）情報のセットを取得するためのプロンプトを与える。
-既知問題（かんたん）~
コーパスで学習しているハズなので、ソレを取り出すプロンプトを与える。
-未知問題（ただし難しい）~
コーパスで学習していないので、情報を組み合わせたり、傾向を探ったりするプロンプトを与え~
「確定的な知識獲得」ではなく、類似ドメイン・隣接領域からの類推、構造的共通性の抽出をする。
***出来ないこと [#fbce5286]
網羅性や重要度を目的変数として最適化していないため~
「情報の網羅性の欠如」と「フォーカスポイントの欠如」が発生する。
-「平均的な知識」「多数派の言説」「よく知られたトピック」に偏る
-膨大な文書から学習しているため、テンプレ的構造には強い。
-目的依存で内容の意味的な重みや本質的な論点を再定義する力は人間ほど強くない。
--重要な視点（低頻度重要問題）や最新の情報の項目（時間軸問題）が抜け落ちる可能性がある。
--重要なハイレベル課題に人間が適切な軸をプロンプトとして与えなければリーチしない。
...従って、AIを使用し「０（零）」ベースでドメイン知識を得るのは非効率。
*詳細 [#kaa4fbbf]
**体系的ドメイン・コンテキストの作成方法 [#ae6900ac]
[[リバース>#i1f0ad91]]、[[フォワード>#y0923734]]の手法があり、基本的にはフォワードで事足りる。~
フォワードでは、必要な情報が含まれなかったり、情報の比率が異なる様なケースで、リバース手法で補う事が出来る。
***フォワード [#y0923734]
-体系的ドメイン・コンテキストのフォワード自動生成
AAAAにおけるBBBBについての重要な項目を2-3層の目次レベルで体系化してください。
--CCCCにフォーカスして詳細化
CCCCにフォーカスしてさらに詳細化して下さい。
--DDDD界隈のドメインに特化させる
更に界隈の常識に特化させ、且つ、以下のトピックを追加して下さい。
- ...上段で不足していたトピックのリストを渡す...
-最近は、上記の手順を踏まずに提案されるようになってきた（以下はプロンプト例）。
--IT系の性能問題で発生しやすい問題はどの様な問題ですか？
--...Web系/業務系/クラウド/組込、設計・実装か？運用トラブルか？
--...新規開発/既存改善、オンライン/バッチ、DB種別
***リバース [#i1f0ad91]
-ソースを体系的ドメイン・コンテキストを生成するためのノウハウとして使用する。
-リバースでの体系的ドメイン・コンテキストは「既存」と「生成」によるものがある。
--既存：例えば「[[性能問題のポイント>https://techinfoofmicrosofttech.osscons.jp/index.php?%E6%80%A7%E8%83%BD%E5%95%8F%E9%A1%8C%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88]]」の目次項目を使用する。
--生成：VDBに格納したリーフページから生成
---プロンプトの例
「以下はノウハウ集のリーフページのXXXXを要約したものです。
ココから、このドメインのXXXXに関する重要項目を2-3層の目次レベルで体系化するとどのようになりますか？」
---ただし、生成AIは、以下の点で問題があると言われているので、複雑な体系化は難しい可能性がある。
・与えられた情報を文章として整えることは得意だが、知識の構造を認識し、階層的に整理することは苦手。
・大量のリーフページ情報を一度に扱うことができないため階層的な全体像を保持しつつ要約するのが困難。
・一貫した論理構造を維持するのが苦手なため、同じドメインでも質問の仕方次第で異なる解釈をすることがある。
・（一応、この文脈で、グラフ技術が活用できる旨があったが、グラフの評価結果からはあまり期待していない）
---また、取得したチャンクが適切でない場合、誤った体系的ドメイン・コンテキストが出力される。
・検索されたチャンクが質問の意図とズレていた場合、言語モデルはその情報に引きずられて、誤った／関係ない回答を生成する。
・取得されたチャンクが古い情報や誤った記述だった場合、それが信頼できる情報として生成結果に反映される。
・関連度が低い情報（ノイズ）が多数混入すると、本当に重要な文脈が埋もれてしまい、回答の質が低下する。
--生成：エージェントのGoogle検索結果から生成
---プロンプトの例
あなたはユーザーの要求に合わせインターネット検索を行い、発見した技術情報を提供するエージェントです。
インターネットや、インターネット上の以下の優先ナレッジから情報を取得して回答をします。
https://opentouryo.osscons.jp/
https://techinfoofmicrosofttech.osscons.jp/
https://dotnetdevelopmentinfrastructure.osscons.jp/
優先ナレッジを使用する場合、以下の様に検索してください。
site:techinfoofmicrosofttech.osscons.jp {キーワード}
参考にしたWebページ情報はユーザにも提示して下さい。
ユーザーの要求：
「XXXXのYYYYを教えてください。」
※ キーワードには「X」「Y」「Z」などを使用します。
---GoogleはVBDと異なり、Recallは捨てて、 Precisionを極限まで高めたHybrid Retrieval
---XXXXのYYYYについて検索キーワードで検索した結果から重要な情報を抽出して体系的ドメイン・コンテキスト化しているモノと思われる。
**ドメイン・ナレッジ生成ステップ [#gd7fab87]
エージェントを使うとブラックボックス化できる。
***1. 一般知識から基礎ドメイン知識への変換 [#m35e4e9c]
-用語の適合
-概念の再構築：ドメイン文脈で一般知識を解釈し直す
-事例の選定：実例を使い一般知識をカスタマイズ
***2. 重み付けと情報の比率調整 [#kec5dc5c]
より高度な専門知識に適応させる。
-関連度に応じた重み付け
-コンテキスト取得元データソースの選択
-ICLによる専門性の向上
※ ココでは主に「[["体系的"ドメイン・コンテキスト>#ae6900ac]]」を使用する。
※ ココでの「体系的と」は目的に適合するように「階層化されたMECEな（インデックス）情報」に近い。
***3. ドメイン独自ルール（定義）を適用 [#b2ce2b05]
-論理ルール（当該ドメインにおける原則）の適用
-ドメイン用語集や独自フレームワークの導入
-ドメイン強制ルールの適用
***4. 最適化とフィードバックループ [#y757c2c6]
-人間による評価（RLHF）
-プロンプトエンジニアリング
-（ファインチューニング）
*参考 [#h7100b45]
**OSSコンソーシアム [#ie4b551e]
***学びをサポートするAI活用のAS-ISとTO-BE [#f9559575]
https://1drv.ms/p/s!Amfs5caPP9r5kAxog0vFyvOF_zsi
***リサーチをサポートするAI活用のAS-ISとTO-BE [#l1547cca]
https://1drv.ms/p/s!Amfs5caPP9r5kB29-FBGDhVDl0RR
...
IP:153.227.38.36 TIME:"2026-02-04 (水) 04:19:45" REFERER:"https://opentouryo.osscons.jp/index.php?cmd=edit&page=%E3%83%8A%E3%83%AC%E3%83%83%E3%82%B8%E7%94%9F%E6%88%90%E7%94%A8%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88" USER_AGENT:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
