RAGFlow 主要解决文档检索和生成中的准确性问题。
MIRIX 则是一个 多代理个人助理框架，基于 LLM 的多代理记忆系统。

Chunk

🚀 流程实例：以一份 PDF 财务报告为例

假设用户向 RAGFlow 上传了一份 2024 年 Q1 的公司财务报告 PDF，并希望提问相关数据。整个流程分解如下：

阶段 概念/操作 解释 (前因后果)
I. 前因：原始数据 原始文档 (Source Document) 一份完整的、非结构化或半结构化的 PDF 报告，包含封面、目录、多页文本、表格、图表等。
II. 核心：切块 (Chunking) Chunking 过程 RAGFlow 的核心工作。它使用预先选择的切块模板（例如，针对表格的模板）来解析 PDF，并执行以下操作：
1. 深度理解： 识别出表格的边界、标题和每行数据。
2. 智能切分： 将表格的一行数据或一个独立的段落切分成一个Chunk。
III. 后果 1：Chunk 结果 Chunk (切块) 例如，PDF 中一个关于“营收数据”的表格行，被转化为一个 Chunk。这个 Chunk 不仅仅包含表格数据，RAGFlow 还会附加上下文（比如表格的标题、它所属的章节）以增加语义完整性。
IV. 后果 2：嵌入 (Embedding) Embedding (向量化) 嵌入模型将上一步生成的每个 Chunk 文本转化为一个高维向量。
V. 最终用途：检索 (Retrieval) 向量存储 (Vector Store) 所有的 Chunk 向量被存储在 Elasticsearch 或 Infinity 中。
当用户提问（如：“一季度软件服务的营收是多少？”）时，问题也会被向量化，然后在向量存储中快速找到语义最相似的 Chunk（包含“一季度”、“软件服务”、“营收”信息的 Chunk）。

🔍 结论：Chunk 的作用

Chunk 的质量直接决定了 RAG 的可用性。

  • 如果 Chunk 太大： 它可能包含太多不相关的信息，稀释了关键语义，导致检索不精确。
  • 如果 Chunk 太小： 它可能破坏一个完整的语义单元（例如，将表格的一行数据分成了两半），导致 LLM 无法获得完整上下文来生成准确的答案。

RAGFlow 强调切块模板和可视化干预，就是为了让用户能最大限度地优化这个 Chunking 过程，从而确保 LLM 接收到的信息是高质量且完整的。

多路召回（Multiple Recall）？

实例解释：查找“销售额”

我们以一个包含公司年报的 RAGFlow 知识库为例。

假设用户提出了一个问题：

用户查询： “2023 年 Q4 软件服务的营收是多少？”

1. 单一召回的局限性

如果只使用向量召回（语义搜索），系统可能会出现偏差：

  • 问题： 用户问的是“营收”，但向量模型可能会检索到语义相似的词，如“利润”、“净收入”等，而错过了精确包含“营收”这个关键词的表格数据。
  • 结果： 找到了很多关于公司财务情况的定性描述（文本），但没有找到精确的数字（表格）。

2. 多路召回的运作方式

RAGFlow 的多路召回会同时发起至少三种类型的查询：

召回路径 (Path) 策略类型 作用和搜索目标 检索结果（示例 Chunk）
路径一 向量召回 (Vector Recall) 侧重语义相似度。将用户查询向量化，搜索所有语义上最接近“2023 年 Q4 软件服务”的 Chunks。 Chunk A (文本描述): “2023 年第四季度，我们的软件服务增长势头强劲，是核心收入驱动力…”
路径二 关键词召回 (Keyword Recall) 侧重精确匹配。在 Elasticsearch 中搜索精确包含 “2023”、“Q4”、“软件服务”、“营收” 等关键词的 Chunks。 Chunk B (表格行): "软件服务
路径三 结构化召回 (Structured Recall) 侧重结构化信息。针对被 RAGFlow 识别的表格或问答结构，执行特定的结构查询（如果支持）。 Chunk C (表格元数据): 直接从识别的表格中定位到 2023 Q4 对应的“软件服务”行。

3. 结果融合与重排 (Fusion and Re-ranking)

最后一步，系统会对这三条路径返回的全部 Chunks 进行统一处理：

  1. 融合 (Fusion)： 将所有路径的结果合并到一个列表中。
  2. 重排 (Re-ranking)： 使用一个更强大的模型或算法（例如，混合评分算法）对合并后的 Chunks 再次进行排序。

通过这个过程，即使关键词召回（路径二）找到了最准确的数字表格，它也能确保最终被送给 LLM 的信息列表中，精确包含答案的 Chunk B 能排在最前面。

最终结果： LLM 接收到最相关的 Chunks (包含精确的 1.2 亿美元数据)，从而生成一个准确且有数据支撑的回答。

Ollama IPEX-LLM Xinference

部署本地大模型是目前非常热门的话题，Ollama、Xinference、IPEX-LLM 实际上处于大模型部署生态中不同的“生态位”，而 Triton 则属于工业级的“重武器”。

为了让你更直观地理解，我们可以把部署大模型比作**“开一家餐厅（提供模型服务）”**。

