简介《人工智能技术介绍》PPT是一份面向零基础学习者的入门课件适合高校学生、培训学员或准备转行AI的开发者用来理解神经网络与深度学习到底在做什么。内容从神经元基本构造、激活函数和万能近似定理讲起说明神经网络为何能逼近复杂函数随后过渡到梯度下降与反向传播原理并以TensorFlow为例介绍环境搭建、MNIST手写数字识别和单层网络实现帮助读者把概念落到代码层面最后梳理卷积、池化、ReLU与Dropout等深度网络关键技巧并给出网络搭建原则与LeNet-5模型分析适合用于课前预习、课堂讲解或自学复习。资源为1个PPT文件资源包大小约586KB页面紧凑、重点突出可作为一门AI入门课的配套讲义使用。已有61人浏览学习对于想快速建立人工智能技术框架的读者来说这份课件能节省自己整理资料的时间。1. 人工智能技术介绍.ppt一张技术地图不是一份名词清单很多人拿到一份《人工智能技术介绍.ppt》时第一反应是往后翻找“结论页”。但真正会看这种材料的人反而先从目录页开始反推这份标题背后其实是一套技术选型地图——机器学习、深度学习、视觉、语言、大模型、智能体每一页都可以拆成一个“什么需求该选哪条路线、成本多少、风险在哪”的决策分支。你把它当名词解释读它只是一份PPT你把它当决策框架读它能直接帮你回答一个问题我手上这个AI需求到底该用哪种方案值不值得投入。这篇文章就按这个思路把技术要点拆开、落到能复现的步骤上适合正在做技术选型、准备做汇报材料、或者想在一周内验证一个AI想法能不能落地的开发者和产品经理。2. 机器学习与深度学习两条主线先分清适用范围再动手2.1 两条主线的边界为什么深度学习不是“更高级”的机器学习常见的误解是把深度学习当成机器学习的“升级版”觉得数据够就直接上深度模型。但在实际项目里这个选择往往不是按“先进程度”来的而是按“数据形态、样本量、解释性要求”来定的。机器学习这条线核心是人工设计特征加浅层模型。你告诉模型哪些字段重要、怎么组合模型在一个相对小的表格数据上学一个决策边界。它的优点是样本需求少、训练快、可解释性强出了问题能回溯到具体特征。深度学习这条线核心是特征由网络自己学数据直接以图像、文本、音频的原始形态喂进去优点是上限高缺点是要有足够数据和算力而且中间过程基本是个黑匣子。我一般会先问三个问题数据是不是表格型的样本量有没有到万级业务上是否需要解释“为什么是这个结果”如果三个答案里有至少两个偏“是”那机器学习是更稳的起点如果数据是多模态、非结构化、量大再切到深度学习。这个判断比纠结选哪个“最新模型”重要得多。2.2 一个最小训练循环把黑匣子拆成四步为了理解深度学习的训练过程不需要一上来就上重型框架。用一个不依赖任何第三方库的最小代码就能看清训练循环的四个组成部分前向计算、损失计算、梯度计算、参数更新。import random import math # 模拟数据y 2x 1 附近加噪声x 归一化到 [0, 1] 区间 data [(i / 10.0, 2 * (i / 10.0) 1 random.uniform(-0.2, 0.2)) for i in range(10)] w, b 0.0, 0.0 # 初始化权重和偏置 lr 0.05 # 学习率每次更新参数的步长 epochs 100 # 整体数据被反复学习的轮数 for epoch in range(epochs): loss 0.0 dw, db 0.0, 0.0 for x, y_true in data: y_pred w * x b # 前向计算模型给出预测值 err y_pred - y_true # 预测值与真实值的差 loss err * err # 均方误差累计 dw err * x # 损失对 w 的梯度常数因子并入学习率 db err # 损失对 b 的梯度 loss / len(data) dw / len(data) db / len(data) w - lr * dw # 沿负梯度方向更新 b - lr * db if epoch % 20 0: print(fepoch {epoch}: loss{loss:.4f}, w{w:.2f}, b{b:.2f})这段代码把深度学习的核心机制浓缩成了几十行。学利率 lr 决定了每一步往梯度反方向走多远太大loss 会震荡甚至发散太小训练半天参数不动。epochs 是模型遍历完整数据的次数每一次遍历模型都在用所有样本的平均梯度修正自己。数据归一化也很关键x 范围在 [0, 1] 时梯度量级稳定直接用原数值很容易让更新步长过大。实际生产里不会这样手写训练但理解这个循环后再看任何框架的 trainer 配置都只是在换“前向计算、损失函数、优化器、数据加载”这四个组件。框架只是把这段循环写得更高性能和更省显存逻辑没有变。2.3 数据划分的“留出法”最小实现训练循环之外第二件必须动手做的事是数据划分。很多项目在模型上反复调参没有效果回头一查是数据划分那一步就埋了雷。import random samples list(range(100)) # 模拟 100 条样本编号 random.seed(42) # 固定随机种子保证实验可复现 random.shuffle(samples) # 先洗牌再切片 train samples[:70] # 前 70 做训练 val samples[70:85] # 中间 15 做验证用于调参和早停 test samples[85:] # 末尾 15 做测试模型上线前只允许评估一次这里最容易犯的错是直接对原始数据切片而不洗牌。原始数据往往按采集时间或类别顺序排列直接切头尾会造成训练集和测试集分布不一致比如前 70 条全是同一个类别的样本。val 和 test 的分工也不同val 是你反复用来调超参的模型会间接“见过”它所以测试集必须留到最后再碰否则你拿到的准确率是乐观的假象。划分比例上70/15/15 是常见默认值。数据量特别少时可以把 val 并入 train 做交叉验证但 test 一定要独立并且要按业务场景决定是按行随机划分还是按用户 ID、按时间去划分。这一步的道理在后面避坑章节里还会重点展开。3. 视觉与语言两大场景把技术点落成任务和指标3.1 视觉任务分类、检测、分割指标完全不同视觉是 AI 落地最成熟的场景之一但“做视觉”不是一句笼统的话。技术介绍里常出现的图像分类、目标检测、语义分割其实是三种任务评估指标也完全不同选错指标会让方案看起来“没效果”或“效果奇好”这两种误判都很危险。任务输出形态核心指标说明图像分类整图一个类别标签Accuracy、Top-5、混淆矩阵类别不均衡时要看各类别召回目标检测图中多个框类别mAP、IoU、FPS框的位置误差和漏检率都要看语义分割每个像素一个类别mIoU、PA小目标区域占比低时 mIoU 更可靠选型上我一般会先确认“业务瓶颈是识别精度还是推理速度”。如果只是判断图片里有没有某种缺陷分类就够如果还要定位缺陷位置就需要检测如果要在像素级别统计面积才上分割。不要因为技术介绍里把三个都列出来就认为项目必须三步走。视觉项目的另一个常见问题是标注成本。分类一张图可能几秒钟但检测框和像素级标注的时间成本是按分钟算的。所以在动手标注前先拿 50 张图做一个“标注规范试标”让标注人员、算法人员、业务方对齐“什么算缺陷、什么算遮挡、边界怎么画”这一步能省掉后面大量的返工。3.2 语言任务分类、抽取、生成标注质量决定上限自然语言处理的技术栈比视觉更碎。文本分类、情感分析、信息抽取、文本生成每一步都有不同的模型结构和不同的失败模式。技术介绍里常把这些放在同一页但落地时它们是三条完全不同的路径。文本生成类的任务评估最麻烦。BLEU、Rouge 这类指标只能衡量字面重叠对语义正确但措辞不同的输出会给出很低分。我在实际项目里常用的是“先人工抽 100 条两三个人分别打分再决定要不要信任自动指标”。生成任务如果自动指标和人工判断明显冲突以人工判断为准并且把人工打分标准定义清楚比如“信息正确但表述不顺”算不算对。信息抽取类任务则相对好评估精确率、召回率、F1 都能直接算。但抽取任务有个更隐蔽的坑标注规范不一致。同一个实体有人标全称有人标简称模型学到的就是两套不一致的规律。所以抽取类项目的第一步不是选模型而是统一标注规范并对标注结果做一致性检查。3.3 标注质量检查先跑脚本再进训练标注质量直接影响模型上限而且问题往往不是“标错了”而是“标得不一致”。一个几百条数据的检查脚本能在训练前筛掉大部分隐患。# annotation.txt 格式样本ID \t 标签1,标签2,标签3 # 检查三类常见问题空标注、明显重复、类别极度失衡 labels [] with open(annotations.txt, r, encodingutf-8) as f: for line in f: parts line.strip().split(\t) if len(parts) 2: cur [x.strip() for x in parts[1].split(,) if x.strip()] labels.append(cur) empty [i for i, v in enumerate(labels) if len(v) 0] dup [i for i, v in enumerate(labels) if len(v) ! len(set(v))] # 统计类别分布挑出占比超过 80% 的类别 from collections import Counter all_labels [lab for v in labels for lab in v] counter Counter(all_labels) hot {k: v for k, v in counter.items() if v / max(len(all_labels), 1) 0.8} print(空标注条数:, len(empty)) print(疑似重复标签条数:, len(dup)) print(占比超过80%的类别:, hot)脚本背后的逻辑很简单空标注说明标注流程中断了重复标签说明同一条样本被标了两遍或标签体系有重叠类别失衡则说明模型大概率会退化成“全预测大类别也能拿高分”的状态。脚本能兜底但真正决定效果的是规范本身。每发现一批问题不要只改数据要回去找原因是标注工具漏了必填校验还是规范里没写清楚边界。数据清理不是一次性工作而是每一轮迭代前都要跑的例行检查。4. 大模型与智能体PPT 之外真正要投入的两块4.1 大模型不是“更深的网络”是新的交互范式传统深度学习模型解决的是“给定输入输出固定形式的结果”比如分类标签、检测框、一段翻译。大模型改变的是交互方式你通过自然语言指令告诉模型要做什么模型在一个开放的输出空间里生成结果。这个改变带来了两个直接后果一是模型的能力边界不再由任务类型决定而由上下文里的知识和指令决定二是评估方式从“算对错”变成了“判断生成质量”这让评测变得更主观。智能体则更进一步让大模型可以调用工具、读取外部数据、执行多步操作。技术介绍里讲智能体通常是一页概念图但落地时要拆成三件事模型能输出结构化指令、外部工具接口足够稳定、每一步有中间结果可追踪。缺少任何一个智能体都会变成“看起来很聪明但一执行就断”的演示品。我见过很多团队在大模型方案上投入前没有先做一个最简单的手动链路人工把任务拆成步骤调接口看哪一步出错。这其实是在验证“任务本身是否适合智能体解决”而不是让模型从零开始试错。这一步不能省。4.2 把大模型接进业务的第一步结构化输出无论是做抽取、分类还是智能体第一步永远是让模型输出稳定的结构化结果。下面这个调用壳是通用的大模型接口格式兼容大多数部署方案只需要替换地址和密钥。import json import urllib.request # 通用大模型调用壳按你自己的部署或服务商文档替换地址和密钥 endpoint http://127.0.0.1:8000/v1/chat/completions payload { model: your_model_name, messages: [ {role: system, content: 你是信息抽取助手。只输出JSON不输出任何解释。}, {role: user, content: 从文本中抽取出发地、目的地和金额。文本从A地打车去B地花了35元。} ], temperature: 0.0, # 结构化任务固定为 0减少随机性 max_tokens: 256, # 限制输出长度防止模型生成解释文字 top_p: 0.9 # 核采样参数temperature 为 0 时影响较小 } req urllib.request.Request(endpoint, methodPOST) req.add_header(Content-Type, application/json; charsetutf-8) req.add_header(Authorization, Bearer YOUR_API_KEY) with urllib.request.urlopen(req, datajson.dumps(payload).encode(utf-8), timeout60) as resp: ret json.loads(resp.read().decode(utf-8)) content ret[choices][0][message][content] print(content)这里三个参数要重点说明。temperature 控制输出的随机性结构化任务里必须设成 0否则同样的输入可能得到不同的抽取结果。max_tokens 是生成长度上限不设或设太大模型可能输出一段“顺便给你解释一下”的文字破坏 JSON 解析。top_p 是核采样在其他参数不变时先固定 temperature 再调 top_p不要两个一起动。这个壳跑通之后下一步是加一层“输出校验”把返回的 content 用 json.loads 解析解析失败就触发重试或告警。我在项目里见过最多的问题不是模型答错而是模型返回了合法但缺少关键字段的 JSON所以校验要检查“字段是否存在”而不仅是“能不能解析”。4.3 成本估算模板先算 token再谈效果大模型方案的费用估算是落地前必须做的功课但很多人算错。常见做法是把“平均每次输入 token 数”和“平均每次输出 token 数”分别打点然后按调用量乘以一个系数。估算项公式示例输入 token 总量平均输入 token 数 × 日调用量 × 302000 × 1万 × 30输出 token 总量平均输出 token 数 × 日调用量 × 30300 × 1万 × 30重试余量单次失败重试率按 1.3 倍乘入总量缓存命中相同前缀请求会便宜无法给通值按服务商说明自行折算token 的粗略换算也很重要一个汉字约 1 到 2 个 token一个英文单词约 1 到 1.5 个 token。很多人估算时只算“用户输入的一句话”却把长文档、系统提示词、少量示例全部塞进上下文导致实际 token 数比预估高三四倍。所以埋点统计真实平均输入 token比花时间精调公式更有用。并发和带宽也需要提前估。单路推理的吞吐有限如果业务是用户实时交互要按“最大并发数 × 平均输出 token 数”估算出口带宽和延迟上限。这个数字会在压测时直接打脸早算早调架构。5. 避坑排查数据、训练、评测三处最容易翻车5.1 数据泄露测试集看起来很好上线就崩现象训练时的准确率很高测试集指标也漂亮一上真实业务就明显变差。原因最常见的是数据划分时没有隔离同一来源的样本。比如同一个用户的多条记录被随机分到了训练集和测试集模型实际上记住了用户特征而不是任务规律。时序数据直接随机划分也会造成“时间穿越”让模型提前看到了未来信息。解决划分之前先做实体级别去重。按用户 ID、设备 ID或文档 ID 进行分组同一个 ID 的所有样本只能出现在一个集合里。时序数据则严格按时间切分用前 80% 时间段的样本训练后 20% 测试。这个原则在视觉、文本和大模型微调场景里全部适用区别只是“按什么维度分组”由业务决定。5.2 训练 loss 降了验证集却越来越差现象train loss 持续下降val loss 先降后升说明模型开始死记硬背训练数据的细节泛化能力变差。原因模型容量大于数据量时训练轮数过多、学习率没做衰减都会让模型逐渐拟合训练数据里的噪声。解决把 train loss 和 val loss 画在同一张图里两个曲线分离的那一刻就是“早停点”。训练时保存验证集指标最好的那次参数而不是最后一轮的参数。另外验证集被你反复用来调参后它实际上已经变成了训练的一部分所以真正要保留一个从未参与调参的测试集只在最终阶段评估一次。5.3 榜单分数高业务却不达标现象公开评测基准上分数不错用在真实业务数据上效果打折甚至完全不可用。原因评测集的分布和业务分布不一致。公开基准可能以英语为主、场景干净、类别均衡而你的业务数据可能是口语化文本、遮挡严重的图像、类别分布极不均衡。此外评测集样本量太小指标方差很大分数差异没有统计意义。解决上线前先抽 100 条真实业务数据人工标注用同一个模型跑一遍单独看这份“业务小测试集”的指标。不要被大榜单的数字迷惑先做小样本的人工对齐再决定要不要投入更大成本。“先人后机器”的顺序不能反。5.4 大模型返回的 JSON 能解析但内容是编的现象字段格式都对键值也齐全但抽取出的实体在原文里根本不存在模型自己“脑补”了答案。原因temperature 设得过高给了模型发挥空间或任务所需知识不在上下文里模型在凭训练时的记忆补全或指令里没有明确“不确定时留空”。解决结构化抽取任务把 temperature 固定为 0把原文放进上下文并注明“只能从原文抽取”在 system 提示里加一句“如果原文没有该字段输出空字符串”。最关键的是加一层校验对抽取结果做“原文回查”抽取出的实体必须能在源文本里找到子串否则标为可疑样本进入人工抽查。这一条规则能挡掉大部分幻觉。5.5 成本估算翻车预算乘了三倍才发现现象项目上线一个月后账单比预算高出两三倍原因是实际输入 token 数远超预期。原因估算时只算了用户输入的一句话但系统提示词、历史会话、检索返回的参考文档全部进入上下文每轮请求的输入 token 被放大数倍。重试和失败请求也会重复计费没有预留余量。解决先加 token 埋点统计真实流量下平均输入和输出 token 数再乘以 1.3 倍的重试余量。如果业务里大量请求共用相同的系统提示词和文档前缀优先开启服务商的上下文缓存能显著降低成本。成本模型要在第一轮压测之后修订一次而不是上线后才发现。6. 从 PPT 到实战一周搭一个最小 AI 验证栈技术介绍看完最有效的行动是逼自己在七天内做一次“最小闭环验证”。我常用的是一个固定节奏先明确任务类型再卡评测指标然后跑通一个粗糙版本最后人工抽查决定要不要继续。天数动作产出D1写出任务定义输入什么、输出什么、给谁用一页纸说明不写技术方案D2准备 100 条最小验证集先看分布数据样例 标注规范草稿D3跑通一个粗糙基线哪怕用现成接口能出结果的最小管线D4调 3 个参数学习率/温度/上下文长度一组对比记录D5人工抽 50 条和自动指标对照人工评分表D6记录成本时间、标注量、token 消耗投入产出估算D7做决定继续深入 or 换方案 or 停止一页决策说明这个节奏的意义是七天结束你手里不是一个“想法”而是一条有数字验证的结论线。既不浪费大量标注成本也不会在错误方向上磨一个月。在验证阶段我常用一个极简的评估函数来兜住“我以为很好”的错觉def evaluate_predictions(preds, truths): 三个维度的最小评估正确、空输出、错误。preds 和 truths 都是字符串列表。 assert len(preds) len(truths) right, empty, wrong 0, 0, 0 for p, t in zip(preds, truths): p_norm, t_norm p.strip().lower(), t.strip().lower() if not p_norm: empty 1 # 模型没输出内容可能是截断或解析失败 elif p_norm t_norm: right 1 # 完全命中 else: wrong 1 # 有输出但与标注不一致 n len(preds) acc right / n print(f准确率: {acc:.2%}, 空输出: {empty / n:.2%}, 错误: {wrong / n:.2%}) return {acc: acc, empty: empty / n, wrong: wrong / n}不用花哨的指标先把“正确、空、错误”三分类看清楚。空输出比例超过 5%说明生成侧有截断或解析问题优先于准确率去排查。这三个数字能让你在任何汇报里都说得清“现在到底什么状态”。我现在的习惯是任何 AI 需求到手第一周不写任何模型代码先写一页任务定义和一百条验证集。这个习惯让我挡掉了不少看着像机会、实际上没数据的伪需求。希望帮到你。本文还有配套的精品资源点击获取