考察点
这道题出自阿里淘天大模型校招面试，属于 RAG 数据工程题。面试官想淘汰只会说「切成 chunk 丢向量库」的人——真实业务文档格式混杂，解析质量决定检索上限。关键得分点：分格式专用管线、PDF 难在哪、表格怎么保结构、解析错误如何传导到下游。追问会往具体工具选型、解析质量怎么评估、扫描件怎么办走。
参考答案
总体设计：统一入口，分格式专用管线
不要幻想一个解析器通吃。我的做法是建一个解析网关：先按 MIME 类型/文件头探测格式，分发到各自的专用处理器，最后统一归一化成「带元数据的文本块」进入切分和索引。元数据里保留来源格式、页码、表格编号，后面检索过滤和答案引用都靠它。
文件 → 格式探测 → ┬ PDF 处理器（版面分析 + OCR 兜底）
├ 网页处理器（正文提取 + 去噪）
├ Office/Markdown（结构化解析）
└ 表格文件（结构感知抽取）
→ 统一中间格式 → 切分 → 索引
为什么 PDF 最难：它是给眼睛看的，不是给程序看的
PDF 里存的本质是「把字符画在坐标上」，阅读顺序、段落、表格全是视觉概念，程序要自己重建。坑按严重程度排：
- 多栏排版：双栏论文按坐标抽文本会把左右栏交错混成一行，直接毁掉语义。需要版面分析模型（文档版面检测类模型先框出标题/正文/表格/图片区域）再按阅读顺序重排。
- 表格：无线表、合并单元格、跨页表格，用通用文本抽取直接变成一团散字。得用专门的表格结构识别（如 pdfplumber 按线框提取、或专门的表格识别模型），抽成 Markdown/HTML 保留行列关系。
- 扫描件：纯图片 PDF 一个字都抽不出来，必须走 OCR 分支，而 OCR 噪声又会污染下游。
- 页眉页脚、公式、图表说明：不剔除会稀释检索质量。
工程上一般组合使用：PyMuPDF 快速探路、pdfplumber 处理表格、MinerU/unstructured 这类带版面模型的工具处理复杂文档、OCR（如 PaddleOCR）兜扫描件的底。
网页：难在噪声不在结构
HTML 结构是现成的，麻烦的是样板内容：导航栏、侧栏推荐、广告、评论区。「正文提取」是关键一步，用 readability 类算法或基于 DOM 密度/规则的正文识别，把标题层级（h1-h3）保留下来——它们天然是切分的语义边界。电商场景特别注意：商品页的核心信息（价格、参数）常在结构化区块里，按正文算法提取反而可能丢掉，需要针对站点模板定制规则。
表格：千万别拍平成纯文本
Excel/CSV 直接转纯文本，「哪列是哪列」的信息就丢了。常用策略三种：
- 序列化保留结构：转成 Markdown 表格或「列名: 值」的逐行描述文本，让 embedding 能抓住字段语义；
- 大表拆分：按行块切分，每块重复表头，保证任何一块都自带列语义；
- 能查库就别检索：结构化数据优先走 Text-to-SQL 或工具调用，RAG 只管非结构化部分——这是很多人忽视的架构判断。
解析质量决定检索上限，怎么兜底
预处理层的错误会放大传导：表格拍平→向量表示失真→召回错误→模型基于错误上下文自信回答。所以要在解析层加质量门禁：抽样人工检查、解析后文本长度/乱码率监控、表格抽取的行列完整性校验。评估端到端效果时，也要把「检索错误归因到解析错误」的比例单独统计，不然你会一直在调检索参数，而病根在 PDF 解析。
可能的追问
1. 扫描件多的场景怎么设计？
OCR 前置 + 置信度过滤，低置信块打标降级；有条件上版面模型先分区域再分区域 OCR；预算允许时表格区域用专门的表格识别模型而不是通用 OCR。
2. 切分策略要按格式区分吗？
要。Markdown/HTML 按标题层级切最自然；PDF 按版面块切再按长度合并；表格按行块切。统一按固定 token 数硬切是万不得已的下策。
3. 图文并茂的文档（图里有关键信息）怎么办？
两条路：图说生成（用多模态模型给图片打描述文本进索引），或多模态 embedding 直接索引图文混合块。前者便宜可控，后者效果好但成本高。