别急着接大模型：档案 AI 的第一张底表到底怎么建？

这篇不讨论哪个模型最聪明，而是讨论模型真正能在档案系统里工作之前，第一张底表应该长什么样。

很多项目把 AI 理解成一个外接插件：系统里加一个问答框，再把大模型 API 接进去，就好像完成了智能化。现场真正卡住的地方通常不在模型，而在数据对象没有稳定关系。目录是一套编号，原文是一批文件，OCR 又是一堆孤立文本，权限另放在业务系统里，日志只记录操作人和时间。模型一旦提问，就不知道该沿着哪条线回到原文。

先把问题拆成工程链路

底表要解决的是对象关系，不只是字段堆叠。一个可用的档案 AI 底座，至少要把档案资源、电子原文、页级文本、权限规则和利用行为放在同一条可追溯链路上。这样模型输出任何结论时，系统都能回答三件事：来自哪份档案，来自哪一页，当前用户是否有权看到。

底表字段示例

下面这个样例不是为了限定数据库设计，而是说明每个 AI 任务都应该留下可追溯对象。字段名称可以按系统调整，但对象关系不能丢。

{
  "archive_id": "QZ-2024-0031",
  "file_id": "F-000018",
  "page_id": "P-000018-07",
  "ocr_span_id": "S-000018-07-04",
  "permission_scope": ["馆内利用", "需审批"],
  "source_hash": "sha256:...",
  "quality_score": 0.86,
  "trace_required": true
}

现场小试怎么跑

硬核文章不能只停在概念层。真正做试点时，建议把范围压小，但记录做细。比如先选一个门类、一个年度或一个固定业务场景，准备 200 到 500 页原文、100 到 300 条目录记录和 30 到 50 个真实问题。样本不需要一开始很大，但必须包含正常页面、低质量页面、字段缺失、跨页引用、权限受限和证据不足这些情况。

执行时分四步走。

· 先选一个真实小样本，不要用演示样例。样本里要有清晰页面、低质量页面、权限受限材料和普通高频查询材料。

· 先跑基线，不接 AI 或只用现有检索，把人工查找时间、字段修正量、召回遗漏和权限拦截情况记录下来。

· 再接入 AI 链路，只允许它在限定材料范围内生成候选结果，并把每次输入、证据、输出和人工修改写入日志。

· 最后做复盘，不只看成功案例，也要把失败样例按 OCR、索引、权限、模型、人工确认五类归因。

这样做的好处，是能把“AI 好不好用”拆成多个可以修的部件。OCR 质量不够，就先修图像和识别；召回不准，就看索引和切片；权限有问题，就先停用生成能力；人工复核工作量降不下来，就说明候选结果还没有真正帮助业务人员。

试点记录最好每天沉淀成一张小表，而不是等项目结束后再补材料。表里至少记录样本批次、处理页数、失败记录数、人工复核人数、平均复核时间、错误归因和下一次调整项。这样连续跑两三轮以后，就能看出优化到底来自模型，还是来自数据清理、规则补充、索引重建或流程调整。

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

验收不能只看演示效果

建议把下面几类指标写进试点记录或验收表，而不是只在会议上看一次问答效果。

· 目录原文绑定率 >= 99.5%

· 页级 OCR 可回跳率 >= 98%

· 权限过滤命中率 = 100%

· AI 输出来源字段缺失率 < 1%

这些指标的意义，是把“好像能用”变成“出了问题能定位”。如果某项指标暂时达不到，也应该记录原因：是数据质量问题、OCR 问题、索引问题、权限同步问题，还是模型生成问题。

和普通演示型方案的差别

演示型方案喜欢展示一个漂亮入口：用户提问，系统回答，页面上再放几个看起来很智能的推荐。工程型方案则先看链路是不是闭合：数据对象有没有主键，原文能不能回跳，权限是否在模型输入前生效，日志能否复盘，人工是否可以接管，错误是否可以回滚。

这两种方案短期看差别不大，都会有界面，也都能回答一些问题。差别会在试运行时出现。用户问题变多、数据质量变差、权限规则变复杂、模型版本变化之后，演示型方案只能继续调提示词；工程型方案可以沿着链路定位问题，并把修正沉淀成规则、索引、样本和验收指标。

因此，真正值得投入的不是“多接一个模型”，而是把每一次试错变成资产。一次错误召回可以补充同义词和重排样本，一次越权拦截可以补充权限规则，一次引用失败可以修正页码映射，一次人工否决可以进入评测集。这样的系统会越用越稳，而不是每次演示都重新开始。

这也是档案 AI 与通用办公 AI 最大的不同。通用办公场景更看重生成速度和表达质量，档案场景还要看证据、责任和长期维护。今天写下的字段、日志和指标，明年仍要能解释；今天引用的页面，后续重建索引后仍要能找到。

失败边界要提前说清

如果目录字段本身混乱、原文文件缺页、权限规则没有数字化，先接模型只会放大问题。底表建设不是一次导入完成，还要支持重识别、字段修正、权限变化后的索引重建。

档案行业的智能化不能只追求自动化比例。越是接近正式业务，越要保留来源、权限、复核、回滚和审计。一个稳的系统，应该允许 AI 给出候选结果，也允许人明确否决、修正和追责。

领至科技的工程视角

领至科技在设计档案 AI 能力时，应把这张底表当成系统接口和项目验收的共同语言。客户问 AI 能不能用，真正要先验证的是这条主键链是否闭合。

这类内容适合持续写成系列，因为它不是单篇文章里的观点，而是一套可以反复验证的建设方法。每一篇都可以对应一个项目检查项：数据能否关联，证据能否回跳，权限能否前置，指标能否复测，结果能否复核。读者看完以后，既能理解为什么不能盲目追热点，也能拿着这些问题去评估自己的系统和供应商方案。

如需了解档案 AI 底座、目录治理和来源追溯方案，可以点击文末阅读原文访问领至科技官网。