RuoYi集成RAGFlow：私有化知识库实战指南

先说明白，这个需求我以前在实际项目里跑通过，不是停留在“能跑通”就行。RuoYi这颗树，很多人觉得它老，但它在国内企业内网里的真实装机量，绝对是排得上号的。RAGFlow这边，文件解析能力在一众开源知识库引擎里又是公认的能打。把这两个东西接到一起，做私有化知识库，本质上就是用最“接地气”的权限框架，去驱动一套最“硬核”的解析引擎。这篇文章我直接按照真实踩坑的顺序写，尽量把那些文档里没写清楚的细节都掏出来。

1. 集成思路与整体架构设计

1.1 为什么是RuoYi接RAGFlow，而不是换个系统或者直接改造RAGFlow

先说结论：如果你在企业内网待过，你会发现绝大多数所谓“知识库系统”其实缺的不是AI能力，而是用户体系、权限控制、审计日志、审批流这些严肃的管理功能。RuoYi这套框架最成熟的就是这些，而且它自带代码生成器，你后续想把知识库跟工单系统、OA审批打通，改起来成本极低。如果用现成的AI平台产品，你面临的问题是：用户数据拿不出来、权限模型对不上组织架构、日志审计不合规。RuoYi做底座，RAGFlow做大脑，各干各擅长的事，这是架构上最稳的一种组合。

有人会问，RAGFlow本身不是也带账号体系和知识库权限吗？确实带，但它的权限粒度基本停留在“团队/知识库”级别，做不到RuoYi那种“按钮级”到“数据行级”的控制。企业知识库最怕的是什么？是销售部的人搜到了财务部的预算文件，还是实习生看到了薪资说明。你可以用RAGFlow的团队隔离做一层粗粒度控制，但上层的用户来源、角色判断、行为审计，还是得靠RuoYi这套成熟RBAC体系兜底。说白了，RuoYi负责“谁可以看”，RAGFlow负责“把答案找出来”。

1.2 两个系统怎么“接”起来：调用链路设计

我实际采用的是RuoYi后端主动调用RAGFlow REST API的方式，没有采用前端直连。原因很直接：前端直连会把RAGFlow的API Key暴露在浏览器里，这在企业内网也是个安全隐患，任何能打开浏览器开发者工具的人都能把你的知识库核心配置抄走。

调用链路是这么设计的：用户在RuoYi页面发起提问，请求打到RuoYi的后端Controller，Controller去Redis里拿用户的登录信息和部门ID，组装上下文，再用后端HttpClient调用RAGFlow的API，拿到流式回答之后，再通过SSE或者WebSocket推给前端页面。RAGFlow所有API操作都发生在服务端，前端感知不到它的存在。

这个链路有个关键细节：账号对应关系。RuoYi用户的ID，要透传给RAGFlow的聊天会话，这样RAGFlow返回的引用来源，将来才能关联回RuoYi的用户行为表。我第一次没做透传，结果所有问答记录都变成“匿名用户”提问，后期想要做操作审计根本查不到人，等于白做。

1.3 部署位置与内网穿透问题

私有化部署，网络环境通常分两种：纯隔离内网、可以访问部分外网的白名单环境。RAGFlow的部署依赖容器拉取镜像，如果服务器完全离线，会非常痛苦。我建议在能联网的机器上先把镜像打包导出，再传到内网Docker里加载。切不可盲目在纯内网环境下一上来就docker compose up，镜像拉不动直接卡死。

组件部署如下：

这里要特别提醒关于Elasticsearch和Infinity的选择。RAGFlow默认的Docker Compose里带有ES和Infinity两套向量存储可选，初版的时候ES的问题比较多，后来版本对Infinity的支持度好了很多。如果你的机器内存只有8G，强烈建议用Infinity，ES太吃内存了，16G内存以下跑ES加解析任务很容易OOM。

2. 环境准备与基础服务部署

2.1 前置条件：服务器和Docker环境

