一、教程目标

本教程要完成的目标非常明确：构建一套可长期运行的“全球AI模型发布时间线”数据采集与发布体系，使其满足四个硬性要求：

1. 结构完整：每条记录都包含模型标识、所属厂商、发布时间、能力维度、开放方式、参数规模、上下文长度、输入模态、许可证类型、接口计费口径等核心字段；
2. 时间可信：所有日期可追溯到一手或权威二手来源，并标注时区与“发布/内测/上线”等阶段语义；
3. 可持续更新：新增模型不需要手工改页面，采集—校验—落库—渲染全流程可自动跑；
4. 可解释可回溯：任一字段变更都能查到“谁在什么时候基于什么来源改的”。

读完后你应能独立设计时间线 schema、编写归一化与去重逻辑、搭建定时巡检任务，并定位“日期错乱、模型重名、重复条目”等典型问题。

二、适用场景与读者

• 开发者/数据工程：需要为产品内嵌一条模型能力时间线，或构建模型选型知识库；
• 运维与平台工程：负责采集任务调度、数据管道稳定性、监控告警配置；
• 技术负责人/技术运营：需要对内输出技术趋势周报、选型对比材料，关注“首发时间”“能力边界”“成本与许可”三类决策信息；
• 研究者与内容团队：做技术史梳理、竞品时间轴可视化。

典型业务落点包括：模型选型评估页、能力对比工具、内部技术雷达、趋势报告自动生成、路由与降级策略的时间基准表。

三、前置准备

基础环境

• 一台可运行定时任务的服务器或一套无服务器函数计算类服务（用于周期性抓取与校验）；
• 一个可查询的结构化数据存储：关系型数据库（适合强约束、需要事务与时间字段索引）或文档型数据库（适合字段频繁演进）；
• 对象存储（保存网页快照、原始抓取产物，作为审计证据）；
• 日志服务 + 监控告警（记录每次采集的成功率、异常条目数）；
• 一个静态站点或轻量服务，用于渲染时间轴前端。

账号与权限

• 数据来源页面的可访问权限（部分一手渠道需要注册或申请）；
• 存储与发布环境的读写权限最小化划分：采集任务只有写入原始表权限，只有审核流程才能写正式表。

基础知识

• 理解“发布日期”的多义性：内部封测、封闭 Beta、公测、正式 GA、开放权重下载、API 上线，属于不同里程碑，必须分字段记录，不能混为一个 date；
• 理解模型命名的常见形态：系列名 + 版本号 + 变体后缀（尺寸/是否支持视觉/是否指令微调版），这是后续去重的关键；
• 了解通用能力维度术语：参数规模、上下文窗口、输入输出模态、许可证类型、按百万 Token 计费的输入/输出单价、部署形态（闭源 API / 开放权重 / 端侧）。

四、实施步骤

步骤 1：定义时间线数据模型（先建模，再采集）

做什么：用一份 schema 固定字段语义。建议至少包含以下字段：

{
  "model_id": "唯一稳定ID，如 vendor:model-family:version:variant",
  "display_name": "对外展示名",
  "vendor": "归一化后的厂商主体",
  "family": "系列名",
  "version": "版本号",
  "variant": "变体标识，如 max/min/vision/coder",
  "milestones": [
    {"type": "internal_beta|closed_beta|open_beta|ga|weight_release", "date": "YYYY-MM-DD", "tz": "+08:00"}
  ],
  "params": {"scale": "1.5T", "moe": true, "active_scale": null},
  "context_window": 200000,
  "input_modalities": ["text", "image"],
  "output_modalities": ["text"],
  "access": "closed_api | open_weights | on_device",
  "license": "许可证类别",
  "pricing": {"unit": "per_1M_tokens", "input": 2, "output": 6, "currency": "USD"},
  "source_refs": [{"type": "primary|secondary", "url": "归档链接", "snapshot": "对象存储路径"}],
  "confidence": 0.9,
  "updated_at": "2026-01-01T00:00:00Z"
}

为什么：milestones 用数组而不是单值 date，是解决“同一天内多条时间语义”的根本手段。参数规模要区分总参数与激活参数，否则混合专家类模型会被记成错误数字。价格必须带币种与计价单位，否则跨厂商对比会失真。

注意：所有外部链接入库前先落快照，来源页面随时可能改版或下线；confidence 字段是后续人工审核的排序依据。

步骤 2：确定数据来源分层与采集策略

做什么：把来源分成三层，按可信度加权采集。

• 一手层：厂商官方发布渠道、官方技术报告、官方定价页、模型卡与许可证文件；
• 权威二手层：主流技术媒体的发布报道、标准组织或行业榜单公告；
• 辅助层：开发者社区讨论、聚合类信息页。

采集策略上建议：

