
对于高专业性或企业级的知识问答应用,RAGFlow是各个开发团队的常用框架,它提供的工具链简化了从知识库搭建、向量检索到生成的RAG流水线开发。RAG这条务实的路径让LLM能实时查询私有知识库,显著提升回答相关性和可控性,避免直接调用LLM产生的知识更新慢、回答不准或数据安全风险。
构建健壮的RAG系统,尤其是企业级应用,涉及复杂组件集成与优化。如何在RAGFlow基础上实现性能优化,也成为大家关注的课题。

从RAG链路出发,首要关键因素即是文档解析的质量。在应用RAGFlow框架时,我们也需要首先关注解析能力,解析输出的数据是AI应用的“基础燃料”,影响后续分块、检索和最终结果,不尽如人意的解析输出将会大幅度影响RAG性能。
如下图中,对于同一份文件的连续两页目录,其中一页识别为正文,另一页识别为表格,这也导致了后续分块的错误。


在实际使用中发现的解析问题还包括:
为了优化解析效果,避免文档中的关键信息在导入知识库时就发生损耗,我们采用了自定义解析工具的策略。
本文将说明文档解析工具的类型与适用性、TextIn的性能、在RAGFlow框架下使用自定义解析的方法、实战教程与完整代码。
简单来说,文档解析工具的核心任务是将非结构化文档(如PDF、图片、扫描件)中的文本、表格、图片等内容识别并提取出来,转化为结构化数据以供机器处理和分析。从社区或商业化、使用方法上,可以区分几种类型:
另一方面,其劣势主要体现在:1、技术门槛高:需要具备相当的开发、运维和系统集成能力才能有效部署、配置、定制和维护,对非技术团队或资源有限的组织挑战较大。2、集成与维护负担:用户需自行解决依赖关系、环境配置、版本升级、性能调优、安全补丁等运维工作,耗费时间和人力。3、专业支持有限:主要依赖社区支持,响应速度和问题解决的专业性、保障性通常不如商业闭源产品的官方支持。4、特定场景功能不足:针对特定行业场景(例如复杂的财务表格、医疗报告结构化)的预训练模型或精细化处理能力,可能不如成熟的商业闭源产品。
商业化产品的劣势在于使用成本与低透明度(用户无法直接修改核心代码)。而优势则包括:1、开箱即用,易于集成:通常提供完善的前端界面、软件开发工具包(SDK)、清晰的文档和示例,集成相对简单快捷,使用技术门槛低。2、专业支持与服务:提供专业的技术支持、问题响应、培训服务,减轻用户运维负担。3、深度优化与特定功能:厂商投入大量资源进行核心算法研发、模型训练(尤其在特定领域如法律合同、医学文献、复杂表格识别)和性能优化,往往在精度、特定场景覆盖和功能深度上具备优势。4、持续更新与维护: 专业厂商负责产品的迭代更新、功能增强、漏洞修复和性能优化,用户无需操心底层技术细节。
在使用方法这个维度,主要有API调用和本地化部署两类,特点如下:
API调用方法便于:1、快速启动,零运维: 无需购置、配置和管理服务器基础设施,注册账号、获取API密钥即可立即使用,大幅缩短上线时间。2、持续获取最新能力: 用户自动获得供应商发布的最新模型、功能和性能优化,无需手动升级。3、降低初始投入: 通常按需付费,避免了前期高昂的硬件和软件许可投资。
但同时,风险项在于:1、不符合部分企业的数据安全要求。2、解析速度和稳定性受网络状况影响。3、 API提供的是标准化的功能接口,功能定制相对受限。
本地部署模式能够保障:1、数据安全与合规性: 文档数据完全保留在用户自己的基础设施(如私有云、数据中心)内部处理,最大程度降低数据风险,更容易满足严格的合规和监管要求。2、性能与延迟可控: 处理过程在本地网络进行,不受公网质量影响,通常延迟更低。对于超大文件或批处理,本地资源更可控。
而其劣势体现在:1、高初始投入与运维负担: 需采购、配置和维护服务器硬件、存储、网络以及软件环境(包括可能的GPU资源),需要专业的IT运维团队。2、部署复杂,上线周期长: 安装、配置、测试和优化本地部署的解决方案需要较长时间和专业知识。3、更新滞后: 用户需要主动关注并手动执行版本升级来获取新功能和修复,过程可能繁琐且存在兼容性风险。
总体来说,最佳选择往往取决于具体需求和资源情况。这一期RAGFlow实战演示中,我们对复杂文档的解析精度有较高要求,同时考虑调用便捷程度,选择了TextIn xParse,支持直接API调用。
聊一下为何选择TextIn。
TextIn xParse文档解析是一款大模型友好的解析工具,能够精准还原pdf、word、excel、ppt、图片等十余种格式的非结构化文件,将其快速转换为Markdown或JSON格式返回,同时包含精确的页面元素和坐标信息。支持识别文本、图像、表格、公式、手写体、表单字段、页眉页脚等各种元素,并支持印章、二维码、条形码等子类型,能满足绝大部分复杂文档的解析需求。
其核心能力包括:
实际的解析效果可以通过一些样本实测初步判断。对于不同的文档集,文档解析工具的效果可能有所差异,大家在调用之前也可在官网上用免费额度测一下自己的样本:https://www.textin.com/market/detail/xparse

