输入：干净的文本 / 简单的 PDF
处理：Chunk → Embed → Retrieve → Generate
输出：答案

输入：扫描件 PDF、带表格的年报、技术手册、合同......
预处理：OCR、布局分析、表格识别、公式识别......
处理：Chunk → Embed → Retrieve → Generate
输出：答案 + 引用

不只是 RAG 框架，而是"文档理解 + RAG"的一体化方案

原文：错误码 E0028
OCR 结果：错误码 E002B（8 被识别成 B）

用户问：错误码 E0028 是什么意思
检索：找不到（因为文档里是 E002B）

原文（两栏排版）：
┌──────────────┬──────────────┐
│ 左栏内容      │ 右栏内容      │
│ 跨多行...    │ 跨多行...    │
└──────────────┴──────────────┘

普通解析结果：
左栏内容
右栏内容  ← 两栏混在一起，语义被打断

原文表格：
┌────────┬────────┬────────┐
│ 参数    │ 类型    │ 说明    │
├────────┼────────┼────────┤
│ timeout│ int    │ 超时时间│
│ retry  │ bool   │ 是否重试│
└────────┴────────┴────────┘

普通解析结果：
参数 类型 说明 timeout int 超时时间 retry bool 是否重试
← 变成一行，结构全丢了

DeepDoc Pipeline：

┌──────────┐    ┌──────────┐    ┌──────────────┐
│  Input   │───▶│  Layout  │───▶│   OCR Engine │
│  File    │    │  Analysis│    │  (PaddleOCR) │
└──────────┘    └──────────┘    └──────┬───────┘
                                       │
                ┌──────────────────────┘
                ▼
┌──────────────────────────────────────────────┐
│           Structure Recognition               │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐  │
│  │  Table   │ │  Figure  │ │   Formula    │  │
│  │  Parser  │ │  Parser  │ │   Parser     │  │
│  └──────────┘ └──────────┘ └──────────────┘  │
└──────────────────────────────────────────────┘
                │
                ▼
┌──────────────────────────────────────────────┐
│           Semantic Understanding              │
│  • 标题识别                                   │
│  • 章节分割                                   │
│  • 关系提取                                   │
└──────────────────────────────────────────────┘
                │
                ▼
┌──────────────────────────────────────────────┐
│           Markdown / Structured Output        │
└──────────────────────────────────────────────┘

Step 1: 表格检测
用目标检测模型定位表格区域

Step 2: 结构识别
Table-Transformer 识别：
- 行边界
- 列边界
- 单元格合并关系

Step 3: 内容识别
对每个单元格做 OCR

Step 4: 结构化输出
┌────────┬────────┐
│ A1     │ A2     │   →   [{"row":1,"col":1,"text":"A1"}, ...]
├────────┼────────┤
│ B1     │ B2     │
└────────┴────────┘

FAQ 文档：
Q: 问题
A: 答案
─────────
每个 QA 对是独立的语义单元

技术手册：
## 安装
步骤 1...
步骤 2...
## 配置
参数 1...
参数 2...
─────────
按章节切分，保留标题上下文

法律文档：
第一条 ...
第二条 ...
第三条 ...
─────────
按条款切分，每条有独立法律意义

原始文档：
# 第一章 概述
## 1.1 背景
文本内容...
## 1.2 目标
文本内容...
# 第二章 设计
## 2.1 架构
文本内容...

切分结果：
Chunk 1: 【第一章 概述 > 1.1 背景】文本内容...
Chunk 2: 【第一章 概述 > 1.2 目标】文本内容...
Chunk 3: 【第二章 设计 > 2.1 架构】文本内容...

方案 1：行级切分
每行一个 chunk，保留表头

方案 2：单元格级切分
每个单元格一个 chunk，附带行列信息

RAGFlow 的做法：
- 检测表格结构
- 保留表头作为上下文
- 行级切分
- 每个 chunk 包含：表头 + 该行内容

示例：
原始表格：
| 参数 | 类型 | 说明 |
|------|------|------|
| timeout | int | 超时时间 |

切分后的 chunk：
【表：API 参数配置】
参数: timeout | 类型: int | 说明: 超时时间

Query
  │
  ├─── 向量检索（Dense）───┐
  │                       │
  ├─── 关键词检索（BM25）──┤──→ RRF 融合 ──→ Rerank ──→ Top-K
  │                       │
  └─── Metadata 过滤 ─────┘

