直接答案:基础模型(Foundation Model)是一类在广泛数据上进行大规模训练、随后能够适配多种下游任务的模型。它是一种可复用的技术底座,不是完整产品,也不天然等于大语言模型、生成式 AI、聊天机器人或通用人工智能(AGI)。真正上线的 AI 系统还需要输入与数据、提示或适配层、检索与工具、权限、安全控制、评测、监控和责任人。
判断一个模型是否“基础”,重点不只是参数量,而是训练范围、可适配性和下游复用方式。选型时也不能只看榜单:同一模型在摘要、抽取、代码、视觉理解或工具调用上的表现可能不同,API 服务、开放权重与自建训练的许可证、数据边界、成本和退出能力也不同。

基础模型是什么?“基础”到底基础在哪里?
“基础模型”一词由 Stanford CRFM 推广。Stanford HAI 的定义和《On the Opportunities and Risks of Foundation Models》报告把它概括为:在广泛数据上以大规模方式训练,并可适配到广泛下游任务的模型。报告也提醒,这不是一条精确的技术分界线,而是描述一类模型及其社会技术影响的工作概念。
“基础”来自下游依赖:多个应用可以共享同一上游模型,再通过提示、示例、检索、工具或参数适配形成不同系统。上游模型的能力、局限、数据问题和安全弱点可能被很多下游继承,因此复用效率越高,集中风险也越值得记录。
| 判断维度 | 需要看到的证据 | 不能据此单独下结论 |
|---|---|---|
| 训练范围 | 数据类型、语言、领域、时间范围和已公开限制 | “海量数据”不证明覆盖你的用户与行业 |
| 训练规模 | 算力、参数、数据或训练方法的可核验披露 | 参数更多不自动代表任务更准 |
| 适配范围 | 跨任务评测、可用接口、适配方法和失败样本 | 能演示多个任务不等于生产可用 |
| 下游复用 | API、权重、许可、文档、版本与集成路径 | 可下载不一定允许所有商业用途 |
| 治理能力 | 模型卡、系统卡、安全测试、事件与更新记录 | 有安全声明不等于你的系统风险已消除 |
所以,“模型很大”“能生成内容”“支持聊天”都不是充分条件。更稳妥的写法是说明模型在什么数据和任务上训练、可以怎样适配、以什么方式提供、对哪些场景有证据,并保留模型与最终产品之间的边界。
读一张基础模型信息卡,应该先看什么?
模型页面通常先展示能力、上下文或演示,但决策者更需要可核验的信息卡:准确的模型标识与发布日期、训练和后训练概况、支持的输入输出、评测方法、已知限制、许可证、数据处理、服务区域、版本变更和联系渠道。如果这些信息缺失,就不能仅凭一个聊天演示推断模型适合生产。
Google Cloud 的基础模型说明把语言、视觉、音频和多模态列为不同模型范围;AWS 的基础模型概览强调同一底座可通过不同方式适配下游任务;IBM 的概念说明则讨论预训练与任务适配。这些厂商页面适合帮助理解实现方式,但不能替代具体模型的模型卡、许可证、服务条款和你自己的任务评测,也不能相互拼接成“行业一致证明”。
阅读信息卡时还要区分“未披露”和“没有”。例如,页面未说明训练数据不代表模型没有使用某类数据;未报告某类失败也不代表不存在失败。对关键缺口应要求提供者补充、通过合同限定用途,或在选型结论中明确写为不确定性,而不是自行补全。关键判断必须留下日期、版本与责任人。
基础模型、大语言模型、生成式 AI 和 AI 系统有什么区别?
这些术语不处于同一条层级。基础模型描述训练与复用范式;大语言模型(LLM)描述以语言序列为核心的一类模型;生成式 AI 描述生成文本、图像、音频、视频、代码等内容的能力与系统;AI 系统则包含模型、数据、界面、工作流、工具和控制。本站的大语言模型完整指南进一步解释 Token、Transformer、RAG 与评测;人工智能定义与系统工作链则给出更上位的系统视角。
| 术语 | 描述层级 | 典型范围 | 不等于 |
|---|---|---|---|
| 基础模型 | 模型训练与复用范式 | 语言、视觉、语音、多模态或科学模型 | 完整应用、AGI、一定可生成内容 |
| 大语言模型 LLM | 模型类型 | 文本与代码建模,也可连接图像、音频和工具 | 所有基础模型、搜索引擎或知识库 |
| 生成式 AI | 能力与系统类别 | 生成文本、图像、音频、视频、代码 | 所有 AI;预测和排序系统也属于 AI |
| 通用 AI 模型 | 法律/治理概念 | 具显著通用性、可集成进多种下游系统的模型 | 面向所有任务都可靠 |
| AI 系统 | 可运行的整体 | 模型加输入、数据、规则、接口、动作和监督 | 模型文件本身 |
| 聊天助手/智能体 | 产品或交互形态 | 对话、检索、工具调用、多步工作流 | 基础模型的同义词 |
欧盟《人工智能法》使用“通用人工智能模型”而非把“基础模型”直接作为唯一法律标签,并明确模型本身不构成完整 AI 系统;当模型被加入界面、流程或其他组件后,才形成可用于具体目的的系统。法律义务要结合角色、能力、用途和司法辖区判断,本文不构成法律意见。
基础模型怎样变成可以使用的 AI 产品?
从模型训练到用户看到答案,中间至少有五层:上游预训练与发布、模型访问、任务适配、系统集成、运行治理。把问题都归因于“模型”会漏掉检索库过期、工具参数错误、权限过大、提示注入、界面误导和人工流程失效等系统问题。