部署RuoYi还好，一个JDK8或者JDK17、一个MySQL、一个Redis就够。RAGFlow就完全不是这个量级了。它的Docker镜像包含了API服务、任务调度、文档解析引擎、向量检索服务等多个容器，磁盘建议至少留出50G，内存建议不低于16G。我最早在一台4G内存的办公电脑上试过，容器倒是能起来，但是解析一个300页PDF就直接把机器卡到无响应。

Docker安装就不多讲了，Linux环境下建议直接装Docker Engine 20.10以上版本。这里必须说一个Docker Compose的关键点：RAGFlow官方文档要求把代码clone到本地再跑docker compose，因为它需要读取项目里的docker/.env文件中的配置，而且这个.env文件里有SVR_HTTP_PORT、STORAGE_PATH等大量自定义参数，你直接复制命令跑镜像，往往拿不到正确配置。

在我实际操作中，一个特别容易被忽略的点是STORAGE_PATH。这个路径是RAGFlow用来存放解析后文件、分块、向量缓存的地方。如果你不提前在宿主机创建好这个目录，并设置好权限，容器启动后会创建一个root用户的目录，后续你以非root用户进入容器排查问题时，会发现文件读不到。这问题看着小，能折腾半天。务必提前mkdir -p /data/ragflow并授权当前用户。

2.2 RAGFlow Docker部署流程

我给一套我实测过的步骤，基于最新稳定版本。

首先clone代码并进入目录，修改.env文件里的关键参数。我自己常用的几种改动如下：

git clone https://github.com/infiniflow/ragflow.git cd ragflow/docker cp .env .env.bak vim .env

需要改的核心配置：

• SVR_HTTP_PORT=9380，保持默认可以，但是如果你机器上已有别的程序占用，必须改掉。
• STORAGE_PATH=/data/ragflow_storage，改成你自己的目录。
• LISTEN=0.0.0.0，确保局域网内其他机器能访问服务端口。
• RAGFLOW_IMAGE=infiniflow/ragflow:v0.15.x，明确指定版本号，不建议用latest，因为RAGFlow迭代频繁，不同版本API有差异，代码对接时容易踩版本坑。

改完之后执行：

docker compose -f docker-compose.yml up -d

这里有一个大家非常关心的问题：Windows 11上怎么跑RAGFlow。用Docker Desktop跑是可以的，但有两个点必须提醒。第一，Docker Desktop的资源设置里，内存不要低于8G，CPU不要低于4核，否则解析服务会频繁崩溃。第二，文件挂载路径不要用中文和带空格的目录，RAGFlow解析引擎对路径中的中文支持不好，你会看到各种莫名其妙的"文件不存在"错误，其实只是路径识别问题。

启动之后，健康检查可以这样看：

docker logs -f ragflow-server docker ps

看到日志中有Your ID is: ...或者API服务正常监听端口的输出，基本就代表服务起来了。然后浏览器访问http://服务器IP:9380，用默认账号admin密码infini_rag_flow登录，第一次登录系统会强制让你改密码。

2.3 大模型选择：到底用什么模型做问答

RAGFlow本身不自带大模型，它只是一个编排引擎。你要么接入云端模型API，要么接入本地推理的模型。这也是标题里那个热搜词“LLaMA适合国内企业拿来搞知识库问答和私有化Agent部署吗”背后的普遍疑问。

我的答案是：完全不适合直接裸用，但可以作为底座。所谓“裸用”，就是你只部署一个LLaMA原始模型，不考虑中文能力、指令遵循能力，那么出来的问答效果会很如同“梦游”——回答生硬、格式混乱、引用原文时丢失关键信息。给国内企业的建议是直接部署基于LLaMA微调过的中文对话模型，比如Qwen系列（百川也有），或者智谱的ChatGLM。部署工具就用Ollama就行，像我自己测试时用的是：

ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct

模型的选择直接影响RuoYi侧接收到的回答质量。如果你想做严肃的企业知识问答，7B以下模型确实勉强；但如果你的知识库场景只是制度问答、操作手册查答案，7B的qwen已经够用了，而且推理速度尚可。14B模型需要至少16G显存，一般内网服务器未必有GPU，用CPU跑14B又会慢到让人怀疑人生。所以我的经验是：先7B跑通整个链路，后续再按需升级。

2.4 创建API Key与数据集连接

