OCR 结果进入 RAG 前怎么保留页码和版面坐标

OCR 结果进入 RAG 时，最容易犯的错误是把所有页面拼成一个字符串，再按字符数切块。这样虽然能生成向量，却丢掉了“这句话来自第几页、页面哪个区域、能否回看原文”这条证据链。更稳妥的做法是：把 OCR 输出先归一成带 source_id、page、bbox、char_start 和 char_end 的文本块，再让切块和索引过程携带这些字段。

核心判断：正文用于语义检索，页码和坐标用于证据定位，两者必须同时进入规范化块；向量库只保存便于过滤的摘要字段，完整多边形和 OCR 原始响应则放在来源侧车中。

先把 OCR 供应商结果归一成可追溯文本块

不同服务的字段名称不同，但可以收敛到同一组业务概念。Google Document AI 用 textAnchor 指向全文字符串的字符片段，并通过 boundingPoly 描述版面区域；Azure Document Intelligence 的分析响应则常见 boundingRegions，其中包含页码和多边形。适配层不要把供应商 JSON 直接传给 RAG，而应保留原始响应引用，再输出稳定的内部结构。

from dataclasses import dataclass

@dataclass
class OcrBlock:
    # text 是检索正文；regions 是可回看的视觉证据
    text: str
    source_id: str
    page_start: int
    page_end: int
    regions: list[dict]
    char_start: int | None = None
    char_end: int | None = None
    kind: str = "paragraph"

def normalize_block(text, source_id, page, polygon, start=None, end=None):
    # 统一成左上角原点、相对原页的四点或多点坐标
    return OcrBlock(
        text=text.strip(), source_id=source_id,
        page_start=page, page_end=page,
        regions=[{"page": page, "polygon": polygon}],
        char_start=start, char_end=end,
    )

这里的 page 不要从零开始混用。适配器内部可以保留供应商的原始索引，但面向读者的引用统一成从 1 开始的页码；同时在 regions 中保留原始多边形，避免只存一个粗略矩形后无法定位表格、双栏或倾斜文本。

切块和召回时不要丢掉引用链

切块时，文本可以按段落或固定长度分割，但 provenance 不能跟着字符串截断。一个块如果覆盖两页，应保留两个区域；如果只截取了某个段落的一部分，最好同时保存全文中的字符范围。向量库的 metadata 可放 source_id、page_start、page_end、block_id 等标量字段，完整 regions 和原始 OCR JSON 另存到文档库或对象存储。

def make_chunk(blocks, chunk_id):
    # 合并正文时同步合并区域，不能只拼 text
    text = "\n".join(block.text for block in blocks if block.text)
    regions = [region for block in blocks for region in block.regions]
    return {
        "id": chunk_id,
        "text": text,
        "metadata": {
            "source_id": blocks[0].source_id,
            "page_start": min(block.page_start for block in blocks),
            "page_end": max(block.page_end for block in blocks),
            "block_ids": [block.source_id for block in blocks],
        },
        # 复杂数组适合放侧车，metadata 只保留召回过滤所需字段
        "provenance": {"regions": regions},
    }

def citation(chunk):
    # 回答层只展示稳定的来源标识和页码，坐标用于回看或高亮
    meta = chunk["metadata"]
    return f"[{meta['source_id']}，第{meta['page_start']}-{meta['page_end']}页]"

召回结果返回后，先按 source_id 和页码去重，再把引用标记交给生成层。不要让模型自行猜页码，也不要用向量相似度替代证据定位。若 OCR 服务没有坐标，只能把引用降级为页码或文本片段，并在界面上明确“无版面坐标”，不能伪造一个框。

上线前检查坐标和页码的几个边界

第一，确认 PDF 页码和文档印刷页码是否一致；封面、目录或插页可能让“第 3 页”出现两种含义。第二，统一坐标单位与原点，并记录页面宽高和旋转方向；不同供应商可能返回像素坐标、归一化坐标或多边形。第三，切块版本变化时不要复用旧坐标，给 OCR 结果和 chunk 记录同一个 document_revision。第四，表格、图片说明和跨页段落优先保留多个区域，而不是强行压成一个矩形。

相关问题

为什么向量库不直接保存完整 polygon？

很多向量库更适合标量过滤，复杂数组会增加索引和更新负担。把坐标放在侧车并用稳定的 chunk_id 关联，通常更容易迁移和回放。

固定长度切块会破坏页码吗？

不会，只要切块函数从原始块复制 regions，并在跨页时保存多个区域；真正危险的是先拼成纯字符串再切块。

没有坐标的 OCR 结果还能做引用吗？

可以退化为来源文件、页码和字符片段引用，但应明确缺少版面定位，并把后续补做布局 OCR 作为数据升级，而不是补写虚构坐标。

这套设计的关键不是选择某一家 OCR，而是把视觉证据当作和正文同等重要的元数据。只要文本块能稳定回到原页原区域，后续更换 OCR 引擎、分块策略或向量库时，RAG 的引用逻辑就不会一起重写。