[Bug]: MinerU parser ignores split page ranges and duplicates chunks

快速结论：该问题在使用 RAGFlow 的 MinerU 解析器处理多页 PDF 时发生，所有分页任务（如 Page(1~13)、Page(13~25)）实际都解析了整份 PDF，导致 chunk 完全重复。优先排查 deepdoc/parser/mineru_parser.py 中的 start_page_id 和 end_page_id 是否被硬编码为固定值。

问题场景

用户在使用 RAGFlow v0.26.2（commit 62f94cd5）搭配 Docker Compose 部署，配置 MinerU 作为 PDF 解析器（通过 MinerU API 服务）。上传一份超过单次解析页数限制的 32 页 PDF（含多张图片），RAGFlow 自动将文档拆分为多个页范围任务（如 1~13、13~25、25~32），但每个任务输出相同数量的 block 和 image，产生重复 chunk。

报错原文

Page(1~13): [MinerU] Parsed 405 blocks from PDF.
Page(1~13): [MinerU] Generating VLM descriptions for 11 images...
Page(1~13): Generate 27 chunks

Page(13~25): [MinerU] Parsed 405 blocks from PDF.
Page(13~25): [MinerU] Generating VLM descriptions for 11 images...
Page(13~25): Generate 27 chunks

Page(25~32): [MinerU] Parsed 405 blocks from PDF.
Page(25~32): [MinerU] Generating VLM descriptions for 11 images...
Page(25~32): Generate 27 chunks

所有分页任务各自产出了完全相同的 block 数、image 数和 chunk 数（405 blocks, 11 images, 27 chunks），说明每个任务都解析了整份 PDF 而非各自分配的页范围。

原因分析

确认是 RAGFlow 源码 deepdoc/parser/mineru_parser.py 中 _run_mineru_api 方法的 bug。该方法在构造 MinerU API 请求时，将 start_page_id 硬编码为 0、end_page_id 硬编码为 99999，导致不论实际任务分配的页范围（如 1~13、13~25），每次 API 请求都会解析 PDF 的全部页面。这是已确认的 bug，并非用户配置错误。

环境排查

RAGFlow 镜像版本：v0.26.2
代码提交 ID：62f94cd59b505b56df724faba4d4a2a8ce79679a（需确认是否已包含修复）
部署方式：Docker Compose
PDF 解析器配置：MinerU（通过 MinerU API 服务）

解决步骤

定位文件：打开 deepdoc/parser/mineru_parser.py，找到 _run_mineru_api 方法。
定位第 303-304 行附近，检查以下硬编码：
```
"start_page_id": 0,
"end_page_id": 99999
```
修改为使用传入的实际页范围参数，例如：
```
"start_page_id": actual_start_page,
"end_page_id": actual_end_page
```
具体变量名需参考调用处传入的参数名称（示例而非确确定义）。
保存文件后，重新构建并部署 RAGFlow，或重启服务以加载修改。
可优先尝试：升级到最新版本的 RAGFlow，确认该修复是否已被合并到主分支。

验证方法

上传一份多页含图的 PDF（例如 32 页），观察分页任务的日志输出。修复后，每个任务的 block 数、image 数和 chunk 数应各不相同，且 chunk 总数不应是单页量乘以任务数。例如：Page(1~13) 解析出约 180 blocks，Page(13~25) 解析出约 150 blocks，Page(25~32) 解析出约 75 blocks 等情况。