RAG开源项目综合应用:把公司所有文档变成 AI 问答系统 —RAGFlow+FastGPT全流程实战

老板周一开会说："咱们公司有 3000 份合同、500 份产品手册，还有堆积如山的客服聊天记录——能不能搞个 AI 系统，让员工随便问什么，立刻给出答案？"

你说"好"，打开 ChatGPT，输入了第一个问题。它给了一段听起来头头是道、但跟你的业务毫无关系的废话。

为什么？ 因为 ChatGPT 根本不认识你的文档。它不知道你们公司去年签过的最大一笔合同金额是多少，不知道产品保修条款在第几页，不知道客服团队处理得最多的投诉类型是什么。

这就是 RAG 要解决的问题——给大模型装上你的专属记忆。

今天这篇文章，带你从头到尾走一遍"把企业文档变成 AI 问答系统"的完整流程。核心用了两个开源工具：RAGFlow（深度文档解析王者）和FastGPT（商业级知识库问答平台）。

不讲虚的。每一个步骤都有配置参数、有代码示例、有踩过的坑。读完这篇，你可以直接在机器上照做。

一、先搞清楚三个问题：RAG 到底是什么？为什么不用微调？RAGFlow 和 FastGPT 各干什么？

大多数人第一次接触"让 AI 懂自己的文档"，脑子里冒出的第一个念头是——"能不能把我的文档喂给 ChatGPT 训练一下？"

直觉反应，但方向完全错了。

RAG 和微调，本质区别在哪

微调是换大脑，RAG 是配图书馆管理员。

微调用新数据更新模型参数。需要几十万条标注数据、几个小时到几天的训练时间、几万块起步的算力成本。

RAG 呢？零训练。数据丢进去就能查。

更重要的是——微调过的模型，知识是"冻"住的。合同改了、产品手册更新了，你得重新训练。RAG 改一份文档就是改一个索引条目，毫秒级生效。

一个粗暴的判断标准：如果你的企业文档超过 1000 页，并且频繁更新——别想微调，直接上 RAG。

RAG 的核心工作流：五步走

任何 RAG 系统都包含五个核心步骤，一步都不能少：

Step 1：文档解析。 把 PDF、Word、PPT、图片、扫描件、网页变成纯文本。这一步是 RAG 系统的命门。 解析出了错、漏了信息、表格碎了——后面所有检索全白搭。

Step 2：文本切片。 把长篇文档切成一块块"知识碎片"。切太大，检索不准。切太小，回答断章取义。这是 RAG 系统最需要调参的环节。

Step 3：向量化嵌入。 把每块切片转成几百维向量。语义相近的文本，向量距离就相近。

Step 4：检索。 用户提问后，在向量库中找出最相关的 N 个切片。方法有纯向量、纯关键词（BM25）、混合检索——后面会细讲。

Step 5：生成。 把检索到的切片作为上下文，连同用户问题一起塞给大模型，生成答案。

走完这五步，大模型就变得言之有物了。

但如果第一步——文档解析——没做好，后面全是用歪砖头盖房子，楼层越高越危险。

RAGFlow vs FastGPT vs Dify：三足鼎立

RAG 领域三座山头，各有各的绝活：

一句话总结：RAGFlow 做"解析"世界第一，FastGPT 做"应用"开箱即用，Dify 做"编排"灵活可插拔。

课程选了前两个——用 RAGFlow 处理复杂文档，用 FastGPT 跑企业级知识库问答。

为什么不用 LangChain 自己搭？LangChain 是一套乐高积木，灵活但门槛高。你花两周搭出来的东西，可能还没 RAGFlow 默认配置效果好。咱从一开始就反复强调：先跑通，再调优。先用开源工具，再考虑自研。

二、RAGFlow 实战：从 Docker 启动到医疗问答助手

先上手 RAGFlow。为什么先讲它？因为 RAGFlow 的文档解析是整个 RAG 流水线的根基。根基不牢，后面全白搭。

环境准备：一个命令启动