密集少线表格识别效果很好,官网前端支持选中表格并在原图上显示模型预测的单元格(TextIn这套前端工具已经开源了,项目地址:https://github.com/intsig-textin/textin-ocr-frontend)。

跨页表格合并效果好,也能精准识别页眉页脚。

多栏学术论文的阅读顺序还原很准确。

对于没有精确数值标注的图表,会通过测量给出预估数值;这个功能对金融分析类工作会很有帮助。

TextIn解析内置有图像处理算法,能解决弯折、倾斜、阴影、模糊这些常见的图像质量问题。
要在RAG流程中实现自定义解析,我们可以考虑两种方案,便捷程度和效果有所差异,下面具体讨论:
较为简易的方案,直接调用自定义解析接口,解析完成后通过API导入RAGFlow知识库。

可以在导入后使用RAGFlow分块策略,也可自行完成Chunking后输入知识库。
这种方法最大的好处在于简便快捷,但由于RAGFlow的API导入有一定缺陷,会产生上传信息不完整(如缺少图片、位置信息)、分块顺序紊乱等问题,因而在知识库预览时也无法联动PDF源文件位置,快速进行对应查看和校对。
如下图3是解析后上传知识库的效果图,图4是在RAGFlow框架内完成解析后的效果,对比可以看到差异。


因此,该方案适合少量文件补充处理,如果要建立更完善的知识库搭建全流程,我们还需要另寻他法。

通过代码修改,我们能从结构上改变解析策略,也能够解决方法1中的不适配问题,实现更彻底的流程搭建。下面,我们来看具体的实战教程,如何快速实现解析方法替换。
1、启动服务(测试的镜像版本为 infiniflow/ragflow:v0.20.1 )
docker compose -f docker-compose-gpu.yml up -d2、textin.com 获取 app-id和secret-code信息

3、替换镜像中的 /ragflow/rag/app/naive.py 文件 (注意修改438行、439行的 x-ti-app-id 和 x-ti-secret-code)
完整代码文件地址:https://dllf.textin.com/download/2025/CustomService/naive.py
docker cp naive.py ragflow-server:/ragflow/rag/app/naive.py4、重启服务
docker compose restart我们来详细解读方案逻辑。
首先,我们需要厘清Ragflow的解析分块过程。

以native分块策略,调用DeepDOC解析PDF文件为例,对应的源码路径为ragflow/rag/app/naive.py。
首先调用PDF解析器:
class Pdf(PdfParser):
def __init__(self):
def __call__(self, filename, binary=None, from_page=0,
to_page=100000, zoomin=3, callback=None, separate_tables_figures=False):
start = timer()
first_start = start
callback(msg="OCR started")
# ocr识别
self.__images__(
filename if not binary else binary,
zoomin,
from_page,
to_page,
callback
)
callback(msg="OCR finished ({:.2f}s)".format(timer() - start))
start = timer()
# 布局分析 识别标题/段落等层级
self._layouts_rec(zoomin)
callback(0.63, "Layout analysis ({:.2f}s)".format(timer() - start))
start = timer()
# 使用 transformer 进行表格检测与识别
self._table_transformer_job(zoomin)
callback(0.65, "Table analysis ({:.2f}s)".format(timer() - start))
start = timer()
self._text_merge()
callback(0.67, "Text merged ({:.2f}s)".format(timer() - start))
# 是否分离表格和图形
if separate_tables_figures:
tbls, figures = self._extract_table_figure(True, zoomin, True, True, True)
self._concat_downward()
logging.info("layouts cost: {}s".format(timer() - first_start))
# 返回文本块+表格+图形
return [(b["text"], self._line_tag(b, zoomin)) for b in self.boxes], tbls, figures
else:
tbls = self._extract_table_figure(True, zoomin, True, True)
# self._naive_vertical_merge()
self._concat_downward()
# self._filter_forpages()
logging.info("layouts cost: {}s".format(timer() - first_start))
return [(b["text"], self._line_tag(b, zoomin)) for b in self.boxes], tblspdf解析器返回的数据结构:

后续将调用以下两个方法,分别处理段落和表格的分块:
res = tokenize_table(tables, doc, is_english):处理表格分块res.extend(tokenize_chunks_with_images(chunks, doc, is_english, images)):处理文本段落分块分块逻辑位于ragflow/rag/nlp,整体策略如下:
。?!;)切分内容。PIL.Image)及位置信息(页码与坐标)。chunk分块返回的数据结构:

