从统计学习到通用智能

原创

从统计学习到通用智能精选

共 13,733 字，需阅读 34 分钟

2026/01/19 上午

852 次阅读

我第一次真正接触「人工智能」这个概念，是在 2016 年左右，在吴军博士的《智能时代》中，我得以窥见那些影响人类的前沿技术，都是如何在远在硅谷的实验室中被创造出来的。

那时候，我在 Coursera 学习吴恩达（Andrew Ng）的机器学习课程，古法手写了勉强能用的 NaiveBayes 分类器，甚至还让它在浏览器跑了起来。那时的技术核心大多围绕着传统统计学习。比如：

朴素贝叶斯：通过统计过往邮件的用词规律，来「计算」一封新邮件更像是垃圾邮件，还是正常邮件。
SVM（支持向量机）：在数据中寻找一条最优的「分界线」，试图以最大的间隙把不同类型的内容分隔开。

转眼多年过去，当下的数据规模、计算能力和模型参数量，都已经跨过了某个关键的「临界点」。这种巨大的量变最终引发了质变，一种近乎于意识涌现的智能现象开始频繁出现。

这种技术飞跃背后的核心动力是：深度学习（Deep Learning）。如果把深度学习看作一个坚实的地基，那么当下席卷全球的大模型（LLM），就是在这个地基之上盖起的、直插云霄的摩天大楼。

#大语言模型（LLM）

大模型的全名是 Large Language Model ，相比于规模跃迁之前的模型，突出的就是一个「大」字：它既大在万亿级别的参数量，也大在动辄数百 GB 甚至 TB 级别的模型规模。

通俗地说：大语言模型 = 深度学习技术 + 海量参数 + 惊人算力 + 近乎全人类文明的文本数据 × 训练之后的产物（推理能力）。

相比早期只能做标签化预测的分类器，大语言模型之所以显得「更聪明」，关键在于它学会了两件以前模型不擅长的事：

一、它开始真正理解一句话里的「顺序和关系」。

不再只是把词当成零散的符号，而是知道哪些词在前、哪些在后，它们之间是因果、指代，还是转折关系。这种对长文本逻辑的掌控力，让它能读懂「话外之音」。

二、它学会了在一句话里「抓重点」。

当一句话中出现「它」、「这件事」、「那个东西」之类的模糊指代时，模型会自动判断这些词更可能指向谁，而不是平均对待每一个词。这让它在理解长句、复杂语义时，看起来更像人在思考。

在这些核心能力的加持下，大模型开始向不同感官演化：

大语言模型 ：最成熟的分支，擅长文字创作、逻辑推理和对话。
视觉大模型 ：不仅能「看」到像素，更能识别出图像中的物体关系、场景氛围甚至复杂的动态行为。
多模态大模型 ：这是目前的「终极形态」，它能同时处理文字、图像和声音，像人类一样通过多种感官综合理解世界。

总之，大模型不再像以前那样只是「判断对错」的工具，而更像是：一个能理解上下文、组合信息、并给出连贯回应的智能系统。 这种体验，就如同我们在和 ChatGPT、Gemini 对话时那般自然。

#向量嵌入（Embedding）

在传统数据库里，存储的都是明确、量化、结构化的信息。比如这样的：

name	gender	height	weight	bmi
张三	male	180	80	24.7
李四	male	170	80	37.7
...	...	...	...	...

当我们需要检索数据时，只能通过明确的字段、参数来过滤数据输出。比如：用 /query?gender=male&height_min=175&bmi_max=23 来筛选出「身高高于 175 且 BMI 低于 23 的男性」。

但如果你的需求是：筛选出几个身材精壮的年轻小伙。 传统数据库就懵了：

「年轻」是多少岁？
「精壮」是看身高、体重、BMI，还是整体感觉？

这种模糊、主观、难以量化的语义，几乎无法用传统数据库来处理。因此， 向量数据库 （Vector Database）应运而生：它存储的核心不再是孤立的字符，而是将数据转化为具有特定含义的「特征向量」。

通俗一点说：向量数据库存储的不再是原始数据本身，而是数据的「含义」。

