目录
1、文档解析器
1.1、DeepDoc
1.1.1、多格式解析器
1.1.2、 视觉信息处理
1.1.3、 增强处理管线
1.1.4、典型应用场景
1.2、Naive（only PDF纯文本）
1.2.1、 核心概念与特点
2、嵌入模型
2.1、核心推荐模型
2.1.1、BGE系列
2.1.2、m3e-large
2.1.3、ERNIE-Search
2.2、 不同场景下的适配建议
2.3、关键选择维度
2.3.1、语义捕捉能力
2.3.2、多语言支持
2.3.3、资源与成本
3、切片方法
3.1、General
3.2、Q&A
3.3、Resume
3.4、Manual（only PDF）
3.5、Table
3.6、 Paper（only PDF）
3.7、Book
3.8、Laws
3.9、Presentation
3.10、One
3.11、Knowledge Graph
3.12、Tag
4、召回增强RAPTOR策略
4.1、核心机制
4.1.1、树状语义组织
4.1.2、动态语义融合
4.2、查询机制
4.2.1、树层遍历（Tree Traversal）
4.2.2、折叠树检索（Collapsed Tree Retrieval）
4.3、典型应用场景
5、知识图谱
5.1、方法
5.1.1、Light
5.1.2、General
5.2、实体归一化
5.3、社区报告生成
1、文档解析器
1.1、DeepDoc
DeepDoc 是一款面向 RAG（检索增强生成）场景设计的深度文档解析框架，具备多格式支持、复杂布局识别和结构化输出能力。其核心特性及实现逻辑如下：
1.1.1、多格式解析器
- PDF：结合 OCR 与视觉模型处理扫描件/数字版文档。
- Office 文档：通过
docx_parser.py/excel_parser.py等模块提取结构化数据。 - 简历/手册：基于实体识别技术提取关键词并生成结构化数据。
1.1.2、 视觉信息处理
-
版面分析：通过
layout_recognizer.py识别文档中的文字、图表、公式区域，支持论文级复杂布局解析。 - 表格处理：定义 5 类表格结构（含跨行列/多级标题），通过
table_structure_recognizer保留语义关联。
1.1.3、 增强处理管线
- OCR 集成：对扫描件执行文字识别，支持多语言混合排版。
- 规则引擎：内置文本块排序规则，辅以 XGBoost 模型处理边界案例（实测规则覆盖 90% 场景）。
1.1.4、典型应用场景
-
技术文档知识库构建：保留手册/论文中的图表与公式上下文，避免传统分块导致的语义断裂。
-
简历智能解析：通过预定义实体（如
大学/公司）提取关键信息，生成标准化人才画像。 -
金融报告分析：精准解析包含多层表头的财务报表，支持 LLM 生成带数据引用的分析结论。
1.2、Naive（only PDF纯文本）
“Naive”通常指代基础、模块化的技术路径，强调分阶段处理与简单流程设计。以下是其核心要点及关联技术总结：
1.2.1、 核心概念与特点
- 模块化 Pipeline 系统：将文档解析拆分为布局分析、内容提取、关系整合等独立阶段，依赖规则引擎逐步处理结构化/非结构化文档。
- Naive RAG 关联技术：作为检索增强生成（RAG）的最初范式，结合传统关键词检索（如 TF-IDF、BM25）与外部知识库增强生成结果，常用于基础文档解析与信息整合场景。
- 流程简单：依赖线性处理逻辑，适合处理固定格式文档（如 PDF、Word）。
- 依赖规则与统计模型：如布局分析基于空间坐标定位文本块，文本分类使用朴素贝叶斯等传统算法。
2、嵌入模型
2.1、核心推荐模型
2.1.1、BGE系列
- BAAI/bge-M3：支持多语言混合检索（如中英混合数据），适合跨语言知识库，语义泛化能力优于单一语言模型。
- BAAI/bge-large-zh：北京智源研究院开发，专为中文优化，在语义检索和长文本处理中表现突出，特别适合对召回率要求高的场景。
2.1.2、m3e-large
纯中文场景下的高性能模型，在中文文本向量化任务中准确率较高，尤其适合短文本密集检索（如法律条款、金融报告）。
2.1.3、ERNIE-Search
百度飞桨团队开发的企业级模型，适用于大规模中文知识库，对复杂语义关系和专业领域术语（如医疗、法律）捕捉能力更强。
2.2、 不同场景下的适配建议
| 需求类型 | 推荐模型 | 优势 |
|---|---|---|
| 纯中文检索 | m3e-large、BAAI/bge-large-zh | 高语义匹配精度，支持长文本深度解析 |
| 中英混合检索 | BAAI/bge-M3 | 多语言优化，跨语言语义对齐能力突出 |
| 轻量级部署 | text2vec-base-chinese、bge-small-zh | 低计算资源需求，适合小规模项目快速验证 |
| 企业级应用 | ERNIE-Search、multilingual-e5-large | 高稳定性与扩展性，适配复杂业务逻辑 |
2.3、关键选择维度
2.3.1、语义捕捉能力
- m3e-large 在短文本场景（如条款匹配）中召回率高于通用模型。
- BGE 系列模型通过预训练优化中文词向量空间分布，在长文本和复杂逻辑关系中表现更优。
2.3.2、多语言支持
需处理多语言数据时，优先选择 BAAI/bge-M3 或 E5 系列，避免单一语言模型导致的跨语言语义偏差。
2.3.3、资源与成本
轻量级模型（如 text2vec）显存需求可低至 4GB，适合边缘部署；BGE-large-zh 需 16GB 显存，适合高精度场景。
3、切片方法
3.1、General
支持的文件格式为DOCX、EXCEL、PPT、IMAGE、PDF、TXT、MD、JSON、EML、HTML。
General 分块方法作为 RAG 知识库的基准策略，适用于格式统一、语义结构简单的文档处理，其核心价值在于实现低成本快速部署。但在处理复杂场景（如多层级法律条文、跨页表格）时，需结合语义分块（Semantic Chunking）或动态分块（Late Chunking）等高级策略以提升效果。
此方法将简单的方法应用于块文件：
- 系统将使用视觉检测模型将连续文本分割成多个片段。
- 接下来，这些连续的片段被合并成Token数不超过“Token数”的块。
3.2、Q&A
此块方法支持 excel 和 csv/txt 文件格式:
- 如果文件是 excel 格式，则应由两个列组成 没有标题：一个提出问题，另一个用于答案， 答案列之前的问题列。多张纸是 只要列正确结构，就可以接受。
- 如果文件是 csv/txt 格式 以 UTF-8 编码且用 TAB 作分开问题和答案的定界符。
未能遵循上述规则的文本行将被忽略，并且 每个问答对将被认为是一个独特的部分。
3.3、Resume
支持的文件格式为DOCX、PDF、TXT。简历有多种格式，就像一个人的个性一样，但我们经常必须将它们组织成结构化数据，以便于搜索。我们不是将简历分块，而是将简历解析为结构化数据。 作为HR，你可以扔掉所有的简历， 您只需与'RAGFlow'交谈即可列出所有符合资格的候选人。
3.4、Manual（only PDF）
仅支持PDF。我们假设手册具有分层部分结构。 我们使用最低的部分标题作为对文档进行切片的枢轴。 因此，同一部分中的图和表不会被分割，并且块大小可能会很大。
3.5、Table
支持XLSX和CSV/TXT格式文件。
- 对于 csv 或 txt 文件，列之间的分隔符为 TAB。
- 第一行必须是列标题。
- 列标题必须是有意义的术语，以便我们的大语言模型能够理解。 列举一些同义词时最好使用斜杠'/'来分隔，甚至更好 使用方括号枚举值，例如 'gender/sex(male,female)'.
3.6、 Paper（only PDF）
仅支持PDF文件。如果我们的模型运行良好，论文将按其部分进行切片，例如摘要、1.1、1.2等。这样做的好处是LLM可以更好的概括论文中相关章节的内容， 产生更全面的答案，帮助读者更好地理解论文。 缺点是它增加了 LLM 对话的背景并增加了计算成本， 所以在对话过程中，你可以考虑减少‘topN’的设置。
3.7、Book
支持的文件格式为DOCX、PDF、TXT。由于一本书很长，并不是所有部分都有用，如果是 PDF， 请为每本书设置页面范围，以消除负面影响并节省分析计算时间。
3.8、Laws
支持的文件格式为DOCX、PDF、TXT。法律文件有非常严格的书写格式。 我们使用文本特征来检测分割点。chunk的粒度与'ARTICLE'一致，所有上层文本都会包含在chunk中。
3.9、Presentation
支持的文件格式为PDF、PPTX。每个页面都将被视为一个块。 并且每个页面的缩略图都会被存储。您上传的所有PPT文件都会使用此方法自动分块，无需为每个PPT文件进行设置。
3.10、One
支持的文件格式为DOCX、EXCEL、PDF、TXT。对于一个文档，它将被视为一个完整的块，根本不会被分割。如果你要总结的东西需要一篇文章的全部上下文，并且所选LLM的上下文长度覆盖了文档长度，你可以尝试这种方法。
3.11、Knowledge Graph
支持的文件格式为DOCX、EXCEL、PPT、IMAGE、PDF、TXT、MD、JSON、EML。文件分块后，使用分块提取整个文档的知识图谱和思维导图。此方法将简单的方法应用于分块文件： 连续的文本将被切成大约 512 个 token 数的块。接下来，将分块传输到 LLM 以提取知识图谱和思维导图的节点和关系。注意您需要指定的条目类型。
3.12、Tag
使用“标签”作为分块方法的知识库应该被其他知识库使用，以将标签添加到其块中，对这些块的查询也将带有标签。使用“标签”作为分块方法的知识库不应该参与 RAG 过程。此知识库中的块是标签的示例，它们演示了整个标签集以及块和标签之间的相关性。
此块方法支持XLSX和CSV/TXT文件格式。
- 如果文件为XLSX格式，则它应该包含两列无标题：一列用于内容，另一列用于标签，内容列位于标签列之前。可以接受多个工作表，只要列结构正确即可。
- 如果文件为 CSV/TXT 格式，则必须使用 UTF-8 编码并以 TAB 作为分隔符来分隔内容和标签。
在标签列中，标签之间使用英文 逗号。不符合上述规则的文本行将被忽略，并且每对文本将被视为一个不同的块。
4、召回增强RAPTOR策略
RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）是一种通过多层次语义组织优化检索效果的召回增强策略，旨在解决传统 RAG 在复杂查询中的语义割裂与全局关联缺失问题。
4.1、核心机制
4.1.1、树状语义组织
- 递归聚类与摘要生成：通过高斯混合模型（GMM）对文本块嵌入向量进行递归聚类，生成多层级摘要，构建从底层细节到高层语义的树状结构。
- 层次化抽象：低层节点保留原始文本片段，中层节点为局部语义摘要（如段落主题），高层节点覆盖全局文档框架（如章节核心观点）。
4.1.2、动态语义融合
通过树状结构在不同抽象层级间建立关联，确保检索时既能捕捉细节信息，又能理解上下文逻辑（如跨段落推理）。
4.2、查询机制
4.2.1、树层遍历（Tree Traversal）
从根节点（高层摘要）逐层向下检索，通过相似度计算选择子节点深入，适合需要逐步细化信息的复杂查询（如多步骤推理任务）。
4.2.2、折叠树检索（Collapsed Tree Retrieval）
将树结构“折叠”为单层，在全局范围内检索所有层级的节点，适合快速获取高相关性的答案（如事实型问题）。
4.3、典型应用场景
- 长文档处理：对论文、法律条文等长文本，通过高层摘要快速定位核心章节，再结合底层文本验证细节。
- 跨域知识关联：在医疗、金融等专业领域，通过树状结构建立术语与案例的多层级关联（如病症→治疗方案→用药指南）。
- 动态数据更新：新增文档时仅需局部更新子树，避免全局索引重建，提升知识库维护效率。
RAPTOR 通过树状语义组织与多层级检索机制，显著提升了 RAG 系统在复杂场景下的召回能力与答案质量，尤其在长文本理解、跨域知识关联等任务中表现突出。其与两阶段优化（如粗筛+精排）、知识图谱增强1等策略结合，可进一步释放 RAG 技术的应用潜力。
5、知识图谱
5.1、方法
5.1.1、Light
实体和关系提取提示来自 GitHub - HKUDS/LightRAG：“LightRAG：简单快速的检索增强生成”。
5.1.2、General
实体和关系提取提示来自 GitHub - microsoft/graphrag：基于图的模块化检索增强生成 (RAG) 系统。
5.2、实体归一化
解析过程会将具有相同含义的实体合并在一起，从而使知识图谱更简洁、更准确。应合并以下实体：特朗普总统、唐纳德·特朗普、唐纳德·J·特朗普、唐纳德·约翰·特朗普。
5.3、社区报告生成
区块被聚集成层次化的社区，实体和关系通过更高抽象层次将每个部分连接起来。然后，我们使用 LLM 生成每个社区的摘要，称为社区报告。更多信息：https://www.microsoft.com/en-us/research/blog/graphrag-improving-global-search-via-dynamic-community-selection/。