先说结论
长文档智能解析不是把整份 PDF 丢给模型，然后等待一段“看起来像答案”的文字。
真正可用的链路至少要回答五个问题：文件能不能稳定解析、结果来自哪一页、输出能不能被程序消费、失败时有没有兜底、改完以后怎么证明没有退步。
在智能标书场景里，我更愿意把它理解成一条可验证的数据流水线：
- PDF / DOC / DOCX 先进入文本解析。
- 扫描件或文本质量差的页面补 OCR。
- PageIndex 保存页码、文本片段和结构节点，建立证据位置。
- LLM-first 负责理解表达差异并抽取资格、符合性、评分、废标等锚点。
- schema 校验与规则 fallback 负责稳定格式、修正分类和兜底。
- gold standard、precision / recall 与真实样本回归负责验证效果。
为什么不能只靠纯规则或纯 LLM
纯规则在固定模板上很稳定，但真实文件的标题、表格、标段和条款写法差异很大。规则会越补越碎，换一种表达就可能漏掉。
纯 LLM 能理解复杂语义，却可能漏抽、多抽、分类漂移或输出格式不一致。后端需要稳定的结构化数据，前端还要把结果定位回原文，不能只接受一段自然语言。
因此更现实的组合是：
- LLM 处理复杂表达和跨段理解。
- 规则处理确定性校验与稳定兜底。
- schema 约束字段、类型和缺失值。
- 人工复核处理高风险结论。
这里的规则不是“旧方案残留”，而是一层风险控制。模型能力提高后，规则可以减少，但不应该为了追求形式上的“全 AI”而全部删除。
OCR 和 PageIndex 分别解决什么
OCR 解决的是“页面里有没有可用文本”。扫描件只有图片，没有 OCR 就没有后续抽取基础。但 OCR 也会带来错字、断行和表格结构丢失，所以 OCR 输出不能直接等于最终事实。
PageIndex 解决的是“这条结果来自哪里”。它把文件页、文本片段和结构信息关联起来，让锚点能够回溯到原文页码和上下文。
它和常见 RAG 的侧重点不同：RAG 通常围绕问题检索 chunk，再让模型生成回答；PageIndex 在这里更偏证据定位，目标是让评审锚点可追溯，而不是生成一段聊天答案。
指标为什么必须写清口径
评测时可以把系统抽取结果与人工确认的 gold standard 对照：
- precision 关注误抽：系统抽出来的锚点中，有多少是真的。
- recall 关注漏抽：基准里应该出现的锚点，有多少被系统找到。
当前公开材料中的约 94.9% 与 98.6%，只对应锚点解析口径下的 precision / recall。它们不能外推为整个评标系统准确率，也不代表废标、评分或专家结论正确率。
高风险 AI 系统最忌讳把局部指标包装成全局结论。没有材料明示的结果，宁可标记为缺失或待专家复核，也不要让模型猜一个完整答案。
出现问题时怎么排查
不要一看到错结果就直接改 prompt。更有效的顺序是：
- 原文件里是否真的存在目标条款。
- 文本解析或 OCR 是否丢页、错行、破坏表格。
- PageIndex 是否把结果关联到正确页面和标段。
- LLM 是否漏抽、误抽或输出不符合 schema。
- 规则 fallback 是否错误覆盖了更可靠的模型结果。
- 修改后是否在同一批 gold 和历史样本上重新回归。
只有定位到问题属于哪一层，才能决定应该改解析器、索引、prompt、schema，还是规则。
公开边界
这篇笔记只讨论已经公开的工程方法与锚点解析指标，不包含客户文件、真实标书内容、内部地址、未脱敏页面或源代码。系统的职责是辅助定位和提示风险，最终判断仍需要人工与专家流程。