一、 三者角色的核心区别

1. Ollama：极简的“自动售货机”

  • 定位： 面向开发者和个人用户的极简桌面级工具。

  • 特点：

    • 傻瓜式： 下载 -> 安装 -> ollama run llama3，一键搞定。
    • 轻量： 主要依赖 GGUF 格式（量化模型），对显存要求低，CPU 也能跑得不错。
    • 生态： 社区非常活跃，很多 WebUI、IDE 插件都首选支持 Ollama。

  • 局限： 主要是为了跑 LLM（对话模型），虽然也支持 Embedding，但对多模态、分布式推理、微调的支持不如专业的全面。

2. Xinference (Xorbits Inference)：全能的“连锁自助餐厅”

  • 定位： 面向企业级开发和数据科学家的全能型推理框架。

  • 特点：

    • 大一统： 不仅支持 LLM，还原生支持 Embedding（向量模型）、Rerank（重排序模型）、Image（绘图）、Audio（语音）。做 RAG（知识库）应用时，这一个框架就能把所有模型服务都包圆了。
    • 后端灵活： 它像一个“中介”，底层可以自动调用 vLLM、CTranslate2、GGUF 等不同的推理引擎。
    • 分布式： 支持多机多卡，如果你有两台电脑，想连起来跑一个大模型，Xinference 原生支持。

  • 局限： 安装和配置比 Ollama 稍微复杂一点点（需要 Python 环境），资源占用相对高一些。

3. IPEX-LLM (Intel Extension for PyTorch)：专属的“发动机加速器”

  • 定位： Intel 硬件专用的加速库。

  • 特点：

    • 它不是一个服务器： 严格来说，它不是像 Ollama 那样直接给你提供 API 的服务软件，而是一个库（Library）。
    • 化腐朽为神奇： 它的作用是让 PyTorch 模型在 Intel 的 CPU（如酷睿 Ultra）、集成显卡（Intel Arc 核显）和 独立显卡 上跑得飞快。
    • 兼容性： 你可以在 Ollama 或 Xinference 的底层使用 IPEX-LLM 来加速（如果你的电脑是 Intel 芯片）。

  • 局限： 如果你用的是 NVIDIA (N卡) 或 AMD 显卡，这个跟你没关系。

二、 它们与 NVIDIA Triton 的关系

Triton Inference Server (NVIDIA) 是这里的“老大哥”，属于工业级/数据中心级的“中央厨房”。

  • 关系：

    • Ollama/Xinference 是为了易用性而设计的，它们牺牲了一些极致的并发性能，换取了“好部署、好管理”。
    • Triton 是为了极致吞吐量和稳定性设计的。

  • 主要区别：

    • Triton 的强项： 动态批处理（Dynamic Batching，同时处理几百个人的请求）、多模型并发、支持 TensorRT 极致加速。它通常用于像 ChatGPT 官网、京东客服这种高并发的生产环境。
    • Triton 的缺点： 配置极其痛苦（写 config.pbtxt），学习曲线陡峭。对于本地单用户来说，用 Triton 属于“杀鸡用牛刀”，而且这把牛刀还很重，拿不动。

三、 实际使用场景与选择建议

为了帮你选择，我构建了几个典型的实际场景：

场景 A：程序员/学生，想在 MacBook 或 游戏本上试玩 Llama3，写代码辅助
  • 选择：Ollama
  • 理由： 你不需要配置 Python 环境，不想折腾依赖库。下载完就能用，配合各类插件（如 VSCode 的 Continue 插件）无缝集成。
场景 B：你需要开发一个 RAG（企业知识库）应用
  • 选择：Xinference
  • 理由： RAG 不仅需要对话模型，还需要 Embedding 模型把文档变成向量，需要 Rerank 模型优化搜索结果。Xinference 可以用一套 API 同时启动这三种模型，管理起来非常方便，而且兼容 OpenAI 格式 API，代码改动小。
场景 C：你的公司买了一批 Intel 的服务器，或者是新的 Intel Core Ultra 笔记本
  • 选择：IPEX-LLM (作为底层)
  • 理由： 如果直接用普通的 PyTorch 或 Ollama 的默认后端，Intel 显卡可能无法调用或速度很慢。你需要安装集成了 IPEX-LLM 的 Ollama 版本，或者在代码中 import ipex_llm，才能榨干 Intel 硬件的性能。
场景 D：你需要在生产环境上线一个服务，预计每秒有 1000 人同时访问
  • 选择：Triton (配合 vLLM 或 TensorRT-LLM)
  • 理由： 这种时候 Ollama 会卡死，Xinference 可能也会有瓶颈。你需要 Triton 强大的调度能力和显存管理能力来保证高并发下的低延迟。

总结对照表

