简介这是一份系统梳理大型语言模型知识体系的专题PDF指南面向希望快速理解大模型的产品经理、技术决策者、算法工程师及进阶学习者。内容从基础概念入手解释模型定义与Transformer架构原理拆解预训练、微调、上下文学习、零样本、单样本与少样本学习等关键技术路线随后梳理BLOOM、Cohere、GLM-130B等主流开源模型并结合文本摘要、机器翻译、情感分析、内容创作、聊天机器人、命名实体识别、代码生成等典型应用场景说明每类任务的落地思路。同时资源也提炼了训练过程中的资源消耗问题以及模型在可靠性、偏见、上下文窗口和系统成本等方面的现实挑战。整份资料为单个PDF文件资源包大小仅660KB便于快速浏览与知识框架搭建目前已有896人学习下载适合作为入门大模型、了解商业化机会与边界的系统参考资料。1. LLM 是什么2023 年为什么绕不开这个概念2023 年你搜“大型语言模型”大概率会遇见两类内容一类是论文翻译稿从 Transformer 架构讲到归一化层读完还是不知道怎么把它接进自己的服务另一类是工具列表把 LangChain、AutoGPT、向量数据库铺了一屏照着跑完 demo 一换业务场景就崩。这篇文想补齐中间那段2023 年这个节点上大模型 LLM 的工作原理、选型依据、部署命令和调优手段分别是什么以及它们之间的因果关系。适合两类人刚接手 LLM 相关项目的后端开发者和需要给团队做技术选型评估的架构师。读完你能回答一个问题一个业务到底该用 API、开源权重还是干脆别用 LLM。2. LLM 原理拆解token 化、自回归与 Temperature 的作用机制2.1 从统计语言模型到自回归 Transformer生成本质上是在“猜下一个词”2023 年以前很多研发对语言模型的印象还停留在 N-gram 或者 LSTM给一个词预测下一个词效果差得没法用。LLM 的变化不是换了个目标函数而是把“猜下一个词”这件事做到了足够大、足够深。GPT 系列和 Llama 系列都遵循同一套范式把文本切成 token编码成向量经过几十层 Transformer 块做注意力计算最后输出一个词表大小的概率分布从分布里采样出下一个 token再拼回去继续生成。这个过程叫自回归生成也叫 next-token prediction。理解这个机制对排查问题很重要。你看到的“答非所问”“前后矛盾”“重复输出”本质上都发生在概率采样环节而不是模型“不懂”。模型不是先想好答案再写出来而是一个词一个词地往前滚前面生成的 token 会重新进入输入影响后续生成。所以上下文一旦被截断、被污染或者采样参数设得不合适输出质量就会断崖式下跌。2023 年的另一个关键变化是 scale 定律被验证了参数量、训练数据量、计算量同时放大时模型能力会平滑提升但推理成本也线性增长。这也直接导致了闭源 API 和开源权重两条路线分化后面选型章会细说。这里只需要记住一个结论token 是 LLM 处理文本的最小单位既不是字符也不是词“上下文窗口能装多少 token”直接决定了你能让它同时看到多少信息。2.2 用 transformers 在本地跑通一次最小生成理论落地最快的方式是本地跑一次生成。2023 年最常用的库是 Hugging Face 的 transformers最小代码如下from transformers import AutoTokenizer, AutoModelForCausalLM # 加载 7B 规模的因果语言模型首次运行会自动下载权重 model_name meta-llama/Llama-2-7b-hf tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, device_mapauto, # 自动分配到 GPU/CPU torch_dtypeauto, # 按硬件自动选择 fp16/bf16 ) prompt LangChain 的主要作用是 inputs tokenizer(prompt, return_tensorspt).to(model.device) # token 化 outputs model.generate( **inputs, max_new_tokens64, # 新生成的 token 数上限不是总长度 do_sampleTrue, # 开启随机采样False 则退化为贪心解码 temperature0.7, # 控制概率分布的尖锐程度 top_p0.9, # 累积概率截断只从高概率 token 里采样 ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这里每个参数都对应前面说的自回归过程。max_new_tokens控制生成长度如果你只给了 64那么无论上下文多长模型最多只能新写 64 个 token超出部分直接截断业务上表现为“回答到一半没了”。do_sampleTrue表示按概率随机采样否则模型每次都挑概率最高的 token输出会显得机械重复。temperature 和 top_p 是控制“随机程度”的关键下面单独讲。2.3 Temperature 到底怎么影响输出一张参数表说清关于 temperature 有一个常见误解调高它就等于“更有创意”。准确地说temperature 是在 softmax 之前对 logits 做缩放。设原始 logits 为 ztemperature 为 T则输入 softmax 的值是 z/T。T 小于 1 时概率分布变得更尖锐高概率 token 的胜出更明显T 大于 1 时分布变平滑低概率 token 更容易被采到。它不是逻辑开关而是连续调节器。参数作用常见范围调大效果调小效果temperature缩放 logits改变采样随机性0.1–1.0更发散词面更丰富易跑题更保守重复率升高top_p只从累积概率占比 p 的 token 中采样0.8–0.95候选集变大内容更跳跃候选集变小更稳但单调max_new_tokens限制新生成 token 数视任务 64–2048回答更长成本更高截断风险上升frequency_penalty对重复 token 施加惩罚0–1.0减少复读对话更有推进感容易陷入重复循环提示temperature 和 top_p 通常会同时设但调试时一次只改一个。先固定 top_p0.9调 temperature稳定不了再动 top_p。两个同时乱调你很难判断输出漂移到底是谁造成的。3. LLM 选型与本地部署开源权重、量化与 API 怎么搭配3.1 2023 年的选型全景闭源 API 与开源权重各解决什么问题2023 年初的选择还很少GPT-4 和 Claude 基本是闭源 API 的代名词年中 Llama 2 开放商用后Mistral 7B、Falcon 40B 一批开源权重陆续出现本地部署才真正走进生产场景。选 API 还是选开源权重我一般用三个条件判断数据能不能出域、单位有没有现成 GPU、对单次推理延迟的容忍度。维度闭源 API开源权重数据隐私数据要发给第三方涉密场景慎用完全在本机或内网初始成本按 token 计费规模大后很贵买卡一次性投入模型能力上限当时最强多模态、长上下文领先受参数规模限制迭代速度无需运维官方升级自己跟新版本、重新部署可控性prompt 可能被服务方策略限制采样参数、系统提示词完全可控还有一个容易忽略的点闭源 API 的限制往往在服务端。2023 年很多人踩过同一类坑——在本地测试时 prompt 带过滤词没问题换到 API 上返回了拒答内容这不是你的代码问题而是服务方策略。如果业务对响应内容有强合规要求开源权重反而是更可控的选择。3.2 用 Ollama 拉起一个 7B 模型的最小命令如果只是先跑通验证不一定要直接上 transformers。Ollama 在 2023 年下半年开始流行它把模型权重、量化、推理服务打包成一套命令行工具适合快速原型和资源有限的机器。最小操作是四步# 1. 拉取量化后的 Llama 2 7B 权重 ollama pull llama2:7b # 2. 进入交互式会话 ollama run llama2:7b # 3. 单次调用适合脚本里测试 ollama run llama2:7b 用三句话解释什么是 RAG # 4. 带采样参数的调用 ollama run llama2:7b --temperature 0.2 --num-predict 256 列出 SQL 优化的五个方向pull拉下来的是已经量化好的权重默认 Q4_0 左右的精度7B 模型大约占 4GB 磁盘。run后的参数与 transformers 里的概念一一对应--num-predict对应max_new_tokens--temperature对应采样温度。这套命令足够让你在一个没有 GPU 的笔记本上快速验证模型效果但它不适合高频生产调用因为每次启动模型都会重新加载进内存。3.3 量化与显存估算到底要买多大的卡2023 年最常见的部署问题是“7B 模型到底要多大显存”。先说结论7B 模型用 FP16 权重大约占 14GB 显存再加上推理时的激活值和 KV cache实际建议准备 16–20GB用 4bit 量化后权重约 4GB但 KV cache 依然会额外占用完整跑起来 8GB 显存的卡也能凑合。模型规模FP16 权重4bit 量化权重推理时建议显存7B约 14GB约 4GB16GB / 8GB13B约 26GB约 7GB32GB / 16GB70B约 140GB约 35GB多卡 80GB×2命在这里特别提醒KV cache 的大小随输入和输出长度动态变化长上下文场景下它可能比权重还占显存。所以“量化后模型能装下”不等于“跑得动”。验证方法是把max_new_tokens和上下文长度一起测用nvidia-smi观察显存峰值而不是只看模型文件大小。4. LLM 实战Prompt 工程、上下文窗口与 JSON 输出稳定化4.1 写 Prompt 的三个层次指令、few-shot 与思维链很多人把 prompt 工程理解为“把话说清楚”其实它有三个递进层次每个层次解决的问题不同。第一层是直接指令适合模型能力本身足够强的任务比如“把这段文本翻译成英文”。第二层是 few-shot给模型两三个输入输出范例让它学会格式和风格适合抽出关键词、打标签这类需要固定输出的任务。第三层是思维链要求模型给出推理步骤。# 直接指令 请判断下面评论的情感是正面还是负面。 评论这家店上菜太慢了。 输出 # few-shot 示例 评论性价比很高下次还来。 - 正面 评论等了一个小时没上菜。 - 负面 请判断服务员态度很差。 - # 思维链 请一步一步推理然后判断这句话是否包含歧视性内容最后输出“是”或“否”。思维链在 2023 年被验证能显著提升复杂推理任务的准确率但它会消耗更多输出 token。注意一个常见误区思维链不是让模型“多想想”而是让它把推理过程显式写出来这样后续步骤能参考前面的推理结果。如果你的任务只是分类、抽取用 few-shot 就够不需要上思维链否则延迟和成本都会翻倍。4.2 上下文窗口与输出长度为什么回答质量忽高忽低上下文窗口决定模型一次能“看到”多少 token2023 年的主流模型集中在 4K 到 32K 之间。实际项目中上下文里通常塞满了检索结果、聊天历史、工具返回报错等。一个典型的不稳定场景把整张 SQL 建表语句、几十行历史会话全塞进去prompt 变得很长模型开始漏细节、答非所问。这多半不是模型变笨了而是关键信息被长尾内容稀释或者到达窗口上限后被截断。解决思路有两个方向。一是精简上下文只保留当前任务相关的字段注释和最近几轮对话不要无脑堆历史。二是把任务拆小让每个 prompt 只处理一个明确目标而不是让模型在 20 个约束条件下做复杂决策。2023 年有个更实在的操作是设置代答逻辑当输入超过窗口的 80% 时先做一次摘要把摘要作为新的上下文再让模型回答。4.3 让 LLM 稳定返回 JSON解析与修复策略LLM 返回文本不是结构化数据直接JSON.parse大概率会失败。2023 年常见的失败形态有三种返回内容被 markdown 代码块包裹、JSON 后面黏了多余说明文字、字符串里有未转义换行。很多 Java 项目因此开始找专门的修复库但更稳妥的做法是自己在解析层做防御。// 以 Java/Jackson 为例从 LLM 原始输出中提取 JSON 再解析 String raw response.getChoices().get(0).getMessage().getContent(); // 去掉 json 代码块围栏 String s raw.replaceFirst((?s)^(?:json)?\\s*, ) .replaceFirst((?s)\\s*$, ); // 只取第一个 { 到最后一个 } 之间的内容 int start s.indexOf({); int end s.lastIndexOf(}); ObjectMapper mapper new ObjectMapper(); if (start 0 end start) { JsonNode node mapper.readTree(s.substring(start, end 1)); // 继续对 node 做字段校验而不是直接信任 }这段代码的核心思想是“先收窄范围再解析”。replaceFirst用正则去掉最外层的代码块标记indexOf和lastIndexOf把首尾多余文本切掉。真正解析前再做字段校验比如判断关键字段是否存在、类型是否正确。这样即使模型输出不规则你也能拿到稳定结果。运行时如果捕获到JsonProcessingException建议把原始输出记录到日志里方便定位是哪一类格式污染。5. 进阶RAG 与 LLM Agent 的最小实现路径5.1 embedding、向量检索与 RAG 的分工一个表看清名词区别2023 年下半年RAG、embedding、向量数据库、Agent 几乎成了必聊词。但它们解决的不是同一个问题embedding 是把文本转成向量向量数据库负责存储和近似检索RAG 是把检索结果拼进 prompt 送给 LLMAgent 则是让 LLM 决策“下一步调用什么工具”。很多人把它们混为一谈导致设计上互相越权。名词解决问题输出典型工具embedding把语义变成可计算的距离数值向量OpenAI embedding / BGE向量检索从大量向量里找相似项相似文档列表FAISS / Chroma / pgvectorRAG让模型基于外部知识回答拼好的 prompt 回答LangChain / LlamaIndexAgent让模型自己决定调哪个工具函数调用指令ReAct / function callingRAG 的价值在于模型权重里的知识是静态的训练截止后就固定了而业务数据、最新文档、用户私有数据都活在外部系统里。RAG 不改变模型权重只改变模型“回答时能看到什么”。所以它的核心难点不在模型而在检索质量——检索不到相关内容再强的 LLM 也只能瞎编。5.2 最小 RAG 实现先跑通再上框架RAG 完整链路是“文档切分 → 向量化 → 存储 → 检索 → 拼 prompt → 生成”。不依赖 LangChain 也能写一个能跑的最小版核心就两步向量化和相似度计算。import numpy as np # 假设 doc_vectors 来自真实 embedding 模型 doc_vectors { RAG 是检索增强生成先检索再拼 prompt: np.array([0.1, 0.3, 0.8]), Agent 根据用户意图选择工具: np.array([0.9, 0.2, 0.1]), 微调会改变模型权重: np.array([0.2, 0.8, 0.4]), } query_vector np.array([0.4, 0.3, 0.7]) def top_k(query, k2): # 用余弦相似度找最相关的文档 scores [] for text, vec in doc_vectors.items(): cos float(query vec / (np.linalg.norm(query) * np.linalg.norm(vec))) scores.append((text, cos)) return sorted(scores, keylambda x: -x[1])[:k] for text, score in top_k(query_vector): print(round(score, 3), text)真实项目里doc_vectors 应该来自一个 embedding 模型比如将 300 篇文档切段后批量向量化存入向量数据库而不是 Python 字典。上面这段代码的价值在于看清楚一个事实所谓“语义检索”最后计算的还是数值相似度。检索回 top_k 之后把文档原文拼进 prompt再调用模型生成回答就完成了最小 RAG。5.3 LLM Agent 的工具调用与注入风险Agent 与普通对话的差别在于模型不仅输出文本还输出一个结构化的工具调用指令。2023 年的做法是把函数 schema 传给模型让它在回答里声明“我要调用 get_weather 参数是北京”。以 JSON 形式定义一个工具{ name: database_query, description: 执行只读 SQL返回查询结果, parameters: { type: object, properties: { sql: { type: string } } } }模型看到这个 schema 后如果用户问“上周订单总量”它可能返回上述结构的函数调用。应用层再去执行真实的 SQL。这里有一个当时容易被忽略的安全点tool name 和 description 也是 LLM 的输入攻击者可以通过精心构造的 prompt injection 来诱导模型选择错误的工具比如把一段隐藏指令塞进用户内容里让模型去调用内部接口。这类针对 tool selection 的 prompt injection 攻击后来在系统安全顶会上被系统化研究2023 年做 Agent 生产化时就必须把工具描述当成不可完全信任的输入来对待。6. LLM 输出不稳定怎么办五步排错与回归测试技巧6.1 一套固定的排错顺序LLM 服务出问题时很多人第一个念头是“换更强的模型”但大多数问题都出在更前面。我习惯按固定顺序排查先看输入再看采样再看截断再看解析最后才怀疑模型能力。输入排查包括上下文里有没有被截断的关键内容、有没有被注入的杂质文本、检索是否真的命中采样排查是把 temperature 降到 0.3 以下做对照实验截断排查是检查finish_reason是stop还是length解析排查是看原始输出是否被后处理逻辑改坏。这五步走完一般能定位到 90% 的不稳定根因。6.2 用回归测试守住 prompt 质量prompt 改坏了往往不是立刻暴露而是某些场景开始漂移。我建议给每个核心业务场景做一组最小回归用例每次改动 prompt 后自动跑一遍。一个很轻的做法是用脚本驱动模型输出再用关键词做断言cases [ (什么是上下文窗口, [token, 上下文]), (什么是 RAG, [检索, embedding]), ] def query_model(prompt: str, model: str llama2:7b) - str: # 实际项目中替换为你的模型调用封装 return call_your_llm(prompt, modelmodel) for prompt, keywords in cases: output query_model(prompt) missed [kw for kw in keywords if kw not in output] if missed: print(fFAIL: {prompt} 缺少关键词 {missed}) else: print(fPASS: {prompt})关键词断言只能防明显退化但比完全不测试强很多。更严格的做法是固定一批历史回答作为基准用 embedding 计算新输出与基准的余弦相似度低于阈值就告警。我一般会把 temperature 固定成一个较低值再跑回归否则采样随机性本身就会造成误报。把这套脚本挂进 CI每次改动 prompt 或模型版本后自动执行是投入产出比最高的稳定性保障。本文还有配套的精品资源点击获取