兴趣使然的创作者

之前的 Ragflow-Plus 在服务器上稳定运行一段时间后，接到任务，要把服务迁移到一台的，的台式机上。起初认为，下载离线安装包，加载离线镜像，迁移下数据就可以了。结果坑多得意想不到，折腾了一晚上才搞定。本文就来分享一下解决方式，Ragflow-Plus 用的是和 Ragflow 相同数据存储方式，用 Ragflow 部署的系统可相同适用。

本文继续研究 LLaMA-Factory，内容侧重于日志监控和模型量化分享。

训练模型的过程通常被戏称为“炼丹”。参数组合和结果息息相关，但没有标准最优参数组合。因此，在自行钻研之前，有必要先看看别人是怎么做的。

要找到最优的模型训练策略，首先要明确模型的评估体系。本文将从这三个问题进行探究。

在前文了解 LLaMA-Factory 的各种主要设置参数后，本文开始使用现有的资料构建自己的微调数据集。

在实际测试前，有必要先梳理一下基本的训练方法，以避免在后续实验中不理解参数的具体含义。这里的基本的训练方法参照 LLaMA-Factory 官方文档作为划分依据，不包含 LLaMA-Factory 支持以外的其它方法。LLaMA-Factory 官方文档地址：https://github.com/hiyouga/LLaMA-Factory训练方法按照训练阶段，可分为预训练(Pre-training)和后训练(Post-training)。

(52.4k)、unsloth(40.6k)、DeepSpeed(38.9k)、peft(18.8k)和axolotl(9.6k)。其中，不仅热度最高，而且还是国人维护，自然成为首选。LLaMA-Factory支持直接通过命令行或 Web UI去微调模型，无需编写代码，其支持各种模型LLaMA、DeepSeek、Qwen等多种模型微调，集成了各种训练主流方法。仓库地址：https://github.com/hiyouga/LLaMA-Factory。

之前写 Dolphin 的分析文章时，我对 VLM 进行文档解析的路线始终不抱希望，因为之前的规律表明：只有模型参数足够大，才能获得好效果，小参数模型一致难以企及大参数模型的性能。MinerU 0.9B 的 VLM 模型让人眼前一亮，一个模型同时解决了布局分析、公式识别、文本OCR等各种任务，而且效果不错。本文中的实验结果表明，每块部分都由小模型去做，虽然能应对大多数场景，但对于部分复杂场景，它的瓶颈也暴露无疑，很难再通过数据训练去突破。

本次继续对进行小版本更新，发布版本。开源地址：https://github.com/zstar1003/ragflow-plus。

本次对进行一轮小版本更新，发布 v0.4.2 版本，主要对上一版本存在的问题进行修复。开源地址：https://github.com/zstar1003/ragflow-plus。

此次更新后，在局域网服务器中进行了一轮测试，目前已基本能满足个人应用场景的使用需求。后续会将精力投入到大模型相关的基建拓展研究中，比如，embedding模型的效果如何评估，如何微调大模型。之前定下的Ragflow-Plus的更新计划将会暂缓推进，如果有开发经验的读者想继续对此项目进行贡献，欢迎提交PR。

RagflowPlus v0.4.0发布摘要 开源项目RagflowPlus迎来重大更新，主要优化包括： 文件上传支持选择文件夹自动解析子文件，优化传输通道减少超时 文档撰写模块重构，新增自定义模板功能，独立响应通道提升速度，支持知识库选择和参数调节 多项优化：调整解析逻辑修复关键词检索问题，修复知识库权限BUG，改进Excel解析效率，统一Ollama接口为v1/embeddings

本文对表格和公式两类元素进行调优测试，不难发现，对于rag系统来说，检索是至关重要的环节。想要效果好，就需要对每一个块进行精调。因此，在进行对话测试前，检索测试是必要环节：如果检索不出来，那就要排查chunk块的类型和关键词设定；如果能检索到，模型回答不出来，那就是模型本身的性能问题。

