Knowledge Extraction with LLMs Semantic Chunkから企業知識を抽出するAIパイプライン

Books: Knowledge Flow実践ガイド: 企業知識をAIが利用できる知識基盤へ変換する

Knowledge Acquisitionによって企業内の情報は共通フォーマットへ正規化され、Semantic Document Chunkingによって意味単位へ分割されました。

しかし、この段階ではAIが扱える「文章」でしかありません。

Knowledge Flowの次の役割は、この文章から企業知識を抽出し、AIが推論できる構造へ変換することです。

ここで初めてLarge Language Model（LLM）が中心的な役割を担います。

しかし、単に文章をLLMへ送るだけではありません。

Knowledge Flowでは、LLMを**知識抽出エンジン（Knowledge Extraction Engine）**として利用し、構造化された企業知識を継続的に生成します。

なぜKnowledge Extractionが必要なのか

Semantic Chunkは意味のまとまりですが、まだ自然言語です。

例えば、

検査工程では、不良率が5%を超えた場合、品質保証部へ通知する。

人間であれば、

• 検査工程
• 不良率
• 品質保証部
• 通知

という概念を自然に理解できます。

しかしLLMは、そのままではこれらを知識として再利用できません。

Knowledge Flowでは、

この文章を

• エンティティ（Entities）
• 関係（Relations）
• 制約（Constraints）
• イベント（Events）
• 意図（Intent）
• ポリシー（Policy）

へ変換します。

LLMは一度にすべてを抽出しない

効率化のため、

Knowledge Flowでは一つの巨大なプロンプトを送りません。

代わりに、

複数の小さなExtraction Taskへ分割します。

例えば、

Semantic Chunk

      │

 ├── Entity Extraction

 ├── Relation Extraction

 ├── Constraint Extraction

 ├── Event Extraction

 └── Intent Extraction

それぞれ独立して実行できます。

これにより、

• 並列処理
• キャッシュ利用
• 再実行

が容易になります。

Entity Extraction

まず概念を抽出します。

入力

検査工程では
不良率が5%を超えた場合
品質保証部へ通知する

出力

{
  "entities":[
    "Inspection",
    "Defect Rate",
    "Quality Assurance"
  ]
}

Entityには

• 名前
• 種類
• 別名
• 所属カテゴリ

も付与します。

例えば、

{
  "name":"Inspection",
  "type":"Business Process",
  "aliases":[
      "Inspection Process"
  ]
}

Relation Extraction

次に、

概念間の関係を抽出します。

例えば、

Inspection

↓

Defect Rate

↓

Notify

↓

Quality Assurance

JSONでは、

{
  "relations":[
    {
      "from":"Inspection",
      "to":"Defect Rate",
      "type":"measure"
    },
    {
      "from":"Defect Rate",
      "to":"Quality Assurance",
      "type":"notify"
    }
  ]
}

になります。

このデータは後にKnowledge Graphへ登録されます。

Constraint Extraction

企業知識で重要なのは

条件

です。

例えば、

不良率が5%を超えたら

は、

{
  "constraints":[
    {
      "variable":"DefectRate",
      "operator":">",
      "value":5,
      "unit":"%"
    }
  ]
}

のように構造化されます。

このConstraintはDSL生成にも利用されます。

Event Extraction

Knowledge Flowでは、

イベントも重要な知識です。

例えば、

Notify QA

は、

{
    "event":"Notify",
    "target":"Quality Assurance"
}

になります。

イベントを抽出することで、

後からWorkflowやAgentへ接続できます。

Intent Extraction

文章には

目的

も存在します。

例えば、

品質保証部へ通知する

目的は

品質問題を早期に発見する

になります。

Knowledge Flowでは、

Intentも抽出します。

これはDecision Trace Modelの

Goal

へ接続されます。

構造化出力（Structured Output）

Knowledge Flowでは、LLMに自由形式の文章を返させません。

必ずJSON Schemaを指定し、構造化データとして出力させます。

例えば、

{
  "entities": [],
  "relations": [],
  "constraints": [],
  "events": [],
  "intent": {}
}

のようなスキーマを固定することで、

後続のOntology BuilderやKnowledge Graph Generatorが安定して処理できます。

モデルが変わっても出力形式を維持できるため、運用性も高まります。

トークンを削減する工夫

LLMのコストを抑えるには、

毎回大量の情報を送らないことが重要です。

Knowledge Flowでは、

Semantic Chunkだけを送信します。

例えば、

Chunk ID
Chunk Text
Document Metadata

だけを送ります。

全文は送りません。

さらに、

共通プロンプトはキャッシュします。

例えば、

System Prompt

↓

Cache

Semantic Chunkだけを毎回送信します。

OpenAI Prompt CacheやAnthropic Prompt Cachingを利用すれば、

入力トークンを大幅に削減できます。

並列実行

Knowledge Flowでは、

Chunkごとに処理します。

つまり、

Chunk A

↓

LLM

Chunk B

↓

LLM

Chunk C

↓

LLM

を同時実行できます。

例えば、

1000チャンクなら

100並列

で処理できます。

これにより、

企業全体の文書でも短時間で解析できます。

差分更新

Knowledge Flowでは、

更新されたChunkだけ再解析します。

例えば、

Version 3.1

↓

Version 3.2

変更されたParagraphだけ

Knowledge Extractionを再実行します。

全文を解析し直す必要はありません。

これが運用コストを大きく削減します。

抽出結果の統合

Entity

Relation

Constraint

Event

Intent

は、

そのまま保存されるのではありません。

後続のOntology Builderが

• 同義語統合
• 概念マージ
• 重複排除
• バージョン管理

を行います。

Knowledge Extractionは、

そのための入力データを生成する役割になります。

Knowledge Extractionは知識生成の入口

Knowledge Flowにおいて、LLMは単なるチャットボットではありません。

企業文書を読み、意味を理解し、組織が持つ知識を構造化されたデータへ変換する知識抽出エンジンです。

Semantic Chunkを入力とし、エンティティ、関係、制約、イベント、意図をJSONとして抽出することで、後続のOntology BuilderやKnowledge Graph Generator、DSL Generatorが利用できる共通の知識表現を生成します。

さらに、構造化出力、プロンプトキャッシュ、並列実行、差分更新などの実装技術を組み合わせることで、Knowledge Flowは数百万件規模の企業ドキュメントにも対応できる実用的な知識生成基盤となります。

Knowledge Extractionは、単なる自然言語解析ではありません。

それは、人間が文章の中から理解している知識を、AIが継続的に学習・推論・意思決定へ活用できる知識資産へと変換する中核プロセスなのです。