企业官网建设流程全解析

简介：这份北京大学 DeepSeek 系列研讨讲座 PDF，面向不具备专业 AI 或 IT 背景的学习者、初级 AIGC 应用者与关注大模型落地的从业者，试图纠正网络内容仅停留在工具操作层面的偏差。全包仅含 1 个 PDF 文件，约 16.61MB，内容围绕 DeepSeek-R1 的概念、优势与历史地位展开，并进一步拆解大模型与 AIGC 的底层工作机制。读者可从中理解推理模型与生成模型的差异、DeepSeek 低成本开源策略带来的行业影响，以及如何在众多 AI 工具中科学选择并高效使用。讲座还结合教育、科研、知识应用、文档分析等场景说明推理密集型任务的应用价值，并对多模态、通用模型、行业模型等术语作梳理。已有 210 人学习，适合希望突破工具应用局限、建立完整认知框架的读者系统阅读。

1. 推理模型真正的分水岭，不在参数规模，在「产出答案的路径」

同一道需要四五步推导的数学题，丢给一个普通对话模型，它几乎秒回，答案往往是错的；丢给一个推理模型，它会先沉默十几秒，屏幕上滚出一段自我拆解的推导，然后给出正确答案。很多人第一次用 DeepSeek-R1 时会以为这只是「回答更长、更啰嗦」，但真正反直觉的地方在于：这两类模型其实不是同一台机器的快慢版本，而是换了整套产出答案的机制。生成模型优化的是「下一个词该是什么」，推理模型优化的是「这条推理链能不能走通」。AIGC 工具用久了，如果只停留在提示词层面，很容易把「会说话」误当成「会推理」，在数学、代码、方案评审这类任务上反复翻车。这一篇不聊怎么注册、怎么写提示词，只把大模型与推理模型背后的底层机制拆开：为什么 CoT 能把错误暴露出来、强化学习在没有标准答案时怎么打分、蒸馏到底传了什么、又丢了多少东西。

2. 生成模型与推理模型：为什么「会说话」和「会推理」是两种机器

2.1 生成模型的本质：一个不断做下一词分类的自回归器

大语言模型（LLM）最朴素的描述是：给定前面所有词，预测下一个词的概率分布。把整句话拆成 token 序列，模型每一刻输出的是词表上几万个 token 的条件概率，按温度或贪心策略挑一个，拼回上下文，再预测下一个。它在结构上是个自回归分类器，损失函数就是一个交叉熵——没有任何显式的「逻辑」模块。

# 生成模型每一步在做的事（结构示意，非真实源码） logits = model(context_tokens) # 输出词表维度的打分 probs = softmax(logits / temperature) # 转成概率分布 next_token = sample(probs) # 采样或取 argmax context_tokens.append(next_token) # 拼回上下文，进入下一轮

参数说明：context_tokens是已生成的上下文，temperature控制随机性，越低越确定。关键点在循环条件——每一步只看「已写出来的词」，不会回头验证中间步骤对不对。这种机制让语言极其流畅，因为流畅本来就是它的优化目标；但一道要推理五步的题，它在第 1 步就定调，后面全在既有路径上做局部延伸，前面错一步，后面越写越像样却越错越远，这就是生成模型在复杂数学与逻辑题上准确率偏低的底层原因。

2.2 推理模型的转向：把隐式计算搬到 token 空间

推理模型的思路不是换一套网络结构，而是在训练和推理方式上换目标。它鼓励模型先输出一段「思考过程」，把原本发生在一个 token 内部的隐式计算，摊开成几十上百个中间 token，再在这些中间结论上继续往下算。思维链（CoT）是这条路线的方法名，强化学习（RL）则解决「模型凭什么愿意、并且正确地展开思考」的问题。

DeepSeek-R1 的定位在材料里写得很清楚：它属于推理模型，专注复杂推理与逻辑能力，擅长数学、编程和自然语言推理，在部分基准测试里准确率超过通用生成模型；代价是当前以文本输入为主，不具备图像等多模态能力，交互节奏也更慢。下表是根据材料对比维度整理出的差异，重点看「定位」和「推理能力」两行，它们直接决定了适用场景的分野。

