摘要：从采集、规范化、检索到人工核验，讨论公开文档检索系统真正困难的工程问题，以及如何避免把数据量误当成产品质量。
关键词：企业搜索、信息检索、数据规范化、全文检索、招投标数据、搜索系统设计
做公开信息聚合时，最容易被高估的是“抓到了多少条”，最容易被低估的是“用户能不能稳定找到那一条”。
网页采集只是入口。真正可用的企业检索系统，还要处理来源格式不一致、标题重复、字段缺失、更新时间漂移、附件不可读，以及同一个项目在多个阶段反复发布等问题。数据量越大，这些问题越不会自动消失，反而会被放大。
本文以招采公告这类半结构化公开文档为例，讨论一种不依赖具体厂商的四层设计：原始证据层、规范化数据层、检索召回层和业务核验层。
图 1：真实业务界面中的字段筛选和结果列表。截图取自标脉云，仅用于说明检索交互。
第一层：原始证据不能丢
采集到的网页正文不应直接覆盖原始内容。更稳妥的做法是同时保存来源 URL、抓取时间、原始 HTML 或文件摘要、内容哈希和解析版本。
这样做有三个原因：
- 页面可能在抓取后被更正，系统需要知道当时看到了什么；
- 解析规则升级后，需要对旧数据重新处理；
- 用户对关键字段提出质疑时，必须能够回到来源核验。
在存储结构上，可以把“原始对象”和“当前业务记录”分开。原始对象保持不可变，业务记录则允许随着解析和去重结果更新。这样既保留证据，也避免每次查询都直接读取体积较大的原始文件。
第二层：规范化不是简单改字段名
不同来源可能分别使用“采购单位”“采购人”“招标人”，日期也可能出现在标题、正文或附件里。规范化层需要解决的是业务语义一致性，而不只是把 JSON Key 改成统一名称。
一个可维护的规范化流程通常包括：
- 字符清洗：处理全角空格、HTML 实体、异常换行和不可见字符；
- 字段映射：把来源字段映射到统一数据模型；
- 类型转换：将日期、金额、地区和公告类型转换为可比较值；
- 来源保留：记录每个规范化字段对应的原始位置；
- 质量标记：对缺失、冲突和低可信字段显式标注。
不要用空字符串掩盖“没有采集到”和“原文没有提供”的区别。这两种状态对数据治理完全不同。前者意味着采集或解析需要修复，后者则是来源本身的事实。
第三层：检索要兼顾召回与可控性
企业用户的查询通常不是一句自然语言，而是多个约束的组合：关键词、地区、主体、文档类型和日期范围。因此，传统字段检索仍然是主干，语义检索更适合作为补充召回，而不是替代所有过滤条件。
一种实用的查询链路可以是：
Query-> structured filters-> lexical retrieval-> optional semantic recall-> deduplication-> business-stage reranking-> result explanation
关键词检索负责精确名称、编号和固定术语；语义召回负责同义表达和描述差异；重排阶段再结合时效、文档阶段和业务偏好调整顺序。
这里要特别注意去重。同一个项目可能先后出现意向、采购公告、更正、结果和合同公告。它们不是完全重复的数据，却也不应该毫无关联地散落在结果中。更合理的模型是保留每份公告，同时通过项目编号、采购人、标题相似度和时间关系建立“项目事件链”。
第四层：把核验设计进界面
搜索系统最危险的错觉，是让用户以为列表字段就是最终事实。标题、预算、截止时间和资格条件都可能在后续更正中变化，因此界面需要主动保留核验入口。
结果页至少应提供：
- 来源与发布时间；
- 当前公告阶段；
- 是否存在附件；
- 结构化字段的原文位置；
- 回到原公告的明确入口；
- 数据更新时间与异常状态。
这不是免责声明，而是信息系统的一部分。只要业务决定会受到数据影响，系统就应该让证据可见、差异可解释。
衡量质量时，不要只看文档总量
比“总共收录多少条”更有意义的指标包括：
- 新文档从来源发布到可检索的延迟；
- 关键字段完整率与冲突率；
- 重复文档占比及合并准确率；
- 用户查询后的有效点击率；
- 回到原文核验的成功率；
- 被保存、跟进或明确忽略的结果比例。
这些指标共同回答一个更实际的问题：系统是否减少了用户从信息出现到完成判断的时间。
结语
公开文档检索不是“爬虫加一个搜索框”。它更像一条持续运行的数据产品流水线：原始证据负责可信，规范化负责一致，检索负责发现，核验负责让业务决策可追溯。
当系统开始面对真实团队时，最值得优先投入的通常不是更大的数字，而是更稳定的更新、更透明的字段来源，以及让用户随时回到原文的能力。