• 请不要在回答技术问题时复制粘贴 AI 生成的内容
cxd8190102
V2EX  ›  程序员

分享一些在 AI 解析中常见的问题,以及工具区别

  •  
  •   cxd8190102 · 10h 4m ago · 438 views

    上周我分享了一个自己做的小项目,已经在 Github 上拿下 1000star 了(到这周是 1500+了),后面有人问我,觉得我做的东西跟 MinerU 好像啊,是不是在重复造轮子? https://www.v2ex.com/t/1219941?p=1#reply2

    所以今天分享一下在 AI 时代做解析可能会遇到的一些问题,以及工具之间的区别。

    首先叠个甲啊,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 消耗更低,完成任务更快。算是又省钱又高效了。

    https://i.imgur.com/CzADhlZ.png

    原因也不复杂。

    如果 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

    2 replies    2026-06-20 22:33:43 +08:00
    nofishing
        1
    nofishing  
       5h 22m ago
    非常棒的想法和设计,感觉也是非常有潜力的一个工具。数据能够 AI-ready ,最重要的是数据治理,这个工具能够提供的是一个通用的第一步的数据治理,与行业无关。这种粗粒度的处理,面向的是通用 Agent ,那么对于垂类 Agent ,如何提供更精细的数据?是否能够提供良好易用的接口,或者是设计一种专有的数据格式,让专业人士很方便地二次加工治理专业领域的数据?一个非常有价值的场景是生物医药领域。
    nofishing
        2
    nofishing  
       5h 21m ago
    @nofishing 胡扯了几句,等节后上班好好研究下,issue 区交流
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   831 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 19:55 · PVG 03:55 · LAX 12:55 · JFK 15:55
    ♥ Do have faith in what you're doing.