AI大模型工程师系统化学习指南：涵盖LLM、RAG、Agent、记忆系统等7大核心领域，助你从入门到精通
·
本文面向AI工程师，提供一份系统化学习指南，涵盖AI大模型工程的7大核心领域：LLM大模型、RAG检索增强生成、Agent智能体、记忆系统、评测系统、模型微调与部署、安全与合规。通过本文，你将建立起AI大模型工程的完整知识框架，为深入学习细分技术打下坚实基础。
面向 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/o3RAG 技术：混合检索、重排序、Graph RAGAgent 智能体：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）价格较高但在复杂任务上性价比更优。
模型选型决策树
任务来了，如何选择模型？
- 需要复杂推理（数学证明、科学研究）？→ 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 有两个天然缺陷：
- 知识截止：训练数据有截止日期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 架构】
流程说明：
- 用户问题 → 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 改写 | 是否优化用户问题
| 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 方法？
- 简单问答/翻译/摘要？→ Zero-shot 就够了2.需要特定格式输出？→ Few-shot（给示例）3.涉及推理（数学、逻辑）？
对延迟敏感？→ Zero-shot CoT（加"请一步一步思考"）对准确率要求高？→ CoT + Self-Consistency（多次推理投票）
- 需要自我纠错？→ 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 Serverfrom 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 CoTprompt = """问题：一个商店有 23 个苹果，卖掉了 17 个，又进货了 12 个，现在有多少个苹果？
请一步一步思考，然后给出答案。"""
# Few-shot CoTprompt = """问题：小明有 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 OpenAIclient = 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 evaluatefrom 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的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2026 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
以上全套大模型资料如何领取？
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
6
0- 0
已为社区贡献254条内容
所有评论(0)