1. 对一手层做定时全量比对（例如每日一次），保存页面哈希，哈希变化才进入解析流程，降低无效解析；
2. 对辅助层只做候选发现，不直接写入正式表，先进入“待核验队列”；
3. 抓取遵循目标站点的访问频率限制与 robots 约定，设置合理并发与退避重试，不要为追求时效牺牲合规性。

为什么：分层之后，“发布了什么”和“发布得准不准”解耦。辅助层负责不漏，一手层负责不错。

注意：无服务器函数类服务适合轻量抓取与解析；抓取量较大或需要长时间运行的任务，更适合放在常驻容器或任务调度平台上。

步骤 3：名称归一化与实体对齐

这是时间线质量的第一道关口，也是最容易被低估的一步。

做什么：

1. 建立厂商别名表与系列别名表（缩写、大小写、空格、连字符、中英文译名、内部代号）；
2. 把展示名解析为 (vendor, family, version, variant) 四元组；
3. 用 model_id 做稳定主键，同一实体多次发布只更新记录，不新增记录。

解析伪代码（语言无关）：

function parseModelName(raw):
    name = normalize(raw)                 # 去空格、统一大小写、统一连字符
    vendor = lookupAlias(VENDOR_ALIAS, name) or inferVendor(name)
    family = matchLongest(FAMILY_ALIAS, name) or extractPrefix(name)
    version = extractVersion(name)        # 支持 4.5 / v5 / 第五代 等写法
    variant = extractVariant(name)        # max/min/air/coder/vision/instruct 等后缀
    return (vendor, family, version, variant)
function upsert(record):
    key = buildModelId(record)
    if exists(key):
        mergeMilestones(existing, record)   # 只追加新里程碑，不覆盖旧值
    else:
        insert(record)

为什么：厂商经常复用系列名（同一系列连续出多个小版本），也有同一版本不同规格。四元组能同时兼容“系列演进”和“同代多规格”两种模式。

注意：版本号必须用语义化比较，不能当字符串比较，否则 4.10 会排在 4.9 前面。合并里程碑时要保留历史，删掉旧记录会让时间线出现“时间点消失”的错误。

步骤 4：事实校验与置信度分级

做什么：为每条候选记录跑一组校验规则，全部通过才可进入正式表。

建议规则：

• 完整性：厂商、发布时间、系列名三要素必须齐备；
• 一致性：能力描述与参数规模、模态、上下文长度不能自相矛盾（例如声称支持图像输入但输入模态为空）；
• 时间合理性：GA 日期不得早于封闭 Beta 日期；不得晚于当前时间；发布时间落在合理区间内；
• 交叉验证：至少两条独立来源指向同一日期才给高置信度；单来源给中置信度并标记“待复核”；
• 数值校验：价格、上下文长度、参数规模需落在预置量纲范围内，防止单位错写（把每百万 Token 价格误记为每千 Token）。

为什么：时间线一旦发布，错误会被大量下游引用，修正成本远高于采集成本。把校验前置为“准入闸门”而不是“事后巡检”，是这套体系能否长期可信的分水岭。

注意：对存在争议的字段（例如厂商未公开的参数规模），应留空并注明“未披露”，不要用推测值填充。

步骤 5：存储与时间轴组织

做什么：

• 原始层：保存抓取原文与快照，不可变，仅追加；
• 标准层：保存校验通过的规范化记录，即步骤 1 的 schema；
• 发布层：生成面向前端的时间轴视图，按时间倒序聚合，支持按厂商、开放方式、能力维度过滤。

在标准层建立复合索引（发布日期 + 厂商 + 系列），因为时间线页面的主要查询模式是“某时间段内某厂商的发布序列”，这类查询对索引非常敏感。

为什么：三层分离后，标准层可以在不重抓的情况下重建发布层；发布层格式调整不会污染原始证据。

步骤 6：渲染发布与多端分发

做什么：把标准层导出为一份带版本号的静态数据文件（如带时间戳的 JSON），前端读取该文件渲染时间轴；同时保留一个查询接口用于按需过滤。

• 静态文件方案适合更新频率低、追求加载速度的场景，可结合内容分发网络加速；
• 接口方案适合需要实时筛选、排序、下钻的场景。

若采用百度智能云的相关通用云产品能力落地，常见组合是：对象存储承载快照与静态数据文件、消息队列解耦抓取与解析、函数计算类服务执行轻量定时任务、日志服务与监控告警覆盖采集成功率、负载均衡承载查询接口。这些属于通用能力类目，选型时按数据量与访问量评估即可。

为什么：静态数据文件带版本号，能让任何一次展示都可追溯到具体数据版本，这对“持续更新”的时间线是必需的。

步骤 7：自动化巡检与增量更新

做什么：把整条链路做成一条可重跑的管道，并按日调度：