而「把数据转换成含义」的过程，就是 向量嵌入 （Embedding）。

Embedding 模型会把一段文字、一句话，甚至一张图片，转换成一串数字坐标，投射到一个高维的「语义空间」中。 在这个空间里：

含义相近的内容，位置会靠得更近（如「首相」与「总统」）。
含义无关的内容，距离自然会很远（如「汽车」与「寺庙」）。

当我们向 AI 提问时，它并不是在像传统检索那样「逐字匹配关键词」，而是在做一件更像人类的事情：找含义最接近的内容。

技术上，它会把问题也转换成一个向量，然后在数据库中寻找语义距离最近的数据片段。这种查找方式，被称为 相似性搜索 （Similarity Search）。常见的衡量标准包括：

欧几里得距离 ：测算两点间的「直线距离」，距离越短，相似度越高。
余弦相似度 ：关注向量之间的「夹角」，夹角越小，意味着它们的逻辑方向越一致。这在处理长短不一的文本语义时表现特别好。

简单来说：AI 并不是在找「完全一样的字符」，而是在找「内涵最接近的灵魂」。 也正因为有了这种机制，AI 才具备了理解人类语言中微妙差异的能力。

当我们开始用「含义」而非「关键词」来检索信息时，一个新的问题就出现了：如果这些「含义」来自我自己的数据，而不是模型的训练记忆呢？模型会给我怎样的答案？

比如，当我问直接去问 GPT：「我还是对前天发生的那件事耿耿于怀，你怎么看？」GPT 不知道前天发生了什么事，不知道训练记忆之外的信息，就只能胡编乱答或者无法回答。

于是，就有了 RAG 这种应用形态。

#检索增强生成（RAG）

前文提到，大语言模型（LLM）是通过海量数据训练得到的。它是一个拿海量数据训练出的结果（概率权重机制），而不是数据本身。 这就意味着它有两个明确的设计边界：

时效性：训练数据有截止日期，它不会知道今天刚发生的新闻。
覆盖面：基于公共数据训练，它不会知道专业领域知识、私有业务知识。

如果不考虑这些限制，大模型往往只能被当作一个通用的推理与生成工具来使用。那，要如何让模型知道并理解我的私有知识呢？

先看一个我经常会用到的实际场景：我每次完成一篇文章，都会把这篇文章的内容全文粘贴到 ChatGPT 的对话窗口，并请它给出纠错和点评。这个流程的实质就是：我把一段大模型原本并不了解的私有内容作为「上下文」交给它，再让它基于这些信息给出理解、分析和反馈。

但如果我给出的不再是一篇文章，而是合并全站的几百篇文章在一起的一个长达数十万字的集合，让大模型来给出一个整体评价呢？

单从技术上说，这是可以做到的。比如 Gemini 1.x 的模型就已经支持百万级 Tokens 的上下文窗口了。但是，这样做的效率会很低，在长上下文的频繁请求下，会产生大量的算力消耗，成本极高。

在现实的场景中，更多的需求是：一个企业希望把自己的产品手册、FAQ、技术文档等私有资料交给大模型，让它能够回答终端用户提出的各种问题。

在这种场景下，效率、成本、准确性 就成了必须认真考虑的问题。

这正是 检索增强生成 （Retrieval-Augmented Generation）出现的原因。

简单去理解的话，RAG 就像是给大模型进行一次「开卷考试」：先从海量资料中检索出相关的考点，再让大模型基于这些知识片段组装答案。

常见的 RAG 流程，大概可以分为两部分：

一、存知识：构建外部知识库。

分块（Chunking）：将长文档切分为语义相对完整的小片段。
向量化（Embedding）：利用 Embedding 模型将片段转为向量，存入向量数据库。

二、取与答：按需调取知识。

检索（Retrieve）：将用户问题转成向量，在数据库中查找语义最接近的内容片段。
生成（Generate）：将「问题 + 检索到的片段」一起打包发给大模型。一般来说，都是类似这样的指令：「请根据以下参考资料回答，如果资料未提及，请回答不知道。」