特性 Ollama Xinference IPEX-LLM Triton
核心定位 个人/开发者工具 全栈模型部署框架 Intel 硬件加速库 工业级推理服务器
上手难度 ⭐ (极简) ⭐⭐ (简单) ⭐⭐⭐ (需改代码/配置) ⭐⭐⭐⭐⭐ (困难)
模型支持 主打 LLM (GGUF) LLM + 图片 + 音频 + 向量 PyTorch 模型 所有主流 AI 框架
硬件倾向 Apple Silicon, NV卡, CPU NV卡 (推荐), CPU Intel CPU/GPU 专用 NVIDIA GPU 专用
适合场景 本地测试、AI 助手 搭建复杂 AI 应用 (RAG) Intel 设备加速 高并发生产环境

一句话建议：
如果你是个人玩，闭眼选 Ollama；如果你要搞开发做系统，选 Xinference；如果你是 Intel 硬件受害者（或受益者），务必带上 IPEX-LLM；如果你要抗住高并发流量，再去研究 Triton。

数据集和核心文件系统

实例说明：一个文件，两个数据集

假设您有一个包含 2024 年 Q1 和 Q2 销售数据的 PDF 文件，文件名为 Sales_Report_2024.pdf。

步骤 操作 核心文件系统 数据集 A (市场分析) 数据集 B (财务检索)
1. 上传 将 Sales_Report_2024.pdf 上传到 RAGFlow。 原始文件被安全存储在这里。 - -
2. 链接 A 将文件链接到数据集 A（用于市场分析）。 原始文件不变。 持有文件的引用。使用 “Q&A 切块模板” 和 “中英文嵌入模型” 进行切块和向量化。 -
3. 链接 B 将文件链接到数据集 B（用于财务检索）。 原始文件不变。 持有文件的引用。 持有文件的引用。使用 “表格切块模板” 和 “财务专业嵌入模型” 进行切块和向量化。
4. 检索 用户在 RAGFlow 中选择数据集 A 或 B 进行提问。 原始文件不变。 在中英文向量空间中搜索 Q&A 风格的 Chunks。 在财务向量空间中搜索表格风格的 Chunks。

结果的优势：

  1. 高效性： 原始文件只存储了一次（在核心文件系统）。
  2. 灵活性： 同一个文件可以应用不同的 RAG 策略（不同的切块模板和嵌入模型）来适应不同的业务需求。
  3. 安全性： 如果您决定删除数据集 A，只会删除 A 中生成的切块和向量，原始文件仍保留在核心文件系统中，可以继续供数据集 B 使用。

Chunk，layout, 框

这是一个非常好的问题，因为这是理解 RAGFlow 这种深度文档理解型 RAG 引擎的关键。

我们通过一个具体的合同文件实例，来清晰区分 Layout 模型 检测出的“框”和最终的 Chunk (切块)。

📄 实例：合同文件中的一个条款和表格

假设我们有一个 PDF 格式的合同文件，其中包含一个条款和一张相关的简单表格。

1. Layout 模型：检测“框” (结构边界)

Layout 模型 的工作是纯粹的机器视觉任务，它像一个高效的机器人视觉系统，只关注文档在页面上的物理排版和结构边界。

Layout 模型检测出的“框” (Boxes) 目的（机器视觉） 核心问题
条款文本框 识别这是一个“文本段落”区域。 “这个区域的边界在哪里？”
表格标题框 识别这是表格的“标题”或“标签”。 “这是什么类型的元素？”
表格行/单元格框 识别表格中每个单元格的内容和边界。 “这个表格是如何分割的？”

结果： Layout 模型输出了一堆带有坐标的“框”，告诉 RAGFlow 哪里是标题，哪里是正文，哪里是表格。

2. Chunking (切块)：创建“语义单元”

Chunking 过程（由 RAGFlow 的切块模板驱动）是一个知识工程任务，它使用 Layout 模型的结果作为输入，目标是创建具有完整语义的知识片段 (Chunk)。

RAGFlow 切块的“语义单元” (Chunk) 目的（知识工程） 核心问题
Chunk 1：条款文本 将整个条款文本作为一个独立 Chunk。 “这个段落的语义是什么？”
Chunk 2：表格行 1 关键区别点： 它会结合表格标题和该行内容，创建一个 Chunk。 “如何让这个 Chunk 独立地回答问题？”

核心区别实例

假设表格内容是：

产品 价格 交付日期
软件授权 $10000 2025/12/31
❌ 错误的切块（简单画框）

如果 Chunk 只是简单地复制表格行 1 的内容 “软件授权 | $10000 | 2025/12/31”，那么检索时 LLM 就会困惑：这是什么的价格？

✅ RAGFlow 智能切块（语义关联）

RAGFlow 的切块模板会利用 Layout 模型的结构信息，生成一个语义丰富的 Chunk：

Chunk Text (用于 Embedding)： “这是合同附件 3 中的表格行。产品：软件授权，价格：10000 美元，交付日期：2025 年 12 月 31 日。”

🌟 总结：从“框”到“Chunk”的转变

特征对比 Layout 模型检测出的“框” RAGFlow 最终的 “Chunk”
本质 物理结构边界（像素和坐标）。 逻辑语义单元（文本和上下文）。
作用 输入：提供文档的排版指导。 输出：用于向量化和检索的最小知识单位。
内容 孤立的文本或数据。 融合了上下文和结构信息的完整语句。
目标 识别**“是什么元素”**。 确保 Chunk 能够独立回答**“为什么”和“是什么意思”**。

