第一阶段索引流程把文档变成知识库步骤1文档接入与存储• 操作通过 UI/API 上传 PDF、Word、Excel、PPT、图片、扫描件、网页等原始文件存入对象存储如 MinIO元数据文件名、时间、来源入库 PostgreSQL。• 为什么这么做统一入口屏蔽格式差异原始文件留存用于溯源与引用对象存储适合非结构化文件PostgreSQL 管好元数据便于检索过滤。• 优点全格式兼容原始文件可追溯存储分层成本低。• 缺点小文件多会增加存储开销上传量大时需异步队列防阻塞。理解文档入库存档方便溯源与引用。具体原始文件存入如 MinIO元数据文件名、时间、来源入库 PostgreSQL怎么做到的• PyMuPDFPDF 解析• python-docxWord 解析• pandasExcel 解析• python-pptxPPT 解析• Pillow OpenCV图片处理• PaddleOCR扫描件、图片文字识别核心• BeautifulSoup4 Playwright网页抓取、动态网页解析步骤2文档深度解析DeepDoc 核心• 操作a. OCR扫描件/图片转文字支持多语言b. 布局分析识别标题、段落、列表、图片、表格位置c. 表格理解TSR解析合并单元格、行列标题转自然语言描述d. 结构化输出带位置、层级、类型的文本块。• 为什么这么做传统 RAG 只抽纯文本会丢结构、表格、层级关系导致分块断裂、检索不准、生成幻觉。DeepDoc 做「视觉-结构-语义」三重解析还原文档原貌。• 优点表格/扫描件解析强结构保留完整信息提取准确率比纯文本高 30%。• 缺点解析耗资源CPU/GPU复杂排版如多栏、手写仍有误差OCR 质量依赖图片清晰度。理解多格式文档读取成数据特例图片转文字原有文档用框架去识别布局、表格等形式方便后续词向量转换步骤3智能分块Chunker核心可控点• 操作◦ 模板分块按文档类型论文/合同/简历/财报预设规则按标题/章节/段落边界切分◦ 语义分块用小模型算句子相似度语义连贯为一块◦ 滑动窗口兜底固定长度重叠如 1000 字/200 重叠◦ 可视化调整手动拖拽分块边界避免关键信息割裂。• 为什么这么做分块是 RAG 成败关键——块太大整页语义混杂、检索不准块太小句子上下文断裂、信息不全无规则切按字数易拆断标题-正文、表格-说明。模板语义分块优先按自然边界切兼顾完整与精准。• 优点关键信息保留率比滑动窗口高 47%可按业务定制支持人工干预可控性强。ragflow智能分块后的结果和token是什么关系token的数量直接划定了每个分块Chunk的“最大容量”。智能分块的过程就是在保证语义完整和不超过Token上限之间寻找最佳平衡。ragflow的智能分块怎么可以人工干预1.提供了ui界面预览 和 编辑 的方式;2.也可以改参数 / 换策略干预自动分块逻辑• 缺点模板需适配场景语义分块增加计算量人工调整成本高。理解按文档类型预设规则步骤4文本向量化Embedding• 操作对每个分块调用嵌入模型默认 BGE、支持 OpenAI/本地模型生成稠密向量如 1024 维向量文本元数据页码、位置、来源绑定。稠密向量 简单说就是用一串包含小数浮点数的、长度固定的数组来表示一个东西比如一句话、一张图的“语义”同类别的稀疏向量.一个直观的例子搜索“智能手机”。用稠密向量可能搜出“iPhone”因为它在语义上相近用稀疏向量则只会搜出严格包含“智能”和“手机”这两个词的结果。在现代RAG系统中标准做法是混合检索 稠密向量语义召回 稀疏向量关键词召回先用两种方法分别找出各自认为相关的文档再用重排序器Reranker 把两路结果合并排序这样能兼顾语义理解能力和关键词匹配的精准度。其他相关的向量类型除了稠密和稀疏你还会碰到这些概念多模态向量可将文本、图像、音频等不同类型的数据映射到同一个向量空间。例如输入“一只猫”的文本和一张猫的图片两者生成的向量会非常相似。二进制向量把浮点数向量“压缩”成只含0和1的向量主要用来加速检索和节省存储空间但检索时精度会有所损失。静态向量Word2Vec、GloVe每个词对应一个固定向量不依赖上下文。“苹果”这个词无论是在水果还是手机语境下生成的向量都是同一个。如今在RAG中已很少使用。动态/上下文向量这是现在主流的方式BERT、GPT家族。“苹果”在“吃苹果”和“买苹果手机”两个句子中会生成不同的向量能准确理解上下文。动态/上下文向量和稠密向量 的区别动态/上下文向量是“看语境定词义”而稠密向量通常指“一词一义”的静态表示。动态/上下文向量同一个词在不同句子中会生成不同的向量。根据语境实时算灵活但慢能理解一词多义。并且它通常本身就是一种稠密向量更高级。“动态”和“稠密”并非互斥的两个类别实际情况是绝大多数动态/上下文向量本身也是稠密向量• 为什么这么做把语义转成向量空间距离——语义越近向量距离越小实现「意思相似」的检索而非仅关键词匹配。• 优点支持语义检索跨语言/歧义理解强向量维度固定便于数据库索引。• 缺点嵌入模型有成本API/算力向量不可解释不同模型向量空间不兼容切换需重嵌。理解就是把源头数据转换成词向量机器可识别的语言步骤5混合存储向量全文元数据• 操作◦ 向量库Milvus/FAISS/Chroma 存向量建 HNSW 索引加速检索◦ 全文库Elasticsearch 存原始文本做关键词/模糊检索◦ 关系库PostgreSQL 存元数据来源、页码、分块 ID用于过滤与溯源。• 为什么这么做单一存储有短板——向量库语义强但关键词弱、难过滤全文库关键词准但语义差关系库管好元数据便于权限、过滤、引用。三者结合兼顾语义精准可追溯。• 优点混合检索效果最优支持过滤如只查某文档/日期元数据完整答案可引用来源。• 缺点多组件部署复杂数据同步需维护存储成本高向量文本元数据三份。ragflow的第四步混合存储详细怎么做的用一步不漏、从数据流向到底层存储结构、再到入库代码逻辑把 RAGFlow 第四步「混合存储Hybrid Storage」讲得清清楚楚你听完就能直接对应到界面和源码。一、先明确RAGFlow 的“混合存储”存了什么不是只存向量是四块同时存原始文件PDF/Word/图片→ 对象存储MinIO/S3分块文本 结构化元数据 → 关系库MySQL/PostgreSQL稠密向量Dense Embedding → 向量库Elasticsearch/Infinity/Milvus稀疏向量BM25 索引 → 全文检索同 ES/Infinity不需要额外引擎这就是“混合”的含义结构化 非结构化 向量 全文索引四路一体。二、整体流程分块完成后 → 怎么进入混合存储最关键前置你已经完成了文档解析PDF → 文本 / 表格 / 图片智能分块自动 人工干预每一块 chunk {id, doc_id, content, title, page_no, …}第 4 步混合存储分 5 个子步骤子步骤 1元数据 原始文件入库MySQL MinIO目的记录 “文档 / 块” 的属性、位置、权限保证可追溯1.MySQL 写入核心元数据document 表文档名、类型、大小、上传时间、用户 ID、知识库 IDchunk 表块 ID、文档 ID、块内容text、标题、页码、token 数、是否有效chunk_meta层级路径如 “第一章→1.1”、关键词、来源页码2.MinIO/S3 写入原始文件 图片原始 PDF/Word 原封不动存用于 “查看原文”块里包含的图片 → 转 jpeg → 存 MinIO → 记录 img_id 到 chunk 表一句话MySQL 管 “块的属性”MinIO 管 “原始文件和图片”。子步骤 2生成稠密向量Dense Embedding目的做语义检索解决“意思相似但词不一样”对每个 chunk.content 调用 Embedding 模型支持BGE-M3、text-embedding、GLM-Embedding、Jina 等输出固定长度浮点数组如 1024 维特点一块 → 一个向量语义越近向量距离越近子步骤 3生成稀疏向量BM25→ 全文索引目的做关键词精确匹配解决“专业术语、编号、人名”RAGFlow 用 ES/Infinity 内置 BM25不需要你自己算稀疏向量直接把 chunk.content 写入 ES 的 text 字段ES 自动分词 → 建倒排索引 → 支持 BM25 打分一句话稠密向量管语义BM25 管关键词。子步骤 4向量 全文索引 写入同一引擎ES/Infinity/Milvus核心设计一个索引存所有不用跨库以 Elasticsearch 为例RAGFlow 默认每个 chunk 对应一条 ES 文档{“chunk_id”: “xxx”,“doc_id”: “yyy”,“content”: “RAGFlow 混合存储…”,“title”: “混合存储”,“vector”: [0.123, 0.456, …], // 稠密向量“create_time”: “2026-04-25”}vector 字段向量索引用于语义检索content 字段text 索引用于 BM25 全文检索同库同索引检索时一次请求同时拿两种结果子步骤 5建立关联 缓存Redis目的加速检索、避免重复计算MySQL ↔ ES 关联靠 chunk_id 双向映射ES 查出来 → 用 chunk_id 去 MySQL 拿标题、页码、层级路径Redis 缓存缓存热门 chunk 的向量、内容缓存检索结果减少 ES 查询压力Q:Elasticsearch怎么存储 稠密向量和稀疏向量的vector 字段存储ES自动计算详细如下这个向量不是一个预先画好的图而是一个实时生成的成绩单稀疏向量 一个很长的表格每行代表一个文档每列代表一个关键词每个格子里要么是0没这个词要么是BM25算出来的重要性分数有这个词。它的特点是格子特别多几十万个关键词但每个文档里非零的格子特别少只有几个词有分数。就像一个超级大的Excel表格里面几乎全是0只有零星几个数字ES就靠这些零星数字来快速找到你想搜的文档。第二阶段检索流程用户提问→精准答案步骤6用户提问解析• 操作接收自然语言问题做意图识别关键词提取问题向量化可配置问题改写如扩写、拆解多轮。意图识别是怎么做的• 为什么这么做用户问题常简短/口语化/歧义多——向量化匹配语义关键词补精准改写优化检索词提升召回率。• 优点口语化/歧义问题适配强多轮问题可拆解检索输入质量高。• 缺点改写规则需调优意图识别不准会误导检索。步骤7多路召回混合检索核心• 操作a. 向量检索问题向量查向量库返回 Top-K 语义相似分块b. 全文检索关键词查 Elasticsearch返回 Top-K 匹配分块c. 结果合并去重保留双路高相关分块。• 为什么这么做向量检索擅长「意思对但词不同」如「营收」vs「收入」全文检索擅长「关键词精准匹配」如专有名词、编号两者互补召回更全、更准。• 优点召回率比单路高 20%兼顾语义与精准覆盖歧义/专业术语场景。• 缺点双路检索增加耗时结果合并需去重逻辑复杂。步骤8重排序Rerank• 操作召回结果送入重排模型如 BGE-Rerank、Cross-Encoder逐对计算问题与分块的语义相关性重新排序取 Top-N 最相关分块如 3-5 块。• 为什么这么做召回阶段为保全会返回较多噪声重排模型做细粒度相关性打分过滤无关、排准顺序给 LLM 高质量上下文减少幻觉、提升答案精准度。• 优点上下文质量显著提升幻觉率降低 30%排序更贴合用户问题。• 缺点重排模型耗时/成本高模型选择影响大Top-N 数量需调优。步骤9提示词构建与 LLM 生成• 操作把「用户问题Top-N 重排分块引用来源模板」拼接成提示词调用 LLMOpenAI/Qwen/ChatGLM/本地模型生成答案强制引用分块来源页码/文档名支持流式输出。• 为什么这么做LLM 强于语言生成但易幻觉用检索到的真实文档上下文约束生成让答案「有据可依」引用来源提升可信度便于核查。• 优点幻觉大幅抑制答案精准、可追溯支持多轮对话、流式输出。• 缺点提示词长度有限LLM 上下文窗口长文档需控制分块数量LLM 成本/响应时间依赖模型。第三阶段系统核心能力与整体优缺点核心能力区别于普通 RAGDeepDoc 深度解析表格/扫描件/结构文档解析强信息保留完整。可控分块模板语义可视化调整分块不割裂、信息全。混合检索向量全文重排召回准、噪声少。可追溯生成答案必带引用来源可信度高、可核查。低门槛可视化拖拽式流程、模板化配置非开发者可上手。整体优点• 全链路一体化从解析到生成一站式无需拼接多开源组件部署简单。• 企业级适配权限、多用户、异步队列、可观测性齐全适合生产环境。• 中文优化好默认 BGE 中文模型中文语义理解强适配国内场景。• 开源可自部署Apache 2.0 协议可私有化部署数据安全可控。整体缺点• 资源消耗高解析、嵌入、重排都耗 CPU/GPU小机器部署慢。• 复杂度高多组件ES/Milvus/PostgreSQL依赖运维有门槛。• 定制成本垂直场景医疗/法律需调优模板、分块策略、提示词。• 幻觉仍存在复杂问题、长上下文、跨文档推理仍有幻觉需持续优化。总结RAGFlow 的核心逻辑是用 DeepDoc 保住文档结构与细节 → 用可控分块平衡完整与精准 → 用混合检索重排拿到高质量上下文 → 用带引用的生成抑制幻觉。每一步都在解决传统 RAG「解析浅、分块乱、检索偏、幻觉重」的痛点代价是更高的资源消耗与复杂度换来企业级可用、精准、可追溯的知识库问答能力。需要我把以上流程整理成一份可直接执行的部署与调优清单包含硬件配置建议、关键参数默认值与调优范围、常见问题排查步骤吗
github上RAGFLOW项目业务分析
第一阶段索引流程把文档变成知识库步骤1文档接入与存储• 操作通过 UI/API 上传 PDF、Word、Excel、PPT、图片、扫描件、网页等原始文件存入对象存储如 MinIO元数据文件名、时间、来源入库 PostgreSQL。• 为什么这么做统一入口屏蔽格式差异原始文件留存用于溯源与引用对象存储适合非结构化文件PostgreSQL 管好元数据便于检索过滤。• 优点全格式兼容原始文件可追溯存储分层成本低。• 缺点小文件多会增加存储开销上传量大时需异步队列防阻塞。理解文档入库存档方便溯源与引用。具体原始文件存入如 MinIO元数据文件名、时间、来源入库 PostgreSQL怎么做到的• PyMuPDFPDF 解析• python-docxWord 解析• pandasExcel 解析• python-pptxPPT 解析• Pillow OpenCV图片处理• PaddleOCR扫描件、图片文字识别核心• BeautifulSoup4 Playwright网页抓取、动态网页解析步骤2文档深度解析DeepDoc 核心• 操作a. OCR扫描件/图片转文字支持多语言b. 布局分析识别标题、段落、列表、图片、表格位置c. 表格理解TSR解析合并单元格、行列标题转自然语言描述d. 结构化输出带位置、层级、类型的文本块。• 为什么这么做传统 RAG 只抽纯文本会丢结构、表格、层级关系导致分块断裂、检索不准、生成幻觉。DeepDoc 做「视觉-结构-语义」三重解析还原文档原貌。• 优点表格/扫描件解析强结构保留完整信息提取准确率比纯文本高 30%。• 缺点解析耗资源CPU/GPU复杂排版如多栏、手写仍有误差OCR 质量依赖图片清晰度。理解多格式文档读取成数据特例图片转文字原有文档用框架去识别布局、表格等形式方便后续词向量转换步骤3智能分块Chunker核心可控点• 操作◦ 模板分块按文档类型论文/合同/简历/财报预设规则按标题/章节/段落边界切分◦ 语义分块用小模型算句子相似度语义连贯为一块◦ 滑动窗口兜底固定长度重叠如 1000 字/200 重叠◦ 可视化调整手动拖拽分块边界避免关键信息割裂。• 为什么这么做分块是 RAG 成败关键——块太大整页语义混杂、检索不准块太小句子上下文断裂、信息不全无规则切按字数易拆断标题-正文、表格-说明。模板语义分块优先按自然边界切兼顾完整与精准。• 优点关键信息保留率比滑动窗口高 47%可按业务定制支持人工干预可控性强。ragflow智能分块后的结果和token是什么关系token的数量直接划定了每个分块Chunk的“最大容量”。智能分块的过程就是在保证语义完整和不超过Token上限之间寻找最佳平衡。ragflow的智能分块怎么可以人工干预1.提供了ui界面预览 和 编辑 的方式;2.也可以改参数 / 换策略干预自动分块逻辑• 缺点模板需适配场景语义分块增加计算量人工调整成本高。理解按文档类型预设规则步骤4文本向量化Embedding• 操作对每个分块调用嵌入模型默认 BGE、支持 OpenAI/本地模型生成稠密向量如 1024 维向量文本元数据页码、位置、来源绑定。稠密向量 简单说就是用一串包含小数浮点数的、长度固定的数组来表示一个东西比如一句话、一张图的“语义”同类别的稀疏向量.一个直观的例子搜索“智能手机”。用稠密向量可能搜出“iPhone”因为它在语义上相近用稀疏向量则只会搜出严格包含“智能”和“手机”这两个词的结果。在现代RAG系统中标准做法是混合检索 稠密向量语义召回 稀疏向量关键词召回先用两种方法分别找出各自认为相关的文档再用重排序器Reranker 把两路结果合并排序这样能兼顾语义理解能力和关键词匹配的精准度。其他相关的向量类型除了稠密和稀疏你还会碰到这些概念多模态向量可将文本、图像、音频等不同类型的数据映射到同一个向量空间。例如输入“一只猫”的文本和一张猫的图片两者生成的向量会非常相似。二进制向量把浮点数向量“压缩”成只含0和1的向量主要用来加速检索和节省存储空间但检索时精度会有所损失。静态向量Word2Vec、GloVe每个词对应一个固定向量不依赖上下文。“苹果”这个词无论是在水果还是手机语境下生成的向量都是同一个。如今在RAG中已很少使用。动态/上下文向量这是现在主流的方式BERT、GPT家族。“苹果”在“吃苹果”和“买苹果手机”两个句子中会生成不同的向量能准确理解上下文。动态/上下文向量和稠密向量 的区别动态/上下文向量是“看语境定词义”而稠密向量通常指“一词一义”的静态表示。动态/上下文向量同一个词在不同句子中会生成不同的向量。根据语境实时算灵活但慢能理解一词多义。并且它通常本身就是一种稠密向量更高级。“动态”和“稠密”并非互斥的两个类别实际情况是绝大多数动态/上下文向量本身也是稠密向量• 为什么这么做把语义转成向量空间距离——语义越近向量距离越小实现「意思相似」的检索而非仅关键词匹配。• 优点支持语义检索跨语言/歧义理解强向量维度固定便于数据库索引。• 缺点嵌入模型有成本API/算力向量不可解释不同模型向量空间不兼容切换需重嵌。理解就是把源头数据转换成词向量机器可识别的语言步骤5混合存储向量全文元数据• 操作◦ 向量库Milvus/FAISS/Chroma 存向量建 HNSW 索引加速检索◦ 全文库Elasticsearch 存原始文本做关键词/模糊检索◦ 关系库PostgreSQL 存元数据来源、页码、分块 ID用于过滤与溯源。• 为什么这么做单一存储有短板——向量库语义强但关键词弱、难过滤全文库关键词准但语义差关系库管好元数据便于权限、过滤、引用。三者结合兼顾语义精准可追溯。• 优点混合检索效果最优支持过滤如只查某文档/日期元数据完整答案可引用来源。• 缺点多组件部署复杂数据同步需维护存储成本高向量文本元数据三份。ragflow的第四步混合存储详细怎么做的用一步不漏、从数据流向到底层存储结构、再到入库代码逻辑把 RAGFlow 第四步「混合存储Hybrid Storage」讲得清清楚楚你听完就能直接对应到界面和源码。一、先明确RAGFlow 的“混合存储”存了什么不是只存向量是四块同时存原始文件PDF/Word/图片→ 对象存储MinIO/S3分块文本 结构化元数据 → 关系库MySQL/PostgreSQL稠密向量Dense Embedding → 向量库Elasticsearch/Infinity/Milvus稀疏向量BM25 索引 → 全文检索同 ES/Infinity不需要额外引擎这就是“混合”的含义结构化 非结构化 向量 全文索引四路一体。二、整体流程分块完成后 → 怎么进入混合存储最关键前置你已经完成了文档解析PDF → 文本 / 表格 / 图片智能分块自动 人工干预每一块 chunk {id, doc_id, content, title, page_no, …}第 4 步混合存储分 5 个子步骤子步骤 1元数据 原始文件入库MySQL MinIO目的记录 “文档 / 块” 的属性、位置、权限保证可追溯1.MySQL 写入核心元数据document 表文档名、类型、大小、上传时间、用户 ID、知识库 IDchunk 表块 ID、文档 ID、块内容text、标题、页码、token 数、是否有效chunk_meta层级路径如 “第一章→1.1”、关键词、来源页码2.MinIO/S3 写入原始文件 图片原始 PDF/Word 原封不动存用于 “查看原文”块里包含的图片 → 转 jpeg → 存 MinIO → 记录 img_id 到 chunk 表一句话MySQL 管 “块的属性”MinIO 管 “原始文件和图片”。子步骤 2生成稠密向量Dense Embedding目的做语义检索解决“意思相似但词不一样”对每个 chunk.content 调用 Embedding 模型支持BGE-M3、text-embedding、GLM-Embedding、Jina 等输出固定长度浮点数组如 1024 维特点一块 → 一个向量语义越近向量距离越近子步骤 3生成稀疏向量BM25→ 全文索引目的做关键词精确匹配解决“专业术语、编号、人名”RAGFlow 用 ES/Infinity 内置 BM25不需要你自己算稀疏向量直接把 chunk.content 写入 ES 的 text 字段ES 自动分词 → 建倒排索引 → 支持 BM25 打分一句话稠密向量管语义BM25 管关键词。子步骤 4向量 全文索引 写入同一引擎ES/Infinity/Milvus核心设计一个索引存所有不用跨库以 Elasticsearch 为例RAGFlow 默认每个 chunk 对应一条 ES 文档{“chunk_id”: “xxx”,“doc_id”: “yyy”,“content”: “RAGFlow 混合存储…”,“title”: “混合存储”,“vector”: [0.123, 0.456, …], // 稠密向量“create_time”: “2026-04-25”}vector 字段向量索引用于语义检索content 字段text 索引用于 BM25 全文检索同库同索引检索时一次请求同时拿两种结果子步骤 5建立关联 缓存Redis目的加速检索、避免重复计算MySQL ↔ ES 关联靠 chunk_id 双向映射ES 查出来 → 用 chunk_id 去 MySQL 拿标题、页码、层级路径Redis 缓存缓存热门 chunk 的向量、内容缓存检索结果减少 ES 查询压力Q:Elasticsearch怎么存储 稠密向量和稀疏向量的vector 字段存储ES自动计算详细如下这个向量不是一个预先画好的图而是一个实时生成的成绩单稀疏向量 一个很长的表格每行代表一个文档每列代表一个关键词每个格子里要么是0没这个词要么是BM25算出来的重要性分数有这个词。它的特点是格子特别多几十万个关键词但每个文档里非零的格子特别少只有几个词有分数。就像一个超级大的Excel表格里面几乎全是0只有零星几个数字ES就靠这些零星数字来快速找到你想搜的文档。第二阶段检索流程用户提问→精准答案步骤6用户提问解析• 操作接收自然语言问题做意图识别关键词提取问题向量化可配置问题改写如扩写、拆解多轮。意图识别是怎么做的• 为什么这么做用户问题常简短/口语化/歧义多——向量化匹配语义关键词补精准改写优化检索词提升召回率。• 优点口语化/歧义问题适配强多轮问题可拆解检索输入质量高。• 缺点改写规则需调优意图识别不准会误导检索。步骤7多路召回混合检索核心• 操作a. 向量检索问题向量查向量库返回 Top-K 语义相似分块b. 全文检索关键词查 Elasticsearch返回 Top-K 匹配分块c. 结果合并去重保留双路高相关分块。• 为什么这么做向量检索擅长「意思对但词不同」如「营收」vs「收入」全文检索擅长「关键词精准匹配」如专有名词、编号两者互补召回更全、更准。• 优点召回率比单路高 20%兼顾语义与精准覆盖歧义/专业术语场景。• 缺点双路检索增加耗时结果合并需去重逻辑复杂。步骤8重排序Rerank• 操作召回结果送入重排模型如 BGE-Rerank、Cross-Encoder逐对计算问题与分块的语义相关性重新排序取 Top-N 最相关分块如 3-5 块。• 为什么这么做召回阶段为保全会返回较多噪声重排模型做细粒度相关性打分过滤无关、排准顺序给 LLM 高质量上下文减少幻觉、提升答案精准度。• 优点上下文质量显著提升幻觉率降低 30%排序更贴合用户问题。• 缺点重排模型耗时/成本高模型选择影响大Top-N 数量需调优。步骤9提示词构建与 LLM 生成• 操作把「用户问题Top-N 重排分块引用来源模板」拼接成提示词调用 LLMOpenAI/Qwen/ChatGLM/本地模型生成答案强制引用分块来源页码/文档名支持流式输出。• 为什么这么做LLM 强于语言生成但易幻觉用检索到的真实文档上下文约束生成让答案「有据可依」引用来源提升可信度便于核查。• 优点幻觉大幅抑制答案精准、可追溯支持多轮对话、流式输出。• 缺点提示词长度有限LLM 上下文窗口长文档需控制分块数量LLM 成本/响应时间依赖模型。第三阶段系统核心能力与整体优缺点核心能力区别于普通 RAGDeepDoc 深度解析表格/扫描件/结构文档解析强信息保留完整。可控分块模板语义可视化调整分块不割裂、信息全。混合检索向量全文重排召回准、噪声少。可追溯生成答案必带引用来源可信度高、可核查。低门槛可视化拖拽式流程、模板化配置非开发者可上手。整体优点• 全链路一体化从解析到生成一站式无需拼接多开源组件部署简单。• 企业级适配权限、多用户、异步队列、可观测性齐全适合生产环境。• 中文优化好默认 BGE 中文模型中文语义理解强适配国内场景。• 开源可自部署Apache 2.0 协议可私有化部署数据安全可控。整体缺点• 资源消耗高解析、嵌入、重排都耗 CPU/GPU小机器部署慢。• 复杂度高多组件ES/Milvus/PostgreSQL依赖运维有门槛。• 定制成本垂直场景医疗/法律需调优模板、分块策略、提示词。• 幻觉仍存在复杂问题、长上下文、跨文档推理仍有幻觉需持续优化。总结RAGFlow 的核心逻辑是用 DeepDoc 保住文档结构与细节 → 用可控分块平衡完整与精准 → 用混合检索重排拿到高质量上下文 → 用带引用的生成抑制幻觉。每一步都在解决传统 RAG「解析浅、分块乱、检索偏、幻觉重」的痛点代价是更高的资源消耗与复杂度换来企业级可用、精准、可追溯的知识库问答能力。需要我把以上流程整理成一份可直接执行的部署与调优清单包含硬件配置建议、关键参数默认值与调优范围、常见问题排查步骤吗