简单来说：RAG = LLM（聪明的大脑）+ 向量数据库（外部知识）。

如果没有外部知识库的支持，大模型只是一个空有逻辑、但在专业盲区会「一本正经地胡说八道」的机器人。而 RAG 的引入，让大模型从「凭记忆作答」转变为「基于证据说话」，在极大程度上抑制了 AI 的幻觉现象。

#智能体（AI Agents）

当我们向 ChatGPT 问出：今天清迈的天气怎么样？ ChatGPT 想要回答这个问题，就必须先「理解」我是在询问关于某时某地的某个数据，然后「动手」去调用一些 API 来获取对应的数据，再返回来组装后输出。

大模型 LLM 本身只是「大脑」，是强有力的思考工具。可以理解输入的意图，但无法产生副作用（即无法直接改变系统状态或操作现实世界）。也就是说：它知道我是在问天气，但它没办法去查询天气，除非我「明确教了它」查询天气的 API 以及调用方法。 或者是 Siri 知道我想让扫地机器人停下来，但我没告诉它扫地机器人应该如何停，它就没有任何办法。

就像这样，当我们不断地为大模型装备上各种可用的工具和能力：查天气的 API、搜索引擎、文件处理、代码执行... 并允许它在思考过程中自主选择和调用这些工具时，一个近乎万能的 智能体 （AI Agents）就诞生了。

通俗地说：AI Agents = 拥有手脚和工具（Tools）的大脑（LLM）。

它与普通 LLM 的最大区别在于：不只是回答问题，而是能够完成实际任务。 比如：

Gemini 集成了 Google 搜索能力，可以分析实时天气、股价和新闻。
ChatGPT 集成了文件与代码工具，可以直接翻译文档、转格式、写代码。

这些能力的背后，就是不同形式的 Agent 的集成。比如，下面就是一段运行在 Cloudflare Workers AI 中的关于工具集成的伪代码：

        
          
            
            JavaScript
          
          
        
        
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
          const { message } = await request.json();

// 定义 LLM 有哪些具体的工具可以使用
const tools = [
  {
    name: "word_to_pdf",
    description: "当用户提出要转换文档、Word 转 PDF 或处理 .docx 文件时调用。",
    parameters: {
      type: "object",
      properties: { filename: { type: "string" } },
    },
  },
];

const aiResponse = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
  // 将工具列表告知 LLM 大模型
  tools: tools,
  messages: [
    { role: "system", content: "你是一个工具网站的 AI 助手。如果用户想转 PDF，请直接调用 word_to_pdf 工具。否则请优雅地回答能力不足。" },
    { role: "user", content: message },
  ],
});

if (aiResponse.tool_calls?.some((tool) => tool.name === "word_to_pdf")) {
  // 如果 AI 理解用户语义后，下达了「转换」指令，则执行相关业务操作
  service.wordToPdf().then((result) => {
    return new Response({
      response: "文件已转换完成",
      pdf: result,
    });
  });
} else {
  return new Response(JSON.stringify({ response: aiResponse.response }));
}

但真正的挑战，出现在复杂任务中。

假设我们给 Agent 这样一个任务：我想去东南亚旅行，在东盟 10 个国家中选择目的地；我要天气晴朗、机票便宜、最好有廉价航空；如果这段时间没有廉航，就直接排除这个地方。

这个任务并不是一次查询就能完成的，而是涉及多个条件、多个步骤、前后强相关的判断。要想顺利完成，Agent 就必须具备像人类一样做事的能力。

那人是怎样做事的？人类在处理复杂任务时，通常会遵循一种朴素但有效的方法：先计划 → 再执行 → 看结果 → 再调整。

这就是著名的 PDCA 循环 。

PDCA 是美国统计学家 Shewhart 博士提出的，由另一个统计学家 Deming 采纳、宣传，获得普及，所以又称戴明环。

PDCA 就是把事务的流程分为四个阶段，以确保每次的目标都能达成。

计划（Plan）：拆解任务，制定步骤。
执行（Do）：按计划逐步行动。
检查（Check）：判断结果是否符合预期。
调整（Act）：总结经验或重新规划，进入下一轮。