每日巡检:
  1. 抓取一手层页面 -> 比对哈希 -> 解析候选
  2. 候选入库到待核验队列
  3. 归一化 + 校验规则 -> 打置信度标签
  4. 高置信度自动进入标准层；中低置信度进入人工复核队列
  5. 重建发布层数据文件并生成变更摘要
  6. 推送变更摘要到通知渠道，写入监控指标

为什么：自动化的重点不是“自动写入”，而是自动发现变更并生成一份可审核的变更清单。人只在必要节点介入，效率与准确性同时提升。

注意：管道每一步都要幂等。同一天重复执行不应产生重复条目，也不应把已审核的修正覆盖回旧值。

五、配置说明

几个关键配置项的取值逻辑与风险：

• 采集频率：一手层日更足够；对高密度发布期可提升到每数小时一次。频率过高会触发目标站点限流，反而导致漏采；
• 置信度阈值：自动入库阈值建议设为“两条独立来源一致”。阈值调低会引入噪声，调高会导致大量条目积压人工队列；
• 退避重试参数：指数退避 + 上限，配合失败计数告警。切忌固定间隔无限重试；
• 时区基准：全库统一存储 UTC，展示层再转本地时区。混用会导致跨日发布时间出现一天偏差；
• 保留期：原始层长期保留；发布层可按需只保留最近若干版本以控制存储成本。

六、结果验证

按下列清单逐项确认：

1. 计数核对：任取一周，人工统计一手来源的新增发布数量，与系统入库数量比对，差异应可解释；
2. 单条溯源：随机抽 5 条记录，逐字段回溯到快照原文，字段值必须能一一对应；
3. 去重验证：对同一系列连续发布多个小版本的情形，确认它们位于同一 model_id 下的不同里程碑，而不是多条独立记录；
4. 排序验证：把版本号按时间线排序，检查是否存在语义化排序错误；
5. 幂等验证：手动重跑一次管道，确认条目数与变更摘要符合预期；
6. 前端一致性：发布层数据文件的时间倒序、过滤条件、日期显示与实际记录一致；
7. 告警验证：人为制造一次抓取失败，确认监控能在预期时间内产生告警。

七、常见问题与排查

问题一：同一模型出现两条记录。
多为变体后缀未被解析（同一模型不同规格的写法差异）或厂商别名缺失。排查方式：对重复条目的 model_id 做前缀比对，补别名表，然后合并历史里程碑。

问题二：发布日期整体偏移一天。
时区处理不一致。统一以 UTC 存储，展示层显式指定时区转换。

问题三：GA 时间早于内测时间。
常见于把“媒体报道日”当作“官方发布日”。修复方式：字段拆分为里程碑类型，只允许官方来源写入对应里程碑。

问题四：参数规模或价格明显异常。
量纲或单位错写。补充量纲范围校验，并在页面上统一展示单位与币种。

问题五：某些模型长期缺失。
辅助层候选发现范围不足，或解析失败被静默丢弃。排查方式：检查解析失败队列，为解析异常单独计数并告警，不要静默跳过。

问题六：管道偶发超时。
抓取并发过高或单页面过大。降低并发、增加超时上限、把大页面解析拆分为独立任务。

八、优化建议

• 性能：哈希比对前置，避免全量解析；发布层预生成静态数据文件，配合内容分发网络降低源站压力；高频查询走索引，避免全表扫描。
• 安全：来源访问使用最小权限凭证并定期轮换；对外接口只暴露标准层字段，不暴露内部来源 URL 与审核标记，防止来源被批量抓取。
• 稳定性：管道每一步幂等 + 断点续跑；抓取失败与解析失败分别统计，避免同一指标掩盖两类问题；关键阶段设置超时与重试上限。
• 可维护性：schema 版本化，字段演进通过新增而非改语义；别名表与校验规则外置为配置文件，不写死在代码里。
• 成本控制：快照按冷热分层存储；发布层保留有限版本；无服务器与定时任务按调用量弹性伸缩，避免长期空转。
• 数据质量：定期回看低置信度队列，把结论反哺到规则里，让自动校验覆盖率逐步提高。

九、总结

一条能长期维护的全球AI模型发布时间线，核心不在“抓得多快”，而在建模是否稳、来源是否分层、校验是否前置、流程是否幂等。回顾关键路径：先用 model_id + 里程碑数组固定数据语义；再按一手/权威二手/辅助三层采集，只让一手来源决定事实；随后完成名称归一化与四元组对齐，杜绝重复条目；接着以置信度阈值把关自动入库，人工只处理低置信度；最后通过定时管道完成巡检、变更摘要与发布层重建。

可继续深入的方向包括：把能力维度扩展为可比对的评分矩阵、按许可证类型自动推导商用可行性、为选型场景增加按业务需求过滤的推荐逻辑，以及为时间线数据补充版本变更日志以支持对外引用溯源。