简介：厦大林子雨副教授团队出品的大模型科普课件，面向想快速建立大模型认知框架的教师、学生及技术爱好者，系统讲解大模型概念、技术原理与行业应用实践。压缩包仅含1个可编辑pptx文件，约61.03MB，内容覆盖人工智能发展简史、人工智能思维、大模型核心技术、AIGC应用与实践等章节，具体包含图灵测试、GPT系列参数对比、大模型原理与分类、智能体与本地部署等可操作知识点。该团队长期专注大数据教学，累计出版15本系列教材，被国内1000余所高校采用，课件延续了其教学沉淀，适合教学备课、通识讲座或自学科普。目前已有148人学习下载，建议有需要的读者抓紧收藏。
1. 大模型不是更大的模型，而是一套新的软件栈
大模型这个词，这两年已经被聊烂了，但真正动手绕过一遍的人并不多。我第一次把某个开源大模型跑起来时，第一反应不是“好强大”，而是“原来我根本不会用”。它不像传统软件那样装好就能点按钮，它需要你重新理解输入输出、理解上下文、理解推理成本，甚至要习惯它的“黑匣子”属性——很多效果上的好坏，强靠经验和实验堆出来，掺杂着大量玄学。
这篇文章会把某高校团队那份广为流传的大模型综述拆开揉碎，从概念到技术再到应用，按一线从业者的视角重新讲一遍。适合两类人：一类是刚被安排做 AI 落地、连 API 都还没调过的同学；另一类是自己练过几个模型、但总觉得效果不稳、不知道怎么往业务里接的熟手。看完你会知道大模型“能做什么、怎么做、坑在哪”，也能照着文里的步骤，自己搭出第一个可演示的应用。
2. 概念层：大模型到底“大”在哪，先别急着谈效果
2.1 参数量只是表象：真正变化的是学习方式
很多教程开篇就堆参数量，动辄千亿万亿，听着吓人。但对做应用的人来说，参数量是最不需要关心的数字——你又不会自己去训练一个千亿模型。真正要理解的是“学习方式变了”：传统模型是“针对某个任务专门学”，大模型是“先看海量文本学通识，再用对话方式适配任务”。
这个转变带来三个直接影响。第一，原来做 NLP 要按任务造特征、选模型、调参，现在大部分任务可以统一表述成“给模型一段文本，让它接着写”。第二，大模型具备很强的少样本能力，给它几个例子它就能照猫画虎，不再需要为每个任务单独跑一遍训练流程。第三，模型的能力边界不再只靠算法，还靠“怎么问”，同样的模型，提示词写得好不好，效果天花板可以差出一大截。
所以我的建议是：先别纠结参数量和结构细节，先建立“大模型 = 一个超强文本续写器 + 一套对话协议”的心智模型，后面看技术才看得懂。
2.2 涌现能力与幻觉：同一枚硬币的两面
大模型被吹得最神的“涌现能力”——模型大到一定程度，突然会做没专门训练过的任务，比如写代码、做数学推理——本质上是模型在超大规模语料里学到了“规律分布”，它不是在思考，是在按概率补全最合理的下文。
这个机制也解释了大模型最让人头疼的问题：幻觉。因为它是在做概率预测，不是查数据库，所以它会在信息不足时一本正经地编造答案。我在实际用的时候踩过不少坑，最典型的是让它总结某个内部系统的文档，它把文件里根本没有的功能写得像模像样，仔细核对才发现全是“合理推测”。
理解了这个，就不会对模型产生不切实际的期待。它适合做生成、改写、提炼、辅助决策，不适合直接当事实数据库用。凡是输出要落库、要走流程、要对外发布的场景，必须加“人工审核环”或者“知识库约束”，这个后面应用章节会細讲。
2.3 三种使用姿态：调用 API、开源部署、微调
我把大模型的使用方式归纳成三种姿态，想清楚自己属于哪种，能少走很多弯路。
第一种是调用在线 API。最省事，按量付费，适合快速验证想法，或者业务对数据合规要求不高的场景。缺点是数据要出网，单次成本随调用量线性上涨，而且模型升级由服务方说了算，你没法锁版本。
第二种是部署开源模型。把模型下载到自己的服务器上跑，数据不出内网，长期成本可控。但前期要买卡、搭环境、配推理框架，门槛高不少。
第三种是开源模型加微调。在部署的基础上，用自己的数据调整模型行为，效果上限最高，但技术栈最长，需要数据清洗、训练脚本、评估流程，时间成本按周算。
这三种不互斥。我的习惯是：先用 API 验证业务逻辑对不对，再评估用量和数据敏感度决定要不要部署开源模型，最后只在效果确实不够时做微调。别一上来就微调——你大概率还没搞清楚瓶颈到底在模型还是在你自己的提示词上。
3. 技术层：从 Transformer 到预训练，应用者需要知道的原理
3.1 自注意力？不需要会推公式，但要懂它的脾气
很多资料花大篇幅讲自注意力机制的公式推导，对做应用的人来说意义不大，但有几件事得知道，否则调试模型时会抓瞎。
第一，自注意力让模型能看到上下文里所有词之间的关系，所以它能理解指代、长距离依赖。这也是为什么大模型比老式 LSTM 更“懂事”。第二，计算开销是序列长度的平方级增长，所以上下文越长，推理越慢、越贵。这就是为什么你问一个超长文档，回答时间会明显变长。第三，注意力是概率分配，不是规则匹配，所以同样的输入，两次输出可能不同——这不是 bug，是模型本性。做应用时要靠温度参数和固定随机种子来平衡确定性。
3.2 预训练、指令微调、对齐：三个阶段的调试意义
正式的大模型流程分三步：预训练在海量文本上学会语言规律，指令微调学会“听指令”的对话模式，对齐阶段学会符合人类偏好。对应用者来说，理解这三个阶段很重要，直接决定了“你拿到手的模型肚子里装的是什么”。
预训练决定了“它懂多少”，既是知识量的来源，也是幻觉的根源——知识是统计来的，不是记忆得来的。指令微调决定了“它听不听话”，同样一批知识，微调做得好不好，直接决定你提问时它是给有用回答还是废话连篇。对齐阶段决定了“它的输出安全不可用”，这层做不好的模型容易答非所问或者埋雷。
所以选模型时，别光看参数和榜单分。同一个底座，不同团队发布的指令微调版本，实际体验可能天差地别。我一般会先拿任务里最刁钻的 20 个问题去问候选模型，对比输出质量再下结论，榜单分数只能参考。
3.3 上下文窗口与关键参数：做应用之前先搞懂这几个旋钮
上下文窗口是模型一次能处理的文本总量，比如 4K、32K、128K。它不是越大越好，越大越贵越慢。实际经验是，优先想办法精简输入，而不是无脑上长窗口。另一个关键参数是温度，越高输出越发散，越低越保守。做代码生成我会调低到 0.2 以下，做创意文案可以拉到 0.8 左右。
还有个常被忽略的 top_p，它控制候选词的概率累积范围，刚入门可以直接保持默认，但要知道它的存在。最后是 max tokens，决定单次回复长度上限。我看到很多人调了半天 prompt 没效果，最后发现是 max tokens 设太短，工具链被截断了。这种问题很初级，但频率极高。
3.4 选型维度：能力、成本、开源的三角取舍
选型没有统一答案，但有统一的判断框架。我一般按三个维度打表：能力维度看它在你的任务场景下的实际表现；成本维度看单次调用价格或硬件折旧分摊；工程维度看部署难度、生态成熟度、周边工具链。
举个例子。内部知识库问答这种场景，中文能力、检索增强配合度、部署成本是核心，那么开源模型配合向量数据库是常见做法。又比如高并发低延时的文本分类，那么在线 API 加缓存就是更务实的方案。千万别为了“自主可控”非要自己部署，结果运维成本和稳定性问题吞掉所有收益。选型是一个动态决策，不是一劳永逸的信念。
4. 应用层：把大模型接进业务的三条实操路径
4.1 路径一：用 API 做概念验证，最快跑通闭环
我先给一段最基础的概念验证代码，基于 OpenAI 兼容接口，用 Python 调用一个大模型 API 完一个文档总结任务。整个过程只需要一个 API Key 和 requests 库就能跑通。
import requests import json # 配置 API 地址和密钥 api_url = "https://your-api-endpoint/v1/chat/completions" api_key = "sk-your-key" # 准备请求头 headers = { "Content-Type": "application/json", "Authorization": f"Bearer {api_key}" } # 构造请求体 payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个严谨的技术文档助手，用不超过200字总结下面的文档。"}, {"role": "user", "content": "文档内容：大模型在政务场景中的应用，涉及智能问答、公文辅助写作、政策解读等方向。"} ], "temperature": 0.3 } # 发送请求 resp = requests.post(api_url, headers=headers, json=payload, timeout=60) result = resp.json() # 输出模型回复 print(result["choices"][0]["message"]["content"])这段代码的逻辑很直白：拼一个 HTTP 请求，把系统指令和用户内容组装成 messages 数组发给模型，等它返回结果再解析。关键在 temperature 调成 0.3，保证总结任务输出相对收敛，不会漫无天际。timeout 设成 60 秒是给长文本留足够时间，但你要知道，文档越长耗时越久，等到了生产环境就要用异步方案替代同步请求。
到了生产环境，代码跑通只是第一步，还要做三件事：限流、缓存、监控。限流防止瞬间爆量把预算打穿；缓存让相同请求直接复用结果，能省 40% 以上的成本；监控里最核心的是“平均首字延迟”和“单次请求成本”，这两个指标直接决定用户体验和费用边界。
4.2 路径二：本地部署开源模型，数据不出网的底线方案
数据敏感的场景下，部署开源模型是最稳妥的选择。我给出一个基于 Ollama 拉取并运行开源模型的示例命令，这是目前上手成本最低的方式，适合首次接触部署的开发者。
# 拉取一个适合中文场景的开源对话模型 ollama pull qwen2.5:7b # 启动带 API 服务的模型，指定端口 ollama run qwen2.5:7b --port 11434 # 用 curl 测试本地模型接口 curl -X POST http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "介绍一下大模型的基本概念"}] }'选 qwen2.5:7b 的原因很实际：中文能力强，7B 规模在消费级显卡上能跑，生态成熟。端口 11434 是默认值，实际部署时建议改成不常见端口并加防火墙白名单。跑起来的瞬时内存占用大概是模型体积的两倍左右，7B 量化版本约 5GB 磁盘，推理时要留约 10GB 内存，这些都要提前规划好。
但 Ollama 更适合个人实验。生产级部署我会换成 vLLM 或类似推理框架，用起来能拿到更高的吞吐量。核心参数是--max-model-len和--gpu-memory-utilization，这两个直接决定你能塞多大 batch、多少并发，没有统一值，按你显存大小试两到三轮再定。
4.3 路径三：检索增强生成，让模型不乱说话的架构级改造
大模型的幻觉问题在需要事实准确性的场景里不可接受，这时就要上检索增强生成（RAG）。它把问题变成三步：把文档切块并向量化存入向量数据库，用户提问时先做相似度检索找出最相关的内容块，再把“检索结果 + 原始问题”一起交给大模型生成答案。架构上就四个组件：文档加载器、切片器、向量库、生成模型。
我这里给一个基于 SentenceTransformer 和 ChromaDB 的最小实现，代码不长，但完整覆盖了从建库到查询的主流程。
from sentence_transformers import SentenceTransformer import chromadb from chromadb.utils import embedding_functions # 1. 初始化嵌入模型和向量库 embedder = SentenceTransformer("BAAI/bge-small-zh-v1.5") client = chromadb.Client() collection = client.create_collection( name="knowledge_base", embedding_function=embedding_functions.SentenceTransformerEmbeddingFunction( model_name="BAAI/bge-small-zh-v1.5" ) ) # 2. 将文档切片并写入向量库 chunks = ["大模型的训练成本主要由算力和数据决定", "检索增强生成能显著降低幻觉率"] for idx, chunk in enumerate(chunks): collection.add( documents=[chunk], ids=[f"chunk_{idx}"] ) # 3. 查询阶段：向量检索 + 组装 prompt query = "如何降低大模型的幻觉率" results = collection.query(query_texts=[query], n_results=1) context = results["documents"][0][0] prompt = f"请根据以下资料回答问题：\n{context}\n\n问题：{query}" print(prompt)这段代码验证了 RAG 的核心——把“直接问模型”换成“先查资料再让模型回答”。嵌入模型选了 bge-small-zh 是因为中文效果好且体积小，换成别的中文嵌入模型也完全可以。建库时真正要调的是切片大小和重叠，切片太大，检索粒度粗，回答容易答非所问；太小则上下文碎片化，模型理解不了全貌。我的经验是 200 到 500 字之间起步，文档段落结构清晰的场景可以按段落切。
实际工程里检索这步还要做重排，因为向量召回的相关性并不完全符合业务诉求。加了重排会让代码复杂度上一个台阶，但对效果是质的提升。如果业务对准确率要求很高，这步建议不要省。
5. 避坑：大模型应用落地最常见的 5 个翻车场景
5.1 翻车场景一：提示词写得太抽象，模型输出完全失控
现象是同样的任务，别人写的提示词效果很好，自己写的却驴头不对马嘴。最常见的问题是只告诉模型“不要做什么”，没告诉它“要怎么做、按什么格式做”。
解决方法是把提示词当成写给实习生的任务说明书：给角色、给步骤、给输出格式、给示例。我有一次让模型改写一段产品文案，只写了“润色一下”，结果它给我整出一篇散文。后来改成“你是产品经理，用不超过 80 字，按卖点、适用场景、行动号召三段式输出”，效果立刻正常。提示词是成本最低、收益最高的调优手段，值得反复迭代。
5.2 翻车场景二：上下文过长导致推理效果骤降
现象是把整本手册塞进上下文，希望模型“理解全部再回答”，结果模型的回答前言不搭后语，而且响应时间暴涨。
原因是自注意力的计算复杂度是输入长度的平方级，不是线性级。上下文越长，模型对早期内容的“关注力”就越容易被稀释，表现为回答忽视前置限定条件。
解决思路是分层召回：先用检索圈出相关片段，再把完整章节留给需要深度理解的场景。另外设合理的 max tokens，别让模型在超长输出上自行发挥。还有个实用小技巧：把最关键的用户指令放在用户消息的最前面或最后面，这两个位置模型注意力相对更强。
5.3 翻车场景三：显存不足问题频发
现象是模型卡在“CUDA out of memory”，或者刚开始推理正常，跑了一会儿内存溢出。最常见原因是直接用默认参数加载模型没有做量化，也有可能是并发请求超出显存承载能力。
我的做法分三步。先量化，7B 模型从 FP16 压到 INT4，显存占用大概减半，性能损失在可接受范围。再限制并发，用合理的批处理框架而不是裸模型接请求。最后按峰值预留显存——不是按单个请求算，而是按最大并发请求数乘单请求占用再乘安全系数。机上跑，配额算好再上生产。
5.4 翻车场景四：接口返回值与预期不符
现象是 API 调用退到非 200 状态码，或者返回了正常状态码但解析到的字段是 null，代码直接抛异常。
这类问题调试效率高，关键在于看响应体里的错误信息。授权失败大多能在错误里看到“401”和密钥提示；频率超限有“rate limit”字样，需要加重试逻辑；字段为 null 往往在choices为空数组或message里的 content 为空，原因多为 max tokens 太小导致回复被截断。
我的应对是：在代码里加专门的错误分类函数，对鉴权、限流、长度三类错误做不同处理。另外写成“消费方要容忍失败”而不是“接口永远成功”，这是所有 AI 应用的常识，但很多人第一次接入时根本没有这个心理预设。
5.5 翻车场景五：微调反而让通用能力倒退
现象是拿小批量业务数据微调之后，业务上的问题改善不大，但模型的通用能力明显变差，问什么都有点呆。
原因是对微调的定位理解错了，以为微调是万能药。实际上微调改的是行为模式，不是知识注入。想让模型懂业务知识，正确手段是 RAG，把知识放在外面检索进来；想让模型按业务口径回答，才是微调的用途。另外一个高频误区是微调数据量太少，不足百条就期望有质变——建议至少准备几百条高质量样本，而且样本质量必须严格把关，几条例外样本就足以带偏整个模型的行为。
6. 进阶：评估、优化与交付，把“能跑”变成“能用”
做工程和做 Demo 最大的区别在于，Demo 只需要“看起来对”，工程需要“持续稳定地对”。这一章给出三个进阶动作：搭建效果评估集、延迟与成本优化、以及可观测的交付思维。
评估集是 AI 项目的生命线。我不建议裸凭感觉判断模型好坏，而是准备 50 到 100 条覆盖典型场景的问答对。每条要有标准答案或评分标准。每次调整提示词、换模型、改参数，都跑一遍这个集合并记录得分变化。没有评估集，你就永远在做“这次效果好像变好/变差了”的模糊判断。评估可以把玄学变成可追溯的工程过程。
延迟和成本优化到最后是要一起看的。延迟上，重点是开流式输出，用户感知到的首字时间是决定体感的关键，实测开流式后首字感知能快 2 到 3 倍。成本上，核心是缓存命中率。高频重复请求加上缓存，能让成本下降 40% 以上。模型输入侧也要控制冗余——每次调用前做一遍内容压缩，去广告、去签名、去无关段落，既是省 token 也能降低噪声提高效果。
交付思维上，我一般会在系统里至少埋四个指标：调用成功率、单次响应耗时、平均 token 消耗、异常率。这组指标加上告警，能让团队在模型服务异常时第一时间发现。我们之前踩过一个大坑：接口一切正常，但模型悄悄变成了重复机械应答模式，是用户投诉后我们才发现的。之后我养成了“每天翻一翻最近 50 条对话抽样”的习惯，效果类问题还是要靠人眼盯一段。希望这些经验帮到你，也祝你的大模型项目少踩坑、早落地。
本文还有配套的精品资源，点击获取