RRF 公式：
score(d) = Σ 1 / (k + rank_i(d))

其中：
- d：文档
- rank_i(d)：文档 d 在第 i 路检索中的排名
- k：平滑参数（通常 60）

问题：向量分数（0.82）和 BM25 分数（5.2）不在同一尺度

传统方案：
- 分数归一化：复杂，不稳定
- 加权融合：权重难调

RRF 的做法：
- 不管分数多少
- 只看排名
- 排名第 1 → 得分 1/61
- 排名第 2 → 得分 1/62
- 两路都召回的文档，得分更高

Query："错误码 401"

向量检索：
#1 Doc_A
#2 Doc_B
#3 Doc_C

BM25 检索：
#1 Doc_D
#2 Doc_C  ← 两路都有
#3 Doc_A  ← 两路都有

RRF 融合：
Doc_C: 1/(60+3) + 1/(60+2) = 0.032  ← 最高
Doc_A: 1/(60+1) + 1/(60+3) = 0.032
Doc_B: 1/(60+2) + 0 = 0.016
Doc_D: 0 + 1/(60+1) = 0.016

原理：
Query + Document → Transformer → Relevance Score

为什么比向量检索更准：
- 向量检索：Query 和 Document 各自编码，交互少
- Cross-Encoder：Query 和 Document 拼在一起编码，充分交互

召回：top-50（向量 + BM25）
Rerank：top-50 全部重排
输出：top-5

RAGFlow：应用导向
"我要做一个企业知识库" → RAGFlow 提供完整方案
特点：一站式，开箱即用

LangChain：组件导向
"我要组装一个 Agent" → LangChain 提供各种组件
特点：灵活，但需要自己组装

LlamaIndex：数据导向
"我要索引和查询数据" → LlamaIndex 提供数据框架
特点：数据处理能力强，适合研究

# RAGFlow：高层抽象，配置驱动
from ragflow import RAGFlow

app = RAGFlow()
dataset = app.create_dataset(name="knowledge")
dataset.add_documents("./docs")
chat = app.create_chat(dataset=dataset)
response = chat.query("What is RAG?")

# LangChain：Chain 组合式
from langchain.chains import RetrievalQA
from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings

vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings())
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(),
    retriever=vectorstore.as_retriever()
)
response = qa.run("What is RAG?")

# LlamaIndex：索引为中心
from llama_index import VectorStoreIndex, SimpleDirectoryReader

documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query("What is RAG?")

# 创建数据集
POST /api/dataset
{"name": "my_knowledge"}

# 上传文档
POST /api/document/upload
-F "file=@document.pdf"
-F "dataset_id={id}"

# 对话
POST /api/chat/completion
{
  "question": "什么是 RAG?",
  "dataset_ids": ["{id}"],
  "stream": true
}

最小部署（Docker Compose）：
├── ragflow（API 服务）
├── milvus（向量库）
├── mysql（元数据）
└── elasticsearch（可选，全文检索）

生产部署（Kubernetes）：
├── Ingress
├── ragflow deployment（多副本）
├── milvus cluster
├── mysql primary/replica
└── 监控（Prometheus + Grafana）

租户隔离：
- 每个租户独立的数据集
- 数据集级别的访问控制
- API Key 认证

权限模型：
- 管理员：全部权限
- 编辑者：上传、解析、编辑
- 查看者：仅查询

指标监控：
- 文档处理吞吐量
- 检索延迟（P50/P95/P99）
- LLM 调用耗时
- 向量库查询性能

日志追踪：
- 请求级 Trace ID
- 结构化日志
- 全链路追踪

# 克隆项目
git clone https://github.com/infiniflow/ragflow.git
cd ragflow

# Docker Compose 启动
docker compose up -d

# 访问 Web UI
open http://localhost:9380

# 创建数据集、上传文档、开始对话

Dataset（数据集）
├── Document（文档）
│   ├── Chunk（切片）
│   └── Embedding（向量）
└── Chat（对话）

流程：
上传文档 → DeepDoc 解析 → 切分 → 向量化 → 存储
                                         ↓
Query → 检索 → Rerank → LLM 生成 → 答案 + 引用

1. DeepDoc：解决被忽视的文档解析问题
2. 多策略 Chunking：不同文档不同切法
3. 混合检索：向量 + BM25 + Rerank
4. 开箱即用：UI + API + 部署方案