AI-Readyな知識横断マップの作成.

Transcript

1. AI-Readyな知識横断マップの作成 NASAに学ぶオントロジーの活用 キーパーソンを「つながり」で検索
2. → ある程度大きな組織共通の課題 → 適切なデータ形式を検討しつつ、モックアップを作成 kako
4. →オントロジーの活用
5. オントロジーとは データの“意味”と“関係のルール”を定義 オントロジーの代表的な構成要素 所属する 組織 社員 担当する 成果物 なぜAIで再注目されるか 保有する スキル ・データ同士の関連性を解釈できる ・ルールに基づく推論が可能 ・AIによりオントロジー作成のハードルが低下 必要 案件 生成する 要素 意味 社内マップでは? クラス（概念） モノの種類 社員・案件・スキル インスタンス クラスの実体 田中さん、AWSスキル プロパティ（属性） クラスが持つ項目 社員の部署・入社年 リレーション（関係） クラス間のつながり 社員—担当する→案件 制約・ルール つながり方の決まり 担当者は社員に限る
7. 構成図
8. グラフデータソース比較 今回の規模では案Aが最適。データ量・同時実行が増えれば案B・案Cが有力 案A（今回） S3 + Lambda 案B（次段階） Neptune Serverless 案C Neptune Analytics グラフDB openCypher Gremlin インメモリグラフ アルゴリズム ベクトル検索 API API AI / RAG ファイルを読み込み アプリ側で辿る 関係を直接保持し 多段探索 分析・AI連携向け 一時停止可 S3（JSON） nodes / edges Lambda メモリ上で探索 評価軸 S3+Lambda Neptune DB データ JSONファイル グラフ構造 グラフ構造 Lambda内 DB内で直接 インメモリ コスト ◎ △ △ 運用負荷 ◎ ◦ △ 拡張性 △ ◦ ◎ 検索精度 ◦ ◦ ◎ 探索の実行 Analytics 凡例 ◎:最適 ◦:対応可 △:工夫が必要 評価のポイント 案A:PoCに最適 （固定費・実装の容易さ） 案B:部門展開の本命 （多段探索・同時実行） 案C:ハイブリッド検索
9. モックアップの舞台
11. 検索対象 社員 Oracle Database
12. 加藤 直人 （退職済み） 注文管理 システム 検索対象 した 社員
13. 検索対象
14. RDBとグラフDB:関係の表し方の違い リレーショナルDB ナレッジグラフ 社員 案件 E01 田中 E02 佐藤 P01 AWS構築 P02 DB移行 社員 保 有 所 属 スキル 中間テーブル（社員×案件） E01 → P01 E01 → P02 E02 → P01 組織 担 当 成果物 生 成 案件 関係ごとに中間テーブルを用意し、JOINで結合して辿る 関係そのものを“エッジ”として直接保持 5種類のエンティティが相互に関係すると、 中間テーブルは最大 ₅C₂ ＝ 10個 必要 中間テーブルは不要。関係が増えてもエッジを足すだけ グラフ形式の場合は関係を“表の結合”として表す必要なく 、“データそのもの”として保有可能。 → AIによる検索精度が向上することが報告されている。（AI-Ready） 10
16. 今後の展望:MCPによる広がり