【爆肝整理】AI大模型开发全栈指南，从LLM到Agent记忆系统，小白程序员也能秒变AI大神！9大核心领域硬核解析，建议收藏反复观看！
本文是一份面向AI工程师的系统化学习指南，详细介绍了AI大模型工程的9大核心领域：LLM大模型、RAG检索增强、Agent智能体、Prompt/Context工程、数据处理、记忆系统、评测系统、模型微调与部署以及安全与合规。文章提供了技术栈对比、最佳实践和代码示例，帮助读者建立完整的知识框架，适合初学者和进阶开发者学习AI大模型应用开发。
·
写在前面
如果你刚刚踏入 AI 工程领域，面对 LangChain、RAG、向量数据库、Agent 这些名词感到困惑，那么这篇文章就是为你准备的。
我会用最直白的方式，帮你建立起 AI 大模型工程的完整知识框架。有了这个框架，你再去学习任何细分技术，都不会迷失方向。
本文涵盖的 9 大核心领域：
| 序号 | 领域 | 核心内容 |
|---|---|---|
| 1 | LLM 大模型 | GPT-4o、Claude、o1/o3 推理模型、智能路由 |
| 2 | RAG 检索增强 | 混合检索、重排序、Agentic RAG、Graph RAG |
| 3 | Agent 智能体 | ReAct、Plan-Execute、MCP、Function Calling |
| 4 | Prompt/Context 工程 | 提示词设计、上下文工程、结构化输出 |
| 5 | 数据处理 | 文档解析、分块策略、多模态处理、向量化 |
| 6 | 记忆系统 | 工作记忆、长期记忆、Mem0、分层架构 |
| 7 | 评测系统 | RAGAS、LLM 基准测试、自动化评测 |
| 8 | 模型微调与部署 | LoRA、vLLM、量化、推理优化 |
| 9 | 安全与合规 | 提示注入防护、GDPR、AI 法案 |
建议收藏，反复阅读。
01 AI 大模型工程的知识地图
让我们先看清楚 AI 工程的全貌：
【AI 大模型工程知识全景图】
第一层：核心能力层
•LLM 大模型：GPT-4o、Claude、o1/o3•RAG 技术：混合检索、重排序、Graph RAG•Agent 智能体：ReAct、MCP、工具调用
第二层：连接层
•Prompt/Context 工程：提示词设计、上下文工程、结构化输出
第三层：支撑层
•数据处理：文档解析、多模态、向量化•记忆系统：工作记忆、长期记忆、Mem0•评测系统：RAGAS、基准测试、自动评测
第四层：基础层
•模型微调：LoRA、vLLM、量化•安全合规：提示注入、GDPR、AI 法案•基础设施：向量数据库、Redis、K8s
这就是 AI 工程的 9 大核心领域，接下来我会逐一讲解。
02 核心领域一：LLM 大语言模型
什么是 LLM？
LLM（Large Language Model）就是我们常说的"AI 大模型"，比如 ChatGPT、Claude、通义千问。
它们是整个 AI 应用的"大脑"，负责理解用户输入、生成回复。
模型能力分类
在选择模型之前，需要理解当前 LLM 的两大能力分支：
| 能力类型 | 代表模型 | 核心特点 | 适用场景 |
|---|---|---|---|
| 通用对话 | GPT-4o, Claude Sonnet | 响应快、多模态、成本适中 | 日常对话、内容生成、代码辅助 |
| 深度推理 | o1, o3, Claude Opus | 扩展思考、复杂推理、高准确率 | 数学证明、科学研究、复杂编程 |
关键洞察：2024-2025 年，业界出现了"推理模型"（Reasoning Model）这一新范式。这类模型通过"思考时间换准确率"的方式，在复杂任务上显著超越传统模型。 — 参考：OpenAI o1 System Card[1]
主流 LLM 提供商
| 提供商 | 代表模型 | 特点 | 适用场景 |
|---|---|---|---|
| OpenAI | GPT-4o, GPT-4o-mini, o1, o3 | 生态成熟，推理模型领先 | 通用对话、复杂推理 |
| Anthropic | Claude Opus 4, Claude Sonnet 4, Claude 3.5 Sonnet | 200K 上下文，代码能力强，Agent 首选 | 长文本、代码生成、自主 Agent |
| Gemini 2.0, Gemini 1.5 Pro | 多模态原生，100万 token 上下文 | 多模态任务、超长文档 | |
| 阿里云 | 通义千问 Qwen 2.5 | 开源生态，中文优化 | 中文场景、私有化部署 |
| DeepSeek | DeepSeek-V3, DeepSeek-R1 | 开源推理模型，性价比高 | 推理任务、成本敏感场景 |
| Meta | Llama 3.3, Llama 4 | 完全开源，可商用 | 私有化部署、定制微调 |
智能路由的思想
真实的生产系统不会只用一个模型。
根据不同场景，智能选择最合适的模型，这就是智能路由：
class LLMRouter:
"""
智能 LLM 路由器（设计示例）
核心思想：根据任务类型、复杂度、成本预算选择最合适的模型
"""
def route(self, task_type: str, complexity: str = "normal") -> str:
"""
根据任务类型和复杂度路由到合适的模型
这是一个简化的示例，实际生产中需要根据业务需求定制
"""
# 复杂推理任务使用推理模型
if complexity == "high" and task_type in ["math", "coding", "reasoning"]:
return "o1" # 或 "claude-opus-4" / "deepseek-r1"
routing_rules = {
"emotional": "claude-sonnet-4", # 情感对话
"creative": "gpt-4o", # 创意生成
"coding": "claude-sonnet-4", # 代码生成（Claude 代码能力领先）
"long_context": "gemini-1.5-pro", # 超长文档（100万 token）
"high_volume": "gpt-4o-mini", # 高并发/低成本
"chinese": "qwen-2.5-72b", # 中文场景
}
return routing_rules.get(task_type, "gpt-4o-mini")
模型选型参考（官方数据）
以下是选型时可参考的官方公开数据：
基准测试得分（官方发布）
| 模型 | MMLU | GPQA Diamond | SWE-bench Verified | 官方来源 |
|---|---|---|---|---|
| GPT-4o | 88.7% | 53.6% | 33.2% | OpenAI GPT-4o[2] |
| o1 | 92.3% | 78.0% | 48.9% | OpenAI o1[3] |
| Claude 3.5 Sonnet | 88.7% | 65.0% | 49.0% | Anthropic Claude 3.5[4] |
| Claude Sonnet 4 | 待更新 | 待更新 | 72.7% | Anthropic Claude 4[5] |
| Gemini 1.5 Pro | 85.9% | - | - | Google Gemini[6] |
注意：基准测试分数仅供参考，实际效果需要在具体业务场景中验证。SWE-bench 是衡量代码能力的重要指标。
API 定价参考（2025年1月）
| 模型 | 输入价格 | 输出价格 | 上下文窗口 | 官方来源 |
|---|---|---|---|---|
| GPT-4o | $2.50/1M | $10.00/1M | 128K | OpenAI Pricing[7] |
| GPT-4o-mini | $0.15/1M | $0.60/1M | 128K | OpenAI Pricing[8] |
| o1 | $15.00/1M | $60.00/1M | 200K | OpenAI Pricing[9] |
| Claude 3.5 Sonnet | $3.00/1M | $15.00/1M | 200K | Anthropic Pricing[10] |
| Claude Sonnet 4 | $3.00/1M | $15.00/1M | 200K | Anthropic Pricing[11] |
| Claude Opus 4 | $15.00/1M | $75.00/1M | 200K | Anthropic Pricing[12] |
定价说明：价格可能随时调整，请以官方最新公告为准。推理模型（o1、Opus）价格较高但在复杂任务上性价比更优。
模型选型决策树
任务来了，如何选择模型？
1.需要复杂推理（数学证明、科学研究）？→ o1 / Claude Opus 4 / DeepSeek-R12.需要处理超长文档（>100K tokens）？→ Gemini 1.5 Pro（100万上下文）/ Claude（200K）3.代码生成/Agent 任务？→ Claude Sonnet 4（SWE-bench 领先）4.中文场景？→ Qwen 2.5 / DeepSeek-V35.高并发/成本敏感？→ GPT-4o-mini / Qwen-turbo6.通用场景？→ GPT-4o / Claude 3.5 Sonnet
一句话总结：不同场景用不同模型，既省钱又提效。推理模型适合复杂任务，通用模型适合日常场景。
延伸阅读
•RouteLLM[13] - LMSYS 开源的 LLM 路由框架•RouteLLM 博客[14] - 智能路由原理详解
03 核心领域二：RAG 检索增强生成
RAG 是什么？
RAG = Retrieval-Augmented Generation = 检索增强生成
用大白话说：让 AI 在回答问题之前，先去知识库"查资料"。
为什么需要 RAG？
LLM 有两个天然缺陷：
1.知识截止：训练数据有截止日期2.私有知识盲区：不知道你公司的内部文档
RAG 就是为了解决这两个问题。
权威定义：RAG 最早由 Meta AI 在 2020 年提出，论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks[15] 奠定了理论基础。
RAG 技术演进
RAG 技术经历了三代演进：
| 代际 | 名称 | 核心特点 | 代表技术 |
|---|---|---|---|
| 第一代 | Naive RAG | 简单检索+生成 | 向量检索 → LLM |
| 第二代 | Advanced RAG | 优化检索质量 | 混合检索、重排序、Query 改写 |
| 第三代 | Agentic RAG | 自主决策检索 | Agent 驱动、多轮检索、自我纠错 |
行业趋势：2024-2025 年，Agentic RAG 成为主流方向。它让 AI 自主决定"何时检索、检索什么、如何验证"，而非被动执行固定流程。 — 参考：LangChain Agentic RAG[16]
RAG 的核心技术栈
RAG 处理流程：
用户提问 → Query 预处理（意图识别、Query 扩写/重写）→ 混合检索（向量检索 + BM25 关键词检索）→ 重排序（Cohere/Jina Reranker 精排）→ LLM 生成（基于检索结果生成回答）→ 最终回答
关键技术点
1. 混合检索（Hybrid Search）
向量搜索理解"意思"，BM25 匹配"关键词"，两者结合效果最好。
| 检索方式 | 原理 | 优势 | 劣势 |
|---|---|---|---|
| 向量检索 | 语义相似度 | 理解同义词、语义 | 对专有名词不敏感 |
| BM25 | 关键词匹配 | 精确匹配、速度快 | 无法理解语义 |
| 混合检索 | 两者融合 | 兼顾语义和精确 | 需要调参 |
实践数据：混合检索相比纯向量检索，召回率通常可提升 10-15%。 — 参考：Qdrant Hybrid Search[17]
2. 重排序（Reranker）
从粗排结果中精选最相关的 Top K。
| Reranker | 特点 | 官方链接 |
|---|---|---|
| Cohere Rerank | 多语言支持，效果稳定 | Cohere Rerank[18] |
| Jina Reranker | 开源可用，支持私有化 | Jina Reranker[19] |
| BGE Reranker | 中文优化，开源免费 | BGE Reranker[20] |
3. Query 改写（Query Rewriting）
用户的原始问题往往不够精确，需要改写优化：
| 技术 | 说明 | 示例 |
|---|---|---|
| Query 扩展 | 添加同义词/相关词 | “Python 教程” → “Python 教程 入门 学习” |
| HyDE | 先生成假设答案，再检索 | 问题 → 假设答案 → 用答案检索 |
| Multi-Query | 生成多个变体问题 | 一个问题 → 3-5 个变体 → 合并结果 |
HyDE 论文：Precise Zero-Shot Dense Retrieval without Relevance Labels[21]
class EnhancedHybridRetriever:
"""
增强版混合检索器
特性:
1. 多种融合算法 (RRF, 线性, 凸组合)
2. 多种归一化方法 (Min-Max, Z-Score, Sigmoid)
3. 集成重排序 (Cohere, Jina)
"""
async def search(self, query, query_embedding, top_k=10):
# 1. 向量检索 (语义相似度)
vector_results = await self.vector_store.search(query_embedding, top_k * 2)
# 2. BM25检索 (关键词匹配)
bm25_results = self.bm25_retriever.search(query, top_k * 2)
# 3. 分数归一化
vector_scores = ScoreNormalizer.normalize(scores, NormalizationMethod.MIN_MAX)
# 4. RRF 融合 (Reciprocal Rank Fusion)
fused_scores = FusionEngine.fuse(
vector_scores, bm25_scores,
method=FusionMethod.RRF,
rrf_k=60 # RRF 常数，通常取 60
)
# 5. 重排序 (可选，但强烈推荐)
if self.reranker:
return await self._rerank(query, scored_chunks, top_k)
高级 RAG 技术
Agentic RAG
Agentic RAG 是 2024-2025 年的主流方向，核心思想是让 Agent 自主决策检索策略：
【Agentic RAG 架构】
流程说明：
1.用户问题 → Agent 分析 → 决策：需要检索吗？2.不需要检索 → 直接回答3.需要检索 → 选择检索策略（向量检索 / 关键词检索 / 知识图谱查询 / Web 搜索）4.检索结果评估：
•结果足够 → 生成回答•结果不足 → 继续检索•结果错误 → 重新检索
官方教程：LangGraph Agentic RAG Tutorial[22]
Graph RAG
Graph RAG 结合知识图谱，适合需要多跳推理的场景：
| 特性 | 传统 RAG | Graph RAG |
|---|---|---|
| 数据结构 | 文档块 | 实体+关系图 |
| 检索方式 | 相似度匹配 | 图遍历+相似度 |
| 适用场景 | 单跳问答 | 多跳推理、关系查询 |
| 复杂度 | 低 | 高 |
微软 Graph RAG：GraphRAG: Unlocking LLM discovery on narrative private data[23]
RAG 优化检查清单
| 优化点 | 检查项 | 预期提升 |
|---|---|---|
| 分块策略 | 块大小是否合适？有无重叠？ | 召回率 +5-10% |
| 混合检索 | 是否同时使用向量+BM25？ | 召回率 +10-15% |
| 重排序 | 是否使用 Reranker？ | 准确率 +10-20% |
| Query 改写 | 是否优化用户问题？ | 召回率 +5-10% |
| 元数据过滤 | 是否利用文档元数据？ | 精确度 +10% |
04 核心领域三：Agent 智能体
Agent 是什么？
Agent 是能够自主决策、使用工具的 AI 系统。
普通的 ChatGPT 只能聊天，而 Agent 可以：
•搜索网络•查询数据库•执行代码•调用 API
主流 Agent 架构
| 架构 | 核心思想 | 适用场景 |
|---|---|---|
| ReAct | 思考 → 行动 → 观察 → 思考… | 探索性任务 |
| Plan-Execute | 先规划，后执行 | 结构化任务 |
注意：Agent 架构内部可以使用下面的「推理增强技术」来提升思考能力。
推理增强技术（Prompt 方法论）
这些技术本质上是指导开发者如何编写提示词的方法论，通过特定的 Prompt 设计来激发 LLM 的推理能力。
业界主流 Prompt 方法论
| 方法 | 核心思想 | 示例 |
|---|---|---|
| Zero-shot | 直接提问，不给示例 | “翻译成英文：你好” |
| Few-shot | 给几个示例，让模型学习模式 | “猫→cat，狗→dog，鸟→?” |
| Chain of Thought (CoT) | 展示推理过程 | “请一步一步思考” |
| Zero-shot CoT | 不给示例，只加魔法咒语 | 问题 + “Let’s think step by step” |
| Self-Consistency | 多次推理，取多数一致的答案 | 生成5个答案，投票选最多的 |
| Tree of Thoughts (ToT) | 探索多条推理路径，选最优 | 像下棋一样探索多个分支 |
| Reflexion | 让模型检查并修正自己的答案 | “请检查上面的答案是否正确” |
| Generated Knowledge | 先让模型生成相关知识，再回答 | “先列出相关知识点，然后回答” |
| Prompt Chaining | 将复杂任务分解为多个 prompt 链式执行 | 先提取关键词→再搜索→再总结 |
方法论可以混合使用
| 组合方式 | 说明 | 效果 |
|---|---|---|
| Few-shot + CoT | 给出带推理过程的示例 | 比单独用CoT更稳定 |
| CoT + Self-Consistency | 用CoT格式多次推理，然后投票 | 准确率更高，但成本高 |
| CoT + Reflexion | 先推理，再让模型检查自己的答案 | 减少错误 |
选型指南
任务来了，如何选择 Prompt 方法？
1.简单问答/翻译/摘要？→ Zero-shot 就够了2.需要特定格式输出？→ Few-shot（给示例）3.涉及推理（数学、逻辑）？
•对延迟敏感？→ Zero-shot CoT（加"请一步一步思考"）•对准确率要求高？→ CoT + Self-Consistency（多次推理投票）
4.需要自我纠错？→ Reflexion
选型对照表
| 场景 | 推荐方法 | 理由 |
|---|---|---|
| 简单问答 | Zero-shot | 成本低、速度快 |
| 格式化输出 （JSON、表格） | Few-shot | 示例能明确格式要求 |
| 数学计算 | Zero-shot CoT | 一句"请一步一步思考"就能大幅提升 |
| 复杂推理 + 高可靠 | CoT + Self-Consistency | 多次推理取共识 |
| 创意写作 | Few-shot | 示例定义风格 |
| 代码生成 | Few-shot + CoT | 示例 + 分步思考 |
| 多步决策 | Tree of Thoughts | 探索多条路径 |
| 需要验证答案 | Reflexion | 自我检查 |
成本 vs 效果权衡
从低成本到高效果排序：
| 方法 | 成本/延迟 | 效果 |
|---|---|---|
| Zero-shot | 最低 | 基础 |
| Few-shot | 低 | 较好 |
| CoT | 中 | 好 |
| Tree of Thoughts | 较高 | 很好 |
| CoT + Self-Consistency | 最高 | 最好 |
实际工程建议
| 阶段 | 策略 |
|---|---|
| 开发初期 | 先用 Zero-shot CoT，快速验证效果 |
| 效果不够 | 加 Few-shot 示例 |
| 生产环境 | 根据准确率要求决定是否用 Self-Consistency |
| 关键场景 | 考虑 Reflexion 自动检查 |
技术分类澄清
┌─────────────────────────────────────────────────────────────┐
│ Prompt 方法论 │
│ (指导如何写提示词) │
│ │
│ ┌──────────┐ ┌─────────┐ ┌─────┐ ┌─────────┐ ┌──────────┐ │
│ │ Few-shot │ │ CoT │ │ ToT │ │Reflexion│ │ 更多... │ │
│ └──────────┘ └─────────┘ └─────┘ └─────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Agent 架构 │
│ (决定AI如何协调思考和行动) │
│ │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ ReAct │ │ Plan-Execute │ │
│ └──────┬──────┘ └────────┬────────┘ │
│ │ │ │
│ └──────────┬───────────────────┘ │
│ ▼ │
│ 内部可以使用 CoT 等方法论增强推理 │
└─────────────────────────────────────────────────────────────┘
为什么 ReAct 容易混淆？
ReAct 比较特殊，它既是一种 Prompt 格式，也是一种 Agent 架构：
# ReAct 的 Prompt 格式
Thought: 我需要查询...
Action: search("...")
Observation: 结果是...
Thought: 现在我知道了...
Final Answer: ...
•作为 Prompt 格式：定义了 Thought/Action/Observation 的输出结构•作为 Agent 架构：定义了思考→行动→观察的循环流程
而 CoT 只是 Prompt 方法论，没有"行动"的部分，所以不是 Agent 架构。
ReAct 架构示例
class ReActAgent:
"""
ReAct = Reasoning + Acting
工作流程:
Think → Act → Observe → Think → ...
特点:
- 显式的推理链 (Chain of Thought)
- 工具调用与推理的紧密结合
- 自我反思和纠错能力
"""
SYSTEM_PROMPT = """对于每个问题，你需要交替进行"思考"和"行动":
## 思考 (Thought)
- 分析当前情况和已有信息
- 明确下一步需要做什么
## 行动 (Action)
- 使用工具获取信息
- 或者直接回答问题
## 观察 (Observation)
- 分析行动的结果
- 决定是否需要更多信息
"""
def _build_graph(self):
"""构建 LangGraph 工作流"""
workflow = StateGraph(ReActState)
# 添加节点
workflow.add_node("think", self._think)
workflow.add_node("act", self._act)
workflow.add_node("tools", ToolNode(self.tools))
# 设置入口和边
workflow.set_entry_point("think")
workflow.add_conditional_edges("think", self._after_think)
workflow.add_edge("tools", "think")
return workflow.compile()
Plan-Execute 架构
对于结构化任务，先规划再执行效果更好：
"""
Plan-Execute 工作流:
1. Planner: 分析任务，生成执行计划
2. Executor: 按计划逐步执行
3. Replan: 根据执行结果调整计划
"""
class PlanExecuteAgent:
def plan(self, task):
"""生成执行计划"""
return self.planner.generate_plan(task)
def execute(self, plan):
"""按计划执行"""
for step in plan.steps:
result = self.executor.run(step)
if result.needs_replan:
plan = self.replan(plan, result)
return plan.final_result
工具调用（Function Calling / Tool Use）
工具调用是 Agent 的核心能力，让 LLM 能够与外部系统交互。
主流实现方式
| 方式 | 提供商 | 特点 | 官方文档 |
|---|---|---|---|
| Function Calling | OpenAI | 结构化 JSON 输出，原生支持 | OpenAI Function Calling[24] |
| Tool Use | Anthropic | 支持复杂工具链，Claude 原生 | Anthropic Tool Use[25] |
| Tools | Gemini 原生支持 | Gemini Function Calling[26] |
工具定义示例
# OpenAI Function Calling 格式
tools = [
{
"type": "function",
"function": {
"name": "search_knowledge_base",
"description": "搜索知识库获取相关信息",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "搜索查询"
},
"top_k": {
"type": "integer",
"description": "返回结果数量",
"default": 5
}
},
"required": ["query"]
}
}
}
]
# 调用示例
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "查找关于 RAG 的资料"}],
tools=tools,
tool_choice="auto" # 让模型自动决定是否调用工具
)
MCP（Model Context Protocol）
MCP 是 Anthropic 于 2024 年 11 月发布的开放协议，被称为"AI 的 USB-C"，旨在标准化 LLM 与外部工具/数据源的连接方式。
官方定义：MCP 是一个开放协议，标准化了应用程序如何向 LLM 提供上下文。 — Model Context Protocol[27]
MCP 核心概念
┌─────────────────────────────────────────────────────────────┐
│ MCP 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Host │ ←─────→ │ MCP Server │ │
│ │ (Claude等) │ 协议 │ (工具提供方) │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Host 功能: Server 功能: │
│ - 发起连接 - 暴露 Resources (数据) │
│ - 调用工具 - 暴露 Tools (功能) │
│ - 管理上下文 - 暴露 Prompts (模板) │
│ │
└─────────────────────────────────────────────────────────────┘
MCP vs 传统 Function Calling
| 维度 | Function Calling | MCP |
|---|---|---|
| 标准化 | 各厂商格式不同 | 统一开放协议 |
| 发现机制 | 需要预定义 | 动态发现可用工具 |
| 数据访问 | 仅工具调用 | Resources + Tools + Prompts |
| 生态系统 | 厂商锁定 | 跨平台互操作 |
MCP Server 示例
# MCP Server 定义示例（Python SDK）
from mcp.server import Server
from mcp.types import Tool, TextContent
server = Server("knowledge-base")
@server.tool()
async def search(query: str, top_k: int = 5) -> list[TextContent]:
"""搜索知识库"""
results = await knowledge_base.search(query, top_k)
return [TextContent(type="text", text=r.content) for r in results]
@server.resource("kb://documents/{doc_id}")
async def get_document(doc_id: str) -> TextContent:
"""获取指定文档"""
doc = await knowledge_base.get(doc_id)
return TextContent(type="text", text=doc.content)
官方资源：
•MCP 规范[28]•MCP Python SDK[29]•MCP TypeScript SDK[30]
Multi-Agent 系统
复杂任务往往需要多个 Agent 协作完成。
常见协作模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| Supervisor | 一个主 Agent 协调多个子 Agent | 任务分解、结果汇总 |
| Hierarchical | 多层级 Agent 树状结构 | 大型复杂系统 |
| Peer-to-Peer | Agent 之间平等协作 | 辩论、多视角分析 |
| Swarm | 大量简单 Agent 涌现智能 | 并行处理、探索任务 |
┌─────────────────────────────────────────────────────────────┐
│ Supervisor 模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Supervisor │ │
│ │ Agent │ │
│ └──────┬──────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Research │ │ Coding │ │ Review │ │
│ │ Agent │ │ Agent │ │ Agent │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
官方教程：LangGraph Multi-Agent[31]
Agent 开发框架对比
| 框架 | 特点 | 适用场景 | 官方链接 |
|---|---|---|---|
| LangGraph | 状态图、可控性强 | 生产级 Agent | LangGraph[32] |
| AutoGen | 多 Agent 对话 | 研究、原型 | AutoGen[33] |
| CrewAI | 角色扮演、简单易用 | 快速原型 | CrewAI[34] |
| OpenAI Assistants | 托管服务、开箱即用 | 快速上线 | Assistants API[35] |
| Claude Computer Use | 操作电脑界面 | 自动化任务 | Computer Use[36] |
05 核心领域四：Prompt/Context 工程
从 Prompt 工程到 Context 工程
2025 年，业界正从 Prompt Engineering 转向 Context Engineering。
| 维度 | Prompt 工程 | Context 工程 |
|---|---|---|
| 定义 | 编写单一、结构良好的输入 | 设计动态系统，提供正确的信息和工具 |
| 范围 | 静态字符串 | 整个信息环境 |
| 类比 | 创意写作 | 系统架构设计 |
“大多数 Agent 失败不再是模型失败，而是上下文失败。” — Anthropic Engineering[37]
Context Engineering 的核心组件
┌─────────────────────────────────────────────────────────────┐
│ Context Engineering │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ System │ │ User │ │ Retrieved │ │
│ │ Prompt │ │ Input │ │ Context │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Context Window │ │
│ │ │ │
│ │ • 角色设定 (Role) │ │
│ │ • 任务指令 (Instructions) │ │
│ │ • 示例 (Examples) │ │
│ │ • 检索内容 (Retrieved Documents) │ │
│ │ • 对话历史 (Conversation History) │ │
│ │ • 工具定义 (Tool Definitions) │ │
│ │ • 输出格式 (Output Format) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
System Prompt 设计原则
结构化模板
# 角色定义
你是一个专业的 [角色]，专注于 [领域]。
# 核心能力
- 能力 1
- 能力 2
- 能力 3
# 行为准则
1. 始终 [正向行为]
2. 避免 [负向行为]
3. 当遇到 [情况] 时，[处理方式]
# 输出格式
[明确的格式要求]
# 示例
[Few-shot 示例]
设计检查清单
| 检查项 | 说明 | 重要性 |
|---|---|---|
| 角色明确 | 清晰定义 AI 的身份和专业领域 | 高 |
| 边界清晰 | 明确什么能做、什么不能做 | 高 |
| 格式规范 | 指定输出格式（JSON、Markdown 等） | 中 |
| 示例充分 | 提供 2-3 个高质量示例 | 中 |
| 错误处理 | 定义异常情况的处理方式 | 中 |
上下文窗口管理
上下文窗口是有限资源，需要精心管理：
上下文优先级
高优先级（必须保留）:
├── System Prompt（角色定义、核心指令）
├── 当前用户输入
└── 最相关的检索结果
中优先级（尽量保留）:
├── 近期对话历史
├── 工具调用结果
└── Few-shot 示例
低优先级（可压缩/丢弃）:
├── 远期对话历史
├── 冗余的检索结果
└── 详细的中间推理过程
上下文压缩策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 摘要压缩 | 用 LLM 总结长文本 | 长对话历史 |
| 选择性保留 | 只保留关键信息 | 检索结果过多 |
| 滑动窗口 | 保留最近 N 轮对话 | 多轮对话 |
| 分层存储 | 重要信息存长期记忆 | 复杂 Agent |
核心提示词技术
1. 思维链（Chain of Thought）
让 AI 展示推理过程，显著提升复杂任务的准确率。
# Zero-shot CoT
prompt = """
问题：一个商店有 23 个苹果，卖掉了 17 个，又进货了 12 个，现在有多少个苹果？
请一步一步思考，然后给出答案。
"""
# Few-shot CoT
prompt = """
问题：小明有 5 个糖果，小红给了他 3 个，他现在有多少个？
思考：
1. 小明原来有 5 个糖果
2. 小红给了他 3 个
3. 5 + 3 = 8
答案：8 个
问题：一个商店有 23 个苹果，卖掉了 17 个，又进货了 12 个，现在有多少个苹果？
思考：
"""
原始论文：Chain-of-Thought Prompting Elicits Reasoning in Large Language Models[38]
2. 结构化输出
确保 LLM 输出符合预期格式：
# JSON 模式（OpenAI）
response = client.chat.completions.create(
model="gpt-4o",
response_format={"type": "json_object"},
messages=[
{"role": "system", "content": "你是一个 JSON 生成器，始终输出有效的 JSON。"},
{"role": "user", "content": "提取以下文本中的人名和地点：..."}
]
)
# Pydantic 结构化输出（推荐）
from pydantic import BaseModel
class ExtractedInfo(BaseModel):
names: list[str]
locations: list[str]
response = client.beta.chat.completions.parse(
model="gpt-4o",
messages=[...],
response_format=ExtractedInfo
)
官方文档：OpenAI Structured Outputs[39]
3. 角色扮演（Role Playing）
设定 AI 的人格和行为准则：
你是一位资深的 Python 开发工程师，拥有 10 年的后端开发经验。
你的特点：
- 代码风格简洁、符合 PEP 8 规范
- 注重代码的可读性和可维护性
- 善于使用设计模式解决问题
- 会主动考虑边界情况和错误处理
你的行为准则：
- 先理解需求，再动手写代码
- 给出代码时附带简要说明
- 如果需求不明确，先提问澄清
Prompt 优化工作流
┌─────────────────────────────────────────────────────────────┐
│ Prompt 优化循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 基线测试 │
│ └── 用简单 prompt 建立基线效果 │
│ │
│ 2. 错误分析 │
│ └── 收集失败案例，分析失败原因 │
│ │
│ 3. 针对性优化 │
│ ├── 添加示例（Few-shot） │
│ ├── 添加约束（边界条件） │
│ ├── 调整格式（结构化输出） │
│ └── 增加推理（CoT） │
│ │
│ 4. A/B 测试 │
│ └── 对比新旧 prompt 效果 │
│ │
│ 5. 迭代 │
│ └── 重复 2-4 直到满足要求 │
│ │
└─────────────────────────────────────────────────────────────┘
06 核心领域五：数据处理管道
数据处理的完整流程
┌─────────────────────────────────────────────────────────────┐
│ 数据处理管道 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 原始数据 │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 数据采集 │ ← 文档上传、网页爬取、API 导入 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 文档解析 │ ← PDF、Word、图片 OCR、音视频转写 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 数据清洗 │ ← 去重、格式化、质量过滤 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 文本分块 │ ← 固定/递归/语义分块 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 向量化 │ ← Embedding 模型 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ 索引存储 │ ← 向量数据库 + 元数据 │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
1. 文档解析
支持的文档格式
| 格式 | 解析工具 | 特点 |
|---|---|---|
| PyMuPDF, pdfplumber, Unstructured | 支持文本/扫描件 | |
| Word | python-docx, Unstructured | 保留格式结构 |
| Excel | openpyxl, pandas | 表格数据提取 |
| PPT | python-pptx | 幻灯片内容提取 |
| 图片 | Tesseract OCR, PaddleOCR | OCR 文字识别 |
| 音频 | Whisper, Azure Speech | 语音转文字 |
| 视频 | 提取音轨 + Whisper | 视频内容转写 |
| 网页 | BeautifulSoup, Playwright | 动态/静态页面 |
推荐解析工具
| 工具 | 特点 | 官方链接 |
|---|---|---|
| Unstructured | 统一接口，支持多格式 | Unstructured[40] |
| LlamaParse | LlamaIndex 官方，效果好 | LlamaParse[41] |
| Docling | IBM 开源，表格识别强 | Docling[42] |
2. 分块策略
分块是 RAG 效果的关键因素之一。
分块策略对比
| 策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 固定大小 | 按字符数切分 | 简单、可预测 | 可能切断语义 | 通用场景 |
| 递归分块 | 按段落/句子边界 | 保持语义完整 | 块大小不均 | 结构化文档 |
| 语义分块 | 按语义相似度 | 效果最好 | 计算量大 | 高质量要求 |
| 文档结构 | 按标题/章节 | 保持文档结构 | 依赖格式 | 技术文档 |
分块参数建议
| 参数 | 建议值 | 说明 |
|---|---|---|
| chunk_size | 512-1024 tokens | 太小丢失上下文，太大检索不精确 |
| chunk_overlap | 50-100 tokens | 保持块之间的连贯性 |
| 分隔符优先级 | \n\n > \n > . > 空格 | 递归分块的分隔符顺序 |
# 递归分块示例（LangChain）
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=100,
separators=["\n\n", "\n", "。", ".", " ", ""],
length_function=len,
)
chunks = splitter.split_text(document_text)
# 语义分块示例（基于 LangChain）
from langchain_experimental.text_splitter import SemanticChunker
class SemanticTextSplitter:
"""基于句子嵌入的语义分块策略"""
def __init__(self, embedding_function):
self.splitter = SemanticChunker(
embeddings=embedding_function,
breakpoint_threshold_type="percentile", # 按百分位切分
)
def split(self, text):
return self.splitter.split_text(text)
3. 向量化（Embedding）
把文字变成数字（向量），让计算机能够理解语义。
主流 Embedding 模型
| 模型 | 维度 | 特点 | 官方链接 |
|---|---|---|---|
| text-embedding-3-small | 1536 | OpenAI，性价比高 | OpenAI Embeddings[43] |
| text-embedding-3-large | 3072 | OpenAI，效果最好 | OpenAI Embeddings[44] |
| voyage-3 | 1024 | Voyage AI，检索优化 | Voyage AI[45] |
| BGE-M3 | 1024 | 开源，多语言 | BGE-M3[46] |
| jina-embeddings-v3 | 1024 | 开源，长文本支持 | Jina Embeddings[47] |
# Embedding 使用示例（OpenAI）
from openai import OpenAI
client = OpenAI()
response = client.embeddings.create(
model="text-embedding-3-small",
input="你好，世界"
)
embedding = response.data[0].embedding # 1536 维向量
4. 多模态数据处理
2024-2025 年，多模态 RAG 成为重要趋势。
多模态处理策略
| 模态 | 处理方式 | 工具/模型 |
|---|---|---|
| 图片 | 视觉 Embedding | CLIP, SigLIP |
| 图片 | 图片描述 → 文本 | GPT-4V, Claude Vision |
| 表格 | 结构化提取 | Docling, Unstructured |
| 图表 | 图表理解 | ChartQA, GPT-4V |
| 音频 | 语音转文字 | Whisper |
# 多模态 Embedding 示例（使用 CLIP）
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('clip-ViT-B-32')
# 文本和图片可以映射到同一向量空间
text_embedding = model.encode("一只可爱的猫")
image_embedding = model.encode(image) # PIL Image
# 可以进行跨模态检索
similarity = cosine_similarity(text_embedding, image_embedding)
5. 向量数据库
主流向量数据库对比
| 数据库 | 特点 | 适用场景 | 官方链接 |
|---|---|---|---|
| Qdrant | Rust 实现，性能高 | 追求性能 | Qdrant[48] |
| Weaviate | AI 原生，GraphQL | 语义搜索 | Weaviate[49] |
| Milvus | 十亿级向量 | 超大规模 | Milvus[50] |
| Pinecone | 全托管，开箱即用 | 快速上线 | Pinecone[51] |
| Chroma | 轻量级，易上手 | 开发测试 | Chroma[52] |
| pgvector | PostgreSQL 扩展 | 已有 PG 基础设施 | pgvector[53] |
07 核心领域六：记忆系统
AI 为什么需要记忆？
普通的 ChatGPT 每次对话都是"失忆"的，不知道你之前说过什么。
记忆系统让 AI 能够：
•记住当前对话的上下文•记住用户的偏好和历史•记住角色的设定和背景•在长期交互中持续学习和改进
记忆类型分类
┌─────────────────────────────────────────────────────────────┐
│ AI 记忆系统 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 短期记忆 (Working Memory) │ │
│ │ │ │
│ │ • 当前对话上下文 │ │
│ │ • 最近几轮对话历史 │ │
│ │ • 存储：上下文窗口 / Redis │ │
│ │ • 生命周期：会话级 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 长期记忆 (Long-term Memory) │ │
│ │ │ │
│ │ • 用户偏好和画像 │ │
│ │ • 历史交互摘要 │ │
│ │ • 学习到的知识 │ │
│ │ • 存储：向量数据库 / 专用记忆系统 │ │
│ │ • 生命周期：持久化 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 情景记忆 (Episodic Memory) │ │
│ │ │ │
│ │ • 具体事件和经历 │ │
│ │ • 时间序列信息 │ │
│ │ • 因果关系链 │ │
│ │ • 存储：知识图谱 / 时序数据库 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
三层记忆架构
| 层级 | 技术 | 延迟 | 用途 | 特点 |
|---|---|---|---|---|
| L1 工作记忆 | Redis | <10ms | 当前对话上下文 | 超低延迟，会话级 |
| L2 长期记忆 | Mem0 | ~100-500ms | 用户画像、偏好 | AI 驱动实体提取 |
| L3 知识记忆 | 向量数据库 | ~50-200ms | 领域知识 | 语义检索 |
主流记忆框架
| 框架 | 特点 | 适用场景 | 官方链接 |
|---|---|---|---|
| Mem0 | AI 驱动，自动提取实体和关系 | 个性化 Agent | Mem0[54] |
| Zep | 自托管，数据主权，时序推理 | 企业级应用 | Zep[55] |
| LangGraph Memory | 与 LangGraph 深度集成 | LangGraph Agent | LangGraph[56] |
| MemGPT/Letta | 虚拟上下文管理，无限记忆 | 研究/实验 | Letta[57] |
Mem0 使用示例
from mem0 import Memory
# 初始化记忆系统
memory = Memory()
# 添加记忆
memory.add(
"用户喜欢简洁的代码风格，偏好 Python",
user_id="user_123",
metadata={"category": "preference"}
)
# 搜索相关记忆
results = memory.search(
"用户的编程偏好是什么？",
user_id="user_123"
)
# 获取用户所有记忆
all_memories = memory.get_all(user_id="user_123")
官方文档：Mem0 Documentation[58]
记忆系统设计模式
1. 对话摘要模式
class ConversationSummarizer:
"""
对话摘要模式：定期压缩对话历史
适用场景：长对话，需要保持上下文但避免超出窗口
"""
def summarize_if_needed(self, messages: list, threshold: int = 10):
if len(messages) > threshold:
# 保留最近 5 条消息
recent = messages[-5:]
# 将之前的消息压缩为摘要
summary = self.llm.summarize(messages[:-5])
return [{"role": "system", "content": f"之前对话摘要：{summary}"}] + recent
return messages
2. 实体提取模式
class EntityMemory:
"""
实体提取模式：从对话中提取关键实体和关系
适用场景：需要记住用户提到的人、地点、事件等
"""
def extract_and_store(self, message: str, user_id: str):
# 使用 LLM 提取实体
entities = self.llm.extract_entities(message)
# 存储到知识图谱或向量数据库
for entity in entities:
self.store.add(entity, user_id=user_id)
3. 分层检索模式
class HierarchicalMemory:
"""
分层检索模式：先查短期记忆，再查长期记忆
适用场景：需要平衡响应速度和记忆深度
"""
async def retrieve(self, query: str, user_id: str):
# L1: 短期记忆（Redis）
short_term = await self.redis.get(f"session:{user_id}")
if short_term and self.is_relevant(query, short_term):
return short_term
# L2: 长期记忆（Mem0/向量数据库）
long_term = await self.mem0.search(query, user_id=user_id)
return long_term
记忆系统最佳实践
| 实践 | 说明 |
|---|---|
| 分层存储 | 热数据用 Redis，冷数据用向量数据库 |
| 定期清理 | 设置 TTL，避免记忆无限增长 |
| 隐私保护 | 敏感信息加密存储，支持用户删除 |
| 版本控制 | 记忆更新时保留历史版本 |
| 一致性 | 多后端同步时注意数据一致性 |
08 核心领域七：评测系统
为什么需要评测？
做 AI 产品不能只靠"感觉"，需要量化指标来衡量效果。
评测系统的核心价值：
•量化效果：用数据说话，而非主观感受•指导优化：找到系统瓶颈，针对性改进•防止退化：持续监控，避免更新后效果下降•对比选型：客观比较不同方案的优劣
评测维度全景
┌─────────────────────────────────────────────────────────────┐
│ AI 系统评测维度 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 检索质量 │ │ 生成质量 │ │ 系统性能 │ │
│ │ │ │ │ │ │ │
│ │ • 召回率 │ │ • 准确性 │ │ • 延迟 │ │
│ │ • 精确率 │ │ • 忠实度 │ │ • 吞吐量 │ │
│ │ • MRR/NDCG │ │ • 相关性 │ │ • 成本 │ │
│ │ • Hit Rate │ │ • 完整性 │ │ • 可用性 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 安全合规 │ │ 用户体验 │ │ 业务指标 │ │
│ │ │ │ │ │ │ │
│ │ • 幻觉率 │ │ • 满意度 │ │ • 转化率 │ │
│ │ • 有害内容 │ │ • 任务完成 │ │ • 留存率 │ │
│ │ • 隐私泄露 │ │ • 响应时间 │ │ • NPS │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
RAG 评测指标详解
检索阶段指标
| 指标 | 含义 | 计算方式 | 目标值 |
|---|---|---|---|
| Recall@K | Top K 结果中包含相关文档的比例 | 相关文档数 / 总相关文档数 | >0.8 |
| Precision@K | Top K 结果中相关文档的比例 | 相关文档数 / K | >0.7 |
| MRR | 第一个相关结果的排名倒数 | 1 / 第一个相关结果位置 | >0.6 |
| NDCG | 考虑位置权重的排序质量 | DCG / IDCG | >0.7 |
| Hit Rate | 至少找到一个相关文档的查询比例 | 成功查询数 / 总查询数 | >0.9 |
生成阶段指标
| 指标 | 含义 | 评估方式 |
|---|---|---|
| Faithfulness | 答案是否基于检索的上下文 | LLM 评估 |
| Answer Relevancy | 答案与问题的相关度 | LLM 评估 |
| Context Precision | 检索文档的相关性 | LLM 评估 |
| Context Recall | 是否检索到所有相关信息 | 与 Ground Truth 对比 |
| Hallucination Rate | 幻觉/编造内容的比例 | 人工 + LLM 评估 |
主流评测框架
| 框架 | 特点 | 适用场景 | 官方链接 |
|---|---|---|---|
| RAGAS | RAG 专用，指标全面 | RAG 系统评测 | RAGAS[59] |
| LangSmith | 可观测性 + 评测 | LangChain 生态 | LangSmith[60] |
| Arize Phoenix | 开源，可视化强 | 生产监控 | Phoenix[61] |
| DeepEval | 单元测试风格 | CI/CD 集成 | DeepEval[62] |
| TruLens | 可解释性评测 | 研究/调试 | TruLens[63] |
RAGAS 评测示例
from ragas import evaluate
from ragas.metrics import (
context_precision,
context_recall,
faithfulness,
answer_relevancy
)
from datasets import Dataset
# 准备评测数据集
eval_data = {
"question": ["什么是 RAG？", "如何优化检索效果？"],
"answer": ["RAG 是检索增强生成...", "可以通过混合检索..."],
"contexts": [["RAG 全称是..."], ["混合检索结合了..."]],
"ground_truth": ["RAG 是一种结合检索和生成的技术", "混合检索、重排序等"]
}
dataset = Dataset.from_dict(eval_data)
# 执行评测
results = evaluate(
dataset,
metrics=[
context_precision,
context_recall,
faithfulness,
answer_relevancy
]
)
print(results)
# 输出示例:
# {
# "context_precision": 0.85,
# "context_recall": 0.92,
# "faithfulness": 0.96,
# "answer_relevancy": 0.88,
# }
官方文档：RAGAS Documentation[64]
LLM 基准测试
用于评估 LLM 基础能力的标准测试集：
| 基准测试 | 评估能力 | 说明 |
|---|---|---|
| MMLU | 知识广度 | 57 个学科的多选题 |
| GPQA | 专家级推理 | 研究生水平科学问题 |
| HumanEval | 代码生成 | Python 编程题 |
| SWE-bench | 软件工程 | 真实 GitHub Issue 修复 |
| MATH | 数学推理 | 竞赛级数学题 |
| GSM8K | 基础数学 | 小学数学应用题 |
排行榜：Vellum LLM Leaderboard[65]
评测最佳实践
1. 建立评测数据集
# 评测数据集结构
eval_dataset = [
{
"id": "q001",
"question": "用户问题",
"ground_truth": "标准答案",
"category": "问题类别",
"difficulty": "easy/medium/hard",
"metadata": {"source": "..."}
}
]
2. 自动化评测流水线
┌─────────────────────────────────────────────────────────────┐
│ 评测流水线 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 代码提交 → 自动评测 → 生成报告 → 对比基线 → 决策 │
│ │
│ • 每次 PR 自动运行评测 │
│ • 与基线版本对比 │
│ • 效果下降则阻止合并 │
│ │
└─────────────────────────────────────────────────────────────┘
3. 评测指标监控
| 监控项 | 告警阈值 | 说明 |
|---|---|---|
| 召回率 | <0.8 | 检索质量下降 |
| 忠实度 | <0.9 | 幻觉风险增加 |
| P95 延迟 | >2s | 用户体验下降 |
| 错误率 | >1% | 系统稳定性问题 |
09 核心领域八：模型微调与部署
什么时候需要微调？
| 场景 | 是否需要微调 | 推荐方案 |
|---|---|---|
| 通用问答 | 否 | Prompt Engineering |
| 特定格式输出 | 可能 | Few-shot 或微调 |
| 领域专业知识 | 可能 | RAG 或微调 |
| 特定风格/语气 | 是 | 微调 |
| 私有数据理解 | 是 | 微调 |
决策原则：先尝试 Prompt Engineering 和 RAG，效果不满足再考虑微调。微调成本高、周期长，但效果上限更高。
微调技术对比
| 技术 | 原理 | 资源需求 | 效果 | 适用场景 |
|---|---|---|---|---|
| Full Fine-tuning | 更新所有参数 | 极高 | 最好 | 大公司、充足资源 |
| LoRA | 低秩适配器 | 低 | 好 | 资源有限、快速迭代 |
| QLoRA | 量化 + LoRA | 更低 | 较好 | 消费级 GPU |
| Prefix Tuning | 学习前缀向量 | 低 | 一般 | 特定任务 |
| Prompt Tuning | 学习软提示 | 最低 | 一般 | 简单适配 |
推荐：大多数场景使用 LoRA 或 QLoRA，性价比最高。 — 参考：LoRA 论文[66]
微调工具链
| 工具 | 特点 | 官方链接 |
|---|---|---|
| Hugging Face PEFT | LoRA/QLoRA 官方实现 | PEFT[67] |
| Axolotl | 简化微调流程 | Axolotl[68] |
| LLaMA-Factory | 中文友好，GUI 界面 | LLaMA-Factory[69] |
| Unsloth | 2x 速度，50% 显存 | Unsloth[70] |
| OpenAI Fine-tuning | 托管服务，开箱即用 | OpenAI Fine-tuning[71] |
模型部署方案
部署方式对比
| 方式 | 特点 | 适用场景 |
|---|---|---|
| API 调用 | 最简单，按量付费 | 快速上线、中小规模 |
| 自托管推理 | 完全控制，成本可控 | 大规模、数据敏感 |
| 边缘部署 | 低延迟，离线可用 | 端侧应用 |
推理框架
| 框架 | 特点 | 官方链接 |
|---|---|---|
| vLLM | 高吞吐，PagedAttention | vLLM[72] |
| TGI | Hugging Face 官方 | TGI[73] |
| Ollama | 本地部署，简单易用 | Ollama[74] |
| llama.cpp | CPU 推理，量化支持 | llama.cpp[75] |
| TensorRT-LLM | NVIDIA 优化 | TensorRT-LLM[76] |
模型量化
量化可以显著降低模型大小和推理成本：
| 量化精度 | 模型大小 | 速度 | 质量损失 |
|---|---|---|---|
| FP16 | 基准 | 基准 | 无 |
| INT8 | ~50% | ~1.5x | 极小 |
| INT4 | ~25% | ~2x | 小 |
| GPTQ/AWQ | ~25% | ~2x | 小 |
10 核心领域九：安全与合规
AI 安全风险全景
┌─────────────────────────────────────────────────────────────┐
│ AI 安全风险 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 输入安全 │ │ 输出安全 │ │ 数据安全 │ │
│ │ │ │ │ │ │ │
│ │ • 提示注入 │ │ • 幻觉 │ │ • 隐私泄露 │ │
│ │ • 越狱攻击 │ │ • 有害内容 │ │ • 数据投毒 │ │
│ │ • 对抗样本 │ │ • 版权侵犯 │ │ • 模型窃取 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 系统安全 │ │ 合规风险 │ │ 运营风险 │ │
│ │ │ │ │ │ │ │
│ │ • API 滥用 │ │ • GDPR │ │ • 成本失控 │ │
│ │ • 拒绝服务 │ │ • 数据出境 │ │ • 服务中断 │ │
│ │ • 供应链 │ │ • 行业监管 │ │ • 声誉损失 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
提示注入防护
提示注入（Prompt Injection）是最常见的 AI 安全威胁：
# 危险示例：用户输入直接拼接
prompt = f"请回答用户问题：{user_input}" # 危险！
# 安全示例：输入验证 + 角色隔离
def safe_prompt(user_input: str) -> str:
# 1. 输入验证
if contains_injection_patterns(user_input):
raise SecurityError("检测到潜在的提示注入")
# 2. 角色隔离
return f"""
<system>你是一个安全的助手，只回答与产品相关的问题。</system>
<user_input>{escape_special_chars(user_input)}</user_input>
"""
安全检查清单
| 检查项 | 说明 | 优先级 |
|---|---|---|
| 输入验证 | 过滤恶意输入、长度限制 | 高 |
| 输出过滤 | 检测有害内容、PII | 高 |
| 速率限制 | 防止 API 滥用 | 高 |
| 日志审计 | 记录所有请求和响应 | 中 |
| 内容审核 | 使用审核 API | 中 |
| 模型隔离 | 敏感场景使用专用模型 | 中 |
合规要求
| 法规 | 适用范围 | 核心要求 |
|---|---|---|
| GDPR | 欧盟用户 | 数据最小化、用户同意、删除权 |
| CCPA | 加州用户 | 知情权、删除权、不歧视 |
| 个人信息保护法 | 中国用户 | 知情同意、数据本地化 |
| AI 法案 | 欧盟 | 风险分级、透明度、人工监督 |
安全工具
| 工具 | 用途 | 官方链接 |
|---|---|---|
| Guardrails AI | 输出验证和过滤 | Guardrails[77] |
| NeMo Guardrails | NVIDIA 安全框架 | NeMo Guardrails[78] |
| LLM Guard | 输入输出安全扫描 | LLM Guard[79] |
| Rebuff | 提示注入检测 | Rebuff[80] |
11 技术栈速查表
核心框架
| 框架 | 用途 | 官方链接 |
|---|---|---|
| LangChain | LLM 应用编排 | https://langchain.com[81] |
| LlamaIndex | 数据索引和检索 | https://llamaindex.ai[82] |
| LangGraph | Agent 工作流编排 | https://langchain-ai.github.io/langgraph/[83] |
向量数据库
| 数据库 | 特点 | 推荐场景 |
|---|---|---|
| Qdrant | Rust 实现，性能高 | 追求性能 |
| Weaviate | AI 原生设计 | 语义搜索 |
| Milvus | 支持十亿级向量 | 超大规模 |
记忆框架
| 框架 | 特点 | 推荐场景 |
|---|---|---|
| Redis | 超低延迟 | 工作记忆 |
| Mem0 | AI 驱动实体提取 | 长期记忆 |
| Zep | 自托管，数据主权 | 合规要求高 |
12企业级 AI 系统技术栈推荐
以下是构建生产级 AI 系统的推荐技术栈：
企业级 AI 系统技术栈 (2025):
├── LLM 层
│ ├── OpenAI (GPT-4o, GPT-4o-mini, o1, o3)
│ ├── Anthropic (Claude Sonnet 4, Claude Opus 4, Claude 3.5 Sonnet)
│ ├── Google (Gemini 2.0, Gemini 1.5 Pro)
│ ├── 国产模型 (通义千问 Qwen 2.5、DeepSeek-V3、DeepSeek-R1)
│ └── 智能路由器 (RouteLLM, 自研路由)
│
├── RAG 框架
│ ├── LangChain + LangGraph (Agent 编排)
│ ├── LlamaIndex (数据索引)
│ ├── 混合检索 (Vector + BM25)
│ └── Agentic RAG (自主检索决策)
│
├── 向量数据库
│ ├── Qdrant (高性能，Rust 实现)
│ ├── Weaviate (AI 原生)
│ ├── Milvus (超大规模)
│ └── pgvector (PostgreSQL 生态)
│
├── Embedding
│ ├── OpenAI text-embedding-3-small/large
│ ├── Voyage AI voyage-3
│ └── BGE-M3 (开源，多语言)
│
├── 重排序
│ ├── Cohere Rerank v3
│ ├── Jina Reranker v2
│ └── BGE Reranker (开源)
│
├── 记忆系统
│ ├── Redis (L1 工作记忆)
│ ├── Mem0 (L2 长期记忆)
│ └── Zep (L3 混合记忆)
│
├── Agent 架构
│ ├── LangGraph (状态图，生产级)
│ ├── MCP (Model Context Protocol)
│ └── Function Calling / Tool Use
│
├── 数据处理
│ ├── Unstructured / LlamaParse (文档解析)
│ ├── 分块策略 (递归/语义)
│ └── Whisper (音频转写)
│
├── 评测系统
│ ├── RAGAS (RAG 评测)
│ ├── LangSmith (可观测性)
│ └── DeepEval (CI/CD 集成)
│
├── 模型部署
│ ├── vLLM (高吞吐推理)
│ ├── TGI (Hugging Face)
│ └── Ollama (本地部署)
│
├── 安全合规
│ ├── Guardrails AI (输出验证)
│ ├── NeMo Guardrails (NVIDIA)
│ └── LLM Guard (安全扫描)
│
└── 基础设施
├── FastAPI (Web 框架)
├── PostgreSQL (关系数据库)
├── Redis (缓存系统)
├── Prometheus + Grafana (监控)
└── Docker + K8s (容器化)
生产环境参考指标
| 指标 | 建议目标值 | 说明 |
|---|---|---|
| 检索延迟 (P95) | < 200ms | 不含 LLM 生成时间 |
| LLM 首 Token 延迟 | < 500ms | TTFT (Time To First Token) |
| 缓存命中率 | > 90% | Redis 热点缓存 |
| 混合检索召回率提升 | > 10% | 相比纯向量检索 |
| 系统可用性 | 99.9% | 需要监控和告警 |
| 幻觉率 | < 5% | 需要持续监控 |
写在最后
AI 大模型工程是一个快速发展的领域，新技术、新框架层出不穷。
但万变不离其宗，核心的知识体系是稳定的：
| 模块 | 类比 | 核心作用 |
|---|---|---|
| LLM | 大脑 | 理解和生成 |
| RAG | 知识库 | 检索外部知识 |
| Agent | 手脚 | 使用工具执行任务 |
| 记忆 | 长期存储 | 保持上下文和历史 |
| Prompt/Context | 沟通桥梁 | 高效传递信息 |
| 评测 | 体检报告 | 量化效果和质量 |
| 安全 | 免疫系统 | 防护和合规 |
掌握了这个框架，你就能在各种新技术中游刃有余。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
5
0- 0
已为社区贡献604条内容
所有评论(0)