档案 AI 基石：第一张底表构建指南

本文不探讨模型智商高低，而是聚焦于模型真正融入档案系统前，首张基础表应具备的形态。

许多项目误将 AI 视为外挂插件：仅在系统嵌入问答框并对接大模型 API，便以为实现了智能化。实际瓶颈常不在模型本身，而在于数据对象缺乏稳定关联。目录仅是一组编号，原文是一批文件，OCR 产出则是孤立文本，权限存于业务系统，日志仅记录操作人与时间。一旦模型发问，便不知沿何路径回溯原文。

底表需解决对象关联，而非单纯字段堆砌。一个可用的档案 AI 底座，至少应将档案资源、电子原文、页级文本、权限规则及应用行为置于同一可追溯链路。如此，模型输出任一结论时，系统皆可回应三问：源自哪份档案、出自哪一页、当前用户是否有权限查看。

以下样例非为限定数据库设计，旨在说明每项 AI 任务均需留存可追溯对象。字段名可依系统调整，但对象关联不可缺失。

JSON

1{

2 "archive_id": "QZ-2024-0031",

3 "file_id": "F-000018",

4 "page_id": "P-000018-07",

5 "ocr_span_id": "S-000018-07-04",

6 "permission_scope": ["馆内利用", "需审批"],

7 "source_hash": "sha256:...",

8 "quality_score": 0.86,

9 "trace_required": true

10}

硬核文章不能止步于概念。真正开展试点时，建议缩小范围但细化记录。例如先选取一个门类、一年度或一固定业务场景，准备 200 至 500 页原文、100 至 300 条目录记录及 30 至 50 个真实问题。样本无需初时庞大，但必须涵盖正常页面、低质页面、字段缺失、跨页引用、权限受限及证据不足等情形。

执行时可分为四步。

此举益处在于能将“AI 是否实用”拆解为多个可修复组件。若 OCR 质量不足，先修复图像与识别；若召回不准，则检查索引与切片；若权限存疑，先暂停生成能力；若人工复核量未降，则说明候选结果未真正助力业务人员。

试点记录最好每日沉淀为一张小表，而非待项目结束后补录。表中至少应记录样本批次、处理页数、失败记录数、人工复核人数、平均复核时长、错误归因及下次调整项。如此连续运行两三轮后，即可判断优化源于模型，还是来自数据清洗、规则补充、索引重建或流程调整。

若单位内部尚无成熟数据，可先行影子试运行：AI 仅生成候选，不写入正式业务库；业务人员仍按原流程操作，但额外记录 AI 候选是否有帮助。影子试运行的价值在于风险低，却能暴露真实问题。待候选结果稳定、权限过滤稳定、审计记录完整后，再逐步开放至半自动流程。

建议将以下几类指标纳入试点记录或验收表，而非仅在会议中查看一次问答效果。

这些指标的意义，在于将“看似可用”转化为“出问题可定位”。若某项指标暂不达标，亦应记录原因：是数据质量问题、OCR 问题、索引问题、权限同步问题，还是模型生成问题。

演示型方案喜展示漂亮入口：用户提问，系统作答，界面再置几个看似智能的推荐。工程型方案则先审视链路是否闭环：数据对象有无主键，原文能否回跳，权限是否在模型输入前生效，日志能否复盘，人工是否可接管，错误是否可回滚。

这两种方案短期看差异不大，皆有界面且能回答问题。差别将在试运行时显现。当用户问题增多、数据质量下降、权限规则复杂化、模型版本更新后，演示型方案仅能继续调整提示词；工程型方案则可沿链路定位问题，并将修正沉淀为规则、索引、样本及验收指标。

因此，真正值得投入的并非“多接一个模型”，而是将每次试错转化为资产。一次错误召回可补充同义词与重排样本，一次越权拦截可补充权限规则，一次引用失败可修正页码映射，一次人工否决可进入评测集。此类系统将越用越稳，而非每次演示都从头开始。

这也是档案 AI 与通用办公 AI 的最大区别。通用办公场景更重生成速度与表达质量，档案场景还需考量证据、责任及长期维护。今日写入的字段、日志与指标，明年仍能解释；今日引用的页面，后续重建索引后仍可查找。

若目录字段本身混乱、原文文件缺页、权限规则未数字化，贸然接入模型只会放大问题。底表建设非一次导入即可完成，还需支持重识别、字段修正及权限变更后的索引重建。

档案行业的智能化不能仅追求自动化比例。越是接近正式业务，越需保留