【必收藏】AI大模型工程师完整学习路线：从LLM、RAG到Agent的9大核心领域系统化指南

面向 AI 工程师的系统化学习指南，涵盖 LLM、RAG、Agent、记忆系统等 7 大核心领域

---

写在前面

---

如果你刚刚踏入 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
Google	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	Google	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. 文档解析

支持的文档格式

格式	解析工具	特点
PDF	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大模型的风口？

领取方式在文末

为什么要学习大模型？

目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

目前，开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景，其中，应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过 30%。

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

最后

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】