还不知道怎么学AI?看完这篇你就会了

为什么要知道这个？因为大模型的一切都按Token计算：

计费按Token算，上下文窗口大小按Token算，API 的速率限制也按 Token 算

你跟模型聊天，所有的输入——System Prompt、对话历史、返回的结果——都装在一个"窗口"里，这个窗口就叫上下文。

而这个窗口有大小限制，这就是上下文窗口（Context Window）。

大模型会编造不存在的问题，而且语气很自信。问它一个不存在的事，它能给你编出完整的逻辑；问它某个工具的用法，它能编一个根本不存在的参数。这就是幻觉。

幻觉不是 Bug，是大模型工作方式的"副产物"——它本质上是在预测"下一个最可能出现的 Token"，而不是在"检索事实"。

理解了幻觉，你就理解了为什么后面这些技术会被需要。

第三阶段：让模型可用

模型的默认输出是自由文本，想说什么就说什么；

Structured Output 就是约束模型按指定格式输出。常见方式有：

1.在Prompt里约定格式（简单但是不稳定）

2.用JSON Schema约束（更可靠，主流API都支持）

这是从“聊天”走向“系统”的关键一步

模型训练用的是公开的数据，但你们公司内部文档，公司会议记录，你的项目需求，它都是不知道的。那么怎么办呢？最直接的办法：把相关资料塞进上下文里，让模型基于资料回答。

这就是RAG（Retrieval-Augmented Generation），检索增强生成：

1.离线阶段：把文档切成片段，转成向量，存进数据库

2.在线阶段：用户提问时，检索最相关的片段，塞进上下文，模型基于这些片段回答

RAG 不改模型本身，而是"在提问的时候给模型补充资料"。这比微调成本低、更新快、也更可控。

RAG要检索相关的片段，那么哪些是相关的呢？

Embedding就负责把文本“翻译”成一组数字（向量），语义越接近的文本，向量距离越近。

所以RAG的检索不是直接搜关键词，而是算向量之间的距离，找到语义最相近的文档片段

有了Embedding之后，就需要一个地方来存这些向量，并且还要能够高效检索，普通数据库（Mysql，Postgresql）擅长精确匹配和范围查询，但向量检索是“找最近的邻居”，这是完全不同的查询方式

向量数据库就是专门做这件事的：存向量，快速相似度检索。

讲到RAG时，有同学会问：为什么不直接微调呢？直接把数据喂给模型不就行了？

实际上并没有这么简单，微调和RAG解决的是不同的问题：

简单来讲：

让模型知道新知识：RAG

让模型学会新能力：微调

大多数开发场景都是RAG优先，微调则是更贵的武器，需要足够的资源

第四阶段：让模型自主

有了Function Calling，模型能调用工具；有了RAG，模型有私有知识了，但是现在，每一步还是我们自己在操控。

Agent就是把“你判断下一步”这件事交给模型来做

Agent本质：思维链（规划能力）+Function Calling（执行能力）+循环（迭代能力），让模型想清楚再行动，这就是Agent能自主规划的基础