RAGFlow里有两个核心概念必须提前搞清楚：数据集（Dataset）和聊天助理（Chat Assistant）。数据集管文件入库和解析，聊天助理管对话设定和检索问答。二者是分开的。

你需要先在页面上创建一个数据集，给它取个名字，比如“制度问答库”，设置好解析方法。然后再创建一个聊天助理，把它绑定到这个数据集上。一切就绪后，在RuoYi代码里调用API时，需要用到两个ID：dataset_id（用于上传文件）和chat_id（用于发起问答），这两个ID都可以在RAGFlow的API文档接口里查到。

API Key的获取路径：点击页面右上角的头像（或登录后个人中心），找到“API”相关菜单，点击“Create API Key”，生成一串以ragflow-开头的密钥。这个密钥，说三遍，只在后端保存，只在后端保存，只在后端保存。前端任何位置都不允许出现它。

3. 核心代码实现：RuoYi侧怎么对接RAGFlow

3.1 RuoYi登录用户信息怎么传给知识库

热搜词里有一条“ruoyi在哪里写入登录用户的信息”，我顺势讲一下。RuoYi的用户登录信息保存在LoginUser对象里，登录成功之后由SecurityUtils.setLoginUser(loginUser)写入到SecurityContext和Redis。所有后续请求的token都是从请求头里解析的，这个流程你最熟悉的位置应该是TokenService.getLoginUser()方法。

在集成知识库的场景下，我建议在RuoYi的表里新增一个字段，用于保存“知识库账号绑定关系”。即某个RuoYi用户对应某一个RAGFlow账号，或者对应某个聊天助理的会话ID。实际操作如下：

