考察点
这道题考的是你踩没踩过真实文档的坑。面试官想区分两种候选人：一种只会 PyPDF2.extract_text()，另一种知道 PDF 分文字版和扫描版、表格抽出来是一坨乱码、跨页表格和合并单元格怎么处理。追问常往「表格怎么切块」「图片内容要不要向量化」「解析质量怎么评估」走。
参考答案
先分流：文字版还是扫描版
入库第一步是判断 PDF 类型，两条路完全不同。判断方法很简单：用 pdfplumber 或 PyMuPDF 抽几页文本，如果一页抽出来的字符数接近于零，或者全是乱码控制符，基本就是扫描件（图片型 PDF）。还有混合型——主体是文字但关键图表是截图，这种按块处理。
文字版 PDF：难点在版面，不在文字
文字版 PDF 的文本可以直接抽，但 PDF 本质上是个「绘制指令集合」，没有段落、标题、表格的概念，抽取顺序经常乱（双栏论文左右栏文字交错是最经典的坑）。工程上常用方案：
- PyMuPDF / pdfplumber：快，适合版式简单的文档，但复杂版面会乱；
- Unstructured：按元素类型（标题/正文/表格/列表）打标输出，切块友好；
- 版面分析模型（如 LayoutLM、PP-StructureV2、MinerU）：先用检测模型框出标题、正文、表格、图片区域，再按阅读顺序重排，复杂版式（双栏、图文混排）效果明显更好，代价是慢，需要 GPU。
标题层级信息要保留下来——切块时按标题层级切比固定 500 字硬切质量好得多，而且标题可以写进 chunk 的元数据，检索时带上「这段属于哪一章哪一节」的上下文。
表格：抽结构，别抽文本
表格是重灾区。直接 extract_text() 得到的表格是一串失去行列关系的文字，embedding 后基本检索不到。正确做法是表格识别（PP-Structure、Camelot、MinerU 都能做），还原成结构化格式，然后两种入库方式选一或混用：
- 转 Markdown 表格作为 chunk 文本，LLM 对 Markdown 表格的理解不错；
- 转成自然语言描述或逐行「列名: 值」的扁平文本，对小模型更友好。
两个工程细节：一是跨页表格要检测表头重复并合并，否则下半页的数据行失去表头就没有意义了；二是合并单元格要展开填充，不然行列错位。表格 chunk 前面最好补一句表标题和上下文说明（「下表为 2024 年各季度营收」），单独检索到这块时语义才完整。
扫描件：OCR + 版面分析
扫描件必须走 OCR。通用中文场景 PaddleOCR 是默认选项，中英文混排、识别精度和速度都比较均衡，开源可私有化。流程是：PDF 每页渲染成图片（300 DPI 左右，太低影响识别率）→ 版面分析框出文字区/表格区/图片区 → 文字区走 OCR，表格区走表格识别，图片区单独存。OCR 的置信度要存下来，低置信度页面打标，后续可以人工复核或换更强的模型重跑。
图片内容：三种处理策略
文档里的插图（架构图、流程图、图表）有几种选择：
- 只存图：chunk 里存图片路径/URL，检索命中后在生成阶段把原图喂给多模态模型（GPT-4o、Qwen-VL），文字 chunk 和图片建立关联；
- 图生文：入库时用多模态模型给每张图生成一段文字描述（caption），caption 参与文本向量化，检索靠描述，生成时带原图；
- 不处理：纯装饰性图片直接丢弃，靠版面分析的尺寸和位置过滤掉页眉页脚 logo。
文档型知识库（财报、论文、技术手册）推荐「caption 检索 + 原图生成」的组合，纯文字向量检索丢的信息太多。
质量评估与兜底
解析质量要有可量化的抽检：随机抽样对比 OCR 文本和原图、统计表格识别后的行列完整率。低质量文档进库比不进库更糟——错误文本被检索到会理直气壮地误导生成。重要文档（合同、财报）建议保留原页截图，回答时引用原文页码，让用户可以溯源核对。
可能的追问
- 双栏论文抽取顺序错乱怎么解决？——上版面分析模型按视觉块重排阅读顺序，别指望按 PDF 内部绘制顺序抽；MinerU 这类工具对学术版式有专门优化。
- 表格 chunk 应该多大？——小表格整体一个 chunk；大表格（几十行以上）按行分组切，每组带上表头；超大表格考虑结构化入 SQL 库走 Text2SQL，而不是塞进向量库。
- 解析一份 100 页扫描 PDF 要多久？——PaddleOCR CPU 大概几秒一页，GPU 快一个数量级，生产上解析任务必须异步化，入库走任务队列，用户上传后先给「处理中」状态。
- 怎么判断解析结果够不够好可以入库？——抽文本长度/页数的比例、OCR 平均置信度、表格识别成功率三个指标设阈值，不达标的进人工复核队列。