2.3 推理模型的优劣势是同一套机制的两面

材料给推理模型列的优势是：演绎与归纳能力强（谜题、数学证明）、链式思维出色（善于分解多步骤问题）、擅长复杂决策、能呈现思考过程；劣势是：响应速度慢且计算成本高、基于知识的任务更容易出错（容易产生幻觉）、处理简单任务效率低（容易「过度思考」）。

这里最容易被误读的一条是「幻觉更容易出现」。很多人以为推理越强越可靠，实际上推理模型在知识类任务上并不必然更好。它擅长的是「有明确验证标准」的推理，一旦问题依赖大量隐性的世界知识，它会把自信的推理套用在不牢靠的前提上，错得反而更连贯。另一个常被忽视的点是「过度思考」：简单任务用一个需要生成大段思考的模型，既慢又可能把本来一句话能答的问题拆出不必要的分支，反而制造噪声。理解这两条，比记住它的跑分更重要。

3. 思维链 CoT：把「一步出答案」拆成「多步打分」，它到底改了什么

3.1 CoT 的机制：把计算从隐空间搬到可见 token

普通生成模型是「问题 token → 答案 token」的短路径，中间几乎没有可展开的空间。CoT 的作用是在问题与答案之间插入一段中间推理，让模型在生成最终答案之前，先把「已知什么、要求什么、先算什么、再验证什么」逐步写出来。机制上有两个变化：一是推理需要执行的计算被分摊到更多 token 上，每一步的输入都包含前面已经算出的中间结果；二是错误变得可见，某一步推错，后续步骤会建立在这个错误上，输出里的矛盾点更容易被人工或模型自己发现。

# CoT 的本质不是多写几句话，而是让每步结论成为下一步的条件 step1 = model("题目: ... 先列出已知条件") # 产出中间状态 step2 = model(step1 + "根据已知条件，第一步推导...") # 基于 step1 继续算 step3 = model(step2 + "验证上一步是否成立...") # 引入自检 answer = model(step3 + "综合以上，最终答案是...")

参数说明：这里的「+」表示把上一段中间输出拼进上下文，关键是后面的调用确实把前面结论当作前提，而不是重新独立回答。真实系统里这些步骤由模型在一次生成中连续产出，不是外部脚本串起来的；拆开只是为了说明条件依赖关系。这也是为什么 CoT 对「多步骤、可分解、每步有验证标准」的任务提升明显，而对需要一次性整体判断的任务帮助有限。

3.2 为什么「慢」反而更准：搜索宽度与自我纠正

推理模型答得准，不是因为它「想得更久」这个动作本身有魔力，而是因为展开思考给了它两条额外的路：一是探索多条候选路径，生成过程中可以自我否定、重走分支，相当于在答案空间里做了更宽的搜索；二是有了中间结论，模型可以在形成最终答案前做一次一致性检查。普通生成模型走的是贪心路线，第一个 token 定方向，后面很难掉头；推理模型把「掉头」的代价降低到了几个 token 的层面。

但这也解释了它的成本结构：思考 token 是要真实计算的，token 越多，显存、时延、费用越高。这就是材料里「响应速度慢且计算成本高」的来源，不是工程没优化好，而是机制决定的固有开销。AIGC 应用里把它当作「默认模型」无差别调用，账单和等待时间都会让人后悔。

3.3 过度思考的边界：什么时候不该上推理模型

过度思考不是模型「想太多」，而是任务本身不需要那么多分支，模型却按高难度任务的策略展开。典型场景是：分类、抽取、格式转换、简单问答、模板化文案。这些任务用推理模型，输出里会多出大量与最终答案无关的中间推导，既拖慢响应，也增加了出错面——中间某一步走偏，最终结论反而被带歪。

一个实用的判断法是看任务有没有「可分解、可验证的中间步骤」。数学证明、代码调试、复杂方案评审有，适合推理模型；把一段话改写成另一种语气、从简历里抽字段，没有，生成模型更快更稳。材料把这条写成「处理简单任务时效率低」，背后其实是同一套机制在不同任务分布上的收益差异。