硬件要求：CPU 4 核、内存 16GB、磁盘 50GB。 RAGFlow 官方给的最低配置。课程用的是完整版镜像（v0.17.2，约 9GB），包含内置的嵌入模型和 DeepDoc 文档解析引擎。

# 1. 克隆代码库 git clone https://github.com/infiniflow/ragflow.git cd ragflow/docker  

# 2. 修改.env，把slim镜像换成完整版 

# RAGFLOW_IMAGE=infiniflow/ragflow:v0.17.2  

# 3. 一键启动 docker compose -p ragflow_docker -f docker-compose.yml up -d  

# 4. 检查启动状态 docker logs -f ragflow-server 

看到 RAGFlow 的 ASCII 艺术 Logo 就说明启动成功。

浏览器打开 http://localhost:80，注册账号登录。

配置大模型：线上+本地双通道

RAGFlow 本身只是一个"管道"，没有大模型能力，必须接入外部 LLM。

亮点：既支持在线大模型（阿里通义千问、DeepSeek、GPT 等），也支持本地 Ollama 部署的模型。

配在线模型很简单——进入"模型提供商"页面，选阿里云百炼，填 API Key 就搞定。

坑在这里： 配置本地 Ollama 时，RAGFlow 跑在 Docker 容器里，请求本地Ollama 服务不能用localhost， 

必须用 http://host.docker.internal:11434。容器网络隔离的坑，很多人卡了半小时。特别强调了这一点。

配好大模型后，设置一个系统模型（所有知识库和对话默认用的模型）。

构建 AI 医疗问诊助手：六万条数据 → 100 条验证

课程选了一个很实战的场景：用 HuggingFace 上的开源医疗 QA 数据集（来自 PubMed 数百万篇论文），构建一个"AI 医生"。

Step 1：下载数据集。 

从 https://huggingface.co/datasets/InfiniFlow/medical_QA 下载 CSV 文件。完整数据有 6 万多条。

Step 2：创建知识库，选正确的切片方法。 

这是最容易忽视但最关键的一步。RAGFlow 提供十几种切片方法——General（通用文档）、Q&A（问答对格式）、Resume（简历）、Table（表格）、Paper（学术论文）、Book（书籍）、Laws（法律文书）、Presentation（PPT）等。

我们的数据是 CSV 格式、QA 问答对，必须选 Q&A 模式切片。 错选了 General 模式？系统会把问答对切碎——问题和答案分到不同切片，检索时根本找不到正确匹配。

Step 3：等待解析完成。

 6 万条全解析要 1 小时以上。课程只取前 100 条做验证，几分钟搞定。

Step 4：检索测试。 

RAGFlow 默认用混合检索——同时跑关键词匹配和语义向量搜索，然后综合排序。BM25 的精确匹配 + Embedding 的语义理解，是目前公认的最优策略。

Step 5：创建对话助手。 

关键操作：必须勾选关联的知识库。 不勾选，模型不会去知识库里查，直接用 LLM 通用知识回答——跟直接问 ChatGPT 没区别。勾选后再问医疗问题，答案下方会标注引用来源和置信度分数。

RAGFlow 的杀手锏：DeepDoc 深度文档解析

为什么 RAGFlow 在 GitHub 上一个月涨了上万 Star？答案就在 DeepDoc。

传统的文档解析工具（PyPDF、python-docx）做的是"提取文本"。遇到双栏 PDF、表格、流程图、扫描件印章时，经常牛头不对马嘴。

DeepDoc 做的是"理解文档结构"。 它不仅有 OCR 识别文字，还会分析版面布局——标题在哪、正文在哪、表格跨页到哪里——然后根据结构做精准提取。

RAGFlow 官方文档反复强调一句话——"Quality in, quality out"（垃圾进，垃圾出）。指的就是这一步。文档解析结果是乱的，后面切片、向量化、检索全在处理垃圾。

一个真实对比：一份 100 页的双栏 PDF 产品手册。用 PyPDF 提取的文本是跳跃的——左边栏第一句后面跟着右边栏第一句——完全不可读。

