网站建设的主要工作网站设计 网站建设 手机网站建设

网站建设的主要工作,网站设计 网站建设 手机网站建设,有哪些可以做头像的网站,做公众号推文的网站RAGFlow 主要解决文档检索和生成中的准确性问题。 MIRIX 则是一个 多代理个人助理框架#xff0c;基于 LLM 的多代理记忆系统。 Chunk #x1f680; 流程实例#xff1a;以一份 PDF 财务报告为例 假设用户向 RAGFlow 上传了一份 2024 年 Q1 的公司财务报告 PDF#xff0c;并…RAGFlow 主要解决文档检索和生成中的准确性问题。MIRIX 则是一个 多代理个人助理框架基于 LLM 的多代理记忆系统。Chunk 流程实例以一份 PDF 财务报告为例假设用户向 RAGFlow 上传了一份2024 年 Q1 的公司财务报告 PDF并希望提问相关数据。整个流程分解如下阶段概念/操作解释 (前因后果)I. 前因原始数据原始文档(Source Document)一份完整的、非结构化或半结构化的 PDF 报告包含封面、目录、多页文本、表格、图表等。II. 核心切块 (Chunking)Chunking 过程RAGFlow 的核心工作。它使用预先选择的切块模板例如针对表格的模板来解析 PDF并执行以下操作1.深度理解识别出表格的边界、标题和每行数据。2.智能切分将表格的一行数据或一个独立的段落切分成一个Chunk。III. 后果 1Chunk 结果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 进行统一处理融合 (Fusion)将所有路径的结果合并到一个列表中。重排 (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 版本或者在代码中 importipex_llm才能榨干 Intel 硬件的性能。场景 D你需要在生产环境上线一个服务预计每秒有 1000 人同时访问选择Triton (配合 vLLM 或 TensorRT-LLM)理由这种时候 Ollama 会卡死Xinference 可能也会有瓶颈。你需要 Triton 强大的调度能力和显存管理能力来保证高并发下的低延迟。总结对照表特性OllamaXinferenceIPEX-LLMTriton核心定位个人/开发者工具全栈模型部署框架Intel 硬件加速库工业级推理服务器上手难度⭐ (极简)⭐⭐ (简单)⭐⭐⭐ (需改代码/配置)⭐⭐⭐⭐⭐ (困难)模型支持主打 LLM (GGUF)LLM 图片 音频 向量PyTorch 模型所有主流 AI 框架硬件倾向Apple Silicon, NV卡, CPUNV卡 (推荐), CPUIntel 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用于市场分析。原始文件不变。持有文件的引用。使用“QA 切块模板”和“中英文嵌入模型”进行切块和向量化。-3. 链接 B将文件链接到数据集 B用于财务检索。原始文件不变。持有文件的引用。持有文件的引用。使用“表格切块模板”和“财务专业嵌入模型”进行切块和向量化。4. 检索用户在 RAGFlow 中选择数据集 A 或 B 进行提问。原始文件不变。在中英文向量空间中搜索 QA 风格的 Chunks。在财务向量空间中搜索表格风格的 Chunks。结果的优势高效性原始文件只存储了一次在核心文件系统。灵活性同一个文件可以应用不同的 RAG 策略不同的切块模板和嵌入模型来适应不同的业务需求。安全性如果您决定删除数据集 A只会删除 A 中生成的切块和向量原始文件仍保留在核心文件系统中可以继续供数据集 B 使用。Chunklayout, 框这是一个非常好的问题因为这是理解 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 独立地回答问题”核心区别实例假设表格内容是产品价格交付日期软件授权$100002025/12/31❌ 错误的切块简单画框如果 Chunk 只是简单地复制表格行 1 的内容“软件授权 | $10000 | 2025/12/31”那么检索时 LLM 就会困惑这是什么的价格✅ RAGFlow 智能切块语义关联RAGFlow 的切块模板会利用 Layout 模型的结构信息生成一个语义丰富的 ChunkChunk 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 处理了您的 ChunkChunk 文本关键词索引中的记录召回机制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 模型和多种切块模板。但是它仍然无法完美处理所有情况复杂排版许多公司报告使用自定义的、不规则的排版机器很难理解这种人为设计的上下文。知识盲区机器无法知道哪些信息对您和您的团队是最重要的、哪些词语是您的团队内部用来搜索的行话例如“A 计划” 实际上指的是 “核心战略项目 2025”。最终准确性要求对于企业级应用例如法律或财务咨询99.99% 的准确率是必须的。即使是 1% 的切块错误也可能导致客户收到错误信息。⚖️ 智能、效率与准确性的平衡RAGFlow 提供的可视化和干预功能不是为了取代自动化而是为了实现“自动化 专家知识校准”RAGFlow (自动化):负责 95% 的工作大大提高效率。用户 (人工干预):只需检查那 5% 的复杂或关键信息并注入专业的知识和上下文确保最终知识库的最高准确率和检索效果。因此虽然手动干预会浪费少量时间但其带来的检索准确率尤其是对关键知识的提升是巨大的最终保证了用户的信任和更好的问答体验。