在构建企业级大模型应用（如矿产资源勘查、工程技术规范问答）时，RAG（检索增强生成）系统的核心痛点往往在于 “搜不准、答不对、没法溯源” 。一个优秀的知识库不能停留在简单的“切块+向量检索”上，而需要兼顾高精度多模态解析、混合召回、多级重排及精准溯源。
本文将深入剖析该生产级 RAG 系统的全链路实现，按照从宏观流水线到底层核心算子的顺序，并结合探矿与地质勘查资料的真实业务场景，完整拆解入库编排与性能瓶颈、多格式分流与 PDF 深度解析、结构化切块与双模索引交接、双路混合检索与二次打分以及多模态精准溯源。
核心架构总览
📄 原始文档 ──> [ 1. 入库流水线 ] ──> 多格式分流解析(DeepDOC) + 结构化切块 ──> 🗄️ 搜索引擎 (ES)
│
💬 用户提问 ──> [ 2. 检索服务 ] ────> 引擎内混合召回(Sparse + Dense kNN) ───────────┘
│
[ 服务层二次打分 / Rerank 精排 ]
│
[ 相似度阈值过滤 ]
│
📝 注入 Prompt ──> ✨ 生成带精准引用的回答
一、 全流程入库流水线与工程耗时剖析（写路径）
文件上传后并非立即同步解析，而是通过异步队列与数据摄取流水线引擎进行解耦。整条入库链路由 Canvas DSL 编排引擎统一驱动，将任务拆解为 6 个状态独立的串行阶段：
上传 ──> [NATS 队列等待调度] ──> [Canvas DSL 编排执行] ──> 写入索引可检索
│
├─ 1. File ─────── 读元数据（秒级）
├─ 2. Parser ───── 多格式/DeepDOC 解析（CPU 密集，耗时大头）
├─ 3. Chunker ──── 结构化合并与切块（纯文本处理，极快）
├─ 4. Extractor ── LLM 抽取增强（I/O 密集，开启后为第二耗时大户）
└─ 5. Tokenizer ── C++ 分词 + 批量 Embedding（带缓存）+ 写索引
- Task queued / running（排队调度） ：任务写入 NATS JetStream 消息队列，由摄取服务的后台 Worker 进程拉取执行。 实战瓶颈洞察：在默认单并发配置下（max_concurrent_workers = 1），同一时刻仅执行一个任务。生产环境中经常出现“排队等待 7 分钟，实际执行仅 3 分钟”的现象——优化吞吐量的首要抓手是合理调大 Worker 并发度，而非盲目优化单点逻辑。
- [File]（读取元数据） ：轻量级前置节点，不加载文件二进制内容，仅秒级读取文件名、存储路径及租户 ID、知识库 ID、语种等运行级元数据并向下游广播。
- [Parser]（解析文件内容） ：由文档解析组件从对象存储（MinIO）拉回文件二进制，按后缀分流解析。PDF 走重型 DeepDOC 视觉引擎，办公文档走原生轻量解析器。这是实际执行阶段计算量最大的环节。
- [Chunker]（智能切块） ：通过文本分块器将解析出的结构化元素按策略切分为切片，支持通用（general）、问答（qa）、表格（table）、手册（manual）等多种可配模式。 💡 结构化智能切块引擎深度拆解： 在系统架构中，[Chunker] 是连接前端文档解析与后端向量检索的“承重墙”。若采用机械式的“固定长度强行切块”，必然会将一段完整的地质构造描述、一个复杂的钻孔化验表或一条关键的找矿结论从中间腰斩。为此，系统内置了多策略可配的切块模式：
- 1. General（通用/标准分块） ：
- 核心逻辑：采用“滑动窗口 + 自然语义边界感知”策略，以 chunk_token_size（默认 512 Token）为软上限，优先在自然分隔符（如 。、？、！、;、\n）处断开，支持重叠率（Overlap）配置。
- 地质实战：适用于《区域地质背景》等大段连贯的正文，保证长论述平滑拆分为语义完整的 Chunk。
- 2. QA（问答对分块） ：
- 核心逻辑：专为问答对、规范条文或 FAQ 结构设计，识别“问题（Q）与答案（A）”对齐结构，强绑定在同一切片内。
- 地质实战：适用于《固体矿产资源/储量分类标准问答》。当总工程师提问时，该切片可实现零延迟精准直达。
- 3. Table（表格专用分块） ：
- 核心逻辑：保持表格结构的完整性绝对不从中间横向切断；若表格行数过多，系统采用“表头附着机制”（Row-Header Inheritance），将复杂表头作为上下文前缀自动附加到每一个被拆分出来的行切片中。
- 地质实战：处理百行钻孔编录表或化验表，确保某一行化验数据在切块和检索时依然能通过表头还原其物理含义。
- 4. Manual（手册/图书级层级分块） ：
- 核心逻辑：依托 DLA 产出的标题层级（H1、H2、H3）按章节拓扑切块，以“完整子章节/技术条款”为边界，并在每个 Chunk 头部自动注入宏观面包屑导航路径（如 [第一章 矿区地质特征] > [第三节 控矿构造]）。
- 地质实战：处理几十万字的《DZ/T 0214-2002 勘查规范》，确保大模型不仅知道条文内容，还知晓其所属章节。
- [Extractor]（LLM 抽取增强） ：可选的信息抽取组件。开启后会针对每个切片并发调用大模型（并发上限默认受控为 10）生成高维语义增强信息，以解决“专业文档表述晦涩、与用户口语提问存在语义鸿沟”的痛点：
- 自动关键词（Auto-Keywords） ：提炼切片的核心实体与领域术语（例如从岩心录井描述中，提炼出 斑岩型铜矿、钾硅酸盐化、黄铜矿化富集带、钻孔ZK402 等高权重词），并在写入索引时赋予更高词项权重。
- 自动模拟问题（Auto-Questions / 逆向 HyDE） ：站在提问者视角，预判这段内容能回答什么问题（例如针对矿床成因自动生成：“研究区东段金矿体的控矿构造是什么？ ”）。这些生成的问题会与原文一并参与分词和向量化，将“问题搜陈述句”转化为极高匹配度的“问题搜问题”。
- 摘要与结构化标签（Summary & Tags） ：将长段落浓缩为核心结论摘要，或按照预设体系自动打上业务标签（如 地球化学勘查、水文地质条件）。
- 工程代价：若未开启此特性，该节点会直接空转跳过；一旦开启，每个切片均需发起大模型请求，会成为仅次于 Parser 的第二耗时大户。
- [Tokenizer]（分词、向量化与落盘） ：通过分词与向量化组件生成全文检索分词串与稠密向量，最终写入底层可插拔的检索引擎层。 💡 存储引擎对比（Elasticsearch vs. Infinity） ： 系统底层并非绑定单一数据库，而是通过统一抽象接口支持两款差异化的引擎：
- Elasticsearch (ES) ：基于 Java/Lucene 的传统分布式全文检索霸主，企业存量集群多、运维生态成熟；但其向量检索能力系后期演进加入，在应对大规模高维向量与全文混合计算时内存开销较大。
- Infinity：专为大模型与 RAG 打造的 C++ 原生 AI 数据库。它从底层原生支持“稠密向量 + 稀疏向量 + 全文检索”的高速融合查询，单机吞吐性能极高且内存占用远低于 ES。企业可根据基础设施现状无缝切换。
二、 核心难点攻坚：多格式分流与 PDF 深度解析
在 [Parser] 阶段，系统面对的是企业内部五花八门的文档格式。为了兼顾解析速度与还原精度，解析调度器采用了“按后缀分流、轻重分离”的设计哲学。
1. 多文档格式解析策略全览
自带结构树的流式办公文档直接走原生语法树（AST/DOM）提取，而无结构或版面固化的 PDF 文档则交由 DeepDOC 视觉流水线攻坚：
流式办公文档（如 .xlsx 格式的钻孔化验数据表、.docx 格式的野外地质踏勘小结）天然维护了段落与表格的逻辑树，轻量解析器可直接实现 100% 准确的还原。真正让大多数 RAG 系统“折戟”的，是排版自由、缺乏统一逻辑树、甚至混杂历史扫描件的 PDF 地质勘查报告。为此，系统基于 Go 语言完整移植并优化了对齐 Python 原版的 DeepDOC 双阶段深度解析引擎。
2. PDF 阶段一：逐页独立并行流水线
PDF 进入解析器后，首先由页面并发工作池调度，每个页面独立、按序经过 1 个前置探测与 5 个核心步骤。普通 PDF 与扫描件走的是同一条流水线，唯一的分叉点仅在步骤二：
- 前置步骤：提取内嵌字符层 —— 分叉的前提 调用底层 PDF 渲染库（pdfium）提取页面内嵌字符及其精确坐标。普通 PDF 返回大量逐字符的坐标对象（此时尚无“行”的概念）；扫描件则返回空。同时计算中位字符高/宽（供后续合并段落判断字号）、英文页判定，以及扫描噪声页判定——识别出表面有字符层但实为乱码噪声的“假文字层”PDF，强制按扫描件处理。
- 步骤一：渲染 216 DPI 位图 —— 视觉模型的统一输入 无论是否有文字层，渲染引擎都会将该页转换为 216 DPI 的位图。这是因为后续的行框检测（Det）、版面分析（DLA）和表格识别（TSR）全部是视觉模型，只看像素，不看文字层。
- 步骤二：获取“行级文本框” —— 唯一分叉点 系统根据页面是否具备干净的内嵌字符层（有字符、非扫描噪声且非乱码页），动态分流至两条处理路径（详见下方对比表）。
- 步骤三：DLA 版面分析 —— 赋予语义角色 对整页位图运行一次版面检测模型，输出 10 类版面区域框，并将版面角色标签映射写回步骤二产出的文本框上（插图区域还会补入一个合成框占位）。
- 步骤四：TSR 表格结构识别 —— 拆解复杂网格 仅当步骤三 DLA 检出表格（table）区域时触发：从页图裁出表格图像 \(\rightarrow\) 运行 TSR 模型识别行、列、表头及跨行列合并单元格 \(\rightarrow\) 将单元格组装成网格，并用步骤二的行框文字填格子（填不出的空格再单独裁图补跑 OCR） \(\rightarrow\) 为每个文本框打上行列位置注释，供后续组装使用。
- 步骤五：零产出放大重试（Zoom Retry） 若整页跑完前 4 步后一个框都未产出（通常因原图分辨率过低或字迹极小），则触发放大重新渲染并重跑 OCR + DLA。
3. 三大核心难点与架构设计拆解
在逐页流水线中，有三个决定系统性能、稳定性与准确率的关键设计：
难点 A：普通 PDF vs. 扫描件的成本与路径分叉（第 2 步拆解）
💡 架构辨析：内置 DeepDoc 专用模型 vs. 界面 VLM 增强插件
- 四个内置 DeepDoc 模型（ONNX） ：随产品打包的基础设施（Det、OCR Rec、DLA、TSR），经 ONNX Runtime 在 CPU 本地进程内推理，无需配置、零 Token 费用。它们只负责“定位框、认字、标版面、拆表结构”，不理解图片画了什么（只知道这里是 figure，不知道画的是断层剖面还是矿区交通图）。
- 外接 VLM 增强插件（如 GPT-4o-mini） ：租户级远程 API 配置。在解析完成后，将 DLA 标出的插图/表格裁图发给 VLM，让其用自然语言描述画面内容（例如输出：“图3-2 展示了北东向 F1 逆断层切穿花岗斑岩体的剖面关系，主矿体赋存于断层下盘破碎带中”），转化为可检索切片。不配 VLM 主流程照常运转，仅缺失图表语义检索能力。
难点 B：DLA 版面分析的 10 大语义标签（第 3 步拆解）
版面分析模型输出的类别索引严格映射自版面标签定义表中的 10 类语义角色：
- 为什么编号 4/7/9 存在重复？ 该标签表是严格对齐 Python 原版 DeepDOC 模型的线上协议（Wire Contract） 。原版模型在训练合并类别时未修改输出层维度，因此工程移植版必须原样保留重复槽位以兼容模型权重。
- 核心价值：OCR 仅解决“字是什么”，而这 10 类标签解决了 “这块内容在文档里扮演什么角色” ，是区分版面分析与纯文字识别的分水岭。
难点 C：防内存暴涨的三重硬核防护（第 5 步拆解）
在第 5 步放大重试（Zoom Retry）中，位图内存随放大倍率呈平方级增长。面对病态扫描页，若直接扔进底层渲染器，会耗费数分钟分配本地内存甚至直接触发 OOM（内存溢出崩溃）。
⚠️ 地质大图 OOM 真实算账示例：
在探矿资料归档中，报告末尾常常附有 A0 超大幅面的《1:10000 区域地质地形图》或《勘探线联合剖面图》 （物理尺寸约 \(46.8 \times 33.1\) 英寸）。
- 首轮渲染：按基础 216 DPI 渲染，像素约为 \(10110 \times 7150 \approx 7200\text{ 万像素}\)（受底层钳制实际已接近预算上限）。
- 灾难性的无保护放大：如果因为图面空白多、图例字太小导致首轮“零产出”而触发比如 3 倍放大重试（648 DPI） ，宽高各乘 3，总像素将暴增 9 倍达到 \(6.5\text{ 亿像素}\) ！
- 内存崩溃：仅这一张未压缩的 RGBA 位图就需要占用 \(6.5\text{ 亿} \times 4\text{ Bytes} \approx \mathbf{2.6\text{ GiB}}\) 的连续原生内存；算上新旧位图短暂并存以及 ONNX 视觉模型推理时的中间特征张量，单页瞬时内存消耗会突破 4~5 GiB。若此时工作池恰好有 4 个并发 Worker 同时处理类似的折页大图，瞬时近 20 GiB 的内存洪峰会瞬间击穿容器内存上限导致进程被 OOM Kill。
系统为此构筑了三重防线：
- 窄触发与倍率封顶：仅首轮“零产出”页面才触发重试；且重试倍率受 9.0 倍上限硬性封顶。
- 渲染前像素预算预检：在进入底层渲染器分配内存前，先用首轮宽高乘以放大倍率的平方预测新位图大小。一旦超过 48M 像素（约 4800 万像素） 预算，直接放弃重试并保留首轮结果，将上述地质折页大图的危险内存分配直接拦在门外。
- 渲染器内部兜底钳制：底层 PDF 渲染引擎内部自带终极防线，若计算出的像素超限则自动按比例下调分辨率缩放比（scale），确保任何单次渲染产出的位图绝不可能超过 48M 像素（约 192 MiB RGBA） 。整个解析池的内存峰值被严格收敛在 并发 Worker 数 × ~200 MiB 的有界安全范围内。
4. PDF 阶段二：文档级全局组装与实战全流程演练
所有页面的文本框、表格与 DLA 区域按页码汇总后，进入文档级版面组装阶段执行跨页全局整理：
- 分栏识别：优先识别双栏/多栏排版并标定列号（必须在去重前执行，防止跨栏的相似短行被误删）。
- 全局降噪清洗：剔除重叠框及背景水印字（如斜体铺满全页的“内部地质资料·严禁外传”）；通过跨页统计自动删除页眉页脚（如超过半数页面顶部出现的《XX省XX县金铜矿详查报告》）；结合 PDF 书签与形态特征整页剔除目录页（TOC）。
- 段落还原：依次执行同行碎片合并 \(\rightarrow\) 按分栏排列阅读顺序 \(\rightarrow\) 英文跨行连字符重连 \(\rightarrow\) 同角色文本纵向自然段合并。
- 表格收尾与图文对齐：执行跨页表格合并，并将正文流里的零散表格框抽离，替换为结构化的 HTML 表格对象；最后将文本框流转换为最终的结构化段落（Sections），并将图注、表注精准挂载到对应的图表对象上。
⛏️ 探矿报告解析全流程演练（以《青海省某斑岩铜钼矿床详查地质报告.pdf》为例） ：
假设这是一份 1990 年代历史扫描页与现代电子排版混编的 PDF 报告，其中第 42~43 页包含双栏排版正文、一张《图 4-1 矿区物探激电异常平面图》、一个跨页的《表 4-2 钻孔见矿层位及化学分析成果表》以及一个用工业指标估算铜金属量的数学公式：
- 逐页分流：第 42 页为现代电子页，系统直接用检测框圈定内嵌字符，零 OCR 识别耗时秒出文本，唯独矿石化学式 \(\text{CuFeS}_2\) 因特殊字体编码缺失被自动裁图补跑了一次 OCR；第 43 页为早年老地质队的手工盖章扫描页，系统自动切入全量 OCR 路径，并将表格内竖排的“岩石名称”列自动旋转 90° 准确识别。
- 角色对号入座：DLA 将双栏文字标为 text，将储量计算公式 \(Q = V \cdot d \cdot \bar{C}\) 标为 equation 独立保护；将激电异常图及下方说明分别标为 figure 和 figure caption。
- 跨页表格缝合：TSR 分别识别出 42 页底部的半张表与 43 页顶部的续表（含“矿体编号”、“钻孔号”、“真厚度(m)”、“平均品位 Cu(%) / Mo(%)”等复杂的双层跨列合并表头）。在全局组装阶段，系统自动剔除了两页中间夹杂的页眉页脚，将两段表格无缝拼接为一个完整的 HTML <table>，并将表注精准挂载到表头上方。
三、 结构化切块与双模索引构建（数据交接棒）
经过解析阶段处理后，无论是 PDF 还是 Office 文档，都统一转化为了结构化的文本段落（带版面类型与页码坐标）、HTML 表格对象与图片资源。接下来，数据交接棒传给分块器与分词向量化组件：
- 结构化智能切块（Chunker） ：
- 常规文本切分：以通用分块器为例，系统按自然分隔符（\n、。、！、？、; 等）和 Token 阈值（默认 512 Token）将文本段合并或切分为语义完整的 Chunk，同时支持配置重叠率（Overlap）与子块分隔符。
- 图表独立保护与坐标继承：HTML 表格与带 VLM 描述的图片区域不会与普通正文混切，而是作为独立切片（或携带上下文窗口）保留，防止《钻孔见矿成果表》被从中间腰斩。同时，当多个 PDF 文本框合并为一个 Chunk 时，它们的页码与矩形坐标（Bounding Box）会以数组形式完整继承到 Chunk 元数据中。
- 双模索引与特征落盘（Tokenizer） ： 每个 Chunk（叠加可选的 LLM 抽取关键词/问题后）并行产出两路核心数据：
- 全文索引侧：调用底层 C++ 分词器绑定，生成细粒度分词串（content_ltks / content_sm_ltks）以及标题分词（title_tks），解决地质专有名词的复合匹配问题。
⛏️ 地质术语双粒度分词示例： 假设某切片原文为： “北东向韧性剪切带控制了蚀变岩型金矿体的空间产出，钻孔 ZK305 在孔深 215m 处见黄铁绢英岩化碎裂岩。”
- 粗粒度分词（content_ltks） ：产出 北东向 / 韧性剪切带 / 控制 / 蚀变岩型金矿体 / 空间产出 / 钻孔 / zk305 / 孔深 / 215m / 黄铁绢英岩化 / 碎裂岩。保证了当用户搜专业长词“蚀变岩型金矿体”时的高精度短语匹配。
- 细粒度二次切分（content_sm_ltks） ：在复合长词基础上进一步拆解出 韧性 / 剪切 / 剪切带 / 蚀变 / 蚀变岩 / 金矿 / 矿体 / 黄铁 / 绢英岩。这样即便地质员在检索时只输入简写“绢英岩金矿”或“剪切带控矿”，依然能通过细粒度词项实现高召回命中，彻底消除长尾复合词搜不到的问题。
- 向量索引侧：按模型最大批处理限制批量调用 Embedding 模型生成稠密向量。系统内置了 Per-chunk 向量缓存机制，结合 Canvas DSL 的节点状态管理，当任务因网络抖动中断重跑时，可直接复用已计算的向量，实现低成本断点续跑。
- 最终写入：分词串、稠密向量、页码坐标元数据，连同用于提升核心权威文档（如最终评审备案版储量报告）排序权重的文档级图特征（PageRank 特征），被一并持久化写入 Elasticsearch 或 Infinity 检索引擎。
四、 读路径：双路混合检索与二次打分服务
当用户发起提问时，系统进入核心混合检索服务，通过“引擎层粗召回 + 服务层精算分”的两阶段设计，兼顾高召回率与高准确率：
- 引擎内双路混合召回（Hybrid Retrieval） ：
- 稀疏侧（Sparse） ：查询构造器对用户问题进行分词，生成全文 Match 检索表达式。
- 稠密侧（Dense） ：Embedding 模型将问题转化为查询向量，构造向量 kNN 检索（默认 topK = 1024）。
- 搜索引擎在单次查询请求中同时执行上述两条路径，并通过引擎内置的融合（Fusion）表达式拉取初步合并的候选集。
- 服务层二次打分（Rescore）与 Rerank 精排： 拿到候选切片后，检索服务层会基于精确的词项匹配度与向量余弦相似度进行显式二次加权打分： \(\text{sim} = (1 - w) \cdot \text{termSimilarity} + w \cdot \text{vectorSimilarity}\) 其中 \(w\) 为向量相似度权重（默认 0.3，即默认 0.7 权重侧重关键词精确匹配，0.3 权重由向量辅助语义泛化）。
- Rerank 覆盖：若知识库配置了外部 Rerank 交叉编码器模型，系统会对候选集前 N 条（默认 64 条）进行深度语义交叉重排，用 Rerank 得分主导最终排序；未配置则直接采用上述混合加权分。
- 阈值过滤与智能容错兜底：
- 阈值截断：按相似度阈值（默认 0.2）过滤掉低分噪声切片，排序分页后返回 Top Chunks 及文档级聚合统计。
- 降级重试兜底：若首轮检索遭遇“零命中”，系统会自动放宽条件（降低全文检索的最小匹配比例并下调向量阈值）发起二次重试；同时针对纯描述性查询提供跳过关键词限制的纯向量（VectorOnly）检索模式。
⛏️ 探矿检索全链路实战示例：
假设总工程师在对话框提问： “ZK305 钻孔在深部见到的富铜矿体，伴生金的品位是多少？围岩发生了什么蚀变？”
- 为什么单路检索会失效？
- 若只用纯向量检索：ZK305 与 ZK301、ZK308 在稠密向量空间里距离极近，向量模型极易发生“张冠李戴”，把隔壁 ZK308 钻孔的富铜矿描述排到第一名，导致大模型答错数据。
- 若只用纯关键词检索：报告原文写的是“含铜黄铁矿体”和“青磐岩化、硅化强烈”，并未直接出现提问中的“富铜矿体”和“围岩蚀变”字样，纯关键词匹配容易漏召回。
- 双路混合 + 二次打分如何破局？
- 稀疏侧通过分词死死咬住精确工程编号 zk305、伴生、au（金）、品位；稠密侧通过语义泛化捕捉到“青磐岩化/硅化”就是“围岩蚀变”、“Cu 2.85% ”就是“富铜矿体”。
- 在服务层二次打分时，因为默认词项权重占 0.7（\(1 - 0.3\)），包含精确编号 ZK305 的切片在 termSimilarity 上拿到接近满分，瞬间将 ZK308 等干扰钻孔甩在身后。
- Rerank 终极一击：前 64 条候选切片送入 Rerank 模型后，交叉编码器深度比对问题与候选切片，将**第 42 页的《表 4-2 钻孔见矿化学分析成果表》（含 ZK305 孔 Au 品位 0.85 g/t）与第 58 页的《ZK305 钻孔地质编录小结》（记载孔深 210~235m 发育强烈硅化与青磐岩化）**精准推至 Top 1 和 Top 2（综合得分均大于 0.85，远超 0.2 阈值），其余低分切片被干净截断。
五、 生成落地：上下文注入与多模态精准溯源
检索服务最终返回的每个 Chunk，不仅包含文本内容，还完整携带了综合相似度、词项相似度、向量相似度三维评分分量，以及从解析阶段一路透传下来的位置元数据。
上层的对话与智能体（Chat/Agent）运行时模块将这些高价值 Chunks 组装进 Prompt 上下文，驱动大模型生成带引用角标的回答。在前端溯源交互上，系统针对不同文档类型实现了分级精准回链：
- PDF 与图片文档（像素级高亮溯源） ：依托 DeepDOC 贯穿全链路的页码与 Bounding Box 坐标数组，当总工程师点击回答中“伴生金平均品位为 0.85 g/t [引用1] ”的角标时，前端 PDF 预览器会直接跳转至《详查报告.pdf》第 42 页，并在原始《钻孔化学分析成果表》的对应位置绘制高亮矩形框，连跨页表格和激电异常插图都能精准框定，方便工程师当场核对原始地质编录。
- Office / HTML / TXT 等流式文档（切片级视图溯源） ：由于流式文档（如 .xlsx 化验台账或 .docx 踏勘记录）无固定版面坐标，点击角标后前端会精准定位并高亮回链至对应的结构化文本切片或表格视图。
通过这套“多格式深度解析 \(\rightarrow\) 结构化双模入库 \(\rightarrow\) 混合召回重排 \(\rightarrow\) 像素级坐标回链”的完整闭环，该系统真正实现了企业级 RAG 知识库搜得准、答得对、查有据的生产级要求。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
The core pain of the RAG system in constructing enterprise-level LLM applications (e.g. mineral resources survey, engineering technical specifications, questions and answers) is often “unable to search, answer and trace”. A good knowledge base must not remain on a simple “cut + vector search” but needs to balance high-precision multimodular resolution, mixed recall, multi-stage reordering and precision traceability.
This paper will provide an in-depth analysis of the entire chain of the production stage RAG system, which is based on the sequence of true operational scenarios from macro-flow lines to the bottom core, combined with prospecting and geological survey information, the complete disassembly of the layout and performance bottlenecks of the library, multi-formatted diversions to PDF depths, a structured cut-off to double-mode indexing, two-way mixed search and double scoring, and a multi-modular precision retrospective.
Core Architecture Overview
📄Preliminary document >[1. Cascadewaterline] >DeepDOC + Structured Cuts > 🗄️Research Engine (ES)
│
User questions: [2. Retrieval services] - > Sparse + Dense kNN - ─ - Peter
│
[ Service Level Double Ratings / Rerank Platoon ]
│
[ Similarity threshold filter]
│
📝 Injecting Prompt -- > > Generates answers with precise references
I. Time-consuming analysis of the full flow of water into the reservoir and the project (writing paths)
The file is uploaded not immediately synchronized with the resolution, but with the data intake stream waterline engine. The entire library chain is driven by the Canvas DSL layout engine, which dismantles the task to a single six-state serial phase:
Upload > [NATS Queue Pending Schedule] > [Canvas DSL Schedule Execution] > Write Index Retrieval
│
read metadata in seconds
2. Parser - - Multiformat/DeepDOC Parsing (CPU intensive, time-consuming)
Ideas - 3. Chunker - - Structured Merge and Cut (pure text processing, very fast)
Ideas -4 Extractor - LLM extraction enhancements (I/O intensive, second time-consuming households after opening)
└5 Tokenizer - - C++ semiwords + Mass Embeding (with cache) + Indexing
- Task queued / running (queue) : Tasks written to NATS JetStream message queue, drawn from the ingestion service backstage Worker process. Practical Bottleneck Insight: Only one task is performed at the same time under the default single-shot configuration (max concurrent workers = 1). In the production environment, there is a pattern of "waiting 7 minutes, actually 3 minutes" - – The primary catcher for optimizing throughput is a rational increase in the volume of workker and hair, rather than blindly optimising single-point logic.
- [File] (Reading metadata): Lightweight pre-node, unloaded binary content of the file, only seconds to read and broadcast running metadata such as file name, storage path and tenant ID, knowledge base ID, languages, etc.
- [Parser] (departure of the file): The file binary is pulled back from the object (MinIO) by the document parsing component, which is deciphered by suffix flow. PDF takes heavy DeepDOC visual engine, office documents takes home light resolution. This is the largest calculation in the actual implementation phase.
- [Chunker] (intellectual cut-off): The dissected structural elements are strategically cut into slices, supporting many matching models such as universal, qa, table, manual, etc. 💡 Structured Smart Slicing Engine Depth Dismantling: In the architecture of the system, [Chunker] is the "weight wall" linking the front-end document resolution to the back-end vector search. The use of mechanical “fixed-length force-cutting” would necessarily cut off from the middle a complete geological tectonic description, a complex drilling test or a critical finding. To that end, the system has a multi-strategy cut-off model:
- General:
- Core logic: using the "Sliding Window + Natural Semantic Border Perception" strategy, with the chunk token size (default 512 Token) as a soft cap, giving priority to the natural separator (e. g., ?,,,,, \n) separated and supporting the Overlap configuration.
- Geological warfare: a coherent text applicable to large sections such as the Regional Geological Background, which guarantees the long discussion of smoothing split as semantic complete Chunk.
- QA (question-and-answer session):
- Core logic: Designed for question-and-answer sessions, normative texts or FAQ structures, identifying “Question (Q) and answer (A)” matching structures and binding them in the same slice.
- Geological warfare: applied to the Standard Classification of Solid Mineral Resources/Reserves. When asked by the chief engineer, the slice achieves zero delay precision.
-Table (part of table):
- Core logic: Keep the integrity of the table structure in no way cut from the middle horizontal; if there are too many rows of tables, the system uses the "Row-Header Inheritance" to automatically attach complex headers as context prefixes to each slice of split.
- Geological warfare: Processing of a log or test form for a 100-line drilling drill to ensure that the physical meaning of a particular line of laboratory data can still be restored through the header at the time of cutting and retrieval.
- Manual (book/ library level segment):
- Core logic: based on the title level of the DLA output (H1, H2, H3) expands the section by chapter, using the term “complete sub-chapter/technical clause” as the boundary and automatically injects macro-fruit navigation paths (e.g. [Chapter I] Geological characteristics of the mining area] > [Section III Controls the mining structure]] into each Chunk head.
- Geological warfare: dealing with hundreds of thousands of words of the " DZ/T 0214-2002 Survey Code ", ensuring that LLM is aware not only of the text but also of its chapter.
- [Extractor] (LLM extraction enhancements): optional information extract component. When you open it, you will use LLM for each slice and call LLM (with a default limit of 10) to generate enhanced information in high-dimensional terms to address the pain of "simplified presentation of professional documents and semantic divides with user language questions":
- Automatic keywords (Auto-Keywords): core entity and field terminology for the extraction of slices (e.g., the extraction of high weights such as bouldered copper ore, potassium silicate, brass mineralization belts, borehole ZK402 from the core description) and the granting of higher word weights in indexing.
- Automatic simulation questions (Auto-Questions / Reverse HyDE): From the perspective of the questioner, predetermines what kind of questions can be answered (e.g. on the automatic generation of the cause of the deposit: “What is the controlled structure of the gold mine in the eastern part of the study region?”). These created problems will be associated with the original language and will translate the “question search statement” into a “problem search” with a very high degree of match.
- summary and structured labels (Summary & Tags): Concentrate long paragraphs into core conclusion summary or automatically label operations according to preset systems (e.g. geochemical survey, hydrogeological conditions).
- Project costs: If this feature is not turned on, the node will jump directly empty; once it is opened, each slice will be required to initiate a request for LLM, which will be the second time-consuming household after Parser.
- [Tokenizer] (terms, to quantization and to Crash): The full-text search string and dense vector are generated by word and from quantization components and are eventually written into the bottom-up search engine layer. 💡 Storage engine comparison (Elasticsearch vs. Information): The bottom of the system does not bind a single database, but supports two different engines through a unified abstract interface:
- Elasticsearch (ES): The traditional distributed full-text search master based on Java/Lucene is based on a large and ecologically mature enterprise stock cluster; however, its vector-retrieving capability is post-production-enactment, with significant memory costs in responding to large-scale high-dimensional vector mixing with full-text calculations.
- Infinity: C++ Native AI database for LLM and RAG. It is a high-speed integration query supported by low-level natives for "bulk vector + thin vector + full text search" with high monotonous capacity and much lower memory occupancy than ES. Businesses can switch seamlessly depending on the state of infrastructure.
II. Core challenge: multiformulation and depth analysis of PDF
At the [Parser] stage, the system is confronted with a variety of document formats within the enterprise. In order to balance the speed of resolution with the accuracy of reduction, the solver uses the design philosophy of "suffying, severing ".
1. Overview of multi-document format resolution policy
The flow office document with the structure tree is taken directly from the original syntax tree (AST/DOM), while the PDF document without structure or layout is given to DeepDOC for the visual flow line:
Fluid office files (e.g., drilling data sheets in.xx format, field geological peddles in.doxx format) naturally maintain the logical tree of paragraphs and tables, with 100 per cent direct reduction by light-measurer. What really makes most RAG systems “false” are the PDF geological survey reports that are set free, lack unified logical trees and even mix historical scans. To this end, the system is based on a complete Go language transplant and optimizes the two-stage DeepDOC analysis engine for alignment with the original Python version.
PDF Phase I: separate and parallel water flows Line
The PDF enters the parser, and is initially moved by a simultaneous working pool with a separate, sequential 1 predetection and 5 core steps for each page. Normal PDF takes the same waterline with the scan, with the only fork in step two:
- Pre-step: extract the embedded character layer - the premise of the fork to call the bottom PDF render library (pdfium) to extract the embedded characters from the page and their precise coordinates. Normal PDF returns a large number of character-by-character coordinates (no line concept exists at this time); the scan returns empty. At the same time calculates the “false text layer” of medium characters high/wide (for subsequent consolidation paragraph judgement) and English page determinations, as well as scanned noise page determinations - to identify “false text layers” with surface layers but noises, and to enforce processing by scanning.
- Step 1: Render 216 DPI bitmap - A uniform input of the visual model will convert the page to 216 DPI bitmap, with or without a text layer. This is because the subsequent line frames testing (Det), layout analysis (DLA) and table recognition (TSR) are all visual models, pixels only and not text layers.
- Step 2: Get the Line Text Box - the only fork in the system flows dynamically to two processing paths depending on whether the page has a clean embedded character layer (a character, non-scan noise and non-discretion page) (see below for details).
- Step 3: DLA Edition Analysis - Gives semantic characters the opportunity to run a layout test model for the entire page map, to output a 10-class layout frame, and to map the role label back to the text frame of the second output (the illustration area will also include a synthetic frame).
- Step IV: TSR Table Structure Recognition - Dismantling the complex grid only triggers when step 3 DLA checks out the table (table) area: \(\rightarrow\) Run TSR model identification rows, columns, table headers and cross-line merged cells\(\rightarrow\) assemble cells into grids and fill cells with the second step line text (unfilled spaces and separate drawings to complete OCR)\(\rightarrow\) for each text box.
- Step 5: Zero output amplification of retry (Zoom Retry) triggers the magnification rerun and reruns OCR + DLA if a box after four steps is not produced (usually because resolution is too low or very small).
3. Dismantling of the three core dilemmas and architecture
Among the page-by-page water lines, there are three key designs that determine systemic performance, stability and accuracy:
Harder A: Normal PDF vs. Scanner Cost and Path Crossing (step 2)
💡 Structure Resolution: Internal DeepDoc Specialized Model vs. Interface VLM Enhancement Plugin
- Four built-in DeepDoc models (ONNX): infrastructure packaged with products (Det, OCR Rec, DLA, TSR), which need not be configured and cost zero token based on ONNX Runtime 's reasoning within the CPU local process. They are responsible only for “positioning frames, ids, layouts, table structure” and do not understand what the picture is (only knowing whether it is a figure or whether it is a traffic map of the mine).
- External VLM enhancements (e. g. GPT-4o-mini): Tenant-level remote API configuration. Upon completion of the analysis, the illustrations/forms from the DLA are sent to VLM to describe the content of the image in natural languages (e.g. output: “figure 3-2 shows the profile of the reverse fault cut through the granite in the north-east to F1 and the main mine is deposited in the broken disc tape under the fault) and converted into retrievable slices. Not worthy of VLM main process running as usual, except for chart semantic search capability.
Difficulty B: 10 large semantic label for DLA layout analysis (step 3 to dismantle)
The category index of the layout model output is strictly mapped from the 10 semantic characters in the layout label definition table:
- Why is the 4/7/9 duplicate? The label is a strict online protocol to align the original Python DeepDOC model. The original model does not modify the output layer dimension when training the merged category, and therefore the project transplant must keep duplicate slots in their original form to accommodate the model weights.
- Core values: OCR solves only what the word is, and this 10-class label solves what the content plays in the document. It is a watershed that distinguishes between layout analysis and pure text recognition.
Hard spot C: Triple hard nuclear protection against an upsurge in memory (step 5 dismantling)
In step 5 Zoom Up Z97Z (Zoom Retry), the bitmap memory shows a square increase with the magnification multiplier. Faced with a pathological scanning page, it takes several minutes to distribute the local memory and even directly trigger OOM (the memory spill crash).
⚠️ Large geological map OOM Real accounting example:
In the archiving of prospecting information, the report is often accompanied by either a map of the geological topography of the A0 area of 10000 or a joint profile of the exploration line (approximately physical dimensions \\(46.8 \times 33 inches)).
- First wheel rendering: Rendering on base 216 DPI, pixels approximately \ (1010 \times 7150 \approx 72 \ text{mix}) (by bottom-cut is actually close to budget ceiling).
- Catastrophe unprotected magnification: if the first round of "zero output" is triggered by a lot of blanks on the surface and too small the legend, for example, 3 times the retry (648 DPI), 3 times the width, 9 times the total pixels!
- Memory crash: this uncompressed RGBA bitmap alone requires the occupancy of a continuous primary memory \\(6.5\text{billion}\times 4\text{Bytes}\approx\mathbf{2.6\text{Gib}}\; calculation of the short-term memory of the old and new bits and the intermediate mass of features in the analysis of the ONNX visual model will exceed 4~5 GiB on a single page. If at this time there were four simultaneous workpools and Worker simultaneously processed a similar large figure, the instant 20 GiB memory summit hit the cap on container memory and caused the process to get OOM Kill.
The system has built a triple defence line for this purpose:
- A narrow trigger and a multiple cap: retry was triggered only by the first round of the “zero output” page; and retry was rigidly capped by 9.0 times the upper limit.
- Pre-rendering of pixels: Before entering the base renderer's distribution memory, project the new bitmap size using the first wheel width multiplied by the squares magnifying the multiplier. Once the budget of 48M pixels (approximately 48 million pixels) is exceeded, the dangerous memory distribution of the above-mentioned large geological folds is stopped directly outside the door by abandoning retry and retaining the results of the first round.
- Thrusts inside the renderer: the bottom PDF rendering engine carries its own ultimate defense line, and the calculated pixel excess automatically reduces the resolution zoom (scale) proportionally to ensure that any single rendering output does not exceed 48M pixels (approximately 192 MiB RGBA). The RAM peak of the entire resolve pool is strictly confined to the perimeter safety of the combined worker number x ~200 MiB.
PDF Phase II: Document-level global assembly and operational process exercise
When text frames, tables and DLA sections of all pages are aggregated by page number, cross-page global organization is carried out in the document-level layout phase:
- Column recognition: priority is given to double/multi-column layout and column numbering (must be performed before renumbering to prevent similar short lines across columns from being incorrectly deleted).
- Global noise-cutting: elimination of overlapping frames and background water printing (e.g., “Intra-geological information is strictly forbidden to be transmitted” in italics); automatic removal of header footers through page-to-page statistics (e.g., “Report of the Survey of Gold and Copper Mines in XX Provinces” at the top of more than half of the page); removal of the entire table of contents (TOC) with PDF bookmarks and morphological features.
- Reverts the paragraph: \\ (\rightarrow\) In the order of reading by column, \\rightarrow\) The English cross-line hyphenation \\ (\rightarrow\) is merged with the vertical natural part of the character text.
- Alignment of tables with graphics: implement the consolidation of cross-page tables and remove the scattered table boxes from the main stream and replace them with structured HTML table objects; eventually convert the text box streams into final structured paragraphs (sections) and load the illustrations, notes and precise notes to the corresponding chart objects.
• A full process exercise for the analysis of prospecting reports (for example, the Geological Report on the Detailed Examination of Copper Molybdenum Deposits in a Qinghai Province).
Assuming that this is a PDF report that is mixed with modern electronic layouts of the historical scanning pages of the 1990s, page 42 to 43 contains a double-column version of the main text, a map of 4-1 mine stimulant electrical abnormalities, a cross-page table 4-2 drilling layers and chemical analysis results table, and a mathematical formula for estimating the amount of copper metal using industrial indicators:
- Page by page: Page 42 is a modern electronic page, the system uses the detection box to define the embedded characters, zero OCR recognizes the time-consuming text, except for the ore chemical formula, which was supplemented by automatic drawings for lack of special font coding; page 43 is a manual stamp scanned page for the older geology team, the system automatically cuts the full OCR path and rotates automatically 90° of the "rock name" column within the table.
- Role pairing: DLA labels double-column text as text, and reserves calculation formula (Q = V \cdot d \cdot \bar{C}) as independent protection; displays power abnormalities and bottom descriptions as figure and figure cap.
- Cross-page table suture: TSR identifies a half table at the bottom of page 42 and a continuation at the top of page 43 (complex cross-column head of table containing “Little body number”, “D drill number”, “Pretty thickness (m)), “average grade Cu (%/Mo)”). During the global assembly phase, the system automatically removes the two-page middle-linked header footers, stitches the two tables seamlessly into a complete HTML <table> and mounts the notes precisely above the table.
III. Structured slices and double-mode index construction (data interface bar)
After the parse phase, both PDF and Office documents are converted to structured text paragraphs (with layout type and page number coordinates), HTML table objects and photographic resources. Next, the data transfer bar to the breaker and the semiword to the quantization component:
- Schunker:
- General text severing: In the case of a universal breaker, the system combines or cuts text segments to semantic complete Chunk by natural separator (\n,,,,,,, etc.) and Token threshold (default 512 Token), while supporting the configuration of overlap (overlap) and segment separators.
- Independent protection of charts and coordinate succession: the HTML form and the picture area described with VLM are not mixed with the normal body, but are retained as a separate slice (or with context window) to prevent the drilling of the mineral results table from being cut in the middle. At the same time, when multiple PDF text boxes are merged into one Chunk, their page numbers and rectangular coordinates (Bounding Box) are inherited in complete array form to the Chunk metadata.
- Two-mode index and feature droper: each chunk (after the optional LLM extracts keywords/questions) produces two-way core data:
- Full text index side: Call on the bottom C++ syllable to create a fine-particle syllable (content ltks/content sm ltks) and a title syllable (title tks) to solve the problem of composite matching of geo-specific terms.
An example of the two-particle fraction of geonomic terms: assuming that the original slice is: “The north-east towards the tenacity cutting band controls the spatial output of the corrosive rock-shaped gold ore, drilled through ZK305 and seen the yellow iron plume in a depth of 215 m.”
- Coarse granular fractions (content ltks): Output / resilient cutting band/control/corrosive rock-type gold ore/ spatial output / drilling / zk305/pore depth / 215m/ brackish rock. High-precision phrases are guaranteed when the user searches the specialized long term “crushing rock-shaped gold bodies”.
- Content sm ltks: Further disassembly/ shear / cut / corrosive / corrosive / gold mine / mine / yellow iron / icy rock based on complex long words. Thus, even if the geologist were to enter only a short “screen rock gold mine” or “clipband control mine” at the time of the search, it would still be possible to achieve a high-recall result through fine-particle words and eliminate the problem of long-tail complex words that could not be found.
- Vector index side: Embedding model is used to generate dense vectors in the largest volume of models. The Per-chunk vector cache mechanism has been installed in the system, combined with the Canvas DSL nodal state management, which allows the mission to rerun by using the calculated vector directly when the mission is interrupted by network shaking, and achieves a low-cost break.
- Final writing: semi-strings, dense vectors, page code coordinates metadata, together with document chart features (PageRank features) to enhance the ranking weights of core authoritative documents (e.g., final review of a file-filed storage report), are permanently written into Elasticsearch or Infinity search engines.
IV. Reading paths: two-way hybrid search and double scoring service
When the user initiates the question, the system enters the core hybrid search service, balancing the high recall rate with the high accuracy rate with the two-stage design of the "Framework of engine-level recall + service-level actuarial fraction":
- Double-track recall within engine:
- Sparse: Query constructor severs user questions to generate full Match search expression.
- Dense: Embeding model converts the problem into a query vector, constructs a kNN search (default topK = 1024).
- The search engine executes both of the above-mentioned paths in a single query request and pulls the initial combination of candidates through the integration (Fusion) expression embedded in the engine.
- Second scoring of service level (Rescore) and rerank fine rows: Upon obtaining the candidate slice, the search service layer is given a numeric double weight rating based on the exact match of words with the vector cosine: \\(text{sim}=(1-w)\cdot\text{termSimilarity} +w\cdot\text{vectorSimilarity}\\\) of which \\w\w\) is the weight of a vector similarity (default 0.3, i.e., default 0.7 weight focuses on the exact match of key words, 0.3 weight is transposed by a vector-aided language).
- Rerank overwrite: If the knowledge base is configured with an external Rerank cross-codifier model, the system will reset the N-codings (default 64) in depth and cross-segregated, with the Reran score prevailing in the final sorting; without configuration, the above-mentioned mixed weights will be applied directly.
- Threshold filter and smart tolerance bottom:
- Threshold cut-off: filter low-point noise slices by similarity threshold (default 0.2), sort pages and return to Top Chunks and document-level aggregation statistics.
- Decreasing retry: If the first round of search encounters a “zero hit”, the system automatically relaxes the conditions (reduces the minimum matching ratio of full-text search and lower the vector threshold) and initiates a second retry; and provides a pure vector (VectorOnly) search mode of jump cleared keyword limits for purely descriptive queries.
Example of full chain of search for prospecting:
Suppose the chief engineer asks in the dialogue box: "What is the grade of the gold accompanying the copper ore that ZK305 saw at the bottom of the drill? What happened to the corrosive rock?"
- Why is the single-circuit search not working?
- If only in pure vectors: ZK305 and ZK301 and ZK308 are very close in dense vector space, vector models are highly likely to occur "Chang Li" that rank the rich copper mine next to the ZK308 drilling hole first, leading to LLM's incorrect answer data.
- If only in pure keywords: The original language of the report is “blown ore” and “rocked, silicized” and the words “rich copper ore” and “crazed rock” in the question do not appear directly, the exact keyword matching is easily retraceable.
- Two-way mix + double scores?
- The thin side bites precise project numbers zk305, companion, au (gold), grade; the dense side captures “blown rockization/silicate” by synonymization, i.e. “cru 2.85” or “rich copper ore”.
- At the secondary scoring of the service level, because the default word item weight is 0.7 (1 - 0.3), the slices containing the exact number ZK305, received close to full score on the termSimilarity, and the interference drills such as ZK308 were dumped behind the back of the body.
- Rerank Final Strike: After the first 64 candidate slices were sent into the Rerank model, the cross-codifier depth compared to the problem with the candidate slice, with table 4-2 on page 42, ** Table 4-2 Drill chemical analysis results table (which contains ZK305 perfork Au grade 0.85 g/t) and ZK305 geological compilations on page 58 (recording depth 210 ~235 m developmental strong siliation and rockization)** accurately pushed to Top 1 and Top 2 (complex scores greater than 0.85, far above 0.2 threshold), with the rest of the low-sliced slices being cut clean.
V. Generating land landing: context injection and polymolecular precision traceability
The search service eventually returns to each Chunk, which not only contains text content, but also completes the composite similarity, word-similarity, 3-D scoring of vector-similarity, and location metadata that are passed through from the resolution stage.
The upper-level dialogue and the AI agent (Chat/Agent) run-time module assembles these high-value Chinks into Prompt context, driving LLM to generate a response with a reference cursor. In front end tracer interaction, the system achieves a hierarchy back chain for different document types:
- PDF and photo files (high pixel-level bright tracer): depending on the page number of DeepDOC running through the entire link and the number of Bounding Box coordinates, when the chief engineer clicks on the corner sign "Auxiliary gold averages 0.85 g/t [reference 1]", the front end PDF previewer will jump directly to page 42 of the DIDR.pdf and draw high-light rectangular frames at the corresponding position of the original Drilling Chemical Analysis Results Table, with cross-page tables and hottension illustrations that are precise enough to allow engineers to check the original geological record on the spot.
- Office / HTML / TXT-style document (script-level view tracer): Since the current document (e. g..xlsx lab account or.docx foot record) does not have fixed layout coordinates, clicking on the front end of the corner mark will position precisely and give high visibility back to the corresponding structured text slice or table view.
The complete closed loop of the Multiformation In-depth Analysis (\rightarrow\) Structured Double Modified Library (\rightarrow\) Mixed recall re-alignment \\(\rightarrow\) Pixel-level Coordinate Returning Chain (\rightarrow\) system actually fulfils the requirements of the production level of the Enterprise RAG knowledge base.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.