if (user.getRagflowChatId() == null) { // 首次提问时自动初始化一个会话 String chatId = ragFlowService.createConversation(user.getUserId().toString()); user.setRagflowChatId(chatId); userService.updateUser(user); }

这样做的目的是，让RuoYi侧能够追踪每个用户的提问上下文。RAGFlow支持多轮对话，如果你不保存conversation_id，每次提问都是全新会话，那“基于上下文追问”的功能就废掉了。很多集成项目忽略这一层，结果用户问“那第二个方案呢”的时候，AI完全不知道在说哪个方案。

3.2 调用RAGFlow API的Java封装

RAGFlow提供标准的REST API，调用方式不复杂，核心就是把请求体凑对。下面是我封装的一个简化例子，基于Java的HttpURLConnection，没有引入额外依赖：

public class RagFlowClient { private static final String BASE_URL = "http://127.0.0.1:9380/api/v1"; private static final String API_KEY = "ragflow-xxxxx"; private HttpURLConnection createConnection(String path, String method) throws IOException { URL url = new URL(BASE_URL + path); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod(method); conn.setRequestProperty("Authorization", "Bearer " + API_KEY); conn.setRequestProperty("Content-Type", "application/json"); conn.setConnectTimeout(5000); conn.setReadTimeout(30000); return conn; } public String chat(String chatId, String question, String userToken) throws IOException { HttpURLConnection conn = createConnection("/chats/" + chatId + "/completions", "POST"); conn.setDoOutput(true); Map<String, Object> requestBody = new HashMap<>(); requestBody.put("question", question); requestBody.put("user", userToken); // 可选：限制回答只召回本知识库, 不启动Agent联网搜索 requestBody.put("stream", false); try (OutputStream os = conn.getOutputStream()) { os.write(new ObjectMapper().writeValueAsBytes(requestBody)); } if (conn.getResponseCode() != 200) { throw new RuntimeException("RAGFlow API error: " + conn.getResponseCode()); } // 解析JSON，提取answer字段 return extractAnswer(conn.getInputStream()); } }

这里需要注意，如果你把stream设成true，RuoYi后端需要处理SSE流式数据，这个后面单独讲。如果是做同步响应，stream=false就够了，代码简单很多。

3.3 文件上传解析集成：RuoYi作为统一入口

知识库总不能每次都在RAGFlow后台手动上传文件吧。企业内部，应该由各部门管理员在RuoYi的界面上传Word、PDF、PPT，然后RuoYi后端把文件转发给RAGFlow解析入库。这一步也是集成中最容易踩坑的地方。

我封装过的上传流程分三个步骤：先create_dataset（创建数据集），再上传文件，最后启动解析任务。注意，RAGFlow一次API调用只能上传一个文件到数据集，批量处理需要循环调用，同时注意接口限流。实际代码中，每个文件都需要携带Content-Disposition头信息，否则上传后文件没名字，后续解析就全乱了。

上传文件的curl样子是这样：

curl -X POST http://127.0.0.1:9380/api/v1/datasets/{dataset_id}/documents \ -H "Authorization: Bearer ragflow-xxxxx" \ -F "file=@/path/to/制度手册.pdf"

收到成功响应后，拿到返回的document_id。然后调用：

curl -X POST http://127.0.0.1:9380/api/v1/datasets/{dataset_id}/chunks \ -H "Authorization: Bearer ragflow-xxxxx" \ -H "Content-Type: application/json" \ -d '{"document_ids": ["doc_id_xxx"], "method": "naive"}'

文中的method字段决定解析方法，我用过的几种里，naive是最基础的按长度切分，适合通用文档；qa是RAGFlow的智能问答切分，适合说明书；paper适合论文文献。选错了解析方式，最直观的影响就是检索准确率下降，回答内容张冠李戴。

3.4 去掉验证码与内网知识库场景的登录改造

热词里有“ruoyi vue 去掉验证码”，这个需求在知识库集成场景下很常见。企业内网知识库，用户多半是AD域账号登录，再配合RuoYi的验证码体系反而繁琐。我处理的方式是把RuoYi的captchaEnabled开关直接关闭：

在application.yml中找到：

captcha: enabled: false

或者在后端启动时，修改SysConfigServiceImpl中sys.account.captchaEnabled的初始化值。注意，如果你们前端是用Vue3那套，验证码组件在login.vue中，本地开发默认是captchaEnabled=true，需要同步修改。实际生产环境，我见过更多团队是保留验证码，但把验证码种类从“字符+数字”换成“滑块验证”，这个就看你们的安全策略了。

集成里另一项常见的登录改造是单点登录集成。如果企业有统一认证中心，可以让RuoYi对接CAS或OAuth2，这样知识库的用户身份、部门信息能自动同步，减少管理员手动维护账号的成本。这个因为内容太长，这里点到为止，但架构上一定要在设计初期留出接口，不然后面想接入SSO的时候，会发现所有登录逻辑耦合得乱七八糟。

3.5 流式返回：把RuoYi接口改造成“打字机”效果

同步返回有个问题：知识库文件多的时候，检索+生成可能要等10-20秒，用户看着页面一直转圈，第一体验就很差。所以生产级集成，一定要考虑流式返回。RuoYi后端可以用SseEmitter，结合RAGFlow的stream=true来实现。

流程是：RuoYi后端发起RAGFlow API请求时，stream置为true；RAGFlow会返回一段data:前缀的SSE格式内容，Java后端每读到一行就往SseEmitter里write一行；前端EventSource或者fetch流式读取，逐字渲染。

SSE不是WebSocket，它是单向的，这个场景够用。但如果你希望用户在下一次提问时能边生成边看到引用来源的角标，那么这个SSE数据流里必须同时传递两个字段：content和reference。我第一次做的时候只传了文本内容，导致前端参考资料那栏永远空白，多花了一天排查。要看RAGFlow返回的原始报文，不要去猜字段名，直接curl一把RAGFlow API看原始JSON结构，这是最稳的调试方法。

4. 文件解析与知识库构建的实战要点

4.1 文件解析机制深度解读

RAGFlow和普通RAG方案最大的区别就在解析层。它不只是简单地把PDF文本抽取出来，而是在解析时做了版面分析、表格结构识别、OCR文字识别、文档方向检测等一系列复杂操作。这意味着它在解析扫描版PDF、图片型资料时，效果远超很多用文本提取工具的方案。

实操层面前提理解是：RAGFlow解析入库后，文档会被切成多个chunk，每个chunk是一个检索单元。切分参数的设置直接决定检索质量。太粗，一个chunk有几千字，检索召回时精度低；太细，一句话一个chunk，上下文丢失严重，回答时缺乏前后文联系。RAGFlow默认的page切分效果在中英文场景下都不算差，但如果你处理的文档里有大量表格，我强烈建议单独选择“表格结构”解析模式，能极大提升结构化数据的召回率。

我刚才提到的解析方法选择，补充一下细节。qa模式：系统会尝试从原文里提取出问题-答案对，非常适合FAQ型知识库。但它的缺点是耗时比naive长很多，而且对文本质量有要求，如果原文是半结构化描述，QA提取可能会产出一些语义不完整的内容。paper模式：适合论文这种包含摘要、章节、参考文献的标准格式，切分逻辑更照顾学术阅读习惯。再有就是manual模式，适合操作手册、说明书。正确做法不是固定选一种解析方法，而是按文件类型分配不同的数据集，比如“制度库”用qa，“操作手册库”用manual。

4.2 批量处理文件的完整套路

热搜词里“ragflow 教程 批量处理文件”对应的情况，我实际处理过。最笨的方法是登录后台，在网页上一个一个拖文件上去。但是如果你有几百个文件，这么干会疯掉。真要批量，可以自己写脚本调用API循环上传。

我建议的批量处理思路分三步：

第一，批量上传。文件全部放在一个目录里，Java或Python脚本遍历目录，逐个调用RAGFlow的upload接口，成功后记录document_id。第二，统一启动解析。上传完成后，分批调用chunks解析接口，比如每批50个文件，发送一次解析任务。不要一个文件一个文件地启动任务，任务太碎会拖垮调度器。第三，等待与状态监控。RAGFlow的解析是异步的，你得周期性地查询每个document的run字段，判断是否解析完成。如果run=UNSTART，说明任务还没被调度；如果run=RUNNING，正在跑；DONE才算完成。

有一个关于批量上传的场景要注意：RAGFlow对同时上传的文件数量有限制，如果一次性发几百个文件，服务端会报429限流错误。解决办法就是在上传循环中加入Thread.sleep(200)，人为降低上传速率，稳妥太多。

4.3 解析失败的两种常见姿势

解析不是每次都成功的。图片型PDF如果没有配OCR模型，结果就是一个空的chunk列表。这是最常见的一种失败。RAGFlow可以在系统设置里配DeepDoc OCR引擎，也可以外接Tesseract。用Tesseract时必须注意，默认英文模型根本认不全中文，你要安装tesseract-ocr-chi-sim语言包。

第二种常见失败是文件格式不兼容。老的Office 2003格式（.doc，.ppt）和WPS生成的某些文档，RAGFlow的解析引擎兼容性不够，解析出来都是乱码。我的统一处理策略是：在RuoYi上传入口做一个格式转换，把doc、ppt统一用LibreOffice转换层PDF，然后再推给RAGFlow。转换这一步有一个副作用——文件里原有的书签、批注都丢了，但为了能解析，这是值得的代价。你问我怎么发现的？我一开始没转，用一批ppt直接推上去，结果解析出来的文本大量形如“?????”，问了好几个人才知道是格式兼容问题。

4.4 多部门知识库隔离的权限设计

私有化知识库，部门隔离是刚需。你要做到的是：财务部的文件不能被技术部的人搜到。有两个位置可以做这个隔离：

第一个位置，RAGFlow侧的文件权限。RAGFlow每个数据集可以设置访问权限。推荐做法是为每个部门建一个独立数据集，让管理员在RuoYi后台按部门上传文件。部门和数据集的映射关系放在RuoYi的数据字典中，后续查询时动态匹配。注意，如果你不为每个部门建独立数据集，而是所有文件混在一个大知识库里，那么权限控制无从做起，这是架构上的失误。

第二个位置，RuoYi侧的业务权限。RuoYi自带部门数据权限，你可以在查询知识库的Controller上加@DataScope注解，这样用户提问后，后端会根据用户部门自动过滤能访问的数据集ID，只把允许的数据集传给RAGFlow。具体说，RAGFlow的聊天助理支持在提问时通过参数指定检索范围（你说的kb_ids），这样既能实现“一套服务，多部门隔离”，又不需要拆成多套系统。

有人实际中会遇到一个问题：RuoYi的部门是树形结构，子公司要不要看母公司文档？这种血缘关系在权限设计里必须提前定好，我是用dept_id为0代表全公司公共库，普通部门只能看到本部门+公共库的内容，再往下细粒度控制就看你们自己业务了。

5. 常见问题排查与性能优化实录

5.1 排错速查表：按症状定位问题

实践下来，总结成一张速查表，非常实用。

这里再单独说一个很隐蔽的问题：RuoYi和RAGFlow时区不一致。比如RuoYi服务器是东八区，RAGFlow容器默认是UTC，你做时间日志对比时就会差8个小时，排查问题时老觉得系统有问题。对自己的SDN做日志分析，或者做审计追溯，一定要在RuoYi传入请求时间和RAGFlow返回时间时，统一转成比ISO带时区的格式。

5.2 性能优化：并发、缓存、队列化

RuoYi作为Java后端，天然支持多线程。但知识库问答是大IO操作，如果你不对接口做限流，几个用户同时提问，RuoYi的线程池很快会满。处理方案我实践过比较有效的是双轨制：

第一，为高频问题做Redis缓存。知识库里的制度问答，90%的问题其实都是重复的。我在RuoYi里封装了一个简单逻辑：先对用户问题用MD5生成摘要，查Redis是否已有同样的提问且答案是“已验证”状态的，有就直接返回，没有才转给RAGFlow。这个缓存策略能把AI引擎的负载降低一半以上。注意，缓存键里必须带上用户所在部门隔离信息，否则跨部门会泄露数据。

第二，限制并发。RuoYi的请求进来后，用信号量（Semaphore）控制同一时刻最多N个请求去访问RAGFlow。我的经验值是先给5，后续根据服务器能力和用户量慢慢调。信号量并不是线程数上限，它是信号量等于N，排队机制由AQS维护。这比单纯调Tomcat线程池要精准得多，因为Tomcat线程很多，但真正能访问RAGFlow的，你只放过去几个，其它都在等，不会打爆推理服务。

如果是纯CPU推理场景（Ollama跑本地模型），你要明白它的瓶颈是显存或内存，而不是网络。大批量用户同时问答时，Ollama一次只能跑一个请求，并发高会排队，用户感受就是“卡”。可以做的优化是：把模型改成continuous batching模式（复杂推理框架才支持），或在硬件允许的情况下多开几个副本，再加一层Nginx负载均衡。就小企业内网场景，我的最简单建议是：把问答接口的排队时间做友好提示，比如前端就显示“已加入推理队列，约等待X秒”，用户认知立刻就不一样了。

5.3 一些很难在文档里查到的小技巧

这里分享几个我踩过坑之后觉得特别值得说的点。

第一个，不要把RuoYi的数据库和RAGFlow的数据库放在同一个MySQL实例里。RAGFlow自己用的是MySQL和ES/Infinity的组合，它会有大量索引更新操作，而RuoYi的事务比较频繁，两边挤在一个实例里，彼此都会受影响。物理隔离，或者至少放在不同实例，运维省心很多。

第二个，RAGFlow容器如果跑了大半天，第一次用得重启一下。这说起来有点土，但真实。它的任务调度器和内存回收在某些版本里表现得不够好，长时间高负载后，chunk解析会莫名阻塞，重启能解决90%的问题。后来我加了定时任务，每天凌晨3点自动重启所有RAGFlow相关容器，之后再也没遇到过解析卡死的情况。

第三个，文档更新了，老版本内容还在被检索到。你说我把文件删了重传，为什么回答还在引用旧内容？因为RAGFlow的向量库中旧chunk可能没有清理干净。正确姿势是走API先删除document，再上传新文档。如果你只是通过界面“更新”文件，某些版本会有缓存残留。这个不是百分百复现，但是出现检索到旧内容时，第一反应就该想到这个。

第四个，给RuoYi的提问接口配一个全局超时。知识库到底有多快，取决于模型推理速度。但HTTP请求超时不能无限长。我在RuoYi配置的RAGFlow调用超时是120秒，超过就给前端返回“系统繁忙请稍后再试”。设置了超时，你的系统才不会被慢模型拖死。很多人觉得超时会丢失回答，其实内网用户是能接受重新提问的，他们更讨厌一直转圈。

5.4 我实测下来的一些性能参考

我在一台16核32G内存、无GPU的机器上做过一个基准测试，模型是Qwen 7B通过Ollama跑CPU推理，知识库文件总量大约是1200多页PDF加若干Word。

单个问题回答时间大约在8到20秒之间波动。这个波动主要来自召回的文件数量，以及文档是否命中PDF中的图片型内容。如果命中图片内容要OCR，耗时会翻倍。所以我的经验是：你要想快，就不能等解析时去OCR，应该在入库前就把扫描件V做一个批量OCR预处理，把识别出来的文本存成一个文本版本的文件，再喂给RAGFlow。这样推理时就不会触发实时OCR了。

并发方面，信号量限到5的时候，5个并发用户同时提问，平均响应时间大概会会上升到30秒左右。我觉得这个体验已经极限了。如果你们未来用户量更大，直接上GPU卡，把7B模型换成14B，或者直接上一台带A10的推理卡。内网知识库模型推理是绝对的性能瓶颈，不要指望架构优化能解决硬件不够的问题。

6. 后续还能怎么扩展

这个集成不只是做个问答机器人就完事了。基于RAGFlow的Agent能力和RuoYi的系统管理能力，你还可以做几个很有价值的方向。

一个方向是把工单系统接进来。用户在RuoYi里查知识库，如果AI回答不了，直接把提问转成一条工单，自动给对应部门主管发审批通知。这个在RuoYi的生态里实现起来非常顺畅，因为它本身就有流程引擎。

另一个方向是做数据报表。RuoYi后台可以增加一个“知识库运营报表”页面，展示每天问答数、热门问题、无命中问题等数据。数据来自RAGFlow的会话记录接口。这些数据对管理层来说是刚需，它能直观告诉你哪个部门的文件覆盖度不够，哪个业务领域的知识沉淀不足。

再一个方向是多模态。当前RAGFlow版本对图片、音视频的解析能力在增强。如果你有一堆产品培训录屏视频，其实可以考虑让知识库直接支持“看了视频片段再回答”的方式，不过现阶段对部署资源要求会高很多，你们可以按节奏来，先跑通文本，再上多媒体。

7. 个人踩坑复盘与体会

最后讲点实在的感受。整套集成，技术难度并不高，真正难的是先把两个系统的边界画清楚。RuoYi那边别去动RAGFlow的源码和解析算法，RAGFlow那边也别去管RuoYi的权限和用户体系。两个系统只通过API通信，各自保持独立升级能力，这才是正确的长期主义。

我开始做的第一版，想的特别复杂，一度想在RuoYi里内嵌RAGFlow的前端页面，让用户无感知自由切换。后来发现，知识库用户真正需要的，只是一个清爽的问答对话界面，加上一个“上传文件”后台入口，其余东西越简单越好。把RAGFlow的页面通过iframe嵌进来，权限控制绕来绕去，反而增加了维护成本。

如果你是从零开始，我的建议是：先把RAGFlow用Docker跑通，自己在页面上传几个文件，调一调解析方法；然后写一个Java测试类，调通API；最后再造RuoYi的页面和权限体系。这个顺序不要乱，每一层都验证了再往上走。

还有一点必须强调，模型选型千万别跟风。别人说13B、70B好用，你就想上大的，先看看自己的服务器到底有几张卡。我见过一个客户非要用70B模型做私有化部署，结果公司买了四张消费级显卡，还没等接口调完，运维就疯了。先在7B这一档跑通整个业务链路，验证知识库确实在产生业务价值，再申请预算升级硬件，这样项目才能落地，而不是永远停留在技术Demo阶段。

知识库集成这件事，重要的不是模型有多聪明，而是让企业内部的人愿意用它，并且真正找得到答案。RuoYi加RAGFlow这套组合，恰好把“权限管理的骨”和“文档解析的肉”凑齐了，后面能不能长得壮，就看你怎么填业务场景的数据了。