理解完检索过程后，回到开篇提到的问题，就可以进一步定位：关键词相似度不足，实际原因就是解析块和问题的分词逻辑不一致。在现版本中，解析时，文本的分词直接通过处理，即会将空格，制表符\t、换行符\n等字符，作为分隔依据，这样操作太过简单。ragflow的分词器在1. 预处理：- 将所有非单词字符（字母、数字、下划线以外的）替换为空格。- 全角字符转半角。- 转换为小写。- 繁体中文转简体中文。2. 按语言切分：- 将预处理后的文本按语言（中文/非中文）分割成多个片段。

RagflowPlus发布了v0.3.0版本，新增了用户会话管理、知识库图像预览显示、文件类型解析拓展、聊天对话字体动态调节等功能。同时，对信息排序、知识库创建、嵌入模型适配等方面进行了优化，并修复了用户人数显示不全、创建时间异常等问题。

MinerU更新频率也相当频繁，在短短一个月内，更新了10个小版本。本文结合最新版本v1.3.10，深入拆解下它进行文档解析时的内部操作细节。

我们提出了 MiMo-7B，一个专为推理任务而生的大型语言模型，其优化贯穿了预训练和后训练两个阶段。在预训练期间，我们增强了数据预处理流程，并采用三阶段数据混合策略来强化基础模型的推理潜力。MiMo-7B-Base 在 25 万亿（Trillion）个 token 上进行预训练，并引入了多词元预测（Multi-Token Prediction）目标以提升性能和加速推理速度。

2025年4月29日，凌晨五点多，Qwen3发布。不得不感叹阿里人真卷呀，在这个点发布新产品。

MCP这个词最近比较流行，在`ragflow v0.18.0`版本中，新增了MCP服务器，因此，花了两天时间，对MCP进行了一些调研。

`RagflowPlus`在一轮紧急更新后，修复了6个主要问题，并新增用户密码重置的功能。

RagflowPlus在更新至v0.2.0受到了很多关注和使用反馈。本文主要介绍RagflowPlus设计理念与操作方式，以便新关注的读者也能快速上手。这次录制了一段视频，如果觉得图文内容较长，看起来费力，可以点击下方链接，观看视频。

全新功能上新

看到不少人说“Ollama就图一乐，生产环境还得用vLLM”。本文决定使用docker对vLLM进行部署，并解决模型配置中，IP地址的硬编码问题。

文件管理和知识库管理两个菜单具有先后关系。用户首先需要上传文件到文件管理菜单中，此步骤会增加数据库中file表的记录，一条记录对应一个文件。之后，在知识库管理界面，用户可以查看管理所有用户的知识库，对应的是数据库中表，私人构建的知识库也难逃法眼。新建数据库，默认会以第一个注册用户的名义构建，可以选择语言、权限。语言标记对实际功能不产生影响，只是作为标签进行提示。权限会对共享情况产生影响，如需团队成员共同查看到该知识库，可设置为团队。

ragflow 有个文件管理菜单，但是每个用户只能看到自己上传的文件，看不到其它用户上传，这显然会对管理造成阻碍。并且，在minio存储桶中，对于单次上传的所有文件会存在同一个桶中，比如，上传一个文件夹，会新建一个桶存放所有文件夹中的文件；再上传一个单独文件，又会新建一个桶存放新的文件。这样设计是非常糟糕的，客观上造成了维护和二次开发的难度。

Ragflow-Plus v0.1.1 在经历一轮用户测试和反馈后，发现了一些问题，v0.1.2 版本进行一轮小更新，修复以下问题：1.新建用户模型配置不全问题2.用户为空时，添加用户异常问题3.用户配置界面点击未刷新问题4.管理员账号密码无法修改问题5.前后端API调用访问不畅问题Ragflow-Plus 仓库地址：https://github.com/zstar1003/ragflow-plus如果尚未下载此仓库代码，推荐使用 git 的方式下载：如果已经使用 git 方式下载，可以在项目根路径下，

