覆盖 27 个此前缺少返回链接的报告页和独立页面（共 50 个 HTML 页，index.html 首页除外） - 标准报告页：header/header-bar 内插入 back-link - 特殊页面：深国际、中医馆、YqBoot、交互式演示等单独适配 - 统一文案「← 返回知识库」，URL 按目录深度自动推算
This commit is contained in:
zdh
+268
@@ -0,0 +1,268 @@
|
||||
# AI 核心技能原理说明
|
||||
|
||||
> 面试快速回顾用，每条控制在 2-3 分钟可讲完。
|
||||
|
||||
---
|
||||
|
||||
## 1. 大语言模型（LLM）基础
|
||||
|
||||
### 核心原理
|
||||
- **Transformer 架构**：所有现代 LLM 的基础。核心是 Self-Attention 机制——每个 token 计算与序列中所有其他 token 的相关性权重，并行处理，突破 RNN 的串行瓶颈。
|
||||
- **训练三阶段**：
|
||||
1. **Pre-training**（预训练）：海量语料上做 Next Token Prediction，学习语言的统计规律和世界知识
|
||||
2. **SFT**（监督微调）：用高质量指令-回答对训练，让模型学会"对话"
|
||||
3. **RLHF**（人类反馈强化学习）：用人类偏好数据训练奖励模型，再用 PPO 优化，对齐人类价值观
|
||||
|
||||
### 关键概念
|
||||
| 概念 | 说明 |
|
||||
|------|------|
|
||||
| **Token** | 模型处理的最小文本单元，中文约 1.5-2 字符/token |
|
||||
| **Context Window** | 模型一次能处理的 token 上限（如 128K、200K） |
|
||||
| **Temperature** | 控制输出随机性，0=确定性，1=高随机 |
|
||||
| **Top-P / Top-K** | 采样策略，限制候选 token 范围 |
|
||||
|
||||
### 主流模型对比
|
||||
| 模型 | 特点 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| GPT-4o | 多模态，综合最强 | 复杂推理、多模态任务 |
|
||||
| Claude 4 | 长上下文 200K，安全性高 | 长文档分析、代码生成 |
|
||||
| DeepSeek-V3 | 开源，性价比高，MoE 架构 | 国内部署、成本敏感场景 |
|
||||
| 通义千问 | 中文优化，阿里云生态 | 政务、企业中文场景 |
|
||||
|
||||
### 面试要点
|
||||
- 说清楚 Transformer 的 Self-Attention 解决了什么问题（长距离依赖、并行化）
|
||||
- 能解释为什么需要 RLHF（对齐问题——模型能力强但不一定听话）
|
||||
- 知道怎么选模型：看场景（精度/成本/延迟）、看上下文长度、看部署方式
|
||||
|
||||
---
|
||||
|
||||
## 2. Prompt Engineering
|
||||
|
||||
### 核心方法论
|
||||
| 技术 | 原理 | 示例 |
|
||||
|------|------|------|
|
||||
| **Zero-shot** | 不给示例，直接提问 | "将以下文本分类为正面/负面：..." |
|
||||
| **Few-shot** | 给 2-5 个示例，模型学会模式 | 示例1 → 示例2 → 新输入 |
|
||||
| **CoT**（思维链） | 要求模型"一步步思考"，激活推理能力 | "让我们一步步分析：首先...其次..." |
|
||||
| **结构化输出** | 约束输出格式（JSON/XML）| "请以 JSON 格式返回，包含 name、age 字段" |
|
||||
| **Self-Consistency** | 多次采样 + 投票，提升推理准确率 | 同一问题跑 5 次，取多数答案 |
|
||||
|
||||
### 为什么 CoT 有效
|
||||
- LLM 是自回归的——每个 token 基于前文生成
|
||||
- 写出推理过程 = 给模型更多"思考空间"，中间步骤的 token 约束了后续输出的方向
|
||||
- 复杂推理任务（数学、逻辑）中 CoT 可将准确率从 ~20% 提升到 ~80%
|
||||
|
||||
### Function Calling 原理
|
||||
1. 定义函数的 JSON Schema（函数名、参数、描述）
|
||||
2. 模型判断用户意图 → 返回函数名 + 结构化参数（而非自然语言）
|
||||
3. 应用层执行函数 → 结果回传模型 → 模型生成最终回复
|
||||
4. 本质：让模型"学会"输出结构化指令，而非直接回答
|
||||
|
||||
### 面试要点
|
||||
- 能解释 CoT 的原理（通过中间 token 约束推理路径）
|
||||
- 能说清楚 Function Calling 的流程（不是模型调用函数，是模型输出参数，应用层执行）
|
||||
- 准备一个实际案例（如：好差评系统中用 Few-shot + CoT 做评价分类）
|
||||
|
||||
---
|
||||
|
||||
## 3. Agent 智能体
|
||||
|
||||
### 核心架构
|
||||
```
|
||||
用户输入 → Agent Core（LLM）→ 规划（Plan）
|
||||
→ 调用工具（Tool Use）
|
||||
→ 观察结果（Observation）
|
||||
→ 反思调整（Reflection）
|
||||
→ 循环直到目标达成 → 输出
|
||||
```
|
||||
|
||||
### 关键设计模式
|
||||
| 模式 | 原理 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| **ReAct** | Reasoning + Acting 交替：思考一步 → 执行一步 → 观察 → 再思考 | 需要与外部交互的任务 |
|
||||
| **Plan-and-Execute** | 先生成完整计划，再逐步执行 | 复杂多步任务 |
|
||||
| **Multi-Agent** | 多个 Agent 分工协作，各司其职 | 跨领域复杂流程 |
|
||||
|
||||
### 多 Agent 协作
|
||||
- **分工原则**：每个 Agent 有明确角色和工具集，互不越界
|
||||
- **通信方式**：
|
||||
- 共享内存/消息队列：Agent A 输出 → Agent B 输入
|
||||
- 中央调度器：Orchestrator 统一分发任务、汇总结果
|
||||
- **冲突仲裁**：定义优先级规则或由调度 Agent 决策
|
||||
|
||||
### 安全护栏（Guardrails）
|
||||
- **输入护栏**：敏感词过滤、注入攻击检测
|
||||
- **输出护栏**：内容合规校验、事实性核查
|
||||
- **行为护栏**：限制可调用的工具范围、设置最大循环次数防止死循环
|
||||
|
||||
### 面试要点
|
||||
- 说清楚 Agent 和普通 LLM 调用的区别（Agent 有自主规划 + 工具调用 + 循环决策能力）
|
||||
- 能画出 Agent 的 ReAct 循环图
|
||||
- 准备一个落地案例（如：民政 AI 客服中，Agent 判断用户意图 → 调用知识库检索 → 查办事进度 API → 生成回答）
|
||||
|
||||
---
|
||||
|
||||
## 4. Skills 编排系统
|
||||
|
||||
### 设计理念
|
||||
将业务能力封装为标准化、可复用的 Skill 模块，由 LLM 根据用户意图自动选择并编排执行。
|
||||
|
||||
### 架构
|
||||
```
|
||||
用户输入
|
||||
│
|
||||
▼
|
||||
意图识别（LLM）
|
||||
│
|
||||
▼
|
||||
Skill 路由（匹配最相关的 Skill 组合）
|
||||
│
|
||||
▼
|
||||
编排执行（串行/并行/条件分支）
|
||||
│
|
||||
▼
|
||||
结果聚合 → 输出
|
||||
```
|
||||
|
||||
### Skill 定义规范
|
||||
```json
|
||||
{
|
||||
"name": "report_generator",
|
||||
"description": "根据查询条件生成业务报表",
|
||||
"parameters": {
|
||||
"report_type": "销售报表 / 库存报表 / 财务报表",
|
||||
"date_range": "起止日期",
|
||||
"format": "PDF / Excel"
|
||||
},
|
||||
"auth_required": true
|
||||
}
|
||||
```
|
||||
|
||||
### 关键机制
|
||||
| 机制 | 说明 |
|
||||
|------|------|
|
||||
| **热加载** | Skill 注册/下线不重启系统，通过配置中心或数据库动态生效 |
|
||||
| **自动路由** | LLM 用语义匹配（Embedding 相似度）找到最相关的 Skill |
|
||||
| **依赖解析** | Skill A 的输出可能是 Skill B 的输入，编排引擎自动处理依赖顺序 |
|
||||
| **降级策略** | 首选 Skill 不可用时，自动回退到备选方案或转人工 |
|
||||
|
||||
### 面试要点
|
||||
- 类比：Skills 编排 ≈ 微服务 + API 网关 + 服务编排，只是"路由规则"由 LLM 动态决定
|
||||
- 能说清楚和 Function Calling 的关系：Skills 编排是更高层的抽象，一个 Skill 可能包含多个 Function Call
|
||||
- 准备一个例子：用户说"帮我生成上月销售报表并推送到钉钉"→ 路由到 `report_generator` + `dingtalk_notifier` 两个 Skill
|
||||
|
||||
---
|
||||
|
||||
## 5. 知识库（RAG）系统
|
||||
|
||||
### 为什么需要 RAG
|
||||
- LLM 训练数据有截止日期，无法回答最新问题
|
||||
- LLM 可能产生幻觉（编造不存在的事实）
|
||||
- 企业私有数据不能用于训练公共模型
|
||||
- RAG = **检索（Retrieve）+ 增强（Augment）+ 生成（Generate）**
|
||||
|
||||
### 核心流程
|
||||
```
|
||||
文档入库（离线）：
|
||||
原始文档 → 解析 → 分块 → Embedding → 存入向量数据库
|
||||
|
||||
在线问答：
|
||||
用户提问 → Embedding → 向量检索（Top-K）→ 拼接 Prompt → LLM 生成 → 返回
|
||||
```
|
||||
|
||||
### 关键技术细节
|
||||
|
||||
**分块策略（Chunking）**
|
||||
| 策略 | 适用 | 优缺点 |
|
||||
|------|------|--------|
|
||||
| 固定长度 | 通用场景 | 简单但可能切断语义 |
|
||||
| 语义分块 | 长文档 | 按段落/章节切分，语义完整 |
|
||||
| 滑动窗口 | 需要上下文 | 相邻块有重叠，避免信息断裂 |
|
||||
|
||||
**Embedding 模型选择**
|
||||
- 中文：bge-large-zh、text2vec-large-chinese、m3e
|
||||
- 多语言：text-embedding-3-large（OpenAI）、bge-m3
|
||||
|
||||
**检索优化**
|
||||
| 技术 | 说明 |
|
||||
|------|------|
|
||||
| 混合检索 | 语义检索（向量）+ 关键词检索（BM25）加权融合 |
|
||||
| Rerank | 粗召回后用精排模型重排序，提升 Top-N 精度 |
|
||||
| 元数据过滤 | 按时间/分类/权限等结构化字段预过滤 |
|
||||
|
||||
### 面试要点
|
||||
- 画出 RAG 的架构流程图（离线入库 + 在线问答两条线）
|
||||
- 能解释 Embedding 的本质（将文本映射到高维向量空间，语义相近的文本向量距离近）
|
||||
- 准备一个踩坑经验：分块大小怎么定？检索不准怎么优化？
|
||||
|
||||
---
|
||||
|
||||
## 6. AI Coding
|
||||
|
||||
### 主流工具原理
|
||||
| 工具 | 底层原理 | 特点 |
|
||||
|------|----------|------|
|
||||
| **Claude Code** | Claude 模型 + 工具调用（文件读写/Shell/搜索），Agent 模式自主执行 | 复杂任务拆解，长期上下文 |
|
||||
| **GitHub Copilot** | Codex 模型，实时上下文（当前文件+相邻Tab+项目结构）补全 | IDE 深度集成，毫秒级响应 |
|
||||
| **Cursor** | 多模型支持，全文件上下文编辑，Composer 模式 | 重构友好，Diff 预览 |
|
||||
| **Aider** | CLI 工具，Git 集成，Map-Reduce 处理大代码库 | 终端场景，可脚本化 |
|
||||
|
||||
### AI Coding 的工作模式
|
||||
1. **补全模式**：根据光标上下文，实时续写代码（Copilot 类）
|
||||
2. **对话模式**：自然语言描述需求 → AI 生成/修改代码（Cursor/Claude Code）
|
||||
3. **Agent 模式**：AI 自主规划 → 读写文件 → 执行命令 → 检查结果 → 迭代修复（Claude Code）
|
||||
|
||||
### 工程化实践
|
||||
- **小步提交**：每次 AI 修改控制在 200 行 diff 以内，便于 Review 和回滚
|
||||
- **测试驱动**：先让 AI 写测试，再让 AI 写实现，"测试是 AI 的 spec"
|
||||
- **代码审查**：AI 生成代码必须人工 Review，关注边界条件和安全问题
|
||||
- **Prompt 工程**：清晰的上下文（项目结构 + 技术栈 + 编码规范）大幅提升 AI 输出质量
|
||||
|
||||
### 面试要点
|
||||
- 能对比主要工具（Copilot vs Cursor vs Claude Code）的差异和选型理由
|
||||
- 能用实际案例说明效率提升（如：原本 3 天的 CRUD 模块，AI 辅助 4 小时完成）
|
||||
- 对 AI 代码的局限性有清醒认识（复杂业务逻辑、安全敏感代码需人工把关）
|
||||
|
||||
---
|
||||
|
||||
## 7. AI 视觉（YOLO）
|
||||
|
||||
### YOLO 核心思想
|
||||
- **You Only Look Once**：将目标检测转化为回归问题
|
||||
- 输入图片 → 单次 CNN 前向传播 → 同时输出边界框 + 类别概率
|
||||
- 相比 R-CNN 系列的两阶段方法（先提候选区 → 再分类），YOLO 更快，适合实时场景
|
||||
|
||||
### 演进路线
|
||||
| 版本 | 关键改进 | 年份 |
|
||||
|------|----------|------|
|
||||
| YOLOv5 | 工程化最成熟，社区生态好 | 2020 |
|
||||
| YOLOv8 | 无锚框检测，多任务（检测/分割/姿态）统一框架 | 2023 |
|
||||
| YOLOv10 | NMS-Free，端到端，效率进一步提升 | 2024 |
|
||||
|
||||
### 训练部署流程
|
||||
```
|
||||
数据采集 → 标注（LabelImg/LabelStudio）→ 数据集划分（训练/验证/测试）
|
||||
→ 数据增强（翻转/旋转/色彩抖动/Mosaic）
|
||||
→ 模型训练（预训练权重微调）
|
||||
→ 模型转换（ONNX/TensorRT）
|
||||
→ 边缘/服务端部署
|
||||
```
|
||||
|
||||
### 面试要点
|
||||
- 能解释 YOLO 为什么快（单阶段，一次前向传播出所有结果）
|
||||
- 能说清楚 mAP@0.5 是什么（IoU 阈值 0.5 时的平均精度）
|
||||
- 准备一个实际场景（如：安全帽检测的完整 Pipeline——RTSP 取流 → 抽帧 → YOLO 推理 → 告警推送）
|
||||
|
||||
---
|
||||
|
||||
## 面试速查：一句话总结每个方向
|
||||
|
||||
| 方向 | 一句话 |
|
||||
|------|--------|
|
||||
| LLM | Transformer + 三阶段训练，Self-Attention 是核心 |
|
||||
| Prompt | 通过输入设计引导模型行为，CoT 通过中间推理提升准确率 |
|
||||
| Agent | LLM + 规划 + 工具调用 + 循环决策 = 自主完成任务 |
|
||||
| Skills 编排 | 业务能力模块化，LLM 动态路由，自动编排执行 |
|
||||
| RAG | 检索外部知识增强 LLM，解决幻觉和知识截止问题 |
|
||||
| AI Coding | AI 辅助代码生成/审查/测试，Agent 模式实现自主开发 |
|
||||
| YOLO | 单阶段目标检测，一次前向传播出检测框+类别，实时性好 |
|
||||
Reference in New Issue
Block a user