用 RAGFlow 的 DeepDoc 处理后，左右分栏被正确识别为两个独立流，输出文本顺序和阅读顺序完全一致。

这就是课程说的：做企业 RAG，文档解析是第一优先级，不是可选项。

三、FastGPT 实战：从爬数据到建知识库的全自动化链路

RAGFlow 搞定了文档解析。但企业场景里还有一个常见需求：网页数据怎么办？

比如竞品分析助手，数据来源是天眼查的公司数据、裁判文书网的法律文档、行业新闻。你不可能手动一篇篇复制粘贴。

FastGPT 的价值就在这里：一套完整的"爬虫→入库→问答"流水线。

FastGPT 环境搭建

和 RAGFlow 一样，Docker 一键启动：

# 创建目录，放入config.json和docker-compose.yml mkdir fastgpt && cd fastgpt  # 启动 docker compose up -d 

FastGPT 依赖 OneAPI 做模型管理和中转。访问 http://localhost:3001 配置 OneAPI——添加 LLM 渠道，测试通道连接，在 config.json 中写入环境变量，重启容器。

天眼查爬虫：把网页数据变成知识库

课程的实战项目很实际：爬取天眼查的公司数据，构建企业信息问答系统。

Step 1：配置登录 Cookie。

浏览器登录天眼查，F12 打开开发者工具，控制台输入 document.cookie，把输出复制到 .env 文件的 TIANYANCHA_COOKIE 字段。没登录只能看到几行，登录后能看到完整工商信息、股东结构、诉讼记录。

Step 2：运行爬虫流水线。 

课程代码是标准 Python 项目结构——config/管配置、crawler/管爬取解析、database/管写入、utils/管日志和工具。核心思路：requests + BeautifulSoup 模拟浏览器请求，解析 HTML 页面，结构化数据存入 MySQL。

Step 3：把数据库接入 FastGPT 知识库。 

FastGPT 支持从数据库直接读数据作为知识源——不需要手动导出 CSV 再导入。配置数据库连接信息，选数据表和字段，FastGPT 自动切片、向量化、建索引。

跑通后在 FastGPT 对话界面输入"查一下北京字节跳动科技有限公司的注册资本和法人代表"，系统自动从天眼查获取最新数据，结合知识库历史记录给出答案。

FastGPT 的工作流核心：不只是问答，是自动化流水线

FastGPT 另一个核心能力是拖拽式工作流编排。

它不只是"用户问→系统答"，而是可以串联多个步骤：

数据采集（爬虫定时任务） → 文本预处理（清洗、去重） → 切片入库（自动建索引） → 知识库检索 → LLM 生成答案 → 结果格式化

这套流水线配置好之后，完全不用人工干预。 爬虫每小时跑一次，知识库自动更新索引，用户随时问随时答。

对于舆情监控、行业研报追踪、竞品动态分析这类需要持续监控外部信息的场景，这套东西是质的飞跃——不用每天手动搜新闻、复制粘贴、整理文档，系统全自动跑。

四、从课程源码看 RAG 系统架构：两个项目教会你什么

蓝天老师在课程设计上有个隐含目的：让你通过两个真实项目，掌握 Python 工程化开发的核心能力。

RAGFlow 帮你理解 RAG 的底层原理，FastGPT 帮你掌握企业级应用搭建。

FastGPT 项目结构：学什么

FastGPT 实战项目的代码结构是一个标准的中型 Python 项目：

fastgpt-project/ ├── config/          

# 配置文件管理（JSON/YAML） │   ├── settings.py 

# 统一配置读取入口 │   └── logger.py    

# 日志系统配置 ├── crawler/        

# 爬虫模块 │   ├── tianyancha.py   

# 天眼查爬虫 │   └── parser.py       

# HTML解析和数据提取 ├── database/        

# 数据库操作层 │   ├── models.py       

# ORM数据模型 │   └── connection.py   

# 数据库连接池管理 ├── utils/           

# 工具函数 │   ├── file_handler.py 

# 文件读写 │   └── helpers.py      

# 通用辅助函数 ├── .env             