结论： Layout 模型画出的“框”是 RAGFlow 智能切块的原材料，而 Chunk 才是经过 RAGFlow 知识工程加工后的“成品”，这个成品具有完整的语义，可以直接交给 LLM 使用。

2. 什么是关键词索引（Full-Text/Keyword Index）？

关键词索引是支撑多路召回（Multiple Recall） 中的全文搜索那一路的关键。

实例：关键词索引

假设 RAGFlow 处理了您的 Chunk：

Chunk 文本 关键词索引中的记录 召回机制
Chunk Text: “核心产品营收 软件服务 2024 Q1 1.2 亿…” 核心、产品、营收、软件、服务、2024、Q1、1.2、亿 用户查询 “2024 Q1 软件营收” 时，系统在 关键词索引 中进行精确匹配，找到包含这四个词的 Chunk，并给予高分。

作用： 确保当用户使用精准词语（如日期、产品名称、特定术语）提问时，系统能迅速且准确地找到对应的 Chunk。这是对向量召回（语义搜索） 的有效补充。

3. 手动修改 Chunk 文本具体指什么？

手动修改主要有三种形式，旨在修复机器切块的边界错误或语义缺失：

手动干预类型 实例 为什么需要（机器不智能）
1. 边界修正（合并/拆分） 机器切分错误： 机器将一个完整的句子：“公司今年决定…（换行）…重点投资 AI 领域。”切成了两个 Chunk。
人工操作： 双击第一个 Chunk，将第二个 Chunk 的文本复制过来，合并成一个完整的句子。		 机器擅长视觉分析，但对复杂的跨页、跨段的语义衔接判断容易出错。
2. 上下文补充 机器切分结果： 一个表格 Chunk 只有数据，没有标题。
人工操作： 手动在 Chunk 文本开头添加：“以下是 2024 年 Q1 软件服务的营收数据。”		 确保每个 Chunk 语义自洽。如果 Chunk 缺失关键上下文，LLM 可能会误解数据。
3. 元数据/关键词注入 Chunk 内容： 描述了公司的“Llama 3 部署项目”。
人工操作： 双击 Chunk，手动添加关键词/标签：“大模型”、“关键项目”、“战略级”。		 增强检索效果。许多关键词（如“战略级”）并未在文本中，但用户会用它来搜索。

4. 人工干预：太不智能？浪费时间？用户体验不好？

您的顾虑是完全正确的。在理想情况下，我们希望机器完全自动化，但这在处理非结构化文档时是一个现实的取舍。

🤖 为什么 RAGFlow 仍然需要人工干预？

RAGFlow 已经比许多简单的 RAG 工具“智能”得多（因为它有 Layout 模型和多种切块模板）。但是，它仍然无法完美处理所有情况：

  1. 复杂排版： 许多公司报告使用自定义的、不规则的排版，机器很难理解这种人为设计的上下文。
  2. 知识盲区： 机器无法知道哪些信息对您和您的团队是最重要的、哪些词语是您的团队内部用来搜索的行话（例如，“A 计划” 实际上指的是 “核心战略项目 2025”）。
  3. 最终准确性要求： 对于企业级应用，例如法律或财务咨询，99.99% 的准确率是必须的。即使是 1% 的切块错误，也可能导致客户收到错误信息。

⚖️ 智能、效率与准确性的平衡

RAGFlow 提供的可视化和干预功能，不是为了取代自动化，而是为了实现 “自动化 + 专家知识校准”：

  • RAGFlow (自动化): 负责 95% 的工作，大大提高效率。
  • 用户 (人工干预): 只需检查那 5% 的复杂或关键信息，并注入专业的知识和上下文，确保最终知识库的最高准确率和检索效果。

因此，虽然手动干预会浪费少量时间，但其带来的检索准确率（尤其是对关键知识）的提升是巨大的，最终保证了用户的信任和更好的问答体验。

这是一个非常好的问题，因为 DLR (Document Layout Recognition) 和 Layout 模型 是同一个概念体系中的不同术语，它们之间存在着强烈的联系，几乎可以视为同一件事。

让我们来详细解释 DLR 的含义，并通过实例说明它与 Layout 模型的关系。

1. DLR (Document Layout Recognition) 的含义

DLR（文档布局识别） 是一种计算机视觉和文档智能技术，其核心任务是理解和解析文档的视觉和逻辑结构。

核心目标

DLR 的目标是识别文档页面上的每一个元素，并确定它们之间的关系和功能。它回答了以下问题：

  1. 这个区域是做什么用的？ (例如：标题、正文段落、脚注、图片说明)
  2. 这些区域之间的关系是什么？ (例如：哪个标题属于哪个段落？这个表格属于哪个章节？)
  3. 阅读顺序是什么？ (例如：从左到右，从上到下，或者在多栏布局中如何跳转)

实例：年报的 DLR

假设 RAGFlow 正在处理一份 PDF 格式的公司年报：