这种方法在人类社会中被反复验证，甚至在日本工业界广受推崇，是高效完成复杂任务的经验总结。

在 AI 领域，这种思路被转化为 ReAct （Reason + Act）框架。它的核心是：让模型在每一步行动前进行思考（Thought），在行动后进行观察（Observation），并把结果反馈给下一步思考。

也就是说，Agent 会在执行过程中不断记录：我在想什么（Thought）、我调用了什么工具（Action）、得到了什么结果（Observation），再基于这些信息继续判断和执行后续任务。

ReAct 对应 PDCA，可抽象为：

规划（Plan/Thought）：将复杂的大任务拆解为小的、可操作的子任务（ToDo List）。
执行（Do/Action）：当内部知识不足时，主动调用外部 API（搜索、运行代码、访问数据库）。
评估（Check/Observation）：检查执行结果是否符合预期。如果 API 报错或数据异常，需要能自我定位原因。目前，顶级模型已具备一定的自我反思能力，但在严苛场景下还是需要结合特定逻辑进行校验。
反思（Act/Next Thought）：基于评估结果，决定是结束任务，还是调整策略进入下一个循环。

这种方式显著提升了 Agent 在复杂任务中的反思能力和问题解决能力，许多知名项目（如 AutoGPT 、 LangChain 中的 Agent 体系）都直接或间接采用了类似思路。

不过，当任务变得足够复杂时，问题也会随之出现：

如果任务拆解得不够细，步骤就无法穷尽。
如果缺乏评估与反馈，循环就可能永远停不下来。

因此，规划能力直接决定着 Agent 的鲁棒性，它是界定一个 Agent 是否真正可用的关键分水岭，也是现在 Agent 研究的核心方向之一。

ReAct 这种设计思想也可以用于 Prompt 的设计中，只需要遵循：

明确引导模型进行链式推理。
定义可执行的行为（工具或 API）。
要求模型在每次行动后进行观察与再评估。
允许循环执行，并设置终止条件（如最大步数或完成判定）。
在满足条件后输出最终答案。

一个典型 ReAct 范式的 Prompt 结构大概像这样：

        
          
            
            txt
          
          
        
        
          1
2
3
4
5
6
7
          Question: 用户的初始问题
Thought: 模型对问题的初步分析，决定下一步该做什么
Action: 模型选择要调用的具体工具
Action Input: 传递给工具的参数
Observation: 工具返回的结果（反馈给模型）
... (重复上述过程，直到找到答案)
Final Answer: 最终输出

这套结构，决定了「AI 像人一样做事」的实力。

#模型上下文协议（MCP）

Agent 的手脚和工具有很多，但 每只手、每只脚的「接口」都不一样，怎么办？

以前，如果想让 Agent 连接自己的 GitHub、Notion 或者本地数据库，开发者需要为每一个工具编写专属的集成代码。这就像是在 USB 出现之前，用鼠标要专门插一个接口，用键盘又是另一个接口，打印机、光驱... 每多一个不同能力的硬件，就要多适配一个硬件特定的接口。

为了终结这种「接口碎片化」的低效、混乱、强耦合， 模型上下文协议 （Model Context Protocol）应运而生。

可以把 MCP 想象成 AI 时代的 USB 标准。它是由 Anthropic（Claude 的母公司）提出的一项开放协议，旨在为大模型和外部数据、工具之间建立一套通用的「对话语言」。

以前的集成模式：模型 ↔ 专门的适配代码 ↔ 不同的工具/数据。
MCP 集成模式：模型 ↔ MCP 协议 ↔ 任何支持 MCP 的工具。

在当下这个 Agent 蓬勃的时代，MCP 非常重要，它极大地降低了开发成本，推进了 AI 生态的完善。

一、从「写集成代码」到「写工具协议」。

以前每接入一个新工具，都要：写一套专属的 Prompt 说明、写一层适配代码、处理模型返回结果，再喂回模型。现在工具只需要实现一次 MCP Server，模型只要支持 MCP Client，双方就能通过统一协议通信。就像是 USB 的公口插到母口那样简单。