# 环境变量（API Key、数据库密码等） └── requirements.txt 

# 项目依赖 

课程通过这个结构教了三件事：

第一，Python 项目的日志处理。 很多人写脚本只用 print() 调试，上了生产环境出问题根本找不到原因。课程示范了 logging 标准库的完整用法——日志级别、多 Handler、按时间或大小轮转。

第二，配置文件的加载和管理。 .env 放敏感信息，config.json 放业务参数。代码中通过 python-dotenv 加载环境变量，settings.py 统一对外暴露配置。改参数不需要搜整个代码库。

第三，Docker Compose 编排多服务。 一个 FastGPT 项目涉及至少 5 个容器——FastGPT、OneAPI、MongoDB、MySQL、PostgreSQL。docker-compose.yml 定义了每个服务的镜像、端口映射、环境变量、数据卷挂载和依赖关系。课程提供了完整文件，直接用或者学会自己写都行。

RAGFlow 源码结构：看什么

RAGFlow 是 Star 数 5 万+的顶级开源项目，源码结构非常有参考价值：

ragflow/ ├── agent/              

# AI Agent框架（20+工具组件） │   ├── templates/      

# 预制Agent模板（客服、医疗、投资研究等） │   └── component/      # 可组合工具组件（搜索、翻译、邮件、SQL等） ├── deepdoc/            # 深度文档解析引擎（核心竞争力） │   ├── parser/         

# 12种文档解析器 │   └── vision/         

# OCR和布局识别 ├── rag/                

# RAG核心逻辑 │   ├── llm/            

# 大模型适配层（Chat、Embedding、Rerank） │   ├── nlp/            # 分词、搜索、同义词 │   └── app/            

# 不同文档类型的RAG处理策略 ├── graphrag/           

知识图谱增强RAG ├── api/                

# RESTful API层 ├── web/                

# React前端 └── docker/             

# Docker部署配置 

作为开发者，最值得学三个模块：

deepdoc/parser/。 12 种文档类型解析器——pdf_parser.py、docx_parser.py、excel_parser.py、ppt_parser.py等。要做自己的文档处理系统，这些代码是顶级参考资料。

agent/component/。 内置 20 多个 AI Agent 工具组件——Bing 搜索、Google 搜索、维基百科、arXiv 学术搜索、PubMed 医学搜索、邮件发送、天气查询、股票数据、金融问答。每个都是一个独立 Python 模块，可以当成"AI 工具包"直接复用。

rag/llm/。 多模型统一适配层。不管用 OpenAI、通义千问、DeepSeek 还是 Ollama 本地模型，都通过同一个接口调用。适配器模式+工厂模式，直接读源码比看十篇设计模式文章都管用。

五、通用文档智能问答系统：从 Demo 到生产，最后一公里的坑

最后一部分讲"商业化落地"。光跑通一个 Demo 和真正上线一个系统，中间差了十万八千里。

文本切片：RAG 系统最精妙的调参

切片大小是个经典权衡题。

切太大： 2000 字符的切片里包含合同编号、金额、签约日期三条信息。用户问"合同金额多少"，系统检索到这条切片，返回 2000 个字符全塞给大模型。大模型要从里面找到金额那一句——容易看漏、串到隔壁合同去。大切片=丢精度。

切太小： 把"甲方应于 2025 年 6 月 30 日前支付 100 万元"切成"甲方应于 2025 年 6 月"和"30 日前支付 100 万元"两段。日期和金额被分开了。用户问"什么时候付 100 万"——系统答不了完整信息。小切片=丢上下文。

课程给出的经验法则：切片 300-500 字符，重叠 100 字符。 保留完整语义单元，又通过重叠确保跨边界信息不丢失。

RAGFlow 的优化更进一步——不是一刀切，而是先做版面分析，识别标题、正文、表格、图注，在自然语义边界处切分。表格不切碎，标题和正文不分家。这就是 RAGFlow 的"模板化切片"——可解释、可控制。

混合检索：为什么单一方法不够用

