企业文档检索：先修好入库流水线

企业文档搜不准，问题可能出在 PDF 进入索引之前：表格被拆散，扫描签字页没识别，旧制度和新制度混在一起。原文的核心判断是，先把解析、切块和元数据做好，通常比急着换向量模型更有价值。

这套思路适合正在做企业知识库或 RAG（检索增强生成）的团队。它把「搜不到」拆成了可以排查的工程问题，也给出了一批起步参数。不过，文中的成本、速度和效果提升数字缺少完整实验条件，需要和实施建议分开看。

为什么 PDF 里的字提出来了，答案还是找不到

PDF 的视觉顺序，不一定是机器读出的顺序。双栏正文可能串行，页眉页脚可能混入段落，表格可能退化成一串空格分隔的文字。下游拿到这样的输入，检索模型很难恢复原来的关系。

作者建议，解析结果应保留标题、段落、列表、表格等类型，每个元素带页码和坐标。这能让后续切块知道哪里是边界，也让答案有机会定位回原页。

扫描检测则要逐页做。真实文件可能正文有文本层，最后一页签字是扫描图。原文给出的启发式是：每页提取后统计字符，少于约 40 个字符的页面，再送去 OCR（光学字符识别）。这个阈值适合起步，但空白页、图片页、短标题页也可能触发，不能把它当成扫描页的确定判据。

工具按文档类型分配：简单数字文件用轻量提取器，表格密集文件选支持表格网格的库，复杂版式选能输出类型化元素的解析器，PPT、电子表格、旧版 Office 和邮件等长尾格式可交给 Apache Tika 一类通用服务。原文列出的候选还有 pypdf、pdfplumber、pdfminer.six、unstructured.io、PyMuPDF、Marker 和 Tesseract，并未给出它们之间的实测排名。

原文引用的资料称，普通文字的标准 OCR 比视觉模型快 10–20 倍；对旧扫描件和传真，经过纠偏、去噪、二值化，再做高分辨率 OCR 和模型后校正，错误率通常可从 15–20% 降到 3–5%。其 2026 年建议是让 OCR 处理文字，让视觉模型处理图表和复杂版式。方向合理，具体收益仍取决于材料质量。

切块先看结构，表格尤其不能随手截断

固定字符数切块容易制造一种隐蔽故障：标题留在上一块，解释落到下一块；问题和答案各占一边。每块都能成功生成向量，语义却已经残缺。

作者建议按「标题 → 段落 → 句子」寻找边界，最后才用长度上限兜底。起步范围是 300–800 tokens，相邻块重叠 10%–20%，约 50–150 tokens。技术合同、论文等密集内容可以偏小，叙述性内容可以偏大，最终用问题集验证。

切在哪里，比切多长更先决定内容是否完整。

表格应尽量作为完整块保留；放不下时按行拆，每份重复表头，避免数值和字段名称分离。例如报销标准里的金额，离开对应的职级、地区和币种，就很难成为可靠答案。

生成嵌入前还要做确定性文本规范化和去重，让相同内容得到相同字节表示，减少重复计算。这里有两个不同问题：去重解决重复段落，合理切块解决超长内容稀释向量语义，不能指望只做去重就修好切块。

找文件和找答案，需要不同的检索入口

「找上季度的供应商合同」要求系统判断整份文件；「差旅报销审批需要几天」则要求定位某一句话。

原文建议同时保留文档级和块级检索：前者每份文档一个向量，提供整体候选；后者每个块一个向量，定位具体内容。两路结果合并，再重排序。文档级检索定位粗，块级检索依赖切块质量，组合能互补，但也增加索引和排序维护工作。

另一组互补是关键词与语义检索。查询 POL-4827 这样的编号时，精确匹配更直接；询问员工境外出差规则时，语义检索更容易跨越措辞差异。原文将两路召回合并后重排序视为文档场景的常见配置，但没有提供相对单路检索的对照数据。

验证时要分清两类样本：用 50–100 个代表性问题检查召回，用 50–100 份代表性文档检查解析。前者看正确材料能否被找到，后者看输入是否已经损坏。

解析参考目标包括字符错误率控制在 5%–10% 以内、与基准文本的相似度高于 0.85、版面区域检测 F1 高于 0.90、图表数据提取准确率高于 0.80。文末将相似度指标写为 BLEU，但没有交代计算和标注细节；这些数值可以帮助设计检查项，尚不足以直接充当统一验收线。

可追溯、版本和权限，要在入库时就安排好

每个块至少需要来源文件标识、页码、章节路径、块序号和内容哈希。原文正文使用 doc_id，参考资料也列出 document_id/page/section/chunk_index 这样的字段形状。

这些信息各有用途：页码和章节用于展示来源，内容哈希用于识别重复写入。审计若要追到原文某一行，还需要字符偏移等定位信息；前面所说的坐标也应保留下来。

作者推荐三层数据组织：原始层保存源文件字节和清单，以文件哈希识别；中间层保存解析后的页面和类型化元素，方便重跑处理；成品层保存清洗、切块、去重后的内容，附带内容派生的 chunk_id 和来源字段。写入使用幂等 upsert，即重复处理未变化的文件，不产生重复记录。

版本需要单独管理。同一制度可能从 V1.0 到 V3.2，旧条款不能仅因语义更匹配就排到前面。文档元数据应记录版本号、生效日期和废弃状态，检索时过滤或大幅降低过期版本权重，chunk ID 也要包含版本信息。旧版本通常保留供历史查询和审计使用。

权限则要随块进入索引，通过访问控制列表（ACL）在检索时预过滤。若先召回越权内容，再由页面隐藏，内容可能已经进入答案生成环节。

我的判断

我赞同把排查顺序前移。表格关系已经丢失、签字页根本没入库，换模型无法补回缺失信息。这套检查顺序比一上来调整向量参数更容易定位故障。

但原文更接近经验指南，缺少作者亲自开展、可复现的对照实验。它引用「解析改善使端到端效果提升 15%–25%」，却没明确效果指标和基线。每月 10,000 页的成本比较也只给出粗略量级：云文档智能服务十几美元，自建开源方案免许可费但另算 GPU，开源文本解析加视觉模型处理图表约 $50。缺少页型、调用量和维护成本，不能据此直接做预算。

还有两个边界要补清。内容哈希适合去重，却不能代替版本和权限身份；相同段落可能属于不同文件、不同授权范围。版本进入 chunk ID 后，也不会自动替换旧块，系统仍须明确哪些版本可以被检索。

原文最后推广 Tengence Search，并关联 Tengence GEO 的 GEO + SEO 业务。因此，通用工程建议可以采纳，产品是否兑现了可靠召回和权限控制，仍要独立验收。

能拿来做什么

• 给现有知识库准备 50–100 个真实问题，分别覆盖找文件、找答案、编号、表格和旧版本，并记录故障发生在解析、召回还是排序环节。
• 在 Node 入库流程中逐页检测文本量，保存类型化元素，对表格保留表头和行列关系，再用 300–800 tokens、10%–20% 重叠作为切块起点。
• 在前端结果页展示文件名、页码、章节和版本，让用户能回到来源核对；对应字段应由入库流程提供。
• 在扩大量级前验证权限预过滤、版本生效规则和幂等 upsert，确认重复导入不堆积数据，普通查询不会优先返回废弃条款。