DLR 识别出的元素 对应的布局识别结果 对 RAGFlow 的价值
视觉元素 页面中央的粗体大字是主标题；右下角的小字是页码；左侧一栏是目录；右侧是正文。 RAGFlow 知道哪些文本是重要的（标题），哪些是需要忽略的（页码、页眉）。
逻辑结构 识别出“执行摘要”是一个一级标题；紧随其后的三个段落是其正文内容；接下来的“财务表现”是另一个一级标题。 RAGFlow 可以确保切块（Chunking）时，来自“执行摘要”段落的文本，会带着**“执行摘要”的上下文和元数据**。

2. DLR 和 Layout 模型的关系

在 RAGFlow 的语境中，以及整个 AI 文档处理领域：

Layout 模型是实现 DLR 任务所使用的“工具”或“模型”。

术语 含义 角色
DLR (文档布局识别) 任务/目标：识别并理解文档的结构和语义。 目的：我们想要做什么。
Layout 模型 (如 DeepDoc) 工具/技术：实现 DLR 任务的深度学习模型。 手段：我们用什么技术来做。

它们是一回事吗？

  • 在操作层面，当技术人员说“模型正在进行 Layout 检测”时，他们通常指的就是在执行 DLR 任务。
  • RAGFlow 提到的 DeepDoc 就是一个执行 DLR、OCR 和 TSR 任务的视觉模型（Layout Model）。

总结 RAGFlow 的数据提取任务

RAGFlow 提供的 DeepDoc 选项，实际上执行了三个相互关联的任务：

  1. OCR (Optical Character Recognition): 字符识别（将图片中的文字转化为可编辑文本）。
  2. TSR (Table Structure Recognition): 表格结构识别（识别表格的行、列和单元格关系）。
  3. DLR (Document Layout Recognition): 文档布局识别（识别标题、段落、列表、图表等文档的逻辑结构）。

这三个任务的结果共同作为输入，指导 RAGFlow 的 Chunking（切块） 引擎，确保切块是语义完整、结构准确的。

“Page Rank”（页面权重/数据集优先级）

如果您的聊天助手从“数据集 A (2024 年新闻)”和“数据集 B (2023 年新闻)”中获取信息，但您希望优先使用 2024 年的新闻，那么这个功能就非常有用。

评分机制（Scoring mechanism）

这段是最核心的技术解释，说明 Page Rank 如何影响最终的检索结果。

If you configure a chat assistant’s similarity threshold to 0.2, only chunks with a hybrid score greater than 0.2 x 100 = 20 will be retrieved and sent to the chat model for content generation. This initial filtering step is crucial for narrowing down relevant information.

【前置知识：混合得分与阈值】

  • RAGFlow 使用混合得分（Hybrid Score） 来评估 Chunk 的相关性（结合了向量相似度和关键词权重）。
  • 阈值作用： 如果相似度阈值设置为 0.20.20.2，则只有混合得分高于 0.2×100=200.2 \times 100 = 200.2×100=20 的 Chunk 才能进入下一步处理。

If you have assigned a page rank of 1 to dataset A (2024 news) and 0 to dataset B (2023 news), the final hybrid scores of the retrieved chunks will be adjusted accordingly. A chunk retrieved from dataset A with an initial score of 50 will receive a boost of 1×100=1001 \times 100 = 1001×100=100 points, resulting in a final score of 50+1×100=15050 + 1 \times 100 = 15050+1×100=150. In this way, chunks retrieved from dataset A will always precede chunks from dataset B.

【Page Rank 提升机制】

  • 提升计算： 提升的分数是 Page Rank 值 ×100\times 100×100。
  • 实例：
    • 数据集 A (Page Rank=1): 初始得分为 505050 的 Chunk，最终得分 = 50+(1×100)=150=\ 50 + (1 \times 100) = 150= 50+(1×100)=150。
    • 数据集 B (Page Rank=0): Page Rank 为 0，得分不变，仍为 505050。
  • 效果： 通过这种直接分数叠加的方式，Page Rank 值越高的 Chunk，其最终得分也会越高，从而在最终的检索列表中获得优先排序（如示例中，数据集 A 的 Chunk 会排在数据集 B 的 Chunk 之前）。

Auto-keyword Auto-question

场景实例：客服问答手册

假设 RAGFlow 正在处理一份关于“耳机保修政策”的文档，并且我们已经将其切块（Chunking）。

📄 原始知识片段 (Chunk)

Chunk ID 原始文本
C-501 “在正常的磨损和使用条件下，所有 TWS 耳机产品提供自购买之日起 12 个月的有限保修。保修范围不包括人为损坏或液体接触。”

1. 自动关键词（Auto-keyword）的作用

这个功能用于纠正错误和增强检索准确性。它通过 LLM 为 Chunk 添加同义词和相关术语。

💡 解决的问题：同义词和术语不匹配

用户可能会使用非官方术语提问。

用户查询 原始 Chunk C-501 Auto-keyword 增强 检索结果
“耳塞坏了能修吗？” Chunk 文本：没有“耳塞”、“修”等词。检索可能失败或排名靠后。 LLM 添加：耳塞、维修、免费更换、1年质保 成功！ 查询词匹配了 LLM 生成的关键词 维修 或 耳塞，Chunk 得分提高，被检索出来。
Auto-keyword 运作方式