4. 强化学习与蒸馏：R1 怎么自我训练，小模型又继承了什么

4.1 强化学习：没有标准答案时，奖励从哪来

CoT 能让模型展开思考，但光靠提示「请一步步想」并不足以稳定产出高质量推理链。强化学习的作用是让模型在大量题目上自己试、自己得分、自己调整策略，逐渐学会「什么样的思考路径更容易通向正确答案」。难点在于奖励信号怎么设计：开放式任务的「好答案」很难自动判定，所以常见的做法是优先选那些结果可验证的任务——数学题能对答案，代码题能跑测试用例，逻辑题能检查最终结论。奖励不需要理解过程，只需要判断终点对不对。

# 训练奖励的常见结构（概念示意） reward = 0 if final_answer == ground_truth: reward += 1.0 # 终点正确 if code_passes_all_tests: reward += 1.0 # 代码跑通 if format_matches_expected: reward += 0.1 # 格式约束 # 组内相对比较：同一题的多条采样里，好的相对加分，差的相对减分

参数说明：这里的奖励由结果侧规则给出，不依赖人工逐条标注；格式奖励只是辅助，防止模型用奇怪格式绕过评测。这种「结果可验证 + 组内相对比较」的思路，是推理模型能在没有海量人工标注的情况下自我提升的关键。它训练的是「探索出正确路径的概率」，而不是「记住某道题的答案」。也正因为奖励依赖可验证性，模型在数学、代码上进步快，在主观性强、没有明确判据的任务上提升就有限。

4.2 蒸馏：大模型的能力怎么「压缩」到小模型

蒸馏要解决的问题很实际：大模型推理能力强，但部署成本高，能不能让小模型也具备类似的推理表现。常见做法是先把大模型在大量题目上生成的思考过程和答案收集起来，作为训练数据去微调小模型。小模型学的不是「参数变多」，而是「遇到这类问题该按什么格式展开、沿什么路径推导、在哪里做验证」。

# 蒸馏的数据形态（概念示意） { "question": "...", "reasoning_chain": "先...再...验证...", # 教师模型产出的思考过程 "final_answer": "..." } # 小模型以 question 为输入，同时拟合 reasoning_chain 与 final_answer 的分布

参数说明：reasoning_chain是教师模型的输出，小模型通过监督学习去模仿它的生成分布。这里最关键的取舍是：蒸馏传递的是「结果分布 + 表达格式」，而不是「探索能力」。教师模型在训练中通过 RL 学到的「遇到没见过的难题怎么试错」，很难被静态数据完整传递。所以蒸馏后的小模型在同分布题目上表现接近，在分布外的新题上往往仍明显弱于教师模型。材料把蒸馏描述为「在不损失能力的情况下缩小模型」，工程上更准确的理解是「在目标分布上尽量少损失」，而不是无条件等价。

4.3 蒸馏的失效边界：什么情况下小模型会露馅

判断蒸馏模型能不能替代大模型，看三个条件是否同时成立：任务类型是否与蒸馏数据分布接近、问题难度是否落在教师模型能稳定解出的区间、对延迟和成本的约束是否真的那么紧。三者有一个不满足，替换就可能翻车。常见的误判是把「在评测集上接近」当成「在所有任务上接近」，实际业务里的长尾问题恰恰是蒸馏最容易丢的部分。这一点在下面的避坑章节会具体展开。

5. 避坑与常见问题：误用推理模型的五类翻车现场

5.1 把推理模型当万能生成器

现象：所有请求都走推理模型，结果批量文案、字段抽取这类任务响应时间翻了几倍，偶尔输出里还夹着与结果无关的推导段落。

原因：推理模型的机制决定了它默认展开思考，任务越简单，这部分开销越是纯浪费，而且中间推导可能引入额外偏差。

解决：按任务分层路由。需要多步推导、结果可验证的任务走推理模型；格式转换、简单问答、模板生成走生成模型。路由规则写进调用层，而不是靠每次人工判断。

5.2 相信「思考过程」就是真实推理

现象：模型展示了看似严密的推导，人工检查却发现某一步是编造的，最终答案恰好凑对或恰好凑错。

