RAG 文档入库如何减少脏数据真正困难的通常不是完成一次 API 调用而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何设计 OCR、PDF 文本抽取和摘要分层的 RAG 文档入库流程”给出一套可以直接落到任务状态和数据契约上的实现方式。问题与结果将文件原件、抽取文本、切片、摘要和索引元数据分层失败文档不会混入可检索语料。最终交付不是一段不可追溯的模型回答而是一组带来源、版本、状态和失败记录的数据。这样既方便接入后续系统也能在接口、页面或模型输出变化时定位问题。适用场景扫描件和 PDF 知识库入库合同与报告的可检索归档企业文档问答前的数据治理实现前先确定边界先判断文件类型和可读性再选择 OCR 或 PDF 文本抽取摘要只从已验收文本生成抽取为空、乱码或页数异常时停止索引可验证工作流API 编排与职责步骤接口请求方式用途图片识别通用图片文件流 OCR 到文本POST处理图片、扫描件、截图中的文字PDF 文本抽取通用 PDF 文件流 OCR 到文本POST把 PDF 转成可检索文本PDF 摘要PDF 全文多语言 AI 摘要POST生成文档摘要作为检索元数据最小可运行实现上传 PDF 并抽取文本curl-XPOSThttps://api.gugudata.com/imagerecognition/pdf2text?appkeyYOUR_APPKEY\-Ffile./report.pdf对同一份 PDF 生成摘要curl-XPOSThttps://api.gugudata.com/ai/summarize?appkeyYOUR_APPKEYlangzh-cnstreamingfalse\-Ffile./report.pdfPython 侧可以把转换结果交给入库任务importrequests APPKEYYOUR_APPKEYdefpdf_to_text(path:str)-str:Convert a PDF file to text before indexing.withopen(path,rb)asfile_obj:responserequests.post(https://api.gugudata.com/imagerecognition/pdf2text,params{appkey:APPKEY},files{file:file_obj},timeout120,)response.raise_for_status()payloadresponse.json()returnpayload[Data]入库设计文档入库时建议保存这些字段字段说明document_id自己系统里的文档 IDsource_file原始文件名或业务来源extracted_textOCR 或 PDF 转文本结果summary摘要接口返回的文档摘要chunk_id分段后的文本块 IDextracted_at转换时间便于刷新和审计失败分类与降级图片或 PDF 转换失败时Agent 不应该直接生成答案。它应该把文档标记为“转换失败”保留失败原因并允许人工重新上传或换用更清晰的文件。对于大文件可以先做文件大小和格式检查再调用接口减少无效请求。工程化注意事项OCR 结果要保留原始页码或文件来源方便定位答案出处。分段时不要只按固定字数切分要尽量保留标题、段落和表格上下文。入库前去掉明显页眉、页脚和重复水印减少检索噪声。对敏感文档先做权限控制再开放给问答系统。数据契约与留痕建议至少保存以下字段真实项目可以继续拆分但不要删除来源、版本和状态信息。字段作用document_id稳定业务标识用于关联记录并避免名称冲突file_hash内容哈希用于完整性校验、版本识别和去重extract_method业务数据字段保存时记录来源、口径和缺失状态page_count业务数据字段保存时记录来源、口径和缺失状态text_version规则、输入或产物版本变更时保留旧版本summary派生结果必须关联输入版本与生成时间index_status显式状态或结果禁止用空值代替失败所有派生结果都应带生成时间和输入版本。发生重试时新增尝试记录不要覆盖最后一次失败以免排查时只剩“最终成功”而看不到中间问题。验收清单同一文件重复上传不会产生重复索引每个切片可回溯到页码或原文件抽取失败与摘要失败分开记录能力边界公开 Demo 只能证明响应形状OCR 准确率、文件上限、并发和配额需要按实际账号重新验证。示例中的YOUR_APPKEY仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中不应进入前端、文章、日志或版本库。