LLM 接收 C-501 原始文本，并基于语义生成 3-5 个关键词（假设配置值是 3-5）。这些关键词被添加到 Chunk 的元数据中，增强了关键词索引。

2. 自动问题（Auto-question）的作用

这个功能用于提高用户查询的匹配度，尤其适用于 FAQ 和政策文档。它通过 LLM 为 Chunk 预设可能的问题。

💡 解决的问题：用户提问形式的多样性

用户可能会以不同的方式提问相同的问题。

用户查询 原始 Chunk C-501 Auto-question 增强 检索结果
“进水保修吗？” Chunk 文本：只提到“液体接触”。 LLM 添加：产品进水是否在保修范围内？、人为损坏是否能享受免费维修？ 成功！ 用户查询的向量与 LLM 生成的问题的向量高度相似，Chunk 被检索出来。
Auto-question 运作方式

LLM 接收 C-501 原始文本，并基于内容生成 1-2 个典型问题（假设配置值是 1-2）。这些问题被向量化后，存储在向量索引中。当用户提问时，系统会拿用户的提问向量去匹配这些自动生成的问题向量，从而实现更强大的语义匹配。

🎯 总结：为什么要使用这两个功能？

功能 核心作用 提升维度 成本（警告）
Auto-keyword 弥补词汇差异：添加同义词、术语。 关键词召回 增加索引时间和 Token 消耗。
Auto-question 弥补句式差异：添加用户可能提出的问题。 向量召回/语义匹配 增加索引时间和 Token 消耗。

这两个功能虽然增加了索引时间和成本，但对于复杂的、用户提问方式多变的场景（如客服 FAQ、技术文档），它们能显著提高 LLM 找到正确信息的概率，从而提升最终问答的准确率和用户体验。

Excel2HTML

场景实例：复杂财务报表

假设您的 RAGFlow 数据集中包含一个复杂的 Excel 文件，其中包含一张年度预算与实际支出对比表，并且有合并单元格来表示大类。

📄 原始 Excel 表格片段

部门 项目类别 (合并单元格) 2024 年预算 (USD) 2024 年实际支出 (USD)
研发部 (合并单元格) 软件授权 50,000 48,000
人力成本 100,000 105,000

1. 禁用 Excel2HTML：键值对表示（Garbled/弄乱）

如果 Excel2HTML 被禁用，RAGFlow 会尝试将表格信息转换为简单的键值对来处理，但它很难处理合并单元格和多层结构。

❌ RAGFlow 生成的 Chunk（禁用 Excel2HTML）

Chunk Text (用于 Embedding)：
“部门: 软件授权, 项目类别: 50,000, 2024 年预算 (USD): 48,000, 2024 年实际支出 (USD): 研发部, 软件授权: 100,000, 2024 年预算 (USD): 105,000”

问题：

  • 信息丢失： “研发部”这个关键信息错位了，它被当作了后面一行的数据。
  • 语义混乱： “软件授权”和“人力成本”失去了它们作为“项目类别”的上下文，键值对的结构被打破，整个文本变得难以理解（garbled）。
  • LLM 无法理解： 当用户提问“研发部的人力成本是多少？”时，LLM 检索到的 Chunk 是一团乱麻，无法给出正确答案。

2. 启用 Excel2HTML：HTML 表格表示（结构保留）

如果 Excel2HTML 被启用，RAGFlow 会将表格转换为 HTML 格式的文本，HTML 格式能完美保留合并单元格和多列的复杂结构。

✅ RAGFlow 生成的 Chunk（启用 Excel2HTML）

Chunk Text (用于 Embedding)：

<table>
  <tr><td rowspan="2">研发部</td><td>软件授权</td><td>50,000</td><td>48,000</td></tr>
  <tr><td>人力成本</td><td>100,000</td><td>105,000</td></tr>
</table>

(在发送给 LLM 之前，这个 HTML 通常会被转化为可读的 Markdown 或更结构化的文本。)

优势：

  • 结构清晰： HTML 标签（如 rowspan="2"）清晰地定义了“研发部”这个标签涵盖了下面两行数据。
  • LLM 理解： 当这段结构化文本发送给 LLM 时，LLM 可以通过其强大的推理能力，准确地理解这是一个表格，并且知道“人力成本”属于“研发部”。
  • 准确检索： 用户提问“研发部的人力成本是多少？”时，LLM 可以从这段结构化文本中准确提取出 $105,000。

结论

方式 适用场景 结果
禁用 Excel2HTML (键值对) 简单、只有两列数据的表格。 复杂表格会弄乱（garbled），影响问答准确性。
启用 Excel2HTML (HTML 表格) 复杂表格（合并单元格、多列等）。 保留结构，确保 LLM 能够准确理解和利用表格数据进行问答。

简而言之，启用 Excel2HTML 就像是给 RAGFlow 提供了一个表格的“蓝图”，而不是一堆散乱的零件，从而解决了复杂表格的解析难题。

