之前我分享了一个自己做的小项目，已经在 Github 上拿下 2000 star 了，评论区有人说，觉得我做的东西跟 MinerU 好像啊，是不是在重复造轮子？
我觉得还是不太一样的，今天来分享一下使用场景和区别。
首先叠个甲啊，MinerU 确实是一个很优秀的文档解析工具，它能把 PDF 里的文字、标题、表格、图片等内容提取出来，并转换成 Markdown 。
但问题在于：解析成 Markdown ，并不等于文档已经能被 Agent 理解。
你拿到一份 Markdown 后，通常还要：
把它切成 Chunk ，扔进向量库，然后让 Agent 或 RAG 系统去检索。
听起来很顺，但真正做过的人都知道，坑就在这里。
一份复杂 PDF 原本有章节、有层级、有表格、有图片、有跨页引用。解析成 Markdown 之后，这些结构信息会变弱；再经过切片，每个 Chunk 更像是被切下来的孤立文本片段。
它可能不知道自己属于哪一章，前后文是什么，旁边那张表格在说明什么，相关图片和正文是什么关系。
于是 Agent 检索时，拿到的只是几个“看起来相似”的片段。它不知道"第 3 章第 2 节有一张对比表格，刚才检索到的那段文字其实是对这张表格的说明"。它只能把几个相似度最高的碎片拼在一起，交给 LLM 凑答案。
这就是为什么很多团队用 MinerU 搭 RAG 之后，效果并不是很满意。不是 MinerU 的问题，是文档被打平之后丢失的结构信息，没人帮它找回来。
所以我就在想，能不能做一个更适配 AI Agent 使用的、一步到位的工具，来节省我们的时间呢？
这就是 Knowhere 的由来： https://github.com/Ontos-AI/knowhere
它会帮你把解析出来的文本，继续变成 Agent 可以导航、可以引用、可以推理的长期记忆。
具体方式是这样的：在解析和向量化之间，Knowhere 插入了一个结构重建的流水线：
第一，重建文档层级。
Knowhere 会用树形结构算法恢复文档里的章节关系。每个 Chunk 不再只是一个孤立文本块，而是知道自己在哪个标题下、处于哪一层级、上下文路径是什么。
第二，处理多模态内容。
图片、表格不再只是“附件”或者“丢失的信息”。Knowhere 会对图片做 OCR 和描述，对表格做摘要和结构化处理，并把它们和来源 Chunk 关联起来。这样 Agent 检索时，不只是检索文字，也能拿到相关图表证据。
第三，构建轻量记忆图谱。
当文档被拆成 Chunk 后，Knowhere 会保存导航树、摘要、图谱链接等信息，让文档不再是平铺文本，而是一张可以被 Agent 走动和追踪的知识结构。当你上传多份文档，Knowhere 会在文档之间建立关联，形成一张可导航的跨文档知识图谱。
第四，提供 Agentic Retrieval 。
传统 RAG 更多是向量相似度检索，拿几个片段就交给 LLM 。Knowhere 的检索会融合关键词、路径、内容和语义信号，让 Agent 先发现相关区域，再沿着章节树和图谱链接继续深入，最后返回可溯源的结果。
MinerU 只把 PDF 变成 Markdown 。但 Knowhere 则会把 Markdown 进一步变成 Agent 能用的记忆。
Knowhere 比 MinerU 多做的不是一个小功能，而是把“解析后的文档如何进入 RAG/Agent 系统”这整条链路补齐了。
我们做过内部评测：在相同的 Agentic RAG 任务里，让 Agent 分别基于原始文档、普通 parser 输出，以及 Knowhere 处理后的结构化记忆来完成搜索、修改、问答等任务。使用了 Knowhere 之后，首次准确率提升 36%，召回率提升 11%，有反馈时准确率达到 79%，而直接使用原始文档大约会卡在 53% 左右。以此同时，Agent 循环次数更少，Token 消耗更低，完成任务更快。算是又省钱又高效了。
原因也不复杂。
如果 Agent 面对的是一整坨文本，那它只能盲找。
但如果 Agent 面对的是一棵树、一张图、一组带来源路径的 Chunk ，它就可以像人读文档一样：先看目录，再定位章节，再进入细节。
这就是结构带来的差异。
至于 Knowhere 能用来做什么呢？我觉得，如果你的 AI 应用需要从文档里拿信息，Knowhere 就有用。
比如企业内部知识库——
产品手册、操作规程、FAQ 、培训资料，很多都不是简单文本，而是 PDF 、Word 、PPT 、Excel 混在一起。Knowhere 可以把这些文档处理成 Agent 可检索的结构化记忆。
比如技术文档助手——
设备说明书、API 文档、工程图纸、维护手册，经常又长又复杂。Knowhere 已经支持超长 PDF 和 atlas-style documents ，几百页的技术手册、图纸集合也能走专门的布局感知 parser 。
比如合同和报告分析——
法律文件、财报、招投标文件、研究报告都非常依赖上下文，如果只靠平铺切片，很多引用关系和章节逻辑会丢。Knowhere 的章节路径和证据引用能让结果更稳。
比如 Agentic RAG ——
很多团队现在不是只做“问答”，而是希望 Agent 能基于文档完成多步任务，那就更需要文档本身是可导航的，而不是一堆碎片。
所以说，MinerU 擅长文档解析，它能把 PDF 里的文字、标题、表格、图片等内容提取出来，生成 Markdown 或结构化结果，到这一步对很多开发者来说就足够了。
但如果你的目标是搭 RAG 或 Agent 知识库，解析只是第一步。后面还要做 Chunk 组织、Embedding 、索引入库、检索逻辑、证据引用、文档更新等一整套工作，那么用 Knowhere 就更实在。它不只给你一份解析结果，而是把文档继续处理成可以直接被 Agent 检索和使用的记忆。你不需要再自己额外拼 chunking 、embedding 、向量库、检索 API 这些链路，Knowhere 已经把它们放进同一套流程里。
你只需要装它一个，就能解决从文档读取到接进 AI 应用的全部工作。
如果你也在做相关的 agent 开发或解析工作，那不妨试一下： https://knowhereto.ai/?utm_source=v2ex
我觉得还是不太一样的，今天来分享一下使用场景和区别。
首先叠个甲啊，MinerU 确实是一个很优秀的文档解析工具，它能把 PDF 里的文字、标题、表格、图片等内容提取出来，并转换成 Markdown 。
但问题在于：解析成 Markdown ，并不等于文档已经能被 Agent 理解。
你拿到一份 Markdown 后，通常还要：
把它切成 Chunk ，扔进向量库，然后让 Agent 或 RAG 系统去检索。
听起来很顺，但真正做过的人都知道，坑就在这里。
一份复杂 PDF 原本有章节、有层级、有表格、有图片、有跨页引用。解析成 Markdown 之后，这些结构信息会变弱；再经过切片，每个 Chunk 更像是被切下来的孤立文本片段。
它可能不知道自己属于哪一章，前后文是什么，旁边那张表格在说明什么，相关图片和正文是什么关系。
于是 Agent 检索时，拿到的只是几个“看起来相似”的片段。它不知道"第 3 章第 2 节有一张对比表格，刚才检索到的那段文字其实是对这张表格的说明"。它只能把几个相似度最高的碎片拼在一起，交给 LLM 凑答案。
这就是为什么很多团队用 MinerU 搭 RAG 之后，效果并不是很满意。不是 MinerU 的问题，是文档被打平之后丢失的结构信息，没人帮它找回来。
所以我就在想，能不能做一个更适配 AI Agent 使用的、一步到位的工具，来节省我们的时间呢？
这就是 Knowhere 的由来： https://github.com/Ontos-AI/knowhere
它会帮你把解析出来的文本，继续变成 Agent 可以导航、可以引用、可以推理的长期记忆。
具体方式是这样的：在解析和向量化之间，Knowhere 插入了一个结构重建的流水线：
第一，重建文档层级。
Knowhere 会用树形结构算法恢复文档里的章节关系。每个 Chunk 不再只是一个孤立文本块，而是知道自己在哪个标题下、处于哪一层级、上下文路径是什么。
第二，处理多模态内容。
图片、表格不再只是“附件”或者“丢失的信息”。Knowhere 会对图片做 OCR 和描述，对表格做摘要和结构化处理，并把它们和来源 Chunk 关联起来。这样 Agent 检索时，不只是检索文字，也能拿到相关图表证据。
第三，构建轻量记忆图谱。
当文档被拆成 Chunk 后，Knowhere 会保存导航树、摘要、图谱链接等信息，让文档不再是平铺文本，而是一张可以被 Agent 走动和追踪的知识结构。当你上传多份文档，Knowhere 会在文档之间建立关联，形成一张可导航的跨文档知识图谱。
第四，提供 Agentic Retrieval 。
传统 RAG 更多是向量相似度检索，拿几个片段就交给 LLM 。Knowhere 的检索会融合关键词、路径、内容和语义信号，让 Agent 先发现相关区域，再沿着章节树和图谱链接继续深入，最后返回可溯源的结果。
MinerU 只把 PDF 变成 Markdown 。但 Knowhere 则会把 Markdown 进一步变成 Agent 能用的记忆。
Knowhere 比 MinerU 多做的不是一个小功能，而是把“解析后的文档如何进入 RAG/Agent 系统”这整条链路补齐了。
我们做过内部评测：在相同的 Agentic RAG 任务里，让 Agent 分别基于原始文档、普通 parser 输出，以及 Knowhere 处理后的结构化记忆来完成搜索、修改、问答等任务。使用了 Knowhere 之后，首次准确率提升 36%，召回率提升 11%，有反馈时准确率达到 79%，而直接使用原始文档大约会卡在 53% 左右。以此同时，Agent 循环次数更少，Token 消耗更低，完成任务更快。算是又省钱又高效了。
原因也不复杂。
如果 Agent 面对的是一整坨文本，那它只能盲找。
但如果 Agent 面对的是一棵树、一张图、一组带来源路径的 Chunk ，它就可以像人读文档一样：先看目录，再定位章节，再进入细节。
这就是结构带来的差异。
至于 Knowhere 能用来做什么呢？我觉得，如果你的 AI 应用需要从文档里拿信息，Knowhere 就有用。
比如企业内部知识库——
产品手册、操作规程、FAQ 、培训资料，很多都不是简单文本，而是 PDF 、Word 、PPT 、Excel 混在一起。Knowhere 可以把这些文档处理成 Agent 可检索的结构化记忆。
比如技术文档助手——
设备说明书、API 文档、工程图纸、维护手册，经常又长又复杂。Knowhere 已经支持超长 PDF 和 atlas-style documents ，几百页的技术手册、图纸集合也能走专门的布局感知 parser 。
比如合同和报告分析——
法律文件、财报、招投标文件、研究报告都非常依赖上下文，如果只靠平铺切片，很多引用关系和章节逻辑会丢。Knowhere 的章节路径和证据引用能让结果更稳。
比如 Agentic RAG ——
很多团队现在不是只做“问答”，而是希望 Agent 能基于文档完成多步任务，那就更需要文档本身是可导航的，而不是一堆碎片。
所以说，MinerU 擅长文档解析，它能把 PDF 里的文字、标题、表格、图片等内容提取出来，生成 Markdown 或结构化结果，到这一步对很多开发者来说就足够了。
但如果你的目标是搭 RAG 或 Agent 知识库，解析只是第一步。后面还要做 Chunk 组织、Embedding 、索引入库、检索逻辑、证据引用、文档更新等一整套工作，那么用 Knowhere 就更实在。它不只给你一份解析结果，而是把文档继续处理成可以直接被 Agent 检索和使用的记忆。你不需要再自己额外拼 chunking 、embedding 、向量库、检索 API 这些链路，Knowhere 已经把它们放进同一套流程里。
你只需要装它一个，就能解决从文档读取到接进 AI 应用的全部工作。
如果你也在做相关的 agent 开发或解析工作，那不妨试一下： https://knowhereto.ai/?utm_source=v2ex
5
Select Language