很多人在本地把 RAGFlow 当知识库、Dify 当编排层，文本问答跑通了，一遇到带图的 PDF、扫描件、产品图就卡住：要么图片根本没进检索，要么传过去只拿到一段 OCR 文字，图里的表格和版式全丢了。这篇不讲协议原理，只给工程落地的接线顺序、传递方式选择和联调排查清单。
本地把 RAGFlow 当知识库、Dify 当编排层，是最常见的接法。文本问答跑通之后，真正卡人的往往是带图的 PDF、扫描件、产品截图这一类内容：要么图片压根没进检索，模型完全不知道有这张图；要么只拿到一段 OCR 文字，图里的表格结构和版式信息全丢，答案对不上。
下面不聊协议和框架原理，只讲工程上怎么接线、怎么选传递方式、怎么联调排查。三步走：先定图片走哪条链路，再定怎么从 RAGFlow 传到 Dify，最后把解析质量、检查清单和评测用例补齐。
先定图片走哪条路：三条常见链路
接线之前先做一次决策，因为三条链路的工程量和最终效果差别很大，中途换链路的代价比一开始想清楚要高。判断依据其实只有两条：你下游用的模型是不是视觉模型，以及最终答案里需不需要把原图引用给用户看。
| 链路 | 谁负责图片 | 适合场景 | 主要代价 |
|---|---|---|---|
| A 文本化 | RAGFlow 解析成文字后入库，Dify 只拿文本 | 图片只是辅助信息，答案不需要看图 | 图里的版式和视觉信息丢失 |
| B 图块透传 | RAGFlow 返回图块加文字块，Dify 转成 URL 或内联数据 | 产品图、截图、图表类问答 | 需要图片存储和可访问路径 |
| C Dify 主导 | Dify 自己挂多模态模型，RAGFlow 只给图块位置 | 图片是主输入，检索只做辅助 | Dify 侧工作流复杂度上升 |
- 链路 A 最省事，OCR 或版面识别之后进库，Dify 侧一个字都不用改；代价是图里只有文字被留下来，颜色、位置、表格结构都拿不到
- 链路 B 是多数团队最后会选的那条，检索同时返回图块和文字块，Dify 侧把图块变成可引用地址再交给视觉模型
- 链路 C 适合图片本身就是用户输入的场景，RAGFlow 退化成召回元数据，图片本体全部在 Dify 处理
- 只要「下游是视觉模型」或者「答案要引用原图」有一项成立，就别只走链路 A
- 三条链路可以先按场景混用，不必全站统一，按文档类型分流反而更省资源
图片怎么从 RAGFlow 传到 Dify：体积、格式、引用方式
这一步的坑基本都在「怎么传」和「传多大」上。图片以什么形态从检索结果出来，决定了后面所有节点的写法，所以第一件事是把 RAGFlow 返回的图片字段形态确认清楚：是远程地址、本地路径，还是内联在结果里的数据。
- 确认字段形态拿一份带图文档单独查一次，看返回结果里图片是以地址、路径还是内联数据出现；这一步没确认，后面节点全是猜的
- 优先用可访问地址内联数据会让单次请求体膨胀好几倍，容易撞上下文上限和网关的体积限制；内网环境要保证 Dify 容器有网络路径能访问到图片存储
- 拆成两个变量Dify 工作流里把文本上下文和图片上下文分开两个变量，不要把图片塞进文本变量里拼字符串，模型侧会因为格式不合法直接报错
- 加白名单和上限只放行允许的扩展名，并给单张体积设上限；一次召回几十张图会让节点直接拖死，这个限制要写死在代码里而不是靠自觉
- 空值要能过召回结果没有图片块时，图片变量要允许为空并走文本分支，不然纯文本文档一进来就整条链路失败
下游模型对图片格式的支持口径，可以到 官方 API 与模型资料库（/official-api） 的图片视频模型对照页核对，别照着印象传格式。
解析质量不做对，后面全白干
图片进库那一步如果解析得不对，后面链路选得再好也救不回来。最常见的翻车点是扫描件的倾斜和双栏排版、图里嵌表格，以及图块本身几乎没有可用文字却硬套文本嵌入。做法上，OCR 之前先做一轮文档清洗，倾斜校正、双栏切分、表格识别三件事各自独立验证。
| 图片类型 | 推荐处理 | 不适用的情况 |
|---|---|---|
| 表格截图 | 走图块加视觉模型，不要只靠 OCR 读文字顺序 | 下游没有视觉模型时，只能退回 OCR 并接受顺序错乱 |
| 流程图 / 架构图 | 图块透传，让模型看图说话 | 图里文字极少且模型没有视觉能力，检索基本召回不到 |
| 产品图 / 截图 | 图块加文字说明一起入库 | 答案只关心文字描述、不需要看图时不必要 |
| 含图扫描件 | 先清洗再 OCR，复杂页单独走图块 | 扫描质量极差时，任何链路都补不回来 |
- 入库前抽十几张典型图人工看一眼解析结果，这半小时比后面查一周「模型答得不对」划算得多
- 嵌入和重排模型要和图块的实际内容匹配，图块没有可用文字却只用文本嵌入，召回会明显偏；模型口径看 嵌入模型对照（/embeddings）
- 表格类图片优先走图块路径，纯 OCR 的文字顺序会把行列关系打乱，问答时答案容易对不上号
- 文档清洗的具体做法可以参考 AI 笔记与知识库工具目录（/ai-nav/category/ai-note） 里同类工具的处理思路，别自己从零摸索
联调与上线前的检查清单
联调不要一上来就端到端跑，容易在一堆变量里迷路。正确顺序是分段验证：先在 RAGFlow 单独查带图文档，确认返回里有没有图片块；再单独调 Dify 工作流，确认节点能收到图片变量；两个都单独通过之后再串起来。
- 超时要分档配：图片上传、OCR 解析、视觉模型推理三段耗时差很多，一个全局超时会把慢但正常的请求误杀；基线可以先到 测速页（/tools/speed-test） 量一遍再定
- 并发要压住：批量图片入库时限制并发数，OCR 和嵌入服务很容易被自己打满，运行状态可以到 状态页（/ai-status） 观察
- 日志至少记四个字段：文档 ID、是否命中图片块、走的是哪条链路、下游模型有没有报错；少一个字段，一次「图答不出来」就没法复盘
- 降级规则写死：视觉模型不可用时退回纯文字答案，并明确告诉用户这次没看图，不要静默返回一个看起来正常但没用到图的答案
- 上线前把空图片、超大图片、格式不支持三种异常各造一次，确认链路是优雅降级而不是整条崩掉
链路 B 落地时特别容易忽略的一点：图片存储的访问权限。内网对象存储如果没给 Dify 容器开对应策略，检索返回的地址在 Dify 侧是打不开的，表现就是「检索明明命中了图片块，模型却说看不到图」。
怎么判断这套图片方案真的有用
没有一套自己的图片用例集，改链路和换模型全靠感觉，很容易改好一个场景、弄坏三个场景。建议建一小套覆盖性用例：表格截图、流程图、产品图、含图扫描件各来几例，每次动链路或换模型都跑一遍。
| 看哪一层 | 观察什么 | 出问题时先改哪里 |
|---|---|---|
| 召回层 | 目标图块有没有被取到 | 解析、清洗、嵌入和重排配置 |
| 生成层 | 答案有没有用上图里的信息 | 下游模型是否支持视觉、变量有没有传对 |
| 回归层 | 原来的文本问答有没有被改坏 | 工作流分支条件和变量命名 |
公开榜单衡量的是模型通用能力，和你这套链路的效果是两回事，混在一起看会得出错误结论；参考口径可以到 评测与榜单页（/benchmarks） 核对，但结论一定要用自己的用例集说话。只改图片处理链路时，把文本用例一起跑一遍，确认没有把原来好用的文本路径改坏。
下一步把「链路选择、传递方式、解析质量、检查清单、评测用例」当成一条流水线，先在这五处各留一个可验证的检查点，再动手接线上线。→常见问题
RAGFlow 里的图片能不能直接传给 Dify 的工作流？
能，但要看检索结果里图片以什么形式返回。如果是可访问 URL，直接当变量传最省事；如果是本地路径，Dify 容器得能访问到那块存储；如果是内联数据，注意请求体会被撑大。传之前先在 RAGFlow 单独查一次，确认字段形态再动手写节点。
Dify 用了不支持视觉的模型，图片还有必要进知识库吗？
有必要，但目的变了。这时图片的价值在于 OCR 出来的文字，图本身只是文字的载体。所以重点放在解析质量上，把表格、版式还原成顺序正确的文本；如果图里信息用纯文字表达不完整，那就该换一个支持视觉的模型，而不是硬凑。
为什么文本问答好好的，一加图片就变慢甚至超时？
图片链路多了解析和视觉推理两段耗时，而且单次请求体积会明显变大。常见做法是给三段分别配超时，限制单次召回图片数量，批量入库时压住并发。先用量出的延迟基线做参照，再决定卡在哪一段。