开发者从「给模型写适配代码」，变成了「给工具声明能力边界」。

二、模型与工具解耦，避免「绑定厂商」。

传统集成，工具是绑定模型平台的，代码都是专门适配的。MCP 协议下，变成了：任何模型 ↔ MCP ↔ 工具。 哪怕今天用 GPT，明天换 Claude，也不用重写工具的集成了，只要模型支持 MCP Client 就可以无痛迁移。

三、上下文不再靠「猜」，而是结构化地理解。

在没有 MCP 时，模型理解外部环境通常靠：手动粘贴、模型猜测、Prompt 描述。 MCP 协议下：以结构化上下文的方式暴露能力、明确信息的访问的边界和权限。 这让模型在「动手」之前拥有了更清晰的全局观，而不是瞎猜。

简单来说： 如果说 Agent 是让大脑长出了手脚，那么 MCP 就是统一了手脚的神经反射接口。

截止目前，像 Cursor、Claude Desktop 等工具已经深度支持了 MCP。这意味着啥呢？意味着任何人都可以在本地跑一个简单的 MCP Server，让云端的顶尖大模型直接读写你的本地数据库或执行本地脚本。甚至在授权下读取本地的相册、日记、待办，让 AI 真正成为接管数字世界的「超级中枢」。

#模块化技能包（Skills）

如果说 MCP 能给大模型接上一堆不同能力的手脚，那 Skills 解决的就是另一件事：怎么指挥手脚把一件事真正做好。

MCP 关心「能不能做，能做哪些」，而 Skills 关心的是「该怎么做，怎么做最优」。 MCP 强调的是工具能力，Skills 强调的是使用工具的方法论。

就像是：当我们需要做一顿饭，MCP 会先帮我们确保有刀能切、有锅能炒、有灶台能生火，先把工具能力准备齐全；但一顿饭做出来好不好吃，取决于厨师的经验（像是顺序、火候、调剂佐料的时机...）而这些东西，不是工具能实现的，它们是方法，是经验。

Skills 本质上就是把这些「方法」结构化、显式化，变成 AI 可以反复遵循的一套标准流水线 SOP 。

在技术实现上，Skills 解决了一个关键痛点：上下文空间浪费。

比如，我们现在设计了一个机器人，为了力求它全知全能，我们基于一个顶级的大模型，并为它配备了 500 个工具，于是我们就需要把这 500 个工具各自的说明书打包，在 AI 启动时（运行前）全部一股脑丢给它。而这种操作，会瞬间占满 AI 的注意力，导致 AI 在处理核心任务时能力下降，这就是上下文膨胀（Prompt Bloat）。

而 Skills 采用的是 「渐进式披露」 策略。也就是：AI 在启动时只会看到所有 Skill 的名字和简短描述，只有当 AI 判断当前任务确实需要某个特定 Skill 时，才会按需加载它的详细内容。这就像是，以前是给 AI 读整本工具书的全文，AI 记不住，而且还会因为信息太多而把我的问题本身给降权，导致回答不准确；而现在不再给 AI 直接读一本书，而是给它读一个带简单摘要和名字的目录，当要用到某个工具的时候，再进去翻到工具所在的内容页。

一个 Skill 在工程上的表现很简单，其实就是一个文件夹，里面有一个主要的 skill.md 描述文件，和一些可选的资料文件。结构虽然朴素，但在理念上它承载的是一套工作方法论：

skill.md：核心文件，包含元数据（名称/描述）和正文（详细的执行步骤与 SOP）。
References（参考资料）：存放目标范例，让 AI 知道「好结果」长啥样。
Assets（素材模板）：提供规范的输出格式，比如一个 Notion 页面模板。
Scripts（自动化脚本）：对于既定的操作步骤，直接提供代码让 AI 调用。

AI 启动时，并不会把所有 Skill 的正文一股脑塞进上下文，它只去理解每个 Skill 的名字和一句话简介，只有当它判断「这个 Skill 和当前任务高度相关」时，才会把这个 Skill 的正文加载进来。这就是一种按需展开、渐进披露的设计。

