> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # KohakuRAG：从文档树找到证据 - URL: https://www.hubwiz.com/blog/kohakurag-find-evidence-from-the-document-tree/ - Published: 2026-07-06T11:10:25.000Z - Updated: 2026-10-13T15:09:10.000Z - Description: 如果你曾经在工作中构建过 RAG 管道，你可能知道这种感觉：检索在演示中看起来不错，然后在真实问题上悄悄崩溃…… - Author: admin - Tags: RAG, KOHAKURAG, #Import 2026-10-14 14:41 如果你曾经在工作中构建过 RAG 管道，你可能知道这种感觉：检索在演示中看起来不错，然后在真实问题上悄悄崩溃…… 本文之所以有趣，是因为它介绍了一种以非常实用、工程优先的方式解决这一差距的方法。 ## 1、标准 RAG 的问题 对于像 WattBot 2025 挑战赛这样的硬核任务，标准 RAG 往往不够可靠，该挑战赛要求 ±0.1% 的数值精度和精确的来源归属。在实践中，三个问题反复出现： - 扁平分块破坏了语义边界和文档结构，使精确的来源追踪变得更加困难，并削弱了对引用质量的信心。 - 当措辞不一致时，单个查询很容易遗漏相关证据，尤其是当同一概念使用不同术语时。 - 单次生成过程本质上是不稳定的。答案和引用都可能因运行而异，在某些情况下，由于害怕产生幻觉，系统可能会不必要地弃权（输出空白），尽管证据就隐藏在上下文中。 ## 2、KohakuRAG：从扁平块到可引用的树 KohakuRAG 的核心是一个轻量级 RAG 框架，建立在四级层次化文档索引之上：文档 → 章节 → 段落 → 句子。 它通过自底向上的嵌入聚合保留文档结构，通过基于 LLM 的查询规划加上跨查询重排序来提高检索覆盖率，并在生成过程中通过弃权感知的集成投票来稳定最终输出。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-qllUpXRg8mHw_Crc.png) ### 2.1 离线层次化文档索引 第一步是文档解析。 每个文档被组织成四级树状结构：文档 → 章节 → 段落 → 句子。图像和表格被视为特殊的段落节点，由 Qwen3-VL 生成**标题（文本描述）**。图像使用 PyMuPDF 提取，然后传递给 Qwen3-VL 进行标题生成，重点关注技术内容、数值、轴标签等类似细节。 文档解析阶段主要基于规则，使用布局启发式方法从 PDF 和幻灯片中恢复章节和段落结构。**PyMuPDF** 处理文本和布局信息的基本提取，然后使用基于字体大小、间距、格式和相关线索的规则来识别层次结构。 - 章节检测规则：字体大小至少为中位数 1.2 倍的文本块被视为候选章节标题。编号模式（如 1.2 或 A.3）用作确认章节边界的附加信号。 - 段落检测规则：垂直间距小于行高 1.5 倍的连续文本块被合并为一个段落。较大的间距被视为段落边界。 - 句子分割规则：句子分割基于 NLTK 的 sent\_tokenize，并针对技术文档添加了额外规则，以处理如 Fig.、et al. 和 i.e. 等缩写。 下一步是嵌入计算。 嵌入使用长度加权策略自底向上聚合。叶节点（句子）直接嵌入，而父节点使用 token 计数加权平均值从其子节点计算。 KohakuRAG 支持两种嵌入后端：用于文本检索的 Jina v3（768 维，最多 8K 上下文）和用于多模态检索的 Jina v4，支持 128 到 2048 的 Matryoshka 维度，可以直接嵌入文本和图像。向量存储建立在 sqlite-vec 作为轻量级后端之上。 ### 2.2 在线多查询检索 在线阶段从基于 LLM 的查询规划开始。 原始问题被扩展为 n 个语义相关的查询，以覆盖替代措辞、首字母缩略词扩展和子查询分解。 接下来是密集检索。 每个规划的查询用于余弦相似度搜索，仅针对句子和段落节点。 还有一个可选的混合检索步骤。 可以添加基于 BM25 的稀疏检索作为增强，仅应用于段落索引。其结果直接附加在密集检索结果之后。 然后是跨查询重排序。 这里使用三种策略：基于频率、基于分数和组合重排序。被多个查询匹配的节点获得更高的优先级。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-8uYzRqoh-EctdfP-.png) 最后，系统执行索引遍历和层次化上下文扩展。 对于每个匹配的节点，系统使用父节点和兄弟节点扩展上下文。KohakuRAG 还描述了一个可选的树去重步骤，可以移除祖先-后代重叠以节省上下文窗口空间，尽管在比赛提交中未启用。 ### 2.3 回答管道 对于提示词构建，检索到的上下文通过重新排序的布局放置在问题之前。这有助于解决中间丢失问题，同时格式化的引用标记使 LLM 更容易进行归属。 对于结构化输出，LLM 被要求返回 JSON，包括答案、提取的值、引用 ID、解释以及指示结果是否为空白的标志。当证据不足时，模型应明确弃权。 这里的"引用"是在文档 ID 级别进行评估的，而不是页面或跨度级别的归属，这对于理解系统真正优化的内容很重要。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-am0404_v3p7J-Brr.png) 如图 3 所示，还引入了重试机制。如果 LLM 返回空白结果，系统会增加检索 top-k 值并再次运行检索，重复此过程直到获得有效答案或达到重试限制。 ### 2.4 多次生成，然后投票 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-n2fnsUTXwBFVISyi-1.png) 一旦检索结果到位，系统不会只向 LLM 请求一个答案。相反，它独立生成多个答案。 最后，通过投票聚合运行结果。如果至少存在一个非空白答案，则在投票前过滤空白输出；如果所有运行都是空白的，系统则弃权。这使答案和引用都更加稳定。 ## 3、评估 KohakuRAG 是为 WattBot 2025 挑战赛开发的，因此实验结果主要基于该基准数据集。 有 32 篇关于 AI 能耗的技术文档，包括研究论文、技术报告和演示幻灯片。完整集合约 500K token，涵盖 AI 模型的功耗、用水量、碳足迹和性能特征等主题。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-dhTtnBQ-BmrAC3Qp.png) 在这项挑战赛中，KohakuRAG 在公开排行榜上获得 0.902，在私有排行榜上获得 0.861。它也是唯一一个在公开和私有排行榜上都保持 №1 位置的方法。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-groG7IVPh83tVs7T.png) **一个令人惊讶的发现：提示词排序极其重要。** 如图 6 所示，仅仅将问题放在检索到的上下文*之后*（而不是之前）就获得了 80% 的相对改进，证实了"中间丢失"现象。有时，最大的收益来自最简单的调整。 ![None](https://www.hubwiz.com/blog/content/images/2026/07/0-Jm39YNdUyNhW51Nn.png) **另一个有趣的发现：密集检索可能就足够了。** 如图 7 所示，虽然混合搜索（密集 + BM25）通常被视为强大的基线，但 KohakuRAG 表明，结构良好的层次化密集检索本身就具有很强的竞争力。添加 BM25 仅提供了 +3.1% 的边际提升。 ## 4、思考 KohakuRAG 的价值不在于任何单个组件感觉全新。真正的优势在于它如何将四个熟悉的想法——层次化索引、多查询检索、带重试的弃权和集成投票——紧密集成到一个非常具体的目标周围：高度准确的答案、精确的引用，以及在证据不够强时弃权的能力。 它还触及了企业知识问答中最困难的部分之一：可追溯性比仅仅答对问题更重要。从这个意义上说，层次化树结构不仅仅是一种更精细的文档分块方式。它是引用、审计和错误分析的基础设施。 **但我有两个担忧。** 第一个担忧是系统对文档解析质量敏感，可能也对查询规划质量敏感。在真实的企业环境中，文档通常充满嘈杂的 PDF 和不一致的布局。当这种情况发生时，基于规则的章节解析可能在基础层面出错。 第二个是成本和延迟。集成推理或多或少地线性增加成本，重试机制可能使尾部延迟更糟。因此，这感觉更像是一种高可靠性、低吞吐量的设计，而不是天然适合高并发在线问答的方案。 --- 原文链接：[KohakuRAG: Climb the Document Tree, Find the Right Evidence](https://freedium-mirror.cfd/https://medium.com/ai-exploration-journey/kohakurag-climb-the-document-tree-find-the-right-evidence-2635d4a59b2b?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)