TOC

为了让你直观理解 “提取目录（TOC）” 功能的价值，我们用两个非常具体的场景来对比 “普通 RAG” 和 “开启 TOC 增强的 RAG” 的区别。

场景一：员工手册（解决“上下文缺失”问题）

假设你有一份 100 页的公司《员工手册》，里面有两个章节都提到了“请假流程”和“审批人”，但一个是针对普通病假，一个是针对长期停薪留职。

文档结构（目录）：

  • 第 3 章：日常考勤与病假

    • 3.1 申请流程：（内容：向直属经理申请，审批需 1 天）

  • 第 8 章：长期停薪留职

    • 8.1 申请流程：（内容：向 HR 总监申请，审批需 7 天）
用户的提问：“请假审批需要多久？”

1. 普通 RAG（无 TOC）：

  • 检索过程： 系统在文档中切块搜索，可能只找到了切片 A：“审批需 1 天” 和切片 B：“审批需 7 天”。
  • 由于切块很小，切片里可能没有包含“第 3 章”或“第 8 章”的标题信息。
  • LLM 的回答： “根据文档，审批可能需要 1 天，也可能需要 7 天。”（模棱两可，甚至可能把两个混淆，告诉用户病假要找 HR 总监）。

2. 开启 TOC 增强的 RAGFlow：

  • 索引阶段： LLM 已经识别出目录结构，并在切片中打上了标签。

    • 切片 A 标记为：[Context: 第3章 日常考勤与病假]
    • 切片 B 标记为：[Context: 第8章 长期停薪留职]

  • 检索与回答：

    • LLM 能够清晰地看到全局上下文。

  • LLM 的回答： “这取决于您请假的类型。如果是日常病假，根据第 3 章，审批需 1 天；如果是长期停薪留职，根据第 8 章，审批需 7 天。”

  • 价值点： 消除了歧义，精准定位信息的适用范围。

场景二：设备维修手册（解决“切块碎片化”问题）

假设你有一份复杂的《精密仪器维修指南》，其中某一节是关于“故障排查”的，步骤非常长，跨越了多个切块（Chunk）。

文档结构（目录）：

  • 第 5 章：发动机故障

    • 5.2 无法启动排查步骤：

      • （段落 1）：检查电源连接…
      • （段落 2）：检查保险丝…
      • （段落 3）：如果上述无效，重置控制板…
用户的提问：“设备无法启动怎么办？”

1. 普通 RAG（无 TOC）：

  • 检索过程： 系统通过关键词匹配，可能只找到了“无法启动”匹配度最高的**（段落 1）**。
  • 由于 RAG 的切块限制（比如限制了 500 个字符），（段落 2）和（段落 3）因为没有包含“无法启动”这个关键词，或者距离太远，被丢弃了。
  • LLM 的回答： “请检查电源连接。”（回答不完整，用户试了没用就卡住了）。

2. 开启 TOC 增强的 RAGFlow：

  • 检索过程：

    1. 系统首先检索到了（段落 1）。
    2. 关键步骤（TOC 补充）： 系统查看目录结构，发现（段落 1）属于 “5.2 无法启动排查步骤” 这一小节。
    3. 系统自动补全该小节下的所有内容，把（段落 2）和（段落 3）也一起抓取过来，即使它们的关键词匹配度不高。

  • LLM 的回答： “您可以按顺序尝试以下步骤：1. 检查电源连接；2. 检查保险丝；3. 如果都无效，请重置控制板。”

  • 价值点： 保证了逻辑的完整性，防止解决方因切片被截断而“断章取义”。

总结：TOC 增强的核心价值

你可以把普通的 RAG 想象成**“只给你看书里的几句话”，而 TOC 增强则是“不仅给你看那几句话，还告诉你这几句话在目录的哪个位置，并把这一整章的内容都拿给你看”**。

维度 普通 RAG RAGFlow (TOC 增强)
识别能力 见树木不见森林（只看碎片） 既见树木又见森林（知道碎片属于哪一章）
回答质量 容易张冠李戴（把A章节的结论安在B问题上） 逻辑严密，指代清晰
完整性 容易丢失步骤或后续条件 能够根据目录补全缺失的上下文步骤
代价 便宜、快 费钱（Token消耗大）、慢（需要 LLM 预处理）

因此，这个功能对于法律法规、技术文档、复杂的财务报告等逻辑结构性极强的文档，价值巨大。

RAGFlow 实现 TOC（目录）增强功能的“整个链条”，在逻辑上分为两个核心阶段：数据入库阶段（Indexing Phase） 和 检索问答阶段（Retrieval Phase）。

这是一个典型的 “重预处理（Heavy Pre-processing），优检索（Smart Retrieval）” 的架构。

以下是完整的技术实现链条：

第一阶段：数据入库与解析 (Indexing Phase)

这是最消耗资源的一步，也是“TOC 增强”的核心地基。

1. 基础解析 (Raw Parsing)
  • 输入： 用户上传 PDF、Word 等文档。
  • 动作： 系统读取文件，提取出纯文本和基础布局信息。