| 阶段 | 主要工作 | 必须保留的证据 | 典型责任主体 |
|---|---|---|---|
| 预训练与发布 | 准备数据、训练模型、能力与安全评测 | 模型卡、数据说明、评测、已知限制、版本 | 上游模型提供者 |
| 访问与托管 | 提供 API、下载权重或托管推断 | 服务条款、区域、日志、保留期、SLA | 模型/云服务商与采购方 |
| 任务适配 | 提示、示例、RAG、工具、PEFT 或微调 | 配置、知识版本、训练集、回归测试 | 应用开发与领域团队 |
| 系统集成 | 连接界面、权限、业务规则和下游动作 | 数据流、权限矩阵、失败处理、审计日志 | 系统提供者/部署者 |
| 运行治理 | 监控质量、漂移、滥用、事件和费用 | 告警、抽检、申诉、停机与回滚记录 | 运营、风控、安全和业务负责人 |
NIST AI 600-1 生成式 AI 风险管理框架把风险管理放在治理、映射、测量和管理的全生命周期中,并特别说明:并非所有生成式 AI 都必然源于基础模型。这个边界很重要,因为治理对象应是具体系统及其用途,而不是看到“生成”或“基础模型”标签就套用同一答案。
提示词、RAG、工具调用、LoRA 和微调怎样选?
适配不是“默认微调”。先找错误发生在哪一层:如果只是输出格式不稳定,结构化提示与校验可能足够;如果事实会频繁更新,RAG 比把新知识写入参数更容易更新和引用;如果系统需要查库存或提交订单,应使用受权限控制的工具;只有稳定、重复且有高质量训练样本的行为差距,才值得考虑参数适配。
| 方法 | 改变什么 | 适合问题 | 主要风险/成本 |
|---|---|---|---|
| 提示词与示例 | 单次或模板化输入上下文 | 格式、语气、步骤、少量示范 | 上下文占用、注入、稳定性 |
| 结构化输出与校验 | 输出合同和系统验证 | JSON、字段抽取、工作流接入 | 模型仍可能漏字段,必须程序校验 |
| RAG | 在推断时提供检索到的外部知识 | 私有、可更新、需引用的事实 | 召回错误、权限泄露、旧文档 |
| 工具调用 | 让系统调用搜索、数据库或业务 API | 实时查询、计算和受控动作 | 参数错误、越权、不可逆动作 |
| PEFT/LoRA | 学习少量附加参数 | 稳定风格、领域行为、资源受限适配 | 数据质量、版本耦合、仍需完整评测 |
| 全量微调/继续预训练 | 更新大量或全部模型参数 | 有充分数据、算力和长期维护能力的深度适配 | 成本、遗忘、安全回归和复现难度 |
Hugging Face 的 LoRA 指南说明,LoRA 通常冻结原始权重并学习低秩矩阵,从而减少需要训练的参数;这不意味着无需数据治理或上线评测。关于检索增强的完整设计,可继续阅读本站已复核的Transformer 原理与边界并结合 LLM 指南中的 RAG 部分理解。
API、开放权重还是自建训练?
交付方式决定控制面。API 通常启动快,但受服务区域、配额、价格、条款和版本变化影响;开放权重便于本地托管与审计,却不代表训练数据开放,也不保证许可证适合你的用途;从头训练控制最多,同时需要数据、算力、人才、安全和长期维护能力。很多团队应先从可退出的 API 或托管开放权重试点,而不是把“拥有模型”当成业务目标。
| 路线 | 你能控制 | 必须核验 | 适合前提 |
|---|---|---|---|
| 第三方 API | 提示、RAG、工具、应用控制 | 数据使用、保留、区域、版本、配额、退出 | 需要快速验证且数据边界允许 |
| 托管开放权重 | 推断环境、版本、部分安全与适配 | 许可证、硬件、运维、补丁、量化影响 | 有平台能力并需要更多控制 |
| 本地/私有部署 | 网络、日志、权重、数据路径 | 容量、可用性、安全、升级与人员 | 边界严格且能承担持续运维 |
| 继续预训练/全量微调 | 更多模型行为和领域表示 | 数据权利、训练安全、回归、复现 | 稳定规模需求与专业团队 |
| 从头训练 | 架构、数据、训练和发布策略 | 全链路成本、人才、治理与长期竞争力 | 独特数据/科研目标且其他路线不足 |
“开放”也需要拆开问:代码是否开放、权重是否可得、训练数据是否披露、许可证是否允许商用和再分发、衍生模型义务是什么。Open Source Initiative 的开放源代码 AI 定义入口提供了一套讨论框架,但具体模型仍要阅读其许可证与使用限制。
怎样比较基础模型,而不是被单一榜单带偏?
先建立真实任务集,再比较模型。任务集要覆盖常见输入、困难输入、拒答、长上下文、不同中文表达、敏感信息和工具失败。每条样本写明期望输出、允许差异、证据来源、错误成本和人工评分规则。公开榜单可以帮助筛选候选,不应替代你的数据与工作流验收。
| 评测维度 | 可复现记录 | 常见误判 |
|---|---|---|
| 任务质量 | 任务集版本、逐条结果、评分尺、盲评和分歧 | 只报平均分,隐藏高风险失败 |
| 事实与来源 | 原子主张、引用覆盖、忠实度、无法回答率 | 语言流畅就判正确 |
| 安全与权限 | 攻击样本、越权尝试、拒绝、误拒和绕过 | 只运行厂商公开安全分 |
| 延迟与稳定 | P50/P95、超时、限流、并发和重试 | 用一次演示速度代表生产 |
| 成本 | 输入/输出、缓存、检索、工具、人工复核总成本 | 只比较每百万 Token 标价 |
| 可运维性 | 版本固定、日志、回滚、事件响应和替换时间 | 忽略锁定和迁移成本 |
NIST AI 风险管理框架建议把风险工作组织为 Govern、Map、Measure、Manage。实践中可以把“测得高分”与“允许上线”分开:质量只是门槛之一,数据权利、权限、监控、人工处置和回滚同样必须通过。

