プロジェクト概要
人が先に本体を定義し、その上で文書から候補を抽出し、確認済みの結果を Graph として残す知識基盤です。
今の主線本体は、L1 文書物理層、L2 テーマ意味層、L3 業務オブジェクト層、L4A 設計構造層です。L4B は後から接続するコード実装チェック層として切り分けています。特に、設計書が古い、資料が分散している、変更時の影響範囲を追いにくい現場で使うことを想定しています。
詳細資料を開くと内容を表示します。
面接で短く説明しやすいように、まず要点を上にまとめています。今は文書側を中心に作っていて、必要になれば後からコード解析モジュールをつなげられる設計です。下の詳細資料は、深掘りされたときだけ開く想定です。
プロジェクト概要
今の主線本体は、L1 文書物理層、L2 テーマ意味層、L3 業務オブジェクト層、L4A 設計構造層です。L4B は後から接続するコード実装チェック層として切り分けています。特に、設計書が古い、資料が分散している、変更時の影響範囲を追いにくい現場で使うことを想定しています。
課題
今できること
今後の拡張
進め方
面接では、次の 4 ステップで話すと KGBase の本体設計と Graph の考え方が伝わりやすいです。
L1 文書物理、L2 テーマ意味、L3 業務オブジェクト、L4A 設計構造を先に定義し、AI が自由に schema を増やさないようにします。
資料を読み、Topic、Object、Relation の候補を抽出します。
AI の結果をそのまま使わず、Staging Area で確認します。
確認済みの Topic / Object / Relation を Graph として保持し、検索、比較、差分確認、影響分析に使います。
全体像
まずこの図で、何を入力して、どう処理して、何を Graph にし、何に使うかを見せます。L1〜L4A と L4B はその下で短く説明します。
flowchart LR
A["文書 / フォルダ"]
B["文書解析"]
C["Topic / Object / Relation 候補"]
D["Staging Area"]
E["人手確認"]
F["確認済み Graph"]
G["検索・差分確認・影響分析"]
H["L4B コード実装チェック層（後接）"]
A --> B --> C --> D --> E --> F --> G
H -.-> FL1 文書物理層、L2 テーマ意味層、L3 業務オブジェクト層、L4A 設計構造層を先に定義し、主線として扱います。
あとから接続し、確認済み Graph に対して check と証拠補強を行います。
設計の考え方
主線本体は L1〜L4A で定義し、L4B は後から接続する層として分けます。
すべての候補は一度 Staging Area に置き、人が確認してから正式化します。
確認済みの Topic、Object、Relation を Graph として保持し、あとからたどれるようにします。
source_link で元資料へ戻れるようにし、L4B コード実装チェック層をあとから追加できる構成にしています。