Semantic Document Chunking AIが理解できる知識の最小単位を作る

Knowledge Acquisitionによって、企業内のドキュメントは共通フォーマットへ正規化されました。

しかし、この状態のままでは、LLMにとって扱いやすい知識にはなっていません。

企業のマニュアルや設計書、契約書は数十ページから数百ページに及ぶことも珍しくありません。

そのままLLMへ入力すると、

• コンテキストウィンドウを超えてしまう
• 必要な情報だけを取り出せない
• 異なる内容が混ざってしまう
• 推論精度が低下する

といった問題が発生します。

そのためKnowledge Flowでは、ドキュメントを**Semantic Chunk（意味単位）**へ分割します。

Semantic Chunkは、Knowledge Flowにおける知識の最小単位です。

なぜSemantic Chunkが必要なのか

従来のRAGでは、

例えば500文字ごと、

あるいは1000トークンごとに分割することが一般的でした。

Document

↓

1000 Tokens

↓

Chunk 1

Chunk 2

Chunk 3

しかし、この方法では、

文の途中で切れてしまったり、

一つのチャンクの中に複数の話題が混在したりします。

例えば、

品質保証

・・・

検査方法

・・・

人事評価制度

が一つのチャンクになれば、

AIは

「品質保証」

と

「人事制度」

を同時に学習してしまいます。

Knowledge Flowでは、

文字数ではなく、

意味のまとまり

で区切ります。

ドキュメント構造を利用する

最初に、

ドキュメント自身が持っている構造を解析します。

例えば、

設備管理マニュアル

↓

Chapter

↓

Section

↓

Subsection

↓

Paragraph

Wordなら

Heading1

Heading2

Heading3

PowerPointなら

Slide

Bullet

PDFなら

見出し

本文

表

図

を利用します。

つまり、

ドキュメント構造そのものを利用して、

意味の境界を推定します。

Semantic Chunkとは

Paragraphをそのままチャンクにするわけではありません。

LLMが文章を解析して、

一つの意味を持つ単位へ変換します。

例えば、

設備温度が80℃を超えた場合は、
装置を停止し、
品質保証部へ通知する。

これは一つのSemantic Chunkになります。

一方、

設備温度

・・・

品質保証

・・・

在庫管理

なら、

三つのChunkへ分割します。

つまり、

Chunkは

一つの業務知識

だけを持つように設計します。

Semantic Chunkのデータ構造

Knowledge Flowでは、

チャンクごとにメタデータを保持します。

例えば、

{
  "chunk_id": "CHK-000154",
  "document_id": "DOC-001245",
  "source": "SharePoint",
  "title": "品質管理マニュアル",
  "chapter": "設備検査",
  "section": "温度管理",
  "author": "品質保証部",
  "department": "QA",
  "version": "3.2",
  "created_at": "2026-01-15",
  "updated_at": "2026-06-01",
  "language": "ja",
  "security": "Internal",
  "tags": [
    "Inspection",
    "Temperature",
    "Quality"
  ],
  "text": "設備温度が80℃を超えた場合..."
}

このメタデータは、

後続のKnowledge Extractionだけでなく、

検索やガバナンスにも利用されます。

LLMによる意味解析

Chunk生成では、

単純な文章分割だけではなく、

LLMによる意味解析も行います。

例えば、

設備停止

という表現でも、

文書によって意味が異なります。

例えば、

設備停止

↓

安全停止

なのか、

設備停止

↓

計画停止

なのか、

設備停止

↓

故障停止

なのかを判断します。

つまり、

Chunkには

意味

目的

対象

条件

なども付与できます。

チャンク間のリンク

Semantic Chunkは、

独立しているだけではありません。

相互にリンクを持ちます。

例えば、

Chunk A

設備

↓

Chunk B

検査

↓

Chunk C

品質保証

あるいは、

Chunk A

↓

参照

↓

Chunk D

のように、

知識同士を結び付けます。

これが後のKnowledge Graphになります。

Embedding生成

Semantic Chunkごとに、

Embeddingも生成します。

Chunk

↓

Embedding Model

↓

Vector

例えば、

OpenAI Embedding

Voyage AI

BGE

E5

などが利用できます。

Vector Databaseには、

• pgvector
• Qdrant
• Milvus
• Weaviate
• Pinecone

などを利用できます。

Semantic Searchでは、

まずEmbedding検索を行い、

その後Knowledge Graphを参照する

Graph RAG

へ接続できます。

Chunkの品質管理

Knowledge Flowでは、

Chunkにも品質があります。

例えば、

• 一つの話題だけを持っているか
• 長すぎないか
• 短すぎないか
• 文脈が失われていないか
• 意味が自己完結しているか

などを評価します。

必要に応じて、

LLMが

• 分割
• 結合
• 要約

を自動で行います。

つまり、

Chunk自体も継続的に改善されます。

Semantic ChunkはKnowledge Flowの基本単位

Knowledge Flowでは、ドキュメント全体ではなく、Semantic Chunkを知識処理の基本単位として扱います。

一つひとつのChunkは、

• 一つの業務知識
• 一つの判断ルール
• 一つの制約
• 一つの概念

を表現するよう設計されています。

そのため、後続のKnowledge Extractionでは、Chunkごとにエンティティや関係性、制約条件、DSLを高精度に抽出できるようになります。

Knowledge FlowにおいてSemantic Chunkは、単なる文章の分割ではありません。

それは、人間が理解している「意味のまとまり」をAIが処理できる知識単位へ変換するプロセスです。

企業知識を構造化し、オントロジーやKnowledge Graph、Decision Trace Modelへとつなげるための最も重要な基盤が、このSemantic Document Chunkingなのです。