基础模型的风险为什么会沿供应链传递?
基础模型的训练数据、覆盖盲区、偏差、知识截止、安全弱点和评测缺口,可能被多个下游系统继承;下游的检索、工具、界面和自动化又会产生新风险。风险不是“全由上游负责”或“全由部署者负责”的二选一,而是沿供应链分层管理。
| 风险来源 | 可能表现 | 下游可做的控制 | 需要上游提供 |
|---|---|---|---|
| 训练数据与表示 | 语言/群体覆盖不足、偏差、隐私或权利争议 | 场景切片、补充数据、用途限制、人工复核 | 数据与限制说明、投诉与处置机制 |
| 生成不确定性 | 幻觉、遗漏、过度自信、不一致 | 来源约束、校验、拒答、风险分级 | 能力边界、评测方法、版本变更 |
| 安全弱点 | 提示注入、越狱、敏感信息泄露 | 数据隔离、最小权限、输出过滤、红队 | 安全公告、补丁、事件协作 |
| 系统集成 | 错误工具参数、越权动作、循环调用 | 沙箱、确认、限额、幂等、回滚和审计 | 稳定接口、权限范围和错误语义 |
| 运营变化 | 模型更新、漂移、涨价、停服或配额变化 | 版本固定、回归测试、多供应商和退出演练 | 变更通知、兼容期与导出能力 |
OECD AI 原则强调透明、稳健、安全和责任;ISO/IEC 42001则提供 AI 管理体系标准入口。标准和原则能帮助建立组织过程,但不会自动证明某个模型适合你的具体用途。对于安全威胁与处置,可以参考本站的AI 安全威胁与防护指南和AI 滥用风险治理清单。
企业选型与采购应问哪些问题?
把问题写进证据包和合同附件,而不是停留在销售演示。至少要求候选方说明模型/服务版本、适用任务、数据处理、评测、事件响应和退出路径。若答案只包含“行业领先”“企业级安全”“准确率高”,应继续追问可复核材料。
| 问题 | 合格证据 | 阻断信号 |
|---|---|---|
| 具体调用哪个模型与版本? | 可固定的标识、变更通知、回归窗口 | 服务可无通知替换且不能回滚 |
| 输入输出怎样使用和保留? | 目的、地点、期限、子处理者、删除与导出 | 条款含糊或与控制台设置冲突 |
| 许可证允许什么? | 权重/代码/数据各自许可与商用限制 | 把“开放权重”口头等同于无限制商用 |
| 质量证据是什么? | 与你任务匹配的数据、基线、失败样本和方法 | 只给综合榜单或精选演示 |
| 怎样处理安全事件? | 联系方式、时限、日志、补丁与联合调查 | 没有事件渠道或无法导出日志 |
| 如何退出或替换? | 数据/配置导出、兼容层、迁移测试和预算 | 核心提示、知识或日志无法带走 |
在进入采购前,先按本站的AI 项目立项与上线指南写清业务基线、目标指标、失败边界和停止条件。模型能力再强,如果没有明确用户、决策位置和责任人,也只是昂贵的技术试验。
一套可直接执行的基础模型选型流程
- 定义任务而非行业:写出输入、输出、使用者、动作、错误成本和拒绝条件。
- 建立非 AI 基线:记录当前人工、规则或搜索方案的质量、时间和成本。
- 筛选交付路线:先判断数据能否出域、是否需要私有部署、许可证和延迟约束。
- 建立版本化任务集:覆盖普通、边界、对抗、权限和失败恢复样本。
- 逐项运行而非只看总分:保存输入、输出、来源、延迟、费用与人工判定。
- 做系统级红队:测试检索污染、提示注入、工具越权、敏感数据和不可逆动作。
- 小流量上线:从只读、低风险和人工确认开始,设置告警、限额、熔断与回滚。
- 持续复核:模型、知识、提示、工具或政策任一变化后运行回归集。
这套流程的结果不是“哪个模型全球最好”,而是“在某一版本、某组任务和某套控制下,哪个方案达到了上线标准”。如果数据不足,应保留“未得出结论”,而不是用模型品牌或参数规模替代证据。
常见问题
基础模型一定是生成式 AI 吗?
不一定。基础模型强调广泛训练和下游适配,生成式 AI 强调生成内容。两者大量重叠,但概念不等同;NIST 也明确提醒,并非所有生成式 AI 都来自基础模型。
所有大语言模型都是基础模型吗?
不能仅凭“LLM”标签判断。若语言模型在广泛数据上训练并可适配多种下游任务,通常会被视为基础模型;面向单一窄域、由其他模型蒸馏或深度专门化的模型,边界可能需要结合训练与用途说明。术语本身不存在统一参数阈值。
基础模型就是 AGI 吗?
不是。基础模型可以跨任务复用,但这不证明它具备人类水平通用能力、意识或在所有环境中可靠行动。对 AGI 的定义和测试仍有争议,不应把产品营销名称当作既成事实。
使用基础模型必须微调吗?
不必须。很多任务先用提示、结构化输出、RAG 或工具即可验证。微调适合稳定、重复且有高质量样本的行为差距,也需要重新进行质量、安全和回归测试。
开放权重等于开源、免费和可商用吗?
不等于。需要分别检查代码、权重、训练数据、许可证、用途限制、托管成本和衍生模型义务。下载免费也不代表推断、运维和合规成本为零。
参数更多的基础模型一定更好吗?
不一定。任务质量还受训练数据、架构、后训练、提示、检索、工具和评测方法影响;生产选择还要考虑延迟、成本、稳定性、安全与可运维性。应使用自己的任务集比较。
结论:把基础模型当作可审计的依赖,而不是万能大脑
基础模型的价值在于复用:一次大规模训练可以支持多种下游任务。但复用也会放大上游依赖。成熟做法是明确模型与系统边界,选择最轻的适配方法,用真实任务与失败样本验收,并把许可证、数据、安全、成本、运行和退出能力一起纳入上线闸门。
复核说明:本文依据 Stanford CRFM/HAI、NIST、欧盟《人工智能法》、OECD、OSI、ISO 与 Hugging Face 截至 2026 年 7 月 18 日可访问资料整理。概念、服务条款和监管解释可能更新;采购或高风险部署应复核原始文件并咨询相应专业人员。本站的来源、更新与纠错原则见关于本站与编辑规范。