2. 目录提取 (LLM TOC Extraction) —— 关键步骤

  • 动作： 系统将文档内容（或前几页/结构化信息）发送给配置好的 LLM（大模型）。

  • Prompt 逻辑： 系统会提示 LLM：“阅读这份文档，分析其层级结构，提取出标准的目录树（JSON 格式），包含章节标题和对应的层级关系。”

  • 产出： 一个结构化的**目录树（TOC Tree）**对象。

    • 例如：{ "Chapter 1": { "range": "p1-p5" }, "Chapter 2": { "sub_node": ... } }
3. 切片与元数据注入 (Chunking & Injection) —— 改变了数据的形状

  • 动作： 系统按照常规方式对文本进行切片（Chunking）。

  • 增强逻辑： 在生成切片的同时，系统会将切片与刚才提取的 目录树 进行映射。

  • 数据变形：

    • 普通 Chunk： 内容：...审批流程需3天...

    • TOC 增强后的 Chunk：

      • Content: [Header: 第3章 财务制度 - 3.1 报销流程] ...审批流程需3天... (直接修改文本，注入上下文)
      • Metadata: { "toc_id": "node_3_1", "chapter_title": "财务制度" } (添加元数据标签)
4. 向量化与存储 (Vectorization & Storage)
  • 动作： 将带有目录上下文的 Chunk 转化为向量（Embeddings），并存入向量数据库（如 Elasticsearch/Infinity）。

第二阶段：检索与上下文重组 (Retrieval Phase)

这是用户提问时发生的实时处理过程。

1. 混合检索 (Hybrid Search)
  • 输入： 用户提问“报销要多久？”
  • 动作： 系统在数据库中进行关键词搜索和向量搜索。
  • 结果： 找到若干个零散的 Chunks（例如找到了 Chunk A、Chunk C）。
2. 目录聚合与补全 (TOC Aggregation) —— 关键步骤

这是 TOC 功能发挥“缝合怪”作用的地方：

  • 识别： 系统检查命中的 Chunk A 和 Chunk C 的元数据，发现它们都属于 toc_id: node_3_1（即“第3章-3.1节”）。
  • 判断： 系统判定用户的意图可能涉及整个 3.1 节的逻辑。
  • 补全（Expansion）： 系统不再只返回 A 和 C，而是利用 toc_id 索引，把该节点下缺失的 Chunk B 也一起拉取出来。
  • 重组： 将 A -> B -> C 按顺序拼合，还原成完整的“第 3.1 节”段落。
3. LLM 生成回答 (Generation)
  • 输入： 经过重组的、逻辑连贯的完整章节内容，而非碎片化的句子。
  • 动作： 发送给 Chat Model。
  • 效果： LLM 能够理解“因为是第3章，所以是财务报销”，并且由于 Chunk B 被补全了，中间的逻辑断点被接上了。

为什么这个链条会消耗大量资源？

从上面的流程可以看出：

  1. Token 消耗（索引时）： 在第一阶段，需要把文档喂给 LLM 去生成目录。如果文档有 500 页，这 500 页都要被 LLM “读”一遍，Token 费用很高。
  2. 计算延迟（索引时）： 普通解析只是切分字符串，毫秒级；TOC 解析需要等待 LLM 推理，速度慢很多。
  3. 上下文窗口（检索时）： 在第二阶段，因为系统自动补全了缺失的 Chunk（把整个章节都拉进来了），发送给对话模型的 Prompt 长度会显著增加，导致推理变慢，且更容易触碰 LLM 的上下文窗口限制。

总结

这个功能的本质是：利用 LLM 的理解能力，在数据入库时构建“地图”（TOC），在检索迷路时利用“地图”找回丢失的拼图。

# 人工智能
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

有关LangChain

通过本文，你已经掌握了使用LangChain接入从云端API到本地部署模型的全套方法。无论是简单的对话任务还是复杂的AI应用开发，LangChain都提供了统一而强大的接口。记住，选择云端API还是本地部署取决于你的具体需求：云端API简单快捷，适合大多数应用场景；本地部署则更适合对数据隐私和成本控制有严格要求的场景。在接下来的学习中，我们将深入探讨LangChain的核心组件，包括提示词管理、记

avatar 2048 AI社区

红队 / 蓝队：用 AI 自动生成攻击场景并评估防御效果——从“安全演练”到“可计算的网络对抗系统”

在可编程网络与 IaC（基础设施即代码）深度普及的今天，网络架构的复杂程度早已超越了人力静态审计的极限。然而，我们对网络安全的验证，却仍旧依赖于每年一两次、高度依赖专家经验的“红蓝对抗演练”。未来的网络，将不再是一个等待被攻击的静态靶场，而是一个在 AI 持续对抗中自我修补、自我增强的动态生命体。当我们把红蓝对抗拆解为可计算的攻击路径、可量化的检测指标以及自动化的配置闭环时，我们实际上完成了一场。

avatar 2048 AI社区
cover

学长亲荐8个AI论文平台，本科生毕业论文轻松搞定！

avatar 2048 AI社区