の精度を最も左右するのが、実はチャンク分割です。「文書を512トークンで切る」だけの素朴な実装では、ほぼ確実に精度が出ません。今回は5つの分割方法と、文書タイプ別の選び方を実装例で。
5つの分割方法
| 手法 | 向く文書 | 短所 |
|---|---|---|
| 固定長分割 | 短いブログ・FAQ | 文中で切れる |
| セマンティック分割 | 技術記事・マニュアル | 実装やや重い |
| 階層分割 | 長文・契約書 | メタデータ管理必要 |
| 文書構造ベース | Markdown・HTML・コード | マークアップ前提 |
| ハイブリッド | 混在ナレッジ | 設計コスト高 |
セマンティック分割の実装例
段落・句読点ベースの分割
Python
from typing import Listimport re
def semantic_split(text: str, target_tokens: int = 400) -> List[str]: # 段落で分割、長すぎる段落は句読点で分割 paragraphs = [p for p in text.split("\n\n") if p.strip()] chunks = [] buffer = "" for p in paragraphs: if estimate_tokens(buffer) + estimate_tokens(p) <= target_tokens: buffer += "\n\n" + p if buffer else p else: if buffer: chunks.append(buffer) if estimate_tokens(p) > target_tokens: # 句読点で再分割 chunks.extend(split_by_punctuation(p, target_tokens)) buffer = "" else: buffer = p if buffer: chunks.append(buffer) return chunks階層分割：親チャンクの活用
長文（契約書・社内規程など）では、子チャンクで検索して親チャンクを に渡す「Parent Document Retrieval」が効きます。検索の細かさと文脈の広さを両立できます。
に最適チャンク戦略を選ばせる
prompt：チャンク戦略の選定
以下の文書群に最適なチャンク戦略を提案してください。
## 文書プロファイル
@knowledge_base/sample-50docs/
## 観点
1. 文書タイプの分類（FAQ / 技術記事 / 契約書 / コード / 議事録 / その他）
2. 各タイプの平均長・構造の有無
3. 推奨チャンク戦略（5手法から選定）
4. 想定 chunk_size / overlap
5. 実装サンプルコード 想定される実行結果（例示）
## チャンク戦略提案
### 文書分類
- FAQ: 14件、平均 200 tokens
- 技術記事: 8件、平均 1,500 tokens、Markdown構造あり
- 契約書: 5件、平均 8,000 tokens、章節構造強い
- コード: 12件、ファイル単位
- 議事録: 11件、対話形式
### 推奨戦略
| タイプ | 戦略 | chunk_size | overlap |
|---|---|---|---|
| FAQ | 固定長 | 300 | 0 |
| 技術記事 | 文書構造（H2/H3）+ セマンティック | 500 | 50 |
| 契約書 | 階層（条項単位の親 + 段落単位の子） | 親:2000 / 子:400 | 0 |
| コード | 関数/クラス単位 | 関数1個=1チャンク | 0 |
| 議事録 | 発言クラスタ + セマンティック | 400 | 0 |
### 実装コード生成完了
- `rag/chunking/strategies.py` - 5戦略の実装
- `rag/chunking/router.py` - 文書タイプ判定ルーター
- `tests/test_chunking.py` - 各戦略のテスト
`make chunk-test` で全文書の再チャンク化を実行可能です。次回予告
EP.03 では、 モデル選定の落とし穴を、多言語対応・コスト・ベンチマークの観点で深掘りします。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。