早期的 RAG 用单纯向量检索：用户问题转向量→在向量库找距离最近的 K 个切片→塞给大模型。语义理解强，但有两个致命弱点：

1. 精确匹配不行

BM25 正好补这个缺口。原理很简单——词频-逆文档频率。一个词在文档中出现越多、在整体语料中出现越少，权重越高。

混合检索 = BM25 + 向量检索 → 综合排序。 RAGFlow 默认就是这个。课程在医疗数据集上的验证：纯向量检索 Top-5 准确率约72%，加 BM25 混合检索后提到91%。

引用溯源：消除大模型幻觉的最后防线

幻觉是大模型最大的信任危机。客服、医疗、法律、金融这些低容错领域，一句瞎编的话可能造成严重后果。

RAG 的"引用"机制是解药。用户问问题→系统检索到切片→大模型基于切片生成答案→同时标注每条答案引用了哪个原始文档的哪段内容。

RAGFlow 在回答下方附有"引用来源"卡片，点击直接跳转到 PDF/Word 文档的对应位置。FastGPT 同样支持引用溯源。

从商业化角度看——这个功能不是"加了更好"，而是"不加用户就不信任"。 企业客户采购 RAG 系统，第一个问题永远是："我怎么知道它说的对不对？" 引用溯源就是你的答案。

六、如果你要自己搭一个企业 RAG 系统：逐项核对清单

学完课程，脑中可能有了蓝图。但真实落地时，大部分人会卡在细节上。我把以前踩过的坑整理成清单。

1.部署层面的坑

2.检索层面的坑

3.商业化落地层面的考量

七、下一步：如果你想把 RAG 做得更好

RAGFlow 和 FastGPT 帮你完成了 80%的工作。但想做到极致，课程提到了几个进阶方向。

GraphRAG：知识图谱增强

普通 RAG 只能回答"点"的问题——找到相关切片，拼在一起回答。

但当用户问"我们公司和这三家供应商的历史合作情况怎么样"时，系统需要跨多份文档建立实体关系（公司→合同→金额→日期→条款）。这种"面"级别的问题，普通 RAG 容易漏。

GraphRAG 在向量检索基础上加了一层知识图谱。 先把文档中的实体（公司名、人名、金额、日期）和关系（签署、承接、违约）抽取出来构建有向图。查询时根据实体关联路径找到"隐藏但相关"的信息。

RAGFlow 0.17 版已内置 GraphRAG 支持，提供 General（通用图）和 Light（轻量图）两种模式。对企业内部的合同关联分析、供应链溯源——这是降维打击。

Agent 模式：让 AI 自己决定怎么查

课程涉及的 RAGFlow Agent 模块，能构建"自主决策"的 AI 助手。不只是在知识库检索，还可以：

• 发现知识库无答案时，自动切换外部搜索（Bing/Google）
• 需要计算时，自动生成 SQL 查数据库
• 需要翻译时，自动调用翻译接口
• 按预设工作流，执行多步骤任务

FastGPT 的工作流编排也一样——把爬虫→清洗→入库→检索回答串成流水线，整个系统变成自动化工厂。

多模态 RAG：图片、表格、图表也能搜

目前 RAG 主要处理文本。但真实企业场景里，很多核心信息藏在图片和表格里。

RAGFlow 的 DeepDoc 引擎已经在突破这一点——不仅识别图片文字（OCR），还识别表格结构、提取图表数据。 未来多模态 RAG 的终极目标：上传一张产品图纸，系统直接回答"这个零件的规格是什么"。

八、想，都是问题；做，才有答案

这篇文章的价值不在于教了多少新概念。

恰恰相反——它帮你把"概念"变成了"能跑起来的东西"。

RAG 不是新技术。RAGFlow、FastGPT 也不是刚出的项目。但能把这两个东西安装好、跑通、理解每一步为什么要这么配置、知道踩坑了怎么排查——这才是真正拉开差距的地方。

希望大家学习完之后，具备独立动手解决问题的能力。

一台 16GB 内存的电脑，一个 Docker，一个 API Key。三小时，就能从零到一。

别想了，动手，马上！