RAGFlow 如何实现图片回答？KnowFlow 的实战方案来了（附源码，该方案已升级，最新可看专栏）

最新推荐文章于 2025-05-09 10:02:01 发布

企业知识库布道者

最新推荐文章于 2025-05-09 10:02:01 发布

阅读量888

点赞数 9

分类专栏： RAG 企业知识库文章标签：企业知识库 Dify RAGFlow FastGPT RAG

本文链接：https://blog.csdn.net/cangermeng/article/details/147502709

版权

RAG 企业知识库专栏收录该内容

7 篇文章

订阅专栏

之前博文中有提到，KnowFlow（基于 RAGFlow 二次开发的商业化产品）计划要开发以下三个核心功能：

重构 RAGFlow 前端页面以及交互
进一步增强 RAGFlow 文档解析能力
完善 RAGFlow 结构化输出能力，支持图片、表格、图标等输出形式

今天我们带来的是上述 RAGFlow 支持图片回答，我们先来看下效果图：

原理分析

我们回到解决问题的原点来看，当 RAG 系统生成回答时，如果回答文本中包含指向静态目录的图片 Markdown 链接（比如 ![](images/exmaple.jpg)），此时通过脚本自动渲染为 HTML 图片元素，当浏览器通过 Http 请求获取时将会显示图片。

总结几个关键点：

获取文档中的图片：从文件中通过 OCR 获取到图片并追加到文件内容
本地文件系统到 HTTP 的转化：将回答内容中的本地文件路径转化为 HTTP URL
Markdown 渲染：前端组件能够解析和渲染 Markdown 图片引用
浏览器请求机制：浏览器通过 HTTP URL 请求获取到图片

RAGFlow 现状分析以及解决方案

如何提取图片：同时如何获取一个文件内的所有图片，RAGFlow 的 DeepDoc 模块虽然已经具备了布局分析、图片提取的能力，如果直接在源码内修改，会直接导致后续维护成本巨大。KnowFlow 产品设计初衷是能够持续兼容 RAGFlow 版本更新。

我们最终选择通过专业的 OCR 引擎来解决问题，我们在 KnowFlow 内置了 MinerU 和 PyMuPDF 两种引擎。其中 MinerU 实测效果更好，当然也更加消耗资源，如果有 GPU 硬件配置，速度可以明显提升；PyMuPDF 是轻量级选择，实测简单文本可以正常识别出图片，复杂的识别不出来。当然在架构设计层面，我们后续可扩展其他优秀的 OCR 引擎。

如何访问图片：RAGFlow 包括 Dify 这样的框架设计在容器化 Docker 环境运行，出于安全考虑限制了对宿主主机文件系统直接访问。容器与主机文件系统是隔离的，这个特性导致如何访问这些静态图片成为一个需要考虑的问题。

阿里云 OSS 存储：我们考虑了阿里云 OSS 存储方案，但由于将图片暴露到公网，对于 KnowFlow 来说这是不可接受的，数据隐私是第一要考虑的。
Base64 嵌入：Base64 会带来明显的性能问题，不仅会增加数据体积，还会导致 tokens 急剧上升。
开发插件和工作流：RAGFlow Agent 不支持自定义 Python 组件，Dify 支持。但为了支持该功能，接入 Dify 框架太重了，同时考虑到 Dify 商用的限制，该方案不可行。
图片服务器容器化：这也是目前采用的方案。创建独立的 Http 服务器，用于提供图片，同时容器化，保持和 RAGFlow 在同一网络运行。该方案可扩展，不需要改 RAGFlow 本身。