【Ragflow】11. 文件解析流程分析/批量解析实现

概述

本文继续对ragflow文档解析部分进行分析，并通过脚本的方式实现对文件的批量上传解析。

文件解析流程

文件解析的请求处理流程大致如下：

1.前端上传文件，通过v1/document/run接口，发起文件解析请求

2.后端api\apps\document_app.py的run函数接收请求，校验用户权限，处理文档解析运行信息，创建新的任务队列

3.后端api\db\services\task_service.py的queue_tasks函数进一步根据文档根据文档类型和页数，将文档分割成多个子任务，并通过解析器进行解析。

4.解析器在deepdoc\parser路径下，对于docx、excel、pdf等不同格式的文件都有不同的解析策略。其中，pdf的解析策略最为复杂，因为要设计需要先转成图像，再进行ocr文本识别。

5.解析完成后，会生成文本块，并构建索引，存储到向量数据库。

在解析过程的同时，前端同时还会定时向v1/document/list这个接口发起轮询，以获取解析的进度信息。

文件解析模型

ragflow的文件解析采用了名为deepdoc的模型，该模型的相关资料并不多，是其自研的模型，在hugging face上公布了具体的模型权重：

hf地址：https://huggingface.co/InfiniFlow/deepdoc

从模型体积上看，其采用的模型并不大，但对不同的任务，会采用不同的模型，比如OCR（光学字符识别）、TSR（表格结构识别）、DLA（文档布局分析）等多种解析任务。

文件解析加速实验

由于解析模型都是onnx形式的模型，因此，如果使用gpu进行解析，理论上可以显著加速解析速度。

于是下面做个实验，通过docker-compose-gpu.yml文件启动容器，使其能够访问外部gpu。

启动命令：

docker compose -f docker-compose-gpu.yml up -d

对于一篇学位论文的pdf文件，未使用gpu，通过docker-compose.yml进行解析，花费时间约10分钟。

使用gpu配置启动容器，对相同文件进行解析，发现cpu多核全部拉满，gpu仍然未工作，因此速度基本无差别。

说明仅通过docker-compose-gpu.yml似乎无法成功利用上gpu资源，此点还需进一步论证。

观察docx和pdf的解析器设置，docx只需要解析纯文本信息，而无需进行ocr处理，因此理论解析速度会比pdf文件快很多，下面进行一个实验，比较word文件和pdf文件的解析日志，内容如下：

word格式文件解析日志：

进度:
15:36:34 Task has been received.
15:36:34 Page(