前文写了下 MinerU 的解析效果，收到不少读者催更，想利用 MinerU 替换 Deepdoc 的原始的解析器。我认为，开发新功能基本可遵循这三个阶段：能用：先通过脚本实现该功能,主打的是能用就行好用：不仅能够满足需求，而且搭配简洁易操作的界面，方便用户无需编程也能操作用好：考虑可拓展性，进一步满足日益变化的新需求。本文借助 MinerU 和 Ragflow 的原生接口，实现 MinerU 对指定文件进行解析，批量插入解析块，先实现能用的阶段。

要用好rag的输出增强效果，文档解析是关键一环。如果文档解析块存在问题，那么后面检索到的内容，也会对模型造成错误干扰。前文分析过，ragflow使用自研的Deepdoc算法对不同类型的文档进行解析，然而，对于pdf文件，在多数情况下的解析效果并不如意。

ragflow-plus仓库地址：https://github.com/zstar1003/ragflow-plus

本文继续对ragflow文档解析部分进行分析，并通过脚本的方式实现对文件的批量上传解析。

Ragflow的助理配置中，有很多参数，尽管官方文档给出了一定程度的解释，但不够详细。本文将对各项参数进行更详细的解释说明，并进一步挖掘某些参数中隐含的潜在陷阱。

前几天看到有群友提到一个现象：Ragflow的搜索界面的问答速度很快，但聊天界面的问答速度很慢，究竟是什么原因？在深入挖掘源码之后，逐渐发现了问题的答案。

ragflow，dify之类的，对一些普通人来说还是不太友好，有没有什么开源平台对接api，给用户提供一个像千问，kimi那样的用户界面？之前的文章，看到有朋友这样留言。想来确有道理，ragflow 即便不让用户自己上传文档，也需要创建助理、预设提示词、选择知识库，对用户的确不友好。从商业角度上考量，为什么支付宝要做碰一碰支付？省去一步打开付款码操作，也会带来无穷的商业价值。因此，有必要实现一个更简单的界面，让用户打开即用。

Ragflow 是主流 RAG 结合大模型问答的框架之一，然而其开源版本存在诸多问题，例如，团队使用时，成员间知识库共享操作繁琐，缺乏有效的用户管理后台。因此，我对其进行二次开发，解决了部分问题。解决方案开源共享出来，起名为仓库地址：https://github.com/zstar1003/ragflow-plus。

又解决了一大痛点问题

本文将对Ragflow pythonAPI文档进行中文化梳理，主要根据原文档对主要功能模块的example进行梳理，对于详细参数，可根据英文标识进一步参考原文档。

> 前几天看到群友提到一个现象，在试图询问知识库中某个人信息时，意外触发了DeepSeek的隐私保护机制，使模型拒绝回答该问题。另有群友提到，Ollama上有人发布过DeepSeek移除模型内置审查机制的版本。于是顺着这条线索，对相关内容进行进一步探究。

在你习惯和大模型进行问答交互时，是否考虑过一个问题？如果用大模型辅助论文写作，问答是否是最优交互方式？ChatGPT中用Canvas实现编码的动态交互插入，这种交互形式是否可以进一步推广到文档撰写？于是我在ragflow框架的接口基础上，实现了该功能。

本文将围绕token，对输入token进行统计分析，并对本地部署的DeepSeek大模型token的输出速度进行相关测试。

本文主要回答以下几个问题：1. 本地部署大模型时，如何快速判断所需显存量？2. 大模型推理所需显存由哪几部分构成？3. KV Cache是什么，为什么只有KV Cache而没有Q Cache？4. KV Cache显存如何进行计算？5. 大模型为什么会出现失忆现象，本质原因是什么？6. Ollama中，如何修改上下文长度？