也许在未来 AI 会聪明到不再需要人类主动告知它 SOP。但当下的现实是：越是复杂、越是结果导向的事情，越依赖流程。除非我们对结果本身没有确定性要求。

顺序不一样，结果就不一样。 做饭是这样，写作是这样，做项目、做规划、做决策，也都是这样。Skills 做的事情，就是把那些「经验里才有的流程」提前写清楚：什么时候该问问题，什么时候该产出草稿，什么时候该检查、对齐、收敛，做到什么程度才算「合格」。

这些判断，工具不知道，模型也不会凭空知道，它们只能来自人类智慧的沉淀。

#提示词（Prompt）

传统编程，是以人的意图设计为蓝本（产品），用代码去实现具体业务（开发）。

AI 驱动的编程，同样是实现人的意图（产品），但不再有程序实现这一步，而是通过自然语言编织逻辑（Prompt）来传递意图。 大模型理解这些提示词后，会根据指令去调用对应的工具或生成内容，从而完成任务。

所以，提示词工程不仅仅是简单的提问，而是一门能让 AI 更好地理解和执行需求的技术。 于是就衍生出了这门叫提示词工程（Prompt Engineering）的学问。

简而言之：提示词（Prompt）就是你提交给大模型的「需求说明书」。 你怎么问，它就怎么答。问得好，答案就靠谱；问得烂，答案就离谱。

目前市面上大部分的 AI 功能的本质都是一样的：构造一个 Prompt，然后调用大模型 API。

比如：

AI 润色/摘要？→ Prompt + LLM
AI 翻译/改写？→ Prompt + LLM
AI 生成 PPT？→ Prompt + LLM

所以想实践好大模型应用，Prompt 的编写是非常重要的。而一个良好的 Prompt 结构，就是能够向大模型阐述清楚需求逻辑的结构。

角色（Role）：定义大模型现在的身份（如：你是一位资深的架构师）。
规则（Constraints）：明确必须遵守的底线（如：严禁泄露用户信息，回答必须简洁）。
流程（Workflow）：分步说明做事的方法（如：第一步提取关键词，第二步分析情感）。
输出（Output）：规定结果的格式（如：以特定结构的 JSON 输出，或使用 Markdown 表格）。

当逻辑组织得足够清晰严密时，大模型输出的稳定性和质量都会有很好的提升。

#技术、商业、人文

简单总结一下这些 AI 相关的概念与技术：

LLM：核心大脑（负责理解与推理）。
Embedding：语义翻译官（将万物转化为向量坐标）。
Vector DB：外部记忆库（存储海量坐标，支持语义检索）。
RAG：开卷考试模式（LLM + 向量数据库，解决知识陈旧问题）。
Agent：全能助理（LLM + 插件/工具，具备执行力和副作用）。
MCP：统一接口（AI 界的 USB 标准，连接 Agent 与工具）。
Prompt：控制指令（人与上述所有技术交互的语言）。

基于这些技术，也可以看出些许当下 AI 行业的应用版图。

超级智能体（Agent）：以 ChatGPT、Claude、Gemini 为代表，它们集成强大的插件生态（可能间接推动像 MCP 这种接口标准），以全能助手的定位直接服务用户。
开源底座：像是 DeepSeek、阿里的通义千问（Qwen）、Meta Llama 等强力开源模型。这些都是构建 Agent 的核心底座。
知识库存储：诸如 SupaBase 、 Pinecone 或 Cloudflare Vectorize 之类的云商业数据库，为 AI 提供持久化记忆。
开发编排平台：诸如 Dify 之类的平台，允许开发者通过可视化流，将模型、向量库与工具集成，快速搭建 Agent 应用。
垂直方案封装：像 FastGPT 之类的平台，更侧重于业务层的深度封装。使用成本略高，但效率很高，对完全 0 技术人群来说相当友好。
基础算力设施：以 Cloudflare Workers AI 为代表，只部署开源模型，完全按照算力消耗付费，而且免费额度完全管饱，个人开发者门槛很低。