去年我们把一份推理引擎的评测白皮书塞进自建 RAG 知识库——文件里充斥着高密度的技术图表：A100 与 H20 在不同 Batch Size（1~128）下的 TensorRT-LLM 吞吐柱状图，以及一张融合了七款主流推理框架显存占用、首 Token 延迟与长序列衰减的对比表格。上线当天，一位工程师提出了一个再正常不过的检索问题：“在 A100 上，Batch Size 为 32 时系统的吞吐量是多少？”系统在不到一秒内吐出了极其流畅且语气笃定的回答：“约 3800 tokens/s。”问题在于，这个数字是大模型凭空织出来的幻觉。白皮书评测表格中真实记录的数据是 4200 tokens/s。那张关键的吞吐柱状图，连同周围的对比表格，在文档切分入库的那一刻起，就彻底从向量索引空间中蒸发了。LLM 在下游拿不到任何物理上下文证据，只能根据 Prompt 的语法惯性，硬生生“圆”出了一个看起来毫无破绽的假数据。这一工程惨案直接拉响了警报，也揭示了一条贯穿多模态 RAG 架构设计的硬核铁律：带图表的技术文档能否被准确检索，胜负手绝不在 downstream 问答环节是否挂载了 VLM（视觉语言模型），而在于在 upstream ETL（解析/入库）阶段，图表中的非结构化视觉语义是否被精准提取、结构化标定，并与其关联正文紧密锚定在同一片向量邻域（Vector Neighborhood）中。哪怕你在 RAG 尾端接入了参数量再庞大的视觉大模型，一旦图片在入库抽取时退化为一行毫无语义权重的死占位符（Placeholder），它就永远无法被 Embedding 向量化命中，下游的视觉推理能力便成了空中楼阁。本文将彻底拆解图文混排文档在 RAG 入库链路上的“语义消失术”与终极重构方案。