大模型学习操作文档(13个核心概念串讲)
核心概念全解
第一阶段：和模型对话
- Prompt:你和模型说的每一句话
- System Prompt:给模型定规矩
第二阶段：理解模型的边界
-
Token:模型不是按照"字"来读的
-
上下文窗口：模型一次能看多少
-
幻觉：模型会一本正经的胡说八道
第三阶段：让模型可用
- Structured Output:输出别乱来
- Function Calling:别编了，去查真实数据
- RAG：模型不认识你的私有数据
- Embedding:RAG背后的"翻译官"
- 向量数据库：存向量的"专用仓库"
- 微调：和RAG的区别
第四阶段：让模型自主
-
Agent:让模型自己跑起来
-
MCP：工具对接的USB协议
-
Skill:能力的标准化封装
Prompt:你和模型说的每一句话
Prompt就是你输入给大模型的内容
System Prompt:给模型定规矩
普通的Prompt是你问一句它答一句
但是如果你想让模型始终按照某种风格回答，这个时候就需要System Prompt在对话之前给模型设定一个角色和行为规范
Token:模型不是按照"字"来读取的
Token是大模型处理文本的最小单位，一个汉字通常是1-2个Token，一个英文单词可能是1-3个Token
大模型的一切都以Token计量
上下文窗口：模型一次能看多少
窗口满了怎么办？最早的内容会被挤出去-模型忘记你前面说了什么
上下文窗口越大，成本越高、延迟越高，还可能使中间的内容注意不到
- agent = model + harness
- 在一个ai agent系统里面，除了模型本身之外，几乎所有决定它能不能稳定交付的东西，都属于harness
从prompt到context到harness：ai工程的三次重心转移
-
第一阶段：Prompt Engineering 让模型听懂
- 大模型本质上是一个对上下文极度敏感的概率生成器，你给他什么样的输入，他就沿着那个方向，所以同一件事，换个说法效果效果会差很多
- 核心：模型不是不会，而是你没有把话说明白
- 提示词擅长把任务表达清楚，但是不擅长凭空补出模型不知道的知识。它解决的是"表达"的问题，不是"信息"的问题
-
第二阶段：Context Engineering 让模型知道
- 核心：模型未必知道，所以系统必须在合适的时机，把正确的信息送出去
- 召回（找最相关的信息）、压缩（摘要提炼省空间）、组装（按照顺序排好，重要的放后面）
-
第三阶段：Harness Engineering 让模型做对
- 前两代工程关注的是怎么让模型更会想，Harness关注的是"怎么让模型不跑偏、跑的稳、出了错还能爬起来"
成熟的Harness分为6层
-
按照他在干啥分为3组
-
输入侧（让模型看到正确的东西）：上下文精细化管理+记忆与状态管理
-
动作侧（让模型做出正确的事）：工具系统+任务执行编排
-
校验侧（让模型知道做没做对+出错可以爬起来）：评估观测+约束恢复
-
第一层：上下文精细化
-
管的是空间：发给模型的那一坨上下文，长啥样，装了啥，怎么排布。
-
核心：
- 把角色和目标钉死：大部分agent跑偏，根源是没有说清楚身份。模型要知道自己是谁、任务是啥、成功的标准
- 动态筛选，不是一次塞满：让agent边干活边按需抓信息，而不是一上来就把所有可能有用的东西塞进去
- 结构化组织：固定规则放一处，动态证据放一处，中间结论放一处
-
-
第二层：工具系统
-
没有工具的大模型就是文本预测器，接上工具之后，才能真正活过来
-
给他哪些工具、什么时候使用、工具结果怎么喂回来模型
-
MCP：本质上就是在做工具的标准化，让任何工具都能用同一种方式接到任何agent
第三层：执行编排
- agent的本质，其实就是一个for循环:思考一步->行动一步->观察结果->在思考下一步
- 职责：给模型一条明确的工作轨道，让他知道"我现在在哪一步，下一步干啥"
第四层：记忆与状态
-
幻觉：模型会一本正经地胡说八道
大模型会编造不存在的东西，幻觉不是BUG，是大模型工作方式的副产物，它本质上是在预测下一个最可能出现的Token而不是在检索事实
幻觉的存在，催生了后面的一系列技术：
- Function Calling:不让模型自己编答案，而是让他去调用真实的接口查数据
- RAG：把真实的文档检索出来塞进上下文，让模型基于事实来回答
Structured Output:输出别乱来
模型的默认输出是自由文本，想说什么说什么
但做应用开发，需要的往往是结构化数据
Structured Output就是约束模型按照指定格式输出，格式：
- 在Prompt里规定格式
- 用JSON Schema约束（可靠，api支持）
-
Function Calling：别编了，去查真实数据
模型有两个硬伤：不知道实时信息，也不能操作外部系统
Function Calling就是解决这个问题的：你给模型定义一组"工具"函数，模型在回答时可以决定调用哪个工具，你的代码负责执行，把结果返回
RAG：模型不认识你的私有数据
模型训练用的是公开数据，你公司的内部文档、会议纪要、需求文档---它都不知道
最直觉的想法就是:把相关资料找出来，塞进上下文，让模型基于这些资料来回答
RAG：检索增强生成
RAG不改变模型本身，而是在提问的时候给模型补充资料
离线阶段：把你的文档切成片段，转成向量，存进数据库
在线阶段：用户提问时，检索最相关的片段，塞进上下文，模型基于这些片段回答
Embedding:RAG背后的翻译官
如何判断相关
Embedding就是把文本翻译成一组数字（向量），语义越相近的文本，向量距离越近
向量数据库：存向量的"专用仓库"
有了Embedding，还需要来存放这些向量
普通数据库（Mysql)擅长精确匹配和范围查询，但是向量检索是找"最近的邻居"这是不同的查询方式
向量数据库：存向量、快速做相似度检索。
微调：和RAG的区别
简单来说：要让模型"知道新知识"->RAG
要让模型"学会新能力"->微调
Agent：让模型自己跑起来
有了Function Calling,模型就能调用工具，有了RAG，模型有私有知识
Agent就是把"你判断下一步"这件事交给模型自己做
一个典型的agent循环：
- 接收用户任务
- 自己规划：这件事分几步
- 执行第一步：调用工具、检索资料、直接回答
- 观察结果：判断是否继续
- 如果没有完成，回到第二步
- 任务完成输出最终结果
agent的本质=思维链（规则能力）+Funciton Calling（执行能力）+循环（迭代能力）
所谓思维链，就是让模型把推理过程一步一步写出来，而不是直接给结论。让模型"想清楚再行动"，这就是agent自主规划的基础
MCP：工具对接的"USB"协议
agent能调工具，但是问题来啦，每次接一个新工具，就要写一套对接代码，换个大模型，又要重新写
就像是手机充电口，以前每个手机平牌一个接口，充电器不能通用。MCP就是AI领域的"USB-C"：一个标准化协议，让任何模型都能用统一的方式连接外部工具和数据源
有了MCP：
- 工具开发者只需要实现一次MCP协议，所有支持MCP的模型都能用
- 应用开发者不需要为每个工具写适配代码
- 换模型不需要改工具对接逻辑
skill:能力的标准化封装
skill在agent和mcp之上进一步抽象
skill把agent的某个能力封装成一个可复用的"技能包"，每个skill定义了"能做什么、需要什么输入、输出什么格式、依赖那些工具"