尧图网页设计 
从碎片Chunk到跨文档知识图谱Knowhere三层层级记忆设计思路详解完整指南【免费下载链接】knowhereKnowhere extracts, parses, and outputs structured chunks ready for AI Agents and RAG.项目地址: https://gitcode.com/gh_mirrors/know/knowhere你是否也遇到过这样的困境把文档切成一堆碎片Chunk灌进向量库AI 却只能答出孤立的片段跨文档的关系全部丢失Knowhere是一个开源的文档解析与检索系统它把 PDF、Word、Excel、图片等非结构化文件解析为持久化、可导航的层级记忆专为 AI Agent 和RAG检索增强生成场景设计。本文将带你完整理解它三层 一张图的架构设计思路 。为什么传统 RAG 的碎片化会失效传统 RAG 的做法是切块 → 向量化 → 相似度检索 → 返回 Top-K 片段。问题在于上下文断裂一个片段不知道自己在哪份文档的哪一章结构丢失章节层级、表格、图片的从属关系全部被抹平跨文档孤岛不同文档之间没有可查询的关联。Knowhere 的回答是不要只存碎片要存结构化的记忆。解析完成后每份文档都会变成一棵可导航的树节点上挂着摘要、页码、实体和关联资产检索时 Agent 像人类读者一样先定位章节再深入阅读。三层记忆架构Namespace → Document → Section → ChunkKnowhere 的语料模型在 CORPUS_SCHEMA.md 中给出了权威定义整个语料库是这样一棵四层结构其中核心记忆为三层Namespace命名空间 └─ Document文档document_id, 源文件名, 解析轨道 └─ Section章节section_path, section_level, summary └─ Chunk检索单元chunk_type, content, chunk_metadata第一层Document —— 文档级记忆每份文档是一个稳定对象携带document_id、来源文件名和parse_track解析轨道。它记录了这份文档整体是什么类型构成、顶层关键词、整体摘要。数据模型定义在 document.pyDocument表持有文档级元数据与解析轨道标记。第二层Section —— 可导航的层级树这是 Knowhere 设计的精髓。DocumentSection是一棵父子树parent_section_idsection_pathsection_level每个节点自带 LLM 生成的summary摘要和sort_order阅读顺序字段作用section_path完整章节路径如第3章 / 3.2 风险分析section_level层级深度对应标题级别summary章节摘要支持不读正文只看大纲的导航对于 PDF 这类视觉复杂文档Knowhere 走Page Memory 轨道视觉模型整体理解页面skeleton_extractor.py 从目录TOC锚点推断章节骨架与页码范围再逐级生成层级节点而 DOCX/Excel 等文本原生文档走Chunk 轨道保留精确的标题层级。两条轨道最终汇聚到同一套记忆 Schema——这就是双轨同构的设计哲学。第三层Chunk —— 最小检索单元DocumentChunk挂在 Section 之下类型包括text、page、image、table。关键设计约束每个 Section 至多拥有一个正文 Chunktext或page图片和表格则是独立的资产 Chunk通过正文 Chunk 上的connect_to列表单向链接到它所属的章节。这意味着Chunk 就是它所在章节的最小内容载体检索命中一个 Chunk就能天然回溯到它的章节路径、页码和视觉证据——引用链完整可追溯。跨文档知识图谱把孤岛连成网三层结构解决的是单份文档内部的记忆跨文档关系则由文档图谱承担节点每份文档一个图节点node_kinddocument携带top_keywords、top_entities、top_summary等富元数据边两份文档之间的related无向边评分优先使用类型化实体重叠如人名、组织、指标名无实体时才回退到 TF-IDF 关键词重叠边权重边上记录具体命中了哪些共享实体/关键词让为什么相关可解释。发布逻辑在 DocumentGraphService文档解析完成后自动重算该文档的图节点与边Agent 检索时可以用neighbors工具回答还有哪些文档和这份文档相关。 值得注意的是项目团队在设计中刻意区分了章节树节点与图谱节点两套概念见 entity-node-graph.md并规划了 Chunk 级实体图作为演进方向——从文档相连走向章节相连的更细粒度知识网络。Agent 如何使用这份记忆记忆建好只是第一步Knowhere 把检索做成了面向 Agent 的工具集而不是固定的检索管道。Agent 可以按需组合调用工具场景outline只看大纲和章节摘要快速定位node_filter按章节标题/摘要做遍历过滤grep精确查找标识符、数字、专名recall模糊问题BM25 子串双通道 RRF 融合read已知章节后读取完整正文、解析 SAME-AS 指针assets查图片/表格或反查某资产属于哪一节neighbors找跨文档相关文档这套先大纲定位、再精准阅读的方式正是层级记忆的价值体现Agent 不必在几十万个向量里碰运气而是沿章节树导航。内部评测显示基于 Knowhere 记忆的 Agent 相比直接读原始文档首次回答准确率 36%、召回 11%小结三层层级 一张图谱的设计哲学层次对象核心价值L1Document文档级身份与整体画像L2Section可导航层级树摘要先行L3Chunk最小检索与引用单元带页码和资产链接图Graph跨文档实体关联知识不再孤岛化Knowhere 的核心洞察是RAG 的瓶颈往往不在向量检索本身而在于喂给模型的上下文有没有结构。把碎片重新组织回层级记忆Agent 才能像人一样读懂整个文档库。如果你想动手体验可以参考 CONTRIBUTING.md 中的自部署指南本地跑起 API 与 Worker上传几份文档就能亲眼看到这份记忆是怎么长出来的 。【免费下载链接】knowhereKnowhere extracts, parses, and outputs structured chunks ready for AI Agents and RAG.项目地址: https://gitcode.com/gh_mirrors/know/knowhere创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从碎片Chunk到跨文档知识图谱：Knowhere三层层级记忆设计思路详解（完整指南）
从碎片Chunk到跨文档知识图谱Knowhere三层层级记忆设计思路详解完整指南【免费下载链接】knowhereKnowhere extracts, parses, and outputs structured chunks ready for AI Agents and RAG.项目地址: https://gitcode.com/gh_mirrors/know/knowhere你是否也遇到过这样的困境把文档切成一堆碎片Chunk灌进向量库AI 却只能答出孤立的片段跨文档的关系全部丢失Knowhere是一个开源的文档解析与检索系统它把 PDF、Word、Excel、图片等非结构化文件解析为持久化、可导航的层级记忆专为 AI Agent 和RAG检索增强生成场景设计。本文将带你完整理解它三层 一张图的架构设计思路 。为什么传统 RAG 的碎片化会失效传统 RAG 的做法是切块 → 向量化 → 相似度检索 → 返回 Top-K 片段。问题在于上下文断裂一个片段不知道自己在哪份文档的哪一章结构丢失章节层级、表格、图片的从属关系全部被抹平跨文档孤岛不同文档之间没有可查询的关联。Knowhere 的回答是不要只存碎片要存结构化的记忆。解析完成后每份文档都会变成一棵可导航的树节点上挂着摘要、页码、实体和关联资产检索时 Agent 像人类读者一样先定位章节再深入阅读。三层记忆架构Namespace → Document → Section → ChunkKnowhere 的语料模型在 CORPUS_SCHEMA.md 中给出了权威定义整个语料库是这样一棵四层结构其中核心记忆为三层Namespace命名空间 └─ Document文档document_id, 源文件名, 解析轨道 └─ Section章节section_path, section_level, summary └─ Chunk检索单元chunk_type, content, chunk_metadata第一层Document —— 文档级记忆每份文档是一个稳定对象携带document_id、来源文件名和parse_track解析轨道。它记录了这份文档整体是什么类型构成、顶层关键词、整体摘要。数据模型定义在 document.pyDocument表持有文档级元数据与解析轨道标记。第二层Section —— 可导航的层级树这是 Knowhere 设计的精髓。DocumentSection是一棵父子树parent_section_idsection_pathsection_level每个节点自带 LLM 生成的summary摘要和sort_order阅读顺序字段作用section_path完整章节路径如第3章 / 3.2 风险分析section_level层级深度对应标题级别summary章节摘要支持不读正文只看大纲的导航对于 PDF 这类视觉复杂文档Knowhere 走Page Memory 轨道视觉模型整体理解页面skeleton_extractor.py 从目录TOC锚点推断章节骨架与页码范围再逐级生成层级节点而 DOCX/Excel 等文本原生文档走Chunk 轨道保留精确的标题层级。两条轨道最终汇聚到同一套记忆 Schema——这就是双轨同构的设计哲学。第三层Chunk —— 最小检索单元DocumentChunk挂在 Section 之下类型包括text、page、image、table。关键设计约束每个 Section 至多拥有一个正文 Chunktext或page图片和表格则是独立的资产 Chunk通过正文 Chunk 上的connect_to列表单向链接到它所属的章节。这意味着Chunk 就是它所在章节的最小内容载体检索命中一个 Chunk就能天然回溯到它的章节路径、页码和视觉证据——引用链完整可追溯。跨文档知识图谱把孤岛连成网三层结构解决的是单份文档内部的记忆跨文档关系则由文档图谱承担节点每份文档一个图节点node_kinddocument携带top_keywords、top_entities、top_summary等富元数据边两份文档之间的related无向边评分优先使用类型化实体重叠如人名、组织、指标名无实体时才回退到 TF-IDF 关键词重叠边权重边上记录具体命中了哪些共享实体/关键词让为什么相关可解释。发布逻辑在 DocumentGraphService文档解析完成后自动重算该文档的图节点与边Agent 检索时可以用neighbors工具回答还有哪些文档和这份文档相关。 值得注意的是项目团队在设计中刻意区分了章节树节点与图谱节点两套概念见 entity-node-graph.md并规划了 Chunk 级实体图作为演进方向——从文档相连走向章节相连的更细粒度知识网络。Agent 如何使用这份记忆记忆建好只是第一步Knowhere 把检索做成了面向 Agent 的工具集而不是固定的检索管道。Agent 可以按需组合调用工具场景outline只看大纲和章节摘要快速定位node_filter按章节标题/摘要做遍历过滤grep精确查找标识符、数字、专名recall模糊问题BM25 子串双通道 RRF 融合read已知章节后读取完整正文、解析 SAME-AS 指针assets查图片/表格或反查某资产属于哪一节neighbors找跨文档相关文档这套先大纲定位、再精准阅读的方式正是层级记忆的价值体现Agent 不必在几十万个向量里碰运气而是沿章节树导航。内部评测显示基于 Knowhere 记忆的 Agent 相比直接读原始文档首次回答准确率 36%、召回 11%小结三层层级 一张图谱的设计哲学层次对象核心价值L1Document文档级身份与整体画像L2Section可导航层级树摘要先行L3Chunk最小检索与引用单元带页码和资产链接图Graph跨文档实体关联知识不再孤岛化Knowhere 的核心洞察是RAG 的瓶颈往往不在向量检索本身而在于喂给模型的上下文有没有结构。把碎片重新组织回层级记忆Agent 才能像人一样读懂整个文档库。如果你想动手体验可以参考 CONTRIBUTING.md 中的自部署指南本地跑起 API 与 Worker上传几份文档就能亲眼看到这份记忆是怎么长出来的 。【免费下载链接】knowhereKnowhere extracts, parses, and outputs structured chunks ready for AI Agents and RAG.项目地址: https://gitcode.com/gh_mirrors/know/knowhere创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考