通过分析解析分块过程,只需要构造对应的数据结构和修改相应的代码,就可以替换解析和分块。
修改文件/ragflow/rag/app/naive.py,修改PDF类的call方法提前返回,仅保留对images的调用。
class Pdf(PdfParser):
def __init__(self):
super().__init__()
def __call__(self, filename, binary=None, from_page=0,
to_page=100000, zoomin=3, callback=None, separate_tables_figures=False):
start = timer()
first_start = start
callback(msg="OCR started")
self.__images__(
filename if not binary else binary,
zoomin,
from_page,
to_page,
callback
)
callback(msg="OCR finished ({:.2f}s)".format(timer() - start))
logging.info("OCR({}~{}): {:.2f}s".format(from_page, to_page, timer() - start))
return [], [] # 提前结束返回修改文件/ragflow/deepdoc/parser/pdf_parser.py,保留前面通过pypdf获取文本判断是否为英文文档的部分,只跳过OCR识别。
async def __img_ocr(i, id, img, chars, limiter):
return # 提前结束返回修改文件/ragflow/rag/app/naive.py,修改chunk函数if layout_recognizer == "DeepDOC":分支下的代码。
if layout_recognizer == "DeepDOC":
pdf_parser = Pdf()
# 下面是替换的代码
import json
import requests
sections, tables = pdf_parser(filename if not binary else binary, from_page=from_page, to_page=to_page, callback=callback)
headers = {
'x-ti-app-id': '***',
'x-ti-secret-code': '***',
'Content-Type': 'application/octet-stream'
}
# 这里不需要latex格式的公式,formula_level设为2
result = requests.post('https://api.textin.com/ai/service/v1/pdf_to_markdown',
data=binary,
headers=headers,
params = {
'paratext_mode': 'none',
'formula_level': 2,
'page_start': from_page + 1,
'page_count': to_page - from_page
}
)
json_data = result.json()
detail = json_data.get('result', {}).get('detail', {})
sections=[]
tables=[]
for item in detail:
page_id = item.get('page_id')
text = item.get('text')
text = re.sub(r'\*\*(.+?)\*\*', r'\1', text) # 去除加粗格式,例如 **text** → text
text = re.sub(r'\*(.+?)\*', r'\1', text) # 去除斜体格式,例如 *text* → text
text = re.sub(r'_(.+?)_', r'\1', text) # 去除下划线斜体格式,例如 _text_ → text
text = re.sub(r'!\[.*?\]\((.*?)\)', '', text) # 删除图片标记,例如  → 空
type = item.get('type')
sub_type = item.get('sub_type')
position = item.get('position')
x0, y0, x1, y1 = position[0]/2.0, position[1]/2.0, position[4]/2.0, position[5]/2.0 # TextIn解析默认ppi 144, DeepDOC默认ppi 72
if type == 'paragraph':
if sub_type not in ['text', 'text_title', 'table_title', 'sidebar']: # 按需保留需要的类型
continue
sections.append((text, f'@@{page_id - from_page}\t{x0}\t{x1}\t{y0}\t{y1}##'))
elif type == 'table':
text = text.replace('<br>', '') # 按需处理文本,这里移除表格单元格内的换行符
text = text.replace('border="1"', '')
tables.append(((None, text), [(page_id-1, x0, x1, y0, y1)]))
callback(0.6, "TextIn parsing")
# 上面是替换的代码
res = tokenize_table(tables, doc, is_english)
callback(0.8, "Finish parsing.")从知识库查看分块结果,可以明显看出解析效果提升,文本和表格识别准确率提高。


如图可以看到,原本的解析将行间距较大的文本、小标题识别为表格,这也影响了后续的分段。TextIn能够准确识别标题、段落,使系统获得完整的结构信息,实现更合理分段。


如上图所示,原本解析未能准确识别表格,而表格是文档中数据密集的所在,往往含有关键信息,准确的表格识别对RAG问答性能有相当大的影响。TextIn解析后的分段实现了准确、完整的语义提取。
RAG系统的优化是一项环环相扣的工程。优质的文档解析结果提供了系统运行的基础,接下来,切片也是影响RAG能力的重要因素。
切片策略目前业界也有很多思考,其实际应用受制于输入的结构化文件、上下文窗口长度等因素。我们在此提出一些可能性,与大家一起探讨:

本文介绍了基于RAGFlow自定义解析工具的实战经验,通过优化文档解析环节,提升RAG系统整体性能。高质量的文档解析对RAG应用性能的影响已经得到验证:它决定了知识被结构化、理解和检索的效率。之后我们将持续关注企业级RAG应用的效能的提升,探索更优的语义理解、结果精炼策略。
如果你在实操过程中有任何问题,或对解析、分块、知识库向量化环节有更多需求,可随时向我们提出,共同探讨进步。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。