夜雨聆风你把 PDF、Word、PPT、表格和网页交给大模型，真正难的不是“让它回答”，而是：它能否读懂复杂文档、找回正确片段，并把答案依据摆出来。开源项目 RAGFlow 就是为这件事准备的。
RAGFlow 文档切片演示
先说结论：RAGFlow 用来做什么？
RAGFlow 是 infiniflow 开源的 RAG（检索增强生成）引擎。它把“文档解析—切片—索引—检索—重排序—带引用回答”串成一套可操作的流程，并在此基础上提供 Agent 能力与接口。
换句话说，它不是一个只负责调用大模型的聊天壳，也不是单独的向量数据库。它更像是大模型前面的“上下文生产线”：先将企业资料处理成可检索的知识，再把最相关、可核对的内容送给模型回答。
从仓库 README 可以看到，它重点覆盖以下能力：
- 复杂文档理解：面向 PDF、影印件、图片、Word、PPT、Excel、TXT、网页和结构化数据等异构来源。
- 可解释的文本切片：提供模板化切片，并把切片结果可视化，允许人工干预。
- 可追溯回答：答案可关联关键引用与来源，目标是降低“言之凿凿却没有依据”的幻觉风险。
- 完整检索链路：支持 LLM 与向量模型配置，以及多路召回、融合重排序和 API 集成。
- Agent 化扩展：仓库已加入 Agent 工作流、MCP、代码执行器等方向的能力；是否启用取决于部署配置和具体版本。
适合谁？想把公司制度、产品手册、技术文档、项目资料做成可问答知识库的团队；需要“答案能回到原文”而非只要流畅对话的场景；以及想把 RAG 能力嵌入现有系统的开发者。
不该期待什么？RAGFlow 不能自动保证答案永远正确。文档质量、切片策略、检索配置、模型与评测仍决定最终效果；它提供的是一套把这些环节工程化、可观测化的底座。
它和“直接把文件丢给大模型”有什么不同？
直接上传文件通常适合一次性问答；资料一多，检索边界、权限、引用、更新和系统集成就会变得难以控制。RAGFlow 把流程拆开，让每一环都能调整：
text 原始资料
↓ 解析（版面、文本、图片等）
可查看的切片
↓ 建索引
检索 + 重排序
↓
携带来源片段的提示词
↓
大模型生成答案 + 引用依据
RAGFlow Agent 工作流演示
这套链路特别适合两类问题：一是“这条结论到底来自哪份文档”；二是“文档更新后，如何让回答随之更新”。前者依赖引用与切片可视化，后者依赖重新解析和索引，而不是把知识写死进提示词。
安装前，先确认三件事
官方 README 给出的自托管基线是：
此外请注意：
官方预构建镜像目前面向 x86 平台；ARM64 需按官方构建指南自行构建。 默认文档引擎是 Elasticsearch；部署前不要随意改 DOC_ENGINE。从 Elasticsearch 切换到 Infinity 时，官方流程中的down -v会删除卷和已有数据。若使用代码执行器沙箱，还需要 gVisor；普通知识库问答不以此为前置条件。 Windows 用户建议使用 Docker Desktop 的 WSL 2 后端。README 中的 vm.max<em>map</em>count是 Linux 内核参数；应在实际承载 Docker 的 Linux/WSL 环境里检查，而不是在普通 PowerShell 中照抄执行。
方式一：最快上手——先试云服务
如果你的目标是先体验“上传资料—建知识库—提问”这条链路，不必急着部署：打开 RAGFlow Cloud 即可试用。云服务和自托管在数据位置、权限、成本与运维责任上不同，涉及内部资料时请按组织合规要求选择。
方式二：Docker Compose 自托管（推荐）
这是一条适合大多数试用与私有部署的路径。以下命令以官方 README 中的稳定标签 v0.26.4 为例；实际执行时，请先查看 Releases 决定要固定的版本，并让代码标签与镜像标签一致。
1. 在 Linux / WSL 后端检查内核参数
bash sysctl vm.max_map_count
若结果小于 262144，在承载 Docker 的 Linux 环境执行：
bash sudo sysctl -w vm.max_map_count=262144
这项设置重启后可能失效。长期使用请按发行版方式写入 /etc/sysctl.conf 或对应的 sysctl 配置文件。
2. 获取代码并切到匹配版本
bash git clone https://github.com/infiniflow/ragflow.git
cd ragflow
git checkout v0.26.4
cd docker
为什么要切标签？官方明确提示：这样能让仓库里的 entrypoint.sh与要拉取的 Docker 镜像版本保持一致。不要只改镜像标签、不改代码版本。
3. 先审阅 docker/.env
默认配置中，DEVICE=cpu、DOC_ENGINE=elasticsearch，Web 服务端口为 80，镜像为 infiniflow/ragflow:v0.26.4。首次用于公网或团队环境前，务必修改 .env 中的数据库、对象存储等默认密码；官方文件也明确警告不要在非本地环境使用默认密码。
若网络无法访问 Docker Hub 或 Hugging Face，可参考 .env 内的注释调整 RAGFLOW<em>IMAGE 与 HF</em>ENDPOINT。官方 README 同时列出了华为云、阿里云镜像地址；请根据网络和镜像可信策略自行选择。
4. 启动 CPU 版服务
bash docker compose -f docker-compose.yml up -d
若已配置好 NVIDIA GPU、Docker GPU 运行时及相应环境变量，再按官方 README 的说明把 DEVICE 切为 gpu 后启动。GPU 只会加速部分文档理解任务，并不替代模型服务、检索质量调优或容量规划。
5. 等服务真正就绪，再打开浏览器
bash docker logs -f docker-ragflow-cpu-1
看到日志中的 Running on all addresses (0.0.0.0) 后，再访问：
text http://你的服务器IP
在默认端口配置下，HTTP 的 80 端口可省略。若改了端口映射，则使用 http://IP:端口。首次初始化没完成就登录，官方 README 提示可能出现“网络异常”。
6. 配置模型供应商与 API Key
在 docker/service<em>conf.yaml.template 的 user</em>default<em>llm 中选择模型供应商，并填写对应的 API</em>KEY。这一步不要把密钥提交进 Git，也不要把真实密钥写入教程、截图或公开工单。
到这里，服务端已经启动。接下来在 Web 界面创建知识库，上传资料，检查切片效果，配置模型，然后发起对话。建议先用 20～50 篇你熟悉的资料做小规模验证：既看答案，也核对引用是否真的支持答案。
三个最常见的踩坑点
1. “容器起来了，网页却打不开”
先看 docker compose ps 和 docker logs -f docker-ragflow-cpu-1，确认初始化完成；再检查 80 端口是否被占用、防火墙或云安全组是否放行。不要把“容器已创建”当作“业务已就绪”。
2. “能回答，但回答不可靠”
先检查切片边界和引用，而不是立刻换一个更大的模型。标题、表格、扫描页、双栏排版、图片文字都可能影响解析；再逐步检查检索条数、重排序、Embedding 模型与提示词。RAG 的有效性需要拿真实问题集验证。
3. “我想换文档引擎”
官方写明默认使用 Elasticsearch 存储全文和向量。如果按切换步骤执行了 docker compose ... down -v，现有卷会被删除。生产数据应先备份，再做迁移验证；不要在有价值数据的实例上直接试命令。
何时需要走源码开发？
只有在你要修改解析、检索、后端或前端代码时，才建议走源码启动。官方路径包含：安装 uv、以 Python 3.13 同步依赖、下载运行依赖、用 Compose 拉起 MinIO / Elasticsearch / Redis / MySQL，再分别启动后端与前端。它更适合开发环境，复杂度明显高于 Docker 自托管；只是使用 RAGFlow 时无需从源码起步。
最后的建议：把“效果验收”也一起部署
RAGFlow 最有价值的不是把文档塞进向量库，而是让“资料如何被理解、答案依据在哪里”可见。上线前建议准备一份小型评测集：
10～20 个业务真实问题； 每题预期依据的原文位置； 对答案正确性、引用一致性、拒答边界和响应时间分别记录； 文档更新后重复测试，确认索引与回答是否同步变化。
这样你得到的不是一次演示，而是一套可持续维护的知识库能力。