原因：思考过程本身也是模型生成的文本，它优化的是「看起来合理且通向答案」，不保证每一步都对应真实计算。展示思考提升的是可检查性，不是正确性保证。

解决：把思考过程当作调试线索而不是证据。对关键结论做外部验证——数学题代回检验，代码跑测试，事实类断言交叉比对来源。越是看起来流畅的推理，越要多看一眼中间步骤。

5.3 小模型蒸馏后无脑替换大模型

现象：用蒸馏后的小模型替换大模型，评测集分数接近，上线后长尾问题错误率明显上升。

原因：蒸馏传递的是目标分布上的表现，分布外的探索能力没有完整继承；评测集往往覆盖不到真实业务的长尾。

解决：替换前先构造一批贴近真实业务、且包含边界情况的自建测试集，对比小模型与教师模型的差距，尤其是最难的 10% 样本。差距可接受再替换，并保留回退到教师模型的开关。

5.4 忽视成本与延迟的结构性来源

现象：推理模型接入后，账单和平均响应时间同时上涨，团队以为是「用得多」，其实是用得不对。

原因：成本与时延主要来自思考 token 的数量，而思考 token 的数量又由任务难度和模型策略决定。任务简单却走推理模型，等于为不需要的计算付费。

解决：监控每次请求的思考 token 占比，对简单任务设置更短的思考预算或直接路由到生成模型；对确实需要长推理的任务接受其成本，但把它限制在明确的高价值场景里。

5.5 幻觉治理停留在「让它别乱说」

现象：在提示里反复强调「不要编造」，模型照样在知识类问题上给出自信的错误答案。

原因：推理模型的强项是有验证标准的推理，知识类任务并不天然更可靠；提示层面的约束改变不了「它没有可靠知识来源」这个事实。

解决：把幻觉治理从提示层移到系统层——关键事实走检索增强，把来源一起返回；对无法验证的断言做标注；对高风险场景引入人工复核。与其指望模型「更诚实」，不如让流程在它出错时能兜住。

提示：以上五条的共同点是，问题都不出在模型「不够强」，而出在把推理模型放进了不匹配的任务与流程里。判断标准始终是任务结构，而不是跑分高低。

6. 设计取舍：低成本开源路线真正改变的是什么，怎么验证

把 DeepSeek-R1 这条路线放在行业里看，材料给出的判断是它打破了「堆算力、拼资本」的路径，以低成本和开源策略让推理能力进入第一梯队，同时把 API 定价压到行业均价的一个很低比例，推动中小企业低成本接入。这些是结论，真正值得琢磨的是背后的取舍：它没有走「更大参数 + 更多模态」的通用路线，而是把资源集中在「可验证推理」这一条窄赛道上，用结果侧的奖励信号替代海量人工标注，再用蒸馏把能力扩散到更小的模型。代价也很清楚——多模态能力弱、知识类任务不占优、简单任务效率低、交互节奏慢。换句话说，它不是全面更强的模型，而是「在特定任务结构上性价比极高」的模型。

怎么验证这一点，比记住结论有用。我一般的做法是准备三类自建样本：一类是明确可验证的多步推理题（数学、代码、逻辑），一类是知识密集型问答，一类是简单格式任务。同一批样本同时跑生成模型和推理模型，分别记录正确率、思考 token 占比、端到端时延。跑完通常会发现一个很稳定的模式：第一类推理模型明显领先，第二类两者接近甚至生成模型更稳，第三类推理模型纯亏。这个模式一旦在自己业务的数据上复现，路由策略就不用再拍脑袋了。

那次把推理模型无差别接进一个内容处理流程，是我印象最深的一次踩坑：账单先涨、时延后涨，团队一开始还在怀疑是不是并发没配好，最后拉出思考 token 分布才看明白，八成请求根本不需要推理。从那以后我每次接入新模型，都强制先跑一遍这三类样本的路由验证，再决定哪些流量给谁。希望这套拆法能帮你在自己的场景里少交点学费——这份研讨材料里关于 R1 机制、AIGC 能力与工具选择的部分，配合自建样本一起看，会比只看跑分更能落地。

本文还有配套的精品资源，点击获取