AI核心概念体系完整解析
AI核心概念体系完整解析
本文档系统梳理现代AI系统的核心组件、技术机制及内在联系,帮助理解从基础到应用的完整技术栈。
目录
- Token:AI世界的语言乐高
- Context:模型的工作记忆
- Agent:从大脑到躯体的智能体
- LLM:语言理解的核心引擎
- Skill:模块化的能力组件
- Prompt:人机交互的核心桥梁
- 扩展核心概念
- 概念间内在联系
- 实际应用指南
1. Token:AI世界的语言乐高
1.1 定义
Token是AI模型处理文本的最小语义单元。它不是字,也不是词,而是模型通过分词器将文本智能拆解成的有意义的片段。
1.2 工作原理
分词机制
模型使用不同的分词算法将文本转换为Token序列:
- BPE (Byte Pair Encoding):从字节对开始迭代合并高频组合
- WordPiece:基于概率的分词策略,优先保留完整单词
- Unigram Language Model:基于单语模型的概率分词
示例对比
文本:unbelievable
不同分词器结果:
- BPE:un + belie + able (3 tokens)
- WordPiece:un + believ + able (3 tokens)
- Unigram:un + belie + able (3 tokens)
1.3 语言差异
中英文Token计算差异
| 语言 | 平均Token数 | 计算特点 |
|---|---|---|
| 英文 | 1个单词 ≈ 1.3-2个token | 间距词、前缀后缀拆分 |
| 中文 | 1个汉字 ≈ 1.5-2.5个token | 消耗比英文多50%-100% |
| 代码 | 1行代码 ≈ 5-20个token | 语法结构复杂 |
成本影响
由于中文消耗更多Token,在相同的字符数下,中文任务的API调用成本比英文高约60-80%。
1.4 API计费
计费模型
API调用按输入Token和输出Token分别计费:
- 输入Token:用户提供的Prompt + 上下文信息
- 输出Token:模型生成的响应文本
价格差异
输出Token的价格通常是输入Token的3-10倍,这是因为生成过程需要更多的计算资源。
2026年价格梯队
| 档次 | 价格区间(元/1亿Token) | 代表模型 |
|---|---|---|
| 基础 | 135-250 | Gemini 2.0 Flash-Lite, 通义千问Plus |
| 进阶 | 800-1000 | GPT-5 Mini, Kimi K2 |
| 专业 | 3600-6500 | GPT-5, Claude Sonnet 4 |
| 顶级 | 30,000-68,000 | Claude Opus 4, GPT-5.2 Pro |
1.5 优化技巧
1. Prompt Caching(提示词缓存)
- 缓存重复的System Prompt和上下文
- 可节省高达90%的输入Token成本
- 适用于批量处理、会话保持场景
2. 术语压缩
- 定义常用术语的缩写
- 减少重复性的描述性文本
- 示例:
原:人工智能驱动的数据分析系统需要处理大规模结构化数据 优:AI-DA系统需处理大规模结构化数据
3. 长文本分块处理
- 将长文档拆分为多个上下文窗口
- 通过RAG(检索增强生成)动态检索相关段落
- 避免一次性输入超长文本
1.6 在系统中的作用
Token是整个AI系统的计算基础:
- 计算单位:模型的所有推理计算都以Token为基本单位
- 成本标尺:API调用、资源消耗都与Token数量直接相关
- 性能瓶颈:上下文窗口限制了单次能处理的Token数量
- 信息密度:相同含义不同表述,Token数量可能差异巨大
2. Context:模型的工作记忆
2.1 定义
Context(上下文)指AI模型在生成响应时所能参考的全部前文信息,包括:
- System Prompt:系统指令,定义模型的角色和行为规范
- 对话历史:之前的对话轮次
- 用户输入:当前的提问或指令
- 附加文档:用户上传的文件、检索到的外部资料
2.2 工作机制
上下文窗口
每个模型都有固定的上下文窗口大小,定义了单次请求能处理的Token上限。
信息流向
用户输入 → 分词为Token → 加入Context → 模型推理 → 生成输出Token
2.3 上下文窗口演进
历史发展
| 年份 | 模型 | 上下文窗口 | 相当于 |
|---|---|---|---|
| 2023 | GPT-4 | 8K | 约6,000汉字 |
| 2024 | Claude 3 | 200K | 约15万汉字 |
| 2025 | Gemini 1.5 | 1M | 约75万汉字 |
| 2026 | Llama 4 Scout | 10M | 约750万字 |
技术突破
从8K到10M Token的跨越,主要通过以下技术实现:
- 线性注意力机制:降低复杂度从O(n²)到O(n)
- 环形注意力:实现无限上下文的理论可能
- 压缩技术:智能压缩历史上下文,保留关键信息
2.4 实际挑战
Lost in the Middle现象
模型对上下文信息的注意力分布呈现U型:
- 开头和结尾:信息容易被准确捕捉
- 中间位置:信息容易被忽略或误解
有效上下文 vs 标称上下文
- MCW (Maximum Context Window):模型宣称的最大窗口
- MECW (Maximum Effective Context Window):实际可靠处理的窗口
研究发现,MECW通常只有MCW的30%-70%,具体取决于任务的复杂度。
实用建议
- 保持利用率 < 70%:在标称窗口的70%以内使用,保证稳定性
- 重要信息放两端:将关键指令、约束条件放在开头或结尾
- 结构化组织:使用清晰的标题、列表等结构提高信息可读性
2.5 优化策略
1. 上下文压缩
- 使用摘要压缩历史对话
- 智能识别并删除冗余信息
- 保留关键实体和意图
2. 分块检索(RAG)
- 不将全部上下文传入模型
- 先进行语义检索,只传入最相关的片段
- 降低Token消耗,提升相关性
3. 滑动窗口
- 维护固定大小的最近N轮对话
- 保留最新上下文,丢弃早期内容
- 适合无状态的长对话场景
2.6 在系统中的作用
Context是模型记忆的边界:
- 能力边界:决定了模型能"记住"多少信息
- 性能瓶颈:长上下文处理成本高、延迟大
- 质量保证:合理的上下文组织显著提升输出质量
- 成本控制:通过优化Context管理可大幅降低Token消耗
3. Agent:从大脑到躯体的智能体
3.1 定义
Agent(智能体)是以LLM为核心的、能够自主感知、决策和执行复杂任务的AI系统。
与单纯的LLM不同,Agent具备自主性,能够:
- 感知环境:理解当前状态和外部变化
- 自主决策:根据目标制定执行计划
- 执行行动:调用工具、API或物理设备
- 学习进化:从经验中优化行为策略
3.2 核心架构
公式表达
Agent = LLM(大脑)+ 记忆系统 + 规划能力 + 工具使用
核心组件
| 组件 | 功能 | 技术实现 |
|---|---|---|
| LLM | 认知核心,理解意图、生成决策 | GPT、Claude、LLaMA等 |
| 记忆系统 | 短期记忆(上下文)+ 长期记忆(向量数据库) | ConversationBuffer、Vector Store |
| 规划能力 | 任务分解、策略优化、动态调整 | Chain of Thought、ReAct、Plan-and-Solve |
| 工具使用 | 外部API调用、数据库查询、物理设备交互 | Function Calling、插件系统 |
3.3 核心特征
1. 自主性
不是被动响应用户输入,而是主动规划任务路径。
2. 反应性
能够感知环境变化,动态调整执行策略。
3. 主动性
在目标明确的情况下,主动采取行动,无需持续人类干预。
4. 社会性
多Agent协作,分工合作完成复杂任务。
5. 进化性
通过反馈学习,不断优化决策和执行策略。
3.4 典型应用场景
企业级应用
- 客户服务:自主解答、工单创建、知识库检索
- 销售营销:线索筛选、邮件撰写、客户跟进
- 财务审计:数据采集、异常检测、报告生成
- IT运维:故障诊断、自动修复、日志分析
开发场景
- 代码审查:静态分析、安全扫描、优化建议
- 自动化测试:用例生成、执行、结果分析
- CI/CD集成:自动构建、部署、监控
生活场景
- 个人助理:日程管理、邮件分类、信息摘要
- 学习助手:知识问答、习题辅导、学习计划制定
3.5 代表产品
| 产品 | 核心能力 | 应用场景 |
|---|---|---|
| OpenAI Operator | 网页操作、表单填写 | 自动化办公、数据采集 |
| 智谱AutoGLM | 手机APP操作 | 自动化手机任务 |
| Manus | 通用任务执行 | 多领域工作自动化 |
| Amazon Bedrock Agents | 企业级工作流 | B端业务自动化 |
3.6 与LLM的核心区别
| 维度 | LLM | Agent |
|---|---|---|
| 核心能力 | 语言理解、文本生成 | 规划决策、工具使用 |
| 交互方式 | 被动响应 | 主动行动 |
| 执行能力 | 仅生成文本 | 可调用外部系统 |
| 记忆能力 | 仅短期上下文 | 短期+长期记忆 |
| 任务复杂度 | 单轮或有限多轮对话 | 长期复杂任务 |
| 自主性 | 无 | 强自主性 |
3.7 在系统中的作用
Agent是AI从"认知"到"实践"的桥梁:
- 能力延伸:将LLM的语言能力转化为实际操作能力
- 任务自动化:端到端完成复杂任务链
- 系统集成:连接多个系统和API
- 价值实现:从"回答问题"到"解决问题"
4. LLM:语言理解的核心引擎
4.1 定义
LLM(Large Language Model,大语言模型)是基于Transformer架构、在海量文本数据上预训练的深度学习模型,具备强大的语言理解、生成和推理能力。
4.2 工作原理
Transformer架构核心
LLM的核心是自注意力机制(Self-Attention),能够:
- 并行处理:同时处理序列中所有Token
- 捕捉依赖:理解长距离的语义关联
- 位置编码:识别Token的顺序关系
训练流程
预训练(海量无监督文本)
↓
学习语言模式、世界知识
↓
微调(特定任务数据)
↓
优化特定领域能力
↓
对齐(人类反馈强化学习)
↓
对齐人类价值观和期望行为
4.3 主要能力
1. 语言理解
- 语义理解:理解文本含义、上下文关系
- 意图识别:识别用户的真实需求和意图
- 实体识别:提取人名、地名、时间等关键信息
2. 文本生成
- 文本创作:文章、报告、代码生成
- 翻译:多语言互译
- 摘要:长文本精简提炼
3. 逻辑推理
- 归纳推理:从具体案例总结规律
- 演绎推理:从已知推导未知
- 类比推理:发现概念间的相似性
4. 代码理解与生成
- 代码解释:理解代码逻辑
- 代码生成:根据需求生成代码
- 调试:发现并修复bug
4.4 能力边界
1. 幻觉问题
模型会生成看似合理但完全虚构的信息,主要原因:
- 概率生成:基于概率预测下一个Token,而非真实查询
- 训练数据局限:训练数据不包含实时信息
- 缺乏验证机制:无法自我验证生成内容的真实性
2. 知识截止
预训练模型的知识截止于训练完成的时间点,无法获取实时信息。
3. 数学精确性
虽然可以进行数学运算,但复杂计算可能出错,原因:
- Token化的数字不再是精确数值
- 缺乏专门的数学推理模块
4. 长程一致性
在超长文本中,可能忘记早期的上下文或产生自相矛盾的内容。
4.5 代表模型
GPT系列(OpenAI)
- GPT-4:2023年,8K/32K/128K上下文
- GPT-4 Turbo:2023年底,128K上下文,成本更低
- GPT-5:2025年,支持多模态、推理能力大幅提升
Claude系列(Anthropic)
- Claude 2:200K上下文,长文本能力突出
- Claude 3:2024年,200K/1M上下文,安全对齐优秀
- Claude 4:2026年,Opus/Sonnet/Haiku三档
Gemini系列(Google)
- Gemini 1.0:2023年底,多模态强项
- Gemini 1.5:2025年,1M上下文,视频理解突出
LLaMA系列(Meta)
- LLaMA 2:开源,参数70B
- LLaMA 3:2024年,405B参数,性能接近闭源模型
- LLaMA 4:2026年,Scout版本支持10M上下文
国产模型
- 通义千问:阿里巴巴,多档位选择
- Kimi:Moonshot AI,长文本能力强
- 智谱GLM:Zhipu AI,中文优化
- 百川:百川智能,开源友好
4.6 选择建议
根据任务类型选择
| 任务类型 | 推荐模型 | 理由 |
|---|---|---|
| 通用对话 | GPT-5, Claude 4 | 综合能力强 |
| 长文本处理 | Claude 4, Gemini 2.5 | 上下文大,稳定性高 |
| 代码开发 | GPT-5, Claude 4 | 代码理解生成强 |
| 中文任务 | 通义千问、智谱GLM、Kimi | 中文优化好 |
| 成本敏感 | Gemini Flash-Lite, GPT Mini | 价格低 |
| 安全合规 | Claude 4 | 安全对齐优秀 |
根据预算选择
- 低成本:使用基础模型 + RAG,成本降低60-80%
- 平衡性价比:选择中档模型(如Claude Sonnet 4)
- 追求质量:使用顶级模型(如GPT-5.2 Pro)
4.7 在系统中的作用
LLM是整个AI系统的认知核心:
- 基础能力提供者:为所有上层应用提供语言理解和生成能力
- Agent的大脑:是Agent决策和规划的核心组件
- 工具调用的理解者:理解何时、如何调用外部工具
- 多模态的统一接口:整合文本、图像、音频等多种模态
5. Skill:模块化的能力组件
5.1 定义
Skill(技能)是AI系统中封装特定领域知识和操作逻辑的可复用能力模块。
5.2 核心特征
1. 领域专业化
每个Skill专注于特定领域或任务:
- 数据分析Skill:数据清洗、统计分析、可视化
- 代码生成Skill:代码编写、重构、调试
- 文档处理Skill:格式转换、内容提取、摘要生成
2. 可组合性
多个Skill可以组合协作,完成复杂任务:
复杂任务 = Skill1 + Skill2 + Skill3 + ...
3. 动态加载
- 根据任务需求动态加载相关Skill
- 不需要时卸载,节省资源
- 支持Skill的热更新和扩展
5.3 Skill与Tool的区别
| 维度 | Skill | Tool |
|---|---|---|
| 抽象层次 | 高级能力封装 | 底层功能接口 |
| 智能程度 | 包含决策和逻辑 | 单一功能执行 |
| 实现方式 | 可能组合多个Tool | 单一API或函数 |
| 复用性 | 可复用组件 | 一次性调用 |
| 示例 | "数据分析"Skill | "查询数据库"Tool |
关系表达
Skill = 智能封装的Tool集合 + 领域知识 + 决策逻辑
Tool = Skill的执行基础
5.4 Skill的分类
预定义Skill
由开发者预先编写并加载的固定技能:
- 系统级Skill:日志分析、错误诊断、性能监控
- 领域级Skill:法律文档分析、医疗问答、金融报表分析
- 工具级Skill:文件操作、网络请求、数据库访问
动态学习Skill
Agent通过学习和经验积累形成的技能:
- 个性化Skill:适应特定用户偏好的技能
- 经验型Skill:从历史任务中提炼的最佳实践
5.5 Skill的实现架构
示例:数据分析Skill
class DataAnalysisSkill:
def __init__(self, llm, tools):
self.llm = llm # LLM作为决策核心
self.tools = {
'load_data': tools.load_csv,
'analyze': tools.analyze_statistics,
'visualize': tools.create_chart
}
self.knowledge_base = load_domain_knowledge('data_analysis')
def execute(self, task, data):
# 1. 理解任务
intent = self.llm.parse(task)
# 2. 加载数据
df = self.tools['load_data'](data)
# 3. 根据任务选择分析方法
if intent['type'] == 'statistics':
result = self.tools['analyze'](df, metrics=intent['metrics'])
elif intent['type'] == 'visualization':
result = self.tools['visualize'](df, chart_type=intent['chart'])
# 4. 生成解释性说明
explanation = self.llm.explain(result, context=self.knowledge_base)
return {
'result': result,
'explanation': explanation
}
5.6 Skill的组合模式
1. 串行组合
Skill按顺序执行,前一个Skill的输出作为后一个Skill的输入:
数据提取Skill → 数据清洗Skill → 数据分析Skill → 报告生成Skill
2. 并行组合
多个Skill同时执行,最后合并结果:
[中文翻译Skill] \
→ 结果合并Skill → 最终输出
[英文翻译Skill] /
3. 条件组合
根据条件选择执行哪个Skill:
如果任务类型 == "代码生成":
代码生成Skill
否则如果任务类型 == "数据分析":
数据分析Skill
5.7 在系统中的作用
Skill是AI系统的能力模块:
- 专业化封装:将领域专业知识封装为可复用组件
- 复杂任务分解:将复杂任务分解为多个Skill的组合
- 系统扩展性:通过添加新Skill扩展系统能力
- 质量保证:专业Skill在特定领域比通用LLM表现更好
6. Prompt:人机交互的核心桥梁
6.1 定义
Prompt(提示词)是用户输入给AI的指令、问题、上下文或任何形式的引导信息,是人与AI沟通的核心接口。
6.2 提示工程(Prompt Engineering)
定义
提示工程是设计和优化Prompt以引导模型生成期望输出的技术和艺术。
重要性
优质的Prompt可以:
- 提升性能:将模型输出质量提升30-50%
- 降低成本:通过精简Prompt减少Token消耗
- 提高可靠性:减少幻觉和错误回答
- 加速开发:无需微调即可适配新任务
6.3 核心原则
1. 清晰直接
- 使用明确的指令,避免模糊表述
- 直接说明期望的输出格式
示例对比
❌ 差:帮我分析一下这个数据
✅ 好:请分析以下销售数据,输出格式为:总销售额、同比增长率、Top 5产品
2. 提供充足上下文
- 包含必要的背景信息
- 说明任务的约束条件
示例
你是一家上市公司的财务分析师,需要分析Q3财报数据。
请从以下角度进行分析:收入增长、利润率变化、现金流状况。
3. 结构化表达
- 使用标题、列表、分段等结构
- 用XML标签标注不同部分
示例
<task>
请撰写一份产品介绍文案
</task>
<product>
产品名称:智能手表X
核心功能:心率监测、GPS定位、防水
目标用户:运动爱好者、上班族
</product>
<output_format>
标题 + 3个段落 + 使用场景列表
</output_format>
4. 引导思维链(CoT)
- 让模型展示推理过程
- 逐步分解复杂问题
示例
请逐步分析这个问题:
1. 问题的核心是什么?
2. 需要考虑哪些因素?
3. 可能的解决方案有哪些?
4. 最优方案是什么?为什么?
最终结论:
6.4 高级技巧
1. 少样本提示(Few-Shot Prompting)
通过示例引导模型理解期望输出:
示例1:
输入:今天天气很好
输出:情感:积极
示例2:
输入:我很难过
输出:情感:消极
输入:这部电影太精彩了
输出:
2. 角色设定(Persona Prompting)
明确模型的角色身份和专业知识:
你是一位有10年经验的Python后端工程师,精通Django框架和微服务架构。
请基于以下需求设计技术方案...
3. 格式约束
强制指定输出格式:
请以JSON格式输出:
{
"title": "...",
"summary": "...",
"key_points": ["...", "..."]
}
4. 动态路由(Prompt Routing)
根据任务类型选择合适的Prompt模板:
def route_prompt(task):
if task['type'] == 'code_generation':
return CODE_GEN_TEMPLATE
elif task['type'] == 'data_analysis':
return DATA_ANALYSIS_TEMPLATE
else:
return GENERAL_TEMPLATE
5. Prompt Caching
缓存重复的System Prompt和上下文:
场景:批量处理同一份文档的不同问题
缓存:文档内容 + System Prompt(可重用)
每次请求:仅传输新问题(节省90% Token)
6.5 System Prompt vs User Prompt
| 维度 | System Prompt | User Prompt |
|---|---|---|
| 作用 | 定义模型的角色、行为规范 | 用户的实际任务或问题 |
| 稳定性 | 通常是固定的 | 每次请求都不同 |
| 优先级 | 更高 | 较低 |
| 示例 | “你是一位专业的翻译,风格正式” | “请翻译这段话…” |
6.6 常见问题与解决
问题1:输出格式不符合预期
原因:Prompt对格式要求不够明确
解决:
- 使用明确的格式说明
- 提供示例
- 使用XML标签标注各部分
问题2:回答偏离主题
原因:上下文不足或约束不明确
解决:
- 增加背景信息
- 明确任务边界
- 使用负向约束(“不要做…”)
问题3:幻觉问题严重
原因:模型产生虚构信息
解决:
- 明确告知"不知道就说不知道"
- 要求提供信息来源
- 使用RAG检索真实信息
6.7 最佳实践
1. 迭代优化
初版Prompt → 测试效果 → 发现问题 → 优化Prompt → 再次测试 → 最终版本
2. A/B测试
对比不同Prompt版本的效果:
Prompt A → 结果A
Prompt B → 结果B
对比质量、速度、成本 → 选择最优
3. 版本管理
为Prompt建立版本控制,记录变更历史:
v1.0: 基础版本
v1.1: 增加示例
v1.2: 优化结构
v2.0: 重构,加入CoT
4. 模板化
将常用Prompt抽象为模板,提高复用性:
ANALYSIS_TEMPLATE = """
请分析以下{content_type}:
内容:{content}
分析角度:{aspects}
输出格式:{output_format}
"""
6.8 在系统中的作用
Prompt是人机交互的核心桥梁:
- 意图传递:将人类意图转化为AI能理解的指令
- 行为引导:控制模型的输出风格、格式和内容
- 能力激活:引导模型使用相关知识和技能
- 质量杠杆:小投入撬动大提升
7. 扩展核心概念
7.1 RAG(检索增强生成)
定义
RAG(Retrieval-Augmented Generation)是结合外部知识库检索与LLM生成的技术,用于解决模型知识截止和幻觉问题。
工作流程
1. 用户提问
↓
2. 向量化(Embedding)
↓
3. 向量检索(从知识库中检索相关文档)
↓
4. 构建Prompt(问题 + 检索到的上下文)
↓
5. LLM生成回答
↓
6. 返回结果(回答 + 引用来源)
核心优势
- 实时信息:可访问最新的外部知识
- 可追溯:回答包含信息来源
- 减少幻觉:基于真实信息生成
- 领域适配:轻松接入企业私有知识
应用场景
- 企业知识库问答
- 文档智能分析
- 法律法规咨询
- 医疗健康问答
优化技巧
- 分块策略:合理的文档分块提升检索质量
- 混合检索:向量检索 + 关键词检索
- 重排序(Rerank):对检索结果重新排序
- 元数据过滤:根据时间、作者等元数据筛选
7.2 Fine-tuning(模型微调)
定义
Fine-tuning在预训练模型的基础上,使用特定领域数据进一步训练,调整模型参数。
与提示工程的对比
| 维度 | 提示工程 | 微调 |
|---|---|---|
| 成本 | 低 | 高(需算力+数据) |
| 灵活性 | 高,快速调整 | 低,需重新训练 |
| 效果 | 一般 | 优秀(在特定任务) |
| 适用场景 | 通用任务 | 专门领域任务 |
适用场景
- 企业风格适配:训练模型适应企业的文档风格和术语
- 领域知识深化:学习特定领域的专业知识
- 输出格式固定:训练模型输出特定格式
- 隐私保护:数据不出企业内网
技术方法
- 全量微调:更新所有参数,效果好但成本高
- LoRA(低秩适应):只更新少量参数,成本低
- QLoRA(量化LoRA):结合量化进一步降低成本
7.3 Function Calling(函数调用)
定义
Function Calling是LLM生成结构化函数调用请求的技术,使模型能够调用外部API或函数。
工作原理
1. 用户提问
↓
2. LLM分析是否需要调用工具
↓
3. LLM生成函数调用请求(JSON格式)
↓
4. 系统执行函数
↓
5. 函数结果返回给LLM
↓
6. LLM基于结果生成最终回答
示例
用户:今天北京天气怎么样?
LLM判断:需要调用天气API
LLM生成:
{
"function_name": "get_weather",
"parameters": {
"city": "北京",
"date": "2026-03-17"
}
}
系统执行函数 → 返回:晴天,15°C
LLM最终回答:今天北京是晴天,气温15°C。
在Agent中的作用
Function Calling是Agent工具调用的技术基础,使Agent能够:
- 调用外部API(如天气、地图、数据库)
- 执行系统操作(如文件读写、网络请求)
- 与物理设备交互(如控制智能家居)
7.4 Embedding(嵌入向量)
定义
Embedding是将文本、图像等非结构化数据转换为高维向量的技术,使语义相似的内容在向量空间中距离更近。
工作原理
文本:"苹果" → Embedding模型 → 向量[0.2, -0.5, 0.8, ...]
文本:"香蕉" → Embedding模型 → 向量[0.3, -0.4, 0.7, ...]
文本:"汽车" → Embedding模型 → 向量[0.9, 0.1, -0.2, ...]
计算距离:
"苹果"和"香蕉"的距离 = 0.1(近,语义相似)
"苹果"和"汽车"的距离 = 0.8(远,语义不相似)
应用场景
- 语义搜索:搜索语义相关而非关键词匹配的内容
- 推荐系统:根据用户兴趣向量推荐相似内容
- 文档聚类:将相似文档自动分组
- RAG检索:向量检索是RAG的核心
主流模型
- OpenAI text-embedding-3:多尺寸版本,性价比高
- Cohere embed:多语言支持
- BGE(智谱):开源,中文优化
- M3E:开源,中英双语
7.5 Chain of Thought(思维链)
定义
Chain of Thought(CoT)是让模型展示推理过程,逐步分解问题再得出结论的技术。
示例
问题:一个篮子里有5个苹果,小明拿走2个,小红又放回3个,现在有几个苹果?
普通回答:现在有6个苹果。
CoT回答:
1. 最初篮子里有5个苹果
2. 小明拿走2个:5 - 2 = 3
3. 小红放回3个:3 + 3 = 6
4. 最终:篮子里有6个苹果
结论:现在有6个苹果。
核心优势
- 提升准确性:避免跳跃性错误
- 可解释性:用户可以理解推理过程
- 调试友好:容易发现错误环节
应用场景
- 数学推理:逐步计算
- 逻辑推理:分析因果关系
- 任务分解:复杂任务分步执行
- 代码生成:先写思路再写代码
7.6 System Prompt(系统提示词)
定义
System Prompt是在每次对话开始前发送给模型的固定指令,用于定义模型的角色、行为规范和输出风格。
典型内容
- 角色定义:你是一位专业的翻译
- 行为规范:回答要客观、准确、简洁
- 约束条件:不要捏造信息,不知道就说不知道
- 输出格式:统一使用Markdown格式
优势
- 统一性:所有交互都遵循统一标准
- 优先级高:User Prompt很难覆盖System Prompt的设定
- 降低成本:System Prompt可以缓存复用
示例
你是一位专业的Python后端开发工程师,具备以下特点:
1. 技术栈:精通Django、FastAPI、PostgreSQL、Redis
2. 代码风格:遵循PEP 8规范,注重可读性和可维护性
3. 回答方式:
- 优先提供最佳实践
- 代码附详细注释
- 说明权衡和注意事项
4. 约束:
- 不要提供不安全的代码
- 如需配置,提供完整示例
- 遇到不确定的问题,明确说明
8. 概念间内在联系
8.1 技术栈分层架构
现代AI系统呈现清晰的分层架构:
┌─────────────────────────────────────┐
│ 应用层 (Applications) │
│ 智能客服、代码助手、数据分析工具 │
└─────────────────────────────────────┘
↑
┌─────────────────────────────────────┐
│ 智能体层 (Agents) │
│ 规划、决策、工具使用、任务执行 │
└─────────────────────────────────────┘
↑
┌─────────────────────────────────────┐
│ 接口层 (Interface) │
│ Prompt、Function Calling │
└─────────────────────────────────────┘
↑
┌─────────────────────────────────────┐
│ 能力层 (Capabilities) │
│ Skill、RAG、Fine-tuning │
└─────────────────────────────────────┘
↑
┌─────────────────────────────────────┐
│ 核心层 (Core LLM) │
│ 语言理解、生成、推理 │
└─────────────────────────────────────┘
↑
┌─────────────────────────────────────┐
│ 基础层 (Foundations) │
│ Token、Context、Embedding │
└─────────────────────────────────────┘
8.2 概念间的依赖关系
核心依赖链
Token(计算单位)
→ Embedding(向量化)
→ Context(工作记忆)
→ Prompt(交互接口)
→ Agent(执行实体)
→ Skill(能力组件)
详细依赖说明
-
Token是计算的基础
- 所有文本处理都先转换为Token
- Embedding、Context、Prompt都基于Token
-
Embedding提供语义表示
- RAG检索依赖Embedding
- 语义搜索基于Embedding
-
Context是记忆的框架
- Agent的短期记忆就是Context
- Prompt构建在Context之上
-
Prompt引导LLM行为
- Agent通过Prompt调用LLM
- Function Calling通过Prompt触发
-
Agent整合所有能力
- Agent = LLM + Prompt + Tool + Memory
- Skill是Agent的能力模块
8.3 数据流向与处理链路
完整的处理流程
用户输入
↓
[Tokenization] 分词为Token序列
↓
[Embedding] 转换为向量表示
↓
[Context] 构建上下文(System Prompt + 对话历史 + 输入)
↓
[LLM] 模型推理
↓
[决策] 判断是否需要调用外部系统
↓
├─→ [否] 直接生成响应 → [Detokenization] → 输出
│
└─→ [是] [Function Calling] 生成函数调用
↓
执行外部操作(API调用、数据库查询等)
↓
结果返回Context
↓
[LLM] 基于结果生成最终响应
↓
[Detokenization] → 输出
8.4 核心洞察
1. Token是货币
- 一切计算和计费的基础单位
- 决定了系统的成本和效率
- 优化Token = 优化成本
2. Context是瓶颈
- 既是能力的边界,也是优化的关键战场
- 长上下文是持续优化的方向
- 管理好Context是高级技能
3. LLM是大脑
- 提供通用的语言理解和推理能力
- 是所有上层应用的认知核心
- LLM的能力上限决定了整个系统的上限
4. Agent是躯体
- 赋予大脑感知和行动的能力
- 实现从"思考"到"实践"的跨越
- Agent是AI真正产生价值的关键
5. Prompt是语言
- 人与AI沟通的桥梁
- 提示工程是驾驭AI的核心技能
- 优质Prompt可以显著提升效果
6. Skill是工具集
- 专业化能力的封装
- 通过组合实现复杂任务
- Skill越多,系统越强大
9. 实际应用指南
9.1 选择合适的架构
场景1:简单问答
- 需求:回答明确的、基于事实的问题
- 架构:LLM + RAG(如果需要实时信息)
- 优势:成本低、开发快
场景2:代码开发
- 需求:代码生成、调试、重构
- 架构:LLM(选择代码能力强的模型)+ Code Interpreter Skill
- 优化:使用Function Calling执行代码
场景3:数据分析
- 需求:数据清洗、分析、可视化
- 架构:LLM + Data Analysis Skill + Visualization Skill
- 流程:用户提问 → LLM理解 → Skill执行 → 结果展示
场景4:企业知识库
- 需求:基于企业文档的问答
- 架构:RAG(核心)+ 微调(可选,适配企业风格)
- 关键:文档分块、检索优化、引用来源
场景5:复杂任务自动化
- 需求:端到端完成复杂任务链
- 架构:Agent(完整架构)
- 核心组件:LLM + 记忆 + 规划 + 工具使用
9.2 成本优化策略
Token消耗优化
- 使用Prompt Caching:缓存System Prompt和固定上下文
- 压缩对话历史:总结早期对话,保留关键信息
- 使用RAG:只检索并传入最相关的文档片段
- 精简Prompt:去除冗余表述,使用简洁格式
模型选择优化
-
分层策略:
- 简单任务用基础模型
- 复杂任务用高级模型
- 通过动态路由选择合适模型
-
模型蒸馏:
- 用大模型生成训练数据
- 用小模型学习,降低推理成本
架构优化
- 提前终止:满足条件后提前结束生成
- 批处理:批量处理相似请求
- 异步处理:非实时任务异步执行,使用低成本模型
9.3 性能优化策略
响应速度优化
- 流式输出:边生成边返回,减少用户等待
- 预计算:预计算常见查询的答案
- 缓存:缓存重复请求的结果
质量优化
- 优化Prompt:迭代优化Prompt设计
- 使用CoT:对于复杂任务使用思维链
- 验证机制:加入自我验证步骤
- 人工反馈:收集用户反馈持续优化
9.4 安全与合规
安全考虑
- 输入过滤:检测和拦截恶意输入
- 输出过滤:过滤敏感信息
- 权限控制:限制模型访问敏感系统
- 审计日志:记录所有交互
合规考虑
- 数据隐私:确保用户数据不被滥用
- 版权问题:使用合规的训练数据
- AI伦理:避免生成有害、歧视性内容
9.5 开发最佳实践
1. 分层开发
- 先验证LLM能力
- 再构建Prompt层
- 最后扩展为Agent
2. 迭代优化
- 从MVP开始,快速验证
- 基于反馈持续优化
- 逐步增加复杂度
3. 监控与可观测性
- 监控Token消耗、成本、性能
- 收集用户反馈和使用数据
- 建立报警机制
4. 版本管理
- 对Prompt、模型、架构都进行版本管理
- A/B测试不同版本
- 支持回滚
总结
理解AI的核心概念及其内在联系,是构建高效、可靠AI应用的基础。
核心要点回顾
- Token是基础:一切计算和计费的基本单位
- Context是关键:理解并优化上下文管理
- LLM是核心:选择合适的模型,充分发挥其能力
- Agent是趋势:从单一模型到智能体的演进
- Prompt是杠杆:优质的Prompt可以事半功倍
- Skill是资产:积累和复用专业技能
未来趋势
- 更长的上下文:10M+ Token将成为标准
- 更强的Agent:更自主、更智能的任务执行
- 更低的成本:技术进步持续降低使用门槛
- 更好的可解释性:让AI的决策过程更透明
- 更强的多模态能力:文本、图像、音频、视频的深度融合
行动建议
- 从简单开始:先掌握LLM和Prompt,再扩展到Agent
- 重视基础:深入理解Token、Context等基础概念
- 实践出真知:动手构建项目,积累经验
- 保持学习:AI技术快速迭代,持续关注最新发展
- 安全第一:在追求效果的同时,重视安全和合规
文档版本:v1.0
最后更新:2026年3月
适用范围:AI应用开发、技术决策、学习研究
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)