4.4 知识库存储结构与分段规则

Pop 的知识库（Knowledge Base）之所以能实现高质量检索和精准回答，核心在于：
⭑ 文档解析 → 清洗 → 分段（Chunking） → 嵌入向量 → 存储结构化数据

本节将详细介绍 Pop 如何将文档拆分为可检索的片段，以及它在底层是如何存储的。

🗂️ 一、知识库存储结构概览

每个知识库的数据由三大部分组成：

知识库（KB）
 ├── 文档（Documents）
 ├── 文档片段（Chunks）
 ├── 索引结构（Indexes）
       ├── 向量索引（KNN）
       └── BM25 文本索引

流程示意图：

原始文档 → 解析 → 文本清洗 → 自动分段 → 生成 Embedding → 写入索引

📄 二、文档解析（Parsing）

Pop 会根据不同格式自动解析文档：

文档类型	解析方式
PDF	文本解析 + OCR（扫描版）
Word / PPT	直接读取文本内容
Markdown	按标题结构解析
HTML / URL	自动提取正文（去广告）
代码文件	作为普通文本处理

解析后会得到较为整洁的原始文本，进入下一步清洗。

🧹 三、文本清洗（Cleaning）

为了获得高质量的向量表示，Pop 会对解析后的内容做进一步处理：

去除页眉、页脚、页码
去除多余空白行、特殊符号
合并被硬换行拆散的段落
删除重复内容
修正格式混乱的标题、列表

这样可以显著提升分段效果与语义检索准确性。

🔀 四、文档分段（Chunking）核心逻辑

分段（Chunk）是知识库最关键的步骤之一。
好的分段能让 AI 更容易找到正确的内容，差的分段则会导致答非所问。

Pop 使用混合的智能分段策略：

4.1 按标题结构切分

适用于 Markdown、PDF、Word 等格式：

例如：

# 1. 系统概述
## 1.1 功能列表
### 1.1.1 用户模块

不同层级标题会作为切分根节点，确保结构完整。

4.2 按语义自动切分

在标题结构基础上，进一步按自然段落进行拆分：

避免太长
避免太短
保持语义连贯
保留上下文关联

典型策略：

目标长度：250–500 中文字符 / Chunk
允许上下容差：200–600 字
自动合并过短段落
自动拆分过长段落

4.3 特殊内容的分段处理

不同格式采用不同的优化：

内容类型	处理方式
列表（bullet / number）	整体保留为一个 chunk
表格	视为连续文本（自动格式化）
代码块	作为独立 Chunk
表单字段	自动压缩为键值对形式
图像（OCR）	从 OCR 文本中抽取有效内容

🧩 五、Chunk 存储结构

每个 Chunk 会被存储为结构化对象，如：

{
  "id": "chunk_xxx",
  "kb_id": "kb_abc",
  "document_id": "doc_123",
  "content": "...",
  "tokens": 356,
  "embedding": [0.12, -0.44, ...],
  "order": 17,
  "metadata": {
      "title": "1.2 系统功能",
      "page": 5,
      "source": "xxx.pdf"
  }
}

字段说明：

字段	描述
id	每个 chunk 的唯一 ID
kb_id	所属知识库
document_id	所属文档 ID
content	该片段的文本内容
tokens	token 数量
embedding	向量数据
order	在整个文档的顺序
metadata	标题、页码、来源等信息

🔎 六、索引结构

Pop 构建两类索引：

6.1 KNN 向量索引

用于语义检索：

用选定的向量模型生成 embedding
存入本地向量数据库
支持高维检索（如 768D、1024D）
用于基于语义的召回

6.2 BM25 文本索引

适用于：

精准关键词搜索
FAQ 类内容
术语定位

两者共同支持 Hybrid 检索。

🧠 七、为什么分段如此重要？

分段是 RAG（检索增强生成）的基础，它直接影响：

AI 召回是否准确
是否能找到正确答案
回答是否包含上下文
引用是否能追溯到原文

好的 Chunk = 高质量 RAG。

糟糕的 Chunk = 模型永远答不准。

Pop 使用的智能分段策略在多数情况下能达到一致稳定的效果。

📌 总结

Pop 在知识库底层实现了：

文档解析
清洗去噪
智能分段
语义向量生成
BM25 索引
高性能存储结构

这些共同构成了 Pop 知识库的核心能力，使得 Pop 能够在问答中基于文档内容给出准确且可验证的回答。