问你一个问题：一套真正给 Agent 使用的文档系统，应该怎样理解一份文件？
最常见的路数是：先把文档解析成文字，再让 Agent 阅读解析结果。
这条路当然有用。排版清楚的 PDF、Word、网页和普通表格，转成文字以后，检索快、引用方便，也容易进一步加工。PAGE-INDEX、MinerU 等方案，走的基本都是这条路线。从OCR开始，这是一条存在了20年的老路。
Knowhere 也有这项能力。
但我们在实际处理各类手册、方案、研报、图纸和复杂表格时，发现一个这条老路的痛点：面对复杂的扫描件、又宽又密的表格、千奇百怪的排版、各种零碎的印章、批注、图片和跨页内容等，再好的解析方法也一定会出错，而一旦出错，这些错误会持续停留在数据库（知识库）中被 Agent 反复消费。就算再怎么训练解析模型，对于真实的复杂场景来说，边际收益已经趋近于0。
这么说吧，现有主要的提取器都在想尽办法给文件画素描，那么就多少一定会失真。
于是，为了让 Knowhere 更好地适应现实中的复杂情况，我们结合最新的视觉大模型能力，设计了第二条理解文档的路线，一条纯视觉页面理解驱动的路线：不再解析提取文本内容，而是理解-组织-标注页面，让 Agent 直接看到无损的原页面。
这项功能，就是我们新上线的 VISION-MAP。我们喜欢把它比作这个赛道的全视觉自动驾驶FSD，相比素描，它是给文件拍照和写标注，是高度保真的。
VISION-MAP 能帮我们做什么？
VISION-MAP 的核心，是把页面作为第一公民。我们不再默认用重度提取把一页内容改写成文字替身，而是把原始页面作为最完整、最接近源文件的信息基准保留下来，再按照文档原生的章节、主题和内容关系，将页面组织成可以跨文档导航的层级图谱与关系网络。
为了让页面能够被快速找到，系统会轻量提取其中的核心文字，并结合视觉模型为页面补充章节归属、主题和内容标注；其中的表格、图表和重要配图，依然会按需独立提取，成为可以搜索、引用和复用的资产。
当 Agent 需要使用这些资料时，它会先在页面图谱中检索和导航，找到相关页面后，再把原页交给视觉模型，根据当前问题按需读取金额、条款、图表或版式关系，并将结果追溯到具体页面和源文件。
Knowhere 不是在文本解析和视觉理解之间二选一，而是同时拥有两条轨道。
第一条是文本轨。它把文档解析成段落、表格等结构化内容，适合排版干净、文字容易提取的文件，这条线路主要支持DOCX/XLSX/MD/JSON等非页面格式的数据。
第二条是视觉轨，也就是 VISION-MAP。它把完整页面作为理解对象，适合扫描件、图纸、复杂表格以及版式本身就包含信息的文件，主要支持PDF/PPT等有显著页面的数据。
我们精心设计了知识库的schema，两条轨道最后进入的是同一张文档地图。Agent 找路的方法没有变，区别只是它找到内容以后，拿到的是一段文字，还是一张原始页面。
VISION-MAP，不仅能帮助修补文本解析的短板，也在拓展 Knowhere 的文件理解边界。
以前，系统最擅长处理的是“文字是主体”的文档。加入视觉轨以后，照片、扫描材料、工程图纸、带有大量图表的报告、页面设计复杂的演示文稿，都可以成为文档记忆的一部分。Knowhere 能处理的资料更多元，能进入的业务场景也更广了。
为什么还要做一条纯视觉路线？
在工业、工程、金融、法律、医疗等对于解析要求严苛的行业，是不能接受一个没有源文件可回溯的结果的。
举个例子：一份扫描合同里写的是 5300 万，经过解析以后，数字变成了 530 万。
只少了一个零。
可一旦这份解析结果进入知识库，后面的检索、计算和回答就可能都建立在 530 万这个基数上。Agent 甚至可以给出一个逻辑完整、引用齐全、看起来很可信的答案——只是答案从源头就已经错了。
而且，这种现象，很难100%杜绝。
这不一定是所用的解析器太差，也不是说换个更强的模型就一定能解决。
因为现实里的文件实在太复杂了。扫描歪斜、印章压字、双栏排版、跨页表格、手写批注、工程图纸……这些情况没有一个封闭的标准答案。识别准确率可以越来越高，但只要系统把解析结果当成唯一基准，偶尔一次的小错误，就可能沿着整条链路传下去，还容易造成级联错误（cascading effect）。
在普通资料里，这可能只是一个不太准确的答案；在工程、金融、法律等行业里，事情要严重得多。
工程资料里，一条线、一处标高，都可能影响后续判断。金融报表里，单位是万元还是亿元，小数点在什么位置，区别可大了。
这些行业不仅要求系统给出结果，还要求结果能够复核、能够审计、能够追溯。
但如果原始页面没有被保留下来，或者已经退化成一个很难找到的附件，系统就会连回头核对的机会都没有。你只能看到机器转写后的二手结果，而不是当时真正进入系统的那一页证据。
相当于既抄不全，又改不回。
因此，保留源文件，其实就是一份兜底的保险。
如果把传统解析比作给文件画速写，那么再先进的识别模型，都是在努力把速写画得更像。
VISION-MAP 则换了一个思路：既然速写总有可能漏掉细节，那就把原始页面这张“底片”留在系统里。
以后无论是 Agent 回答问题，还是用户复核结果，都可以沿着引用直接回到原始文件和具体页图，看见数字原本写在哪里、表格原本怎样排列、印章和批注原本覆盖了什么。保留源文件并不能让模型从此绝不出错，但它让错误可以被发现、被复核，也让整条处理链路有据可查。
这也不是说文本解析就没有价值了。恰恰相反，能稳定解析成文字的内容，当然应该继续走文本轨。VISION-MAP 要补上的，是那些不适合只靠文字替身理解的部分。
为什么是现在？
在以前，“直接看页面”这件事，想得出来，却很难真正用起来。
因为早期视觉模型看不稳复杂页面，一次能处理的图片也有限，速度和成本更谈不上适合大规模文档。那时把所有页面都交给模型现看，体验并不好。
现在，多模态模型已经能同时理解多张图片，也能处理更长的页面序列。表格、图形、排版和文字不必先被拆成彼此孤立的部分，模型可以结合整页关系一起判断。
另一方面，像 ColPali 这类以整页图像为检索对象的研究，也说明“先找到页面，再理解页面”是一条可行的路线。
技术成熟到这里，我们才有机会把视觉理解从一个演示能力，变成 Knowhere 文档系统里真正可用的一条轨道。
这套方法能带来什么？
最直接的一点，是信息保留得更完整了。
文字解析擅长得到“页面上写了什么”，视觉理解还能看到“这些内容是怎样放在一起的”。面对复杂表格、图文混排、扫描件和图纸时，后者尤其重要。
第二点，是拓宽了文件和场景的边界。
过去不容易进入知识库的图片资料、图纸、扫描档案和视觉报告，现在也可以被组织、检索和理解。对 Knowhere 来说，这是从“处理以文字为主的文档”，走向“理解包含文字、表格、图片和版式关系的完整资料”。
第三点，是错误更容易纠正，也更方便追溯。
VISION-MAP 也不会承诺永远不出错。章节可能挂偏，Agent 也可能先找错页面。但因为源文件和原页还在，它可以查看邻页、换一条路径，或者重新阅读页面。错误没有在入库时被彻底写死。这条溯源路径对人类也更友好，相比返回一堆文本（格式还能错乱），直接给出页面并高亮答案所在位置，可以缓解人类审核 AI 生成内容的工作量和焦虑。
第四点，是两条轨道可以互相补位。
干净的电子文档可以优先使用文本轨，获得更快、更方便的检索体验，很多格式（MD/DOCX/XLSX等）我们也支持非页面式的解析；难以稳定解析的页面可以走视觉轨，保留完整信息。必要时，同一份文档也可以同时使用两种方式，而不必把所有文件强行塞进同一种处理流程。
第五点，是它更适合 Agent。
Agent 不只是搜索一个关键词，然后拿回几段文字。它需要理解任务、判断方向、进入对应章节，再决定读文字还是看原页，最后把证据连同来源一起交回来。
这个过程，就跟我们人类开车一样：
章节地图是路网，告诉 Agent 往哪里走；页面是摄像头，让它看到真实路况；Agent 是司机，根据用户的问题自己选择路线。
地图解决“去哪里”，视觉解决“看到了什么”。两者放在一起，才是 VISION-MAP。
VISION-MAP 现在仍在持续改进。
我们还在优化章节识别、页面定位、跨页理解以及不同文件之间的关联。
相信之后有了 VISION-MAP 的加持，工业场景下的解析体验必定会更上一个台阶。
下一篇我们将介绍 VISION-MAP 是怎么工作的，敬请期待。
