上一篇我们聊了 Python 自然语言处理 的经典底座：分词、停用词、TF-IDF、Word2Vec。如果你已经跟着跑过一遍，应该会有一个感觉——这套东西在整理文本、做简单分类的时候非常可靠，但当你想让模型理解一句话里到底是讽刺还是由衷夸赞，或者让它直接写出一段像样的回复，传统管线就明显使不上劲。AI 时代的 NLP 指南，不能只停在“把文本变成向量再丢进分类器”这一步。这篇作为系列的（二），我打算把视角转向 2024 年大家真正在用的一套东西：Transformer 架构、预训练模型生态、参数高效微调、检索增强生成、评估体系和推理部署。内容会偏工程，代码为主，但每个环节我都会解释“为什么这么做”，毕竟光抄代码解决不了踩坑。1. 从经典管线走进大模型时代：你的知识地图需要更新了1.1 传统 NLP 仍然在岗，但天花板很明显如果你去翻公司里运行了好几年的旧系统，大概率还能看到 TF-IDF 加逻辑回归做文本分类、Word2Vec 算相似度、LDA 做主题聚类这类经典方案。它们没有被淘汰的原因是：便宜、稳定、可解释。一份日志分类任务，几万条样本训练完，分类速度以毫秒计，线上出问题了还能直接查是哪几个特征把样本分错的。这类场景你去换大模型，反而是给自己找麻烦。但经典管线在语义理解上的天花板也是真实存在的。最典型的问题是表示单一。Word2Vec 训练出来的是一个静态向量，“苹果”这个词无论在“苹果很好吃”还是“苹果手机很贵”里，都是同一个向量。你必须靠下游分类器去隐式区分，而分词和上下文信息一旦清洗得不到位，模型就很容易学歪。第二个问题是长距离依赖处理不好。TF-IDF 只看词频，Word2Vec 只看局部窗口，碰到“虽然这家店的菜偏咸，但我还是因为服务态度给了好评”这种句子，传统特征几乎抓不住转折关系。第三个问题才是致命的：传统 NLP 没有生成能力。你可以用分类器判断情感是正还是负，但你没法让它输出一句“这道菜偏咸但服务加分”这样有信息量的自然语言。2024 年的业务需求里，生成式回复、摘要、开放问答占了很大一块，这已经不是特征工程能解决的事儿了。1.2 大模型给 NLP 增加了哪些新能力大模型的出现，并不是把分词和词向量消灭了，而是把 NLP 的能力重心从“特征工程”转移到“预训练加对齐”。你在第一部分学到的知识，仍然能帮你理解 tokenization、词表、向量空间，只是现在模型参数量大了几个量级，且学会了根据上下文动态生成词表示。新一代 NLP 体系下，几个关键变化值得你重新建立认知：上下文表征：同一个词在不同句子里的向量不一样。这是 Transformer 这类架构带来的核心突破。迁移学习成为默认范式：先在大规模语料上预训练，再在具体任务上微调或直接做少样本提示。生成与理解统一：很多任务不再区分“做分类”和“写回复”，统一看成“给模型一段输入，让它输出目标文本”。情感分析也可以变成“请判断这句话的情感，输出‘正向’或‘负向’”。检索和记忆分离：模型参数负责语言能力，外部知识库负责事实，两者通过检索增强生成（RAG）结合。这些能力让 NLP 项目的技术栈变长了，但并不意味着你什么都要亲自训练。恰恰相反，2024 年的实用路线是用成熟的开源预训练模型，花最少的成本适配自己的数据。1.3 新知识地图：四块拼图如果让我给一个刚进入 AI 时代 NLP 的开发者画知识地图，我会把它分成四块：模型原理：至少理解 Transformer 的核心机制，否则后面看微调、看推理优化全是黑话。模型使用：熟悉预训练模型加载、分词器、文本分类和生成的标准写法。训练适配：用低成本方式把通用模型变成领域模型，常见方案是 LoRA 这类参数高效微调。工程落地：包括评测、检索增强、显存估算、推理加速，这部分最容易被教程忽略，但生产环境每天都被它折磨。下面几章就按这张地图展开。你不用一次性全部吃透，但建议跟着代码把每个环节跑通一遍，踩一次坑比看十遍文章都管用。2. Transformer 不是黑盒：注意力机制与位置编码的人话版2.1 从静态词向量到上下文表示：为什么“苹果”在不同句子中含义不同理解 Transformer，首先得理解它解决的核心问题。经典词向量给每个词分配一个固定向量，这个向量等于把所有上下文打包成了一个平均值，所以语义必然模糊。Transformer 引入了一个更聪明的做法：每个词在进入模型时有一个初始表示，然后它会根据当前句子的其他词不断更新自己的表示。我们可以把它想象成开会。参会者带着自己的初步观点进会议室，经过一轮讨论后，每个人的最终意见都被其他人的发言修正过。如果把“讨论”这个过程重复多层，最终得到的观点就融合了整个会议的信息。Transformer 的一层网络做的就是一次“讨论”，多层堆叠就是多轮讨论。这就是为什么它能捕捉到“苹果”在“苹果很好吃”和“苹果手机很贵”里语义不同——因为它的表示取决于同伴词汇。# 概念示例：一个 token 在两层网络里不断被“上下文”改写 # 实际实现中会用矩阵并行计算，这里只展示思想 def contextualize(token_embedding, sentence_embeddings): context_vector = average(sentence_embeddings) return update(token_embedding, context_vector)2.2 自注意力机制的会议纪要员比喻自注意力（Self-Attention）是 Transformer 讨论环节的核心算法。每个 token 会产生三个向量，分别叫 Query、Key、Value。这三个名字看起来玄乎，其实对应一个非常朴素的流程：Query：当前这个词想问什么。相当于一个人心里想，“谁和我现在讨论的话题有关？”Key：其他词发布的“标签”。相当于每个人胸前的名签，写着“我涉及这些话题”。Value：其他词真正的内容。相当于每个人要说的话。计算过程就是拿 Query 去和所有 Key 做点积，得到一个分数，表示“你和我的相关性”。分数经过 softmax 归一化后变成权重，再用这个权重对所有 Value 做加权求和，得到当前词的更新表示。打个比方：你在开会时问了一句“预算多少合适”，Key 匹配到“预算”“成本”“报价”这些词的注意力高，于是你吸收的 Value 主要来自这几个词，而不是来自无关的“今天的天气”。每一层 transformer 都在重复这个“找你最该听的内容”的过程。import torch import torch.nn.functional as F def softmax_attention(q, k, v): scores = torch.matmul(q, k.transpose(-2, -1)) scores = scores / (k.shape[-1] ** 0.5) # 缩放，避免点积过大 weights = F.softmax(scores, dim=-1) return torch.matmul(weights, v)这里的缩放因子是维度开根号。为什么要缩放？因为维度越高，点积结果方差越大，softmax 之后容易进入梯度极小的区间，缩放能把数值拉回合理范围。这个细节你在自己手写注意力的时候会深刻体会到。2.3 多头注意力、位置编码与训练稳定三件套实际使用的 Transformer 不是只做一次注意力，而是把向量切成多个子空间，分别做注意力，再把结果拼回来，这叫多头注意力。多头有什么必要？单一注意力只能学一种相关性，多头相当于多组人从不同角度看同一份材料：有的关注语法搭配，有的关注指代关系，有的关注语义相近。最后模型融合这些视角，表达能力就上来了。另一个绕不开的问题是位置编码。注意力本身对位置不敏感，你把“我打你”三个词的顺序打乱，注意力计算完全不受影响，但语义变了。所以模型必须额外注入位置信息。最早的方案是用正弦函数生成固定位置向量，后来演变出可学习位置编码、旋转位置编码等。2024 年的主流开源模型基本都采用相对位置或旋转位置编码，好处是对长文本的泛化更好。训练稳定三件套指的是残差连接、层归一化和掩码。残差连接让第 n 层可以拿到第 n-1 层的原始信息，避免深层网络信息丢失；层归一化让每一层的输入分布不要剧烈波动；掩码则分两类：padding mask 用来遮住填充字符，保证它们不参与注意力；causal mask 让生成模型只能看到当前位置之前的 token，防止偷看未来。理解了这三件事，你再去看模型配置文件里的参数名，就不会是一头雾水。3. 用 transformers 生态把文本分类和生成都跑起来3.1 环境准备：先把版本和 CUDA 的坑填了想在 2024 年顺畅地跑 NLP 实验，最推荐的方式还是基于 Python 生态，使用 transformers 这类成熟库。第一步是创建干净的虚拟环境，推荐 Python 3.10 或 3.11。conda create -n nlp python=3.10 conda activate nlp pip install torch transformers datasets tokenizers accelerate这里有个非常常见的坑：如果你直接pip install torch，在部分平台上会默认安装 CPU 版本。机器有 NVIDIA 显卡却用 CPU 跑，后面一微调就慢得怀疑人生。正确做法是先到 PyTorch 官网按 CUDA 版本安装对应的 wheel，再继续装其他库。另一个坑是版本冲突。transformers 依赖 tokenizers，而某些老项目会把 tokenizers 降到很旧的版本，结果加载模型时报 OSError。遇到这种问题，不要急着整个环境重装，先看报错是不是tokenizer版本不匹配，单独升级即可。如果只是做小规模实验，CPU 也不是不能跑，像 BERT 这类 base 规模模型，CPU 上推理单个短文本花费几十毫秒到几百毫秒，够你调试代码逻辑。3.2 一条 AutoModel 走天下：加载分词器与模型transformers 生态最方便的一点是 AutoClass 机制。你不用关心某个模型内部结构叫什么名字，只要提供模型 ID，库会自动把正确的分词器、模型结构加载回来。from transformers import AutoTokenizer, AutoModelForSequenceClassification model_name = "bert-base-chinese" # 中文场景常用的基础文本模型 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=2)分词器负责把原始文本切成 token，再映射成 ID，同时生成注意力掩码等输入字段。中文文本的切分方式与英文差异很大：英文一个词往往就是一个 token，中文则可能按字或按子词切分。BERT-中文这一类模型通常基于字粒度，好处是不用担心分词错误传导到模型。为什么需要AutoModelForSequenceClassification而不是直接用AutoModel？因为分类任务需要在预训练模型上方加一个分类头，这个类会自动帮你加。同理，生成任务有AutoModelForCausalLM，问答任务有AutoModelForQuestionAnswering。你可以把这些看作“模型骨架加上任务专用头”的组合。3.3 文本分类任务的完整跑通流程跑通一个文本分类 Demo，代码很短，但背后的逻辑很完整。如果你还没微调模型，直接用预训练权重做推理，输出只是随机初始化的结果，意义不大；真正有意义的是先微调再推理。这里先展示推理流程的标准写法，下一章讲微调。texts = ["这个商品的体验超出预期", "物流太慢，等了一周没有动静"] batch = tokenizer( texts, padding=True, # 将句子pad到等长 truncation=True, # 超长截断 max_length=128, return_tensors="pt", ) outputs = model(**batch) preds = outputs.logits.argmax(dim=-1) print(preds)padding=True会统一长度，但 pad 出来的位置必须靠 attention mask 告诉模型不要去注意；truncation=True负责把超过 max_length 的内容扔掉。实际项目里，max_length 的选择要看你文本的真实长度分布，不要拍脑袋定 512。如果绝大多数样本都是 64 token 以内，硬设 512 只会浪费显存和算力。我自己的习惯是先用 tokenizer 统计训练集的长度分布，再选择覆盖 90% 样本的最小长度。比如分布结果显示 95% 的样本在 80 token 以内，就设 96 或 128，不要盲目跟风设 512。3.4 生成式任务不是分类的翻版生成式任务的使用方式完全不同。分类模型拿一段文本，输出一个标签；生成模型拿一段 prompt，输出一段新文本。以开源中文对话模型为例：from transformers import AutoTokenizer, AutoModelForCausalLM model_name = "Qwen/Qwen2.5-1.5B-Instruct" # 开源可用的中文对话模型，也可换成你的本地路径 tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, trust_remote_code=True, torch_dtype="auto", ) prompt = "请用一句话解释什么是检索增强生成。" messages = [{"role": "user", "content": prompt}] text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = tokenizer(text, return_tensors="pt") gen = model.generate( **inputs, max_new_tokens=128, do_sample=True, temperature=0.7, top_p=0.9, ) response = tokenizer.decode(gen[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True) print(response)这里有几个关键点。第一，apply_chat_template会把用户输入包装成带助手前缀的完整消息，你必须用模型配套的模板，不能自己随便拼。第二，max_new_tokens控制生成的回复长度，不是控制输入长度。第三，do_sample=True配合temperature和top_p控制随机性，如果做实体抽取这类确定性任务，建议关闭采样，直接贪心解码，结果更稳。很多人第一次跑生成类任务会被“回答得太啰嗦”或“自问自答”吓到。这通常是模板没用对或者 temperature 太高。把 temperature 降到 0.5 左右，关闭include_special_tokens这类多余输出，效果会立刻干净许多。4. 微调不一定要全量：LoRA 参数高效微调的完整思路4.1 全量微调的显存账：为什么很多人望而却步拿到预训练模型之后，最直觉的做法是整个模型拿去自己的数据上接着训练，这叫全量微调。听起来简单，账却不一定算得过来。7B 参数的模型，用 FP16 存储，光参数就要 14GB。训练时还要保存梯度，又要 14GB。优化器如果用 Adam，还要存一阶和二阶动量，这两项合起来又是 28GB 左右。还没算你的训练数据、中间激活值，一张 24GB 显存的卡早就爆了。很多人第一次尝试微调大模型，错误信息只有一个：CUDA out of memory。所以 2024 年工业界的主流方案是参数高效微调，其中 LoRA 是最普及的一种。它的核心思路是：原模型参数全部冻结，不动；另外训练一小组新增参数，让这组参数学会“该往哪个方向微调”。4.2 LoRA 在做什么：冻结主干，训练旁路低秩矩阵LoRA 的理论基础是低秩分解。研究者发现，大模型微调前后权重的变化量 ΔW 通常是低秩的，也就是说这个变化可以用一个很小的矩阵组合近似。假设原来的权重矩阵是 W，微调后等价于 W' = W + ΔW。LoRA 把 ΔW 拆成两个小矩阵 A 和 B 的乘积，A 的维度是(输入维度, r)，B 的维度是(r, 输出维度)，其中秩 r 一般取 4、8、16。训练时，W 不动，只训练 A 和 B。这样可训练参数量从几十亿变成几百万。你可以把 LoRA 想象成给一个庞大的组织请顾问团队：正式员工工资不变，顾问团队只占很小预算，但他们的建议能让整个组织的输出风格明显改变。from peft import LoraConfig, get_peft_model from transformers import AutoModelForSequenceClassification base_model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=2, load_in_4bit=True, # 进一步压缩显存 ) lora_config = LoraConfig( r=8, # 低秩矩阵的秩，越大可学习容量越大，但显存也更多 lora_alpha=16, # 缩放因子，控制 LoRA 参数对原模型的影响强度 target_modules=["query", "value"], # 只对 attention 层的这两个模块加旁路 lora_dropout=0.05, bias="none", task_type="SEQ_CLS", ) model = get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 可训练参数通常只占 1% 甚至更少为什么target_modules选择 query 和 value？实践中最常见的是把注意力层的 Q、V 矩阵都加上 LoRA，因为注意力层的权重变化对任务影响最直接。有些做法也会加 K、O 和 FFN 层，效果会有提升，但显存和训练时间也随之上升。小数据集上不用一上来就全加，先 Q、V 就够了。4.3 一段能跑的 LoRA 微调脚本与关键参数微调脚本我用 transformers 的 Trainer 来写，它可以省掉自己写训练循环的很多边界处理。数据集用 datasets 库加载，保证格式统一。from datasets import Dataset from transformers import ( Trainer, TrainingArguments, DataCollatorWithPadding, ) # 假设 train_data 是包含 text 和 label 的列表 train_ds = Dataset.from_list([ {"text": "这个商品的体验超出预期", "label": 1}, {"text": "物流太慢，等了一周", "label": 0}, ]) def tokenize_func(batch): return tokenizer(batch["text"], truncation=True, max_length=128) train_ds = train_ds.map(tokenize_func, batched=True) training_args = TrainingArguments( output_dir="./lora_cls", per_device_train_batch_size=16, gradient_accumulation_steps=2, learning_rate=2e-4, num_train_epochs=3, fp16=True, save_strategy="epoch", logging_steps=50, remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_ds, tokenizer=tokenizer, data_collator=DataCollatorWithPadding(tokenizer), ) trainer.train()几个参数值得说明。learning_rate在 LoRA 里通常比全量微调大一个量级，我用 1e-4 到 5e-4 之间的值居多。全量微调切忌直接用这么大的学习率，否则很容易把预训练知识冲掉。gradient_accumulation_steps的作用是把多个小 batch 的梯度累加后再更新，相当于变相增大了 batch size。显存不够时，优先把 per_device_train_batch_size 调小，再用累积步数补回来。DataCollatorWithPadding会自动把同一个 batch 里的样本 pad 到等长，避免手动处理不等长输入。这个细节看着小，但能省掉很多报错时间。4.4 微调完之后的合并、保存与常见心态LoRA 训练完保存的是适配器参数，通常是一个几 MB 到几十 MB 的目录，而不是完整的模型。使用时有两条路：一是原模型加适配器一起加载，推理时先用PeftModel.from_pretrained(base_model, "./lora_cls")加载；二是把 LoRA 权重合并回原模型，得到完整的微调后权重。merged_model = model.merge_and_unload() merged_model.save_pretrained("./lora_cls_merged") tokenizer.save_pretrained("./lora_cls_merged")合并的好处是部署时只需加载一份模型文件，推理速度更快。缺点是合并后的文件还是全量大小，存储成本高。我的经验是：实验阶段保留 LoRA 适配器文件，上线阶段再合并导出。还有一个很多人提过但我必须重复的心态问题：微调不是万能药。如果你的数据量只有几十条，LoRA 也不会给你变出魔法。数据质量永远是第一位。先整理清晰、标签一致的数据，再谈训练参数。小样本情况下，宁可先跑几次全量推理，人工检查 prompt 是否能解决问题，也不要盲目开训练。5. 给模型装一个外接知识库：RAG 检索增强生成的工程拆解5.1 RAG 解决的是幻觉和知识过期，不是包装概念如果你微调过一个 7B 模型，会发现一个很现实的问题：它可以写出通顺的回复，但一本正经地编造不存在的“内部政策”或“产品参数”。原因很简单，模型参数里的知识是训练时定死的，训练数据截止之后的新知识它不可能凭空知道。同时，细粒度的私有知识本来就不可能靠微调全部灌进参数。检索增强生成（RAG，Retrieval-Augmented Generation）的思路是改变信息来源：不强迫模型把答案背在参数里，而是在回答问题时，先从外部知识库检索相关资料，再把资料拼进 prompt，让模型基于资料回答。这相当于考试时允许翻书，比考前把所有内容背下来可靠得多。RAG 最适合的项目形态是：企业知识库问答、私有文档助手、客服助手等。它不需要重新训练模型，知识更新只需更新文档库，成本远低于微调。5.2 搭一条最小可用的 RAG 管线RAG 管线看起来环节多，但拆开就是五步：加载文档、切块、向量化、检索、注入生成。给你一个最简单但能跑通全流程的版本。先做文档切块。切块是 RAG 里最影响效果的一步。我在生产项目里常用的参数是 chunk_size 取 300 到 500 字符，chunk_overlap 取 50 到 80 字符。这个数值不是经验玄学：太小的块召回时容易断章取义，一个完整政策被切成七零八落，模型根本看不出前因后果；太大的块噪声多，检索分数容易被无关内容稀释。from sentence_transformers import SentenceTransformer # 中文场景建议使用支持中文的embedding模型，这里用通用示例 embedder = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") # 假设 docs 是已经切好的文本块列表 doc_chunks = [ "退换货政策：签收后七日内可申请无理由退换货……", "物流说明：工作日下午四点前下单，当天发货……", "售后联系：客服工作时间 9:00-18:00……", ] doc_vecs = embedder.encode(doc_chunks) query = "我买的商品不喜欢，能退吗" query_vec = embedder.encode([query]) # 计算余弦相似度，取 top-3 scores = cosine_similarity(query_vec, doc_vecs)[0] top_idx = scores.argsort()[-3:][::-1] print([doc_chunks[i] for i in top_idx])这一步没有向量数据库也能跑，数据量小时候直接算相似度完全够用。数据量到了百万级，再引入向量检索服务也不迟。拿到检索结果后，拼 prompt 的方式很关键。我的习惯是：请仅根据以下资料回答问题，不要使用资料之外的知识。 资料1：…… 资料2：…… 问题：……首句“仅根据资料回答”能显著减少模型自由发挥的概率。注入的顺序也要注意：最相关的资料放在最前面，因为模型对 prompt 开头和结尾的内容记忆更牢，顺序颠倒可能导致关键信息被长资料淹没。5.3 切块、召回、注入顺序：三个最容易翻车的环节用 RAG 的人十有八九会遇到这几个问题，我挨个说。召回质量差是这个方案最大的痛点。很多人跑通 demo 后发现答案驴唇不对马嘴，第一反应是换更强的生成模型，其实问题往往出在 embedding 模型和切块策略上。优先排查点：查一下召回的 top-3 里到底有没有正确答案。如果答案根本不在召回的文本块里，那再强的 LLM 也答不对。此时你要做的是调整切块大小，或者换更适合领域的中文 embedding 模型，而不是去调生成参数。相似度阈值不要拍脑袋。有人喜欢设“余弦相似度大于 0.7 才算命中”，但不同 embedding 模型的分数分布差异极大。有的模型相似度普遍在 0.6 到 0.8 之间，有的模型集中在 0.2 到 0.4。正确做法是拿一批标注了正确答案的样本，统计分析“正确命中的最低分”和“错误命中的最高分”，再决定阈值。上下文注入长度也要克制。很多人把检索到的所有相关片段全部塞进 prompt，认为越多越好。模型上下文窗口是有限的，塞了 5000 字资料后，真正有用的细节可能被淹没，还拖慢推理速度。我一版建议限定只注入 3 到 5 个强相关片段，总共不超过 1500 字。如果业务确实需要长上下文，优先考虑分段回答。6. 别靠感觉调模型：NLP 项目的评估体系搭建方法6.1 传统的分类指标：别只用准确率NLP 项目的惨痛教训之一，是完全用准确率衡量模型。假设你的数据里 95% 是负样本，模型只要全部预测为负，准确率就有 95%，但它对你的业务毫无价值。必须看精确率、召回率和 F1。精确率关心“模型说是正类的里面，有多少真的为正”，召回率关心“真正的正类里，模型找回了多少”。这两个指标常常互斥，F1 是它们的调和平均。对客服工单分类这类业务，漏掉一个紧急工单的代价很高，就要偏重召回；对垃圾评论过滤，误伤正常用户代价更高，就偏重精确率。分类评估还需要看混淆矩阵。它能告诉你哪些类容易被混在一起，这往往是数据标注不清或类别定义重叠的信号。如果“售后与退换货”两个类别频繁互相误判，回到标注规范去改数据，比继续调参有用得多。6.2 BLEU 和 ROUGE 的局限：生成任务要小心到了生成任务，评估一下子变得困难。很多人沿用机器翻译时代的方法，用 BLEU、ROUGE 这些基于 n-gram 重叠的指标。它们能一定程度上衡量生成文本和标准答案的字面相似度，但局限非常大。“这部手机电池很经用”和“这部手机续航表现相当好”意思几乎一样，但字面 n-gram 重合度很低，BLEU 会给一个很差的分数。反过来，一段词汇完全一样但语序错乱的内容，字面重合度可能很高，实际完全不可读。所以我在生成类项目里，只把 BLEU、ROUGE 当作快速看趋势的粗筛工具，绝不把它当最终质量标准。6.3 LLM-as-Judge：让大模型当评分员，但别完全放手2024 年业界更多采用“用一个大模型给另一个大模型的输出打分”的做法，简称 LLM-as-Judge。方法不复杂：把待评文本、参考标准、评分维度都放进 prompt，让评分模型输出 1 到 5 分或分维度打分。要让打分可靠，核心是写清楚评分规则。比如：请从相关性、完整性、忠实度三个维度打分，每项 1-5 分。 相关性：回答是否紧扣问题。 完整性：是否覆盖问题要求的全部要点。 忠实度：是否基于给定资料，有无编造。 不要因为回答长度长就给高分。其中“不要因为长度长就给高分”这类纠偏提示非常关键。最早我用 LLM 打分时，发现模型偏爱又长又绕的答案，加了这个约束后分数才有区分度。另一个稳定技巧是让评分模型多次采样取平均，或者用两个不同模型互相校验，减少单个模型打分偏好带来的偏差。6.4 攒一个黄金回归集，比写一百行 prompt 更值评估体系的真正核心，不是指标有多复杂，而是你有没有一个固定不变、覆盖面广的回归测试集。我习惯叫它 golden set，里面放三类样本：业务侧最常见的典型问题、之前线上翻过车的 bad case、以及边界条件样本。规模不用大，50 到 200 条常常就够用。每次改动 prompt、微调数据或模型版本，都在这个集上跑一遍，记录分数变化。如果总分提升但某个重要 bad case 变差了，就要谨慎上线。我自己固定每周更新一次 golden set：凡是线上新发现的问题案例，盘点后立刻补充进去。这个习惯会让项目越到后期越稳，因为回归集积累的是真实世界里的坑，而不是拍脑袋想出来的完美问题。7. 上线才是真正的开始：显存估算、推理优化与降级方案7.1 先算账：显存和成本的大致估算很多人开发时用一张消费级显卡跑通模型，就以为部署很容易，真到上线才发现显存不够、响应延迟超标。部署前花十分钟算一笔账，能避免后面手忙脚乱。推理显存的粗略公式是：模型显存约等于参数量乘以每个参数占用的字节数。FP32 是 4 字节，FP16 是 2 字节，INT8 是 1 字节，INT4 约 0.5 字节。比如一个 7B 模型用 FP16 推理，参数至少占 14GB，再加上 KV cache 和运行时开销，实际单卡 24GB 才比较从容。换成 INT4 量化后，7B 模型只要约 4GB 参数空间，很多消费级显卡也能跑。但量化不是免费的。INT4 量化可能让模型在复杂推理任务上出现明显质量下降。我的建议是逐步尝试：先在 FP16 上跑通功能，再试 INT8，如果评估集指标没有明显下滑，再考虑 INT4。上线前必须用黄金回归集重新测一遍，不能只看显存数字。7.2 推理优化的三条路线：量化、连续批处理、工程缓存显存只是第一关，延迟和吞吐才是线上最头疼的问题。按投入产出比排序，我会先说工程缓存。工程缓存指的是把重复的查询结果存起来。很多人第一反应是用精确哈希做缓存，但实际用户问题表述千变万化，完全相同的文本比例很低。更有效的方式是：把用户 query 做 embedding，向量相似度高于阈值时直接返回缓存答案。对客服助手这类场景，Top 20 热点问题的缓存命中率可能达到 30% 以上，响应时间直接从秒级降到毫秒级。第二路线是量化加速。除了降低显存，量化还能减少显存带宽压力，这在 GPU 推理里经常比算力更关键。配合批量推理，吞吐量提升显著。如果你的场景是智能客服这种高并发短文本，量化加批量几乎是标准配置。第三路线是实现连续批处理。传统批处理是攒一批请求再一起推理，缺点是高矮个互相拖累，最短的请求也要等最长的跑完。连续批处理把不同请求的生成过程交错执行，先结束的先返回，从而显著提高 GPU 利用率。开源的推理框架很多已经内置了这个能力，你只需要把模型导出成对应格式，不必自己实现复杂调度。7.3 降级与兜底：模型挂了不能只剩报错生产环境里最容易被忽略的是降级方案。大模型推理服务偶尔会因为长尾输入、显存异常或后端波动而超时，如果没有兜底，用户看到的就是一个转圈后报错的页面，体验非常差。我的建议是至少准备两层降级。第一层：模型服务超时后，返回预设的热门 FAQ 或简短提示，而不是直接报 500。第二层：如果超时率达到阈值，自动把流量切换到 lite 模型或规则匹配，保证核心功能不中断。还有一个小细节：生成模型的超时时间要单独设置。分类模型 200 毫秒能返回，生成模型回答几百 token 可能耗时好几秒。如果复用同样的超时配置，很容易误杀正常请求。我通常按“预估生成长度乘以单 token 预计耗时，再留 50% 余量”来配置超时时间，同时给前端流式输出方案，提升用户等待体验。最后一件事：上线后必须持续监控。不用只看模型指标，更要看业务指标，比如用户问题解决率、转人工率、投诉率。模型指标再漂亮，用户不买账也是白搭。把 golden set、线上日志、人工反馈串成一个循环，每周复盘一次，NLP 项目才能从一个“能跑的模型”变成一个“可靠的系统”。
上一篇我们聊了 Python 自然语言处理 的经典底座：分词、停用词、TF-IDF、Word2Vec。如果你已经跟着跑过一遍，应该会有一个感觉——这套东西在整理文本、做简单分类的时候非常可靠，但当你想让模型理解一句话里到底是讽刺还是由衷夸赞，或者让它直接写出一段像样的回复，传统管线就明显使不上劲。AI 时代的 NLP 指南，不能只停在“把文本变成向量再丢进分类器”这一步。这篇作为系列的（二），我打算把视角转向 2024 年大家真正在用的一套东西：Transformer 架构、预训练模型生态、参数高效微调、检索增强生成、评估体系和推理部署。内容会偏工程，代码为主，但每个环节我都会解释“为什么这么做”，毕竟光抄代码解决不了踩坑。1. 从经典管线走进大模型时代：你的知识地图需要更新了1.1 传统 NLP 仍然在岗，但天花板很明显如果你去翻公司里运行了好几年的旧系统，大概率还能看到 TF-IDF 加逻辑回归做文本分类、Word2Vec 算相似度、LDA 做主题聚类这类经典方案。它们没有被淘汰的原因是：便宜、稳定、可解释。一份日志分类任务，几万条样本训练完，分类速度以毫秒计，线上出问题了还能直接查是哪几个特征把样本分错的。这类场景你去换大模型，反而是给自己找麻烦。但经典管线在语义理解上的天花板也是真实存在的。最典型的问题是表示单一。Word2Vec 训练出来的是一个静态向量，“苹果”这个词无论在“苹果很好吃”还是“苹果手机很贵”里，都是同一个向量。你必须靠下游分类器去隐式区分，而分词和上下文信息一旦清洗得不到位，模型就很容易学歪。第二个问题是长距离依赖处理不好。TF-IDF 只看词频，Word2Vec 只看局部窗口，碰到“虽然这家店的菜偏咸，但我还是因为服务态度给了好评”这种句子，传统特征几乎抓不住转折关系。第三个问题才是致命的：传统 NLP 没有生成能力。你可以用分类器判断情感是正还是负，但你没法让它输出一句“这道菜偏咸但服务加分”这样有信息量的自然语言。2024 年的业务需求里，生成式回复、摘要、开放问答占了很大一块，这已经不是特征工程能解决的事儿了。1.2 大模型给 NLP 增加了哪些新能力大模型的出现，并不是把分词和词向量消灭了，而是把 NLP 的能力重心从“特征工程”转移到“预训练加对齐”。你在第一部分学到的知识，仍然能帮你理解 tokenization、词表、向量空间，只是现在模型参数量大了几个量级，且学会了根据上下文动态生成词表示。新一代 NLP 体系下，几个关键变化值得你重新建立认知：上下文表征：同一个词在不同句子里的向量不一样。这是 Transformer 这类架构带来的核心突破。迁移学习成为默认范式：先在大规模语料上预训练，再在具体任务上微调或直接做少样本提示。生成与理解统一：很多任务不再区分“做分类”和“写回复”，统一看成“给模型一段输入，让它输出目标文本”。情感分析也可以变成“请判断这句话的情感，输出‘正向’或‘负向’”。检索和记忆分离：模型参数负责语言能力，外部知识库负责事实，两者通过检索增强生成（RAG）结合。这些能力让 NLP 项目的技术栈变长了，但并不意味着你什么都要亲自训练。恰恰相反，2024 年的实用路线是用成熟的开源预训练模型，花最少的成本适配自己的数据。1.3 新知识地图：四块拼图如果让我给一个刚进入 AI 时代 NLP 的开发者画知识地图，我会把它分成四块：模型原理：至少理解 Transformer 的核心机制，否则后面看微调、看推理优化全是黑话。模型使用：熟悉预训练模型加载、分词器、文本分类和生成的标准写法。训练适配：用低成本方式把通用模型变成领域模型，常见方案是 LoRA 这类参数高效微调。工程落地：包括评测、检索增强、显存估算、推理加速，这部分最容易被教程忽略，但生产环境每天都被它折磨。下面几章就按这张地图展开。你不用一次性全部吃透，但建议跟着代码把每个环节跑通一遍，踩一次坑比看十遍文章都管用。2. Transformer 不是黑盒：注意力机制与位置编码的人话版2.1 从静态词向量到上下文表示：为什么“苹果”在不同句子中含义不同理解 Transformer，首先得理解它解决的核心问题。经典词向量给每个词分配一个固定向量，这个向量等于把所有上下文打包成了一个平均值，所以语义必然模糊。Transformer 引入了一个更聪明的做法：每个词在进入模型时有一个初始表示，然后它会根据当前句子的其他词不断更新自己的表示。我们可以把它想象成开会。参会者带着自己的初步观点进会议室，经过一轮讨论后，每个人的最终意见都被其他人的发言修正过。如果把“讨论”这个过程重复多层，最终得到的观点就融合了整个会议的信息。Transformer 的一层网络做的就是一次“讨论”，多层堆叠就是多轮讨论。这就是为什么它能捕捉到“苹果”在“苹果很好吃”和“苹果手机很贵”里语义不同——因为它的表示取决于同伴词汇。# 概念示例：一个 token 在两层网络里不断被“上下文”改写 # 实际实现中会用矩阵并行计算，这里只展示思想 def contextualize(token_embedding, sentence_embeddings): context_vector = average(sentence_embeddings) return update(token_embedding, context_vector)2.2 自注意力机制的会议纪要员比喻自注意力（Self-Attention）是 Transformer 讨论环节的核心算法。每个 token 会产生三个向量，分别叫 Query、Key、Value。这三个名字看起来玄乎，其实对应一个非常朴素的流程：Query：当前这个词想问什么。相当于一个人心里想，“谁和我现在讨论的话题有关？”Key：其他词发布的“标签”。相当于每个人胸前的名签，写着“我涉及这些话题”。Value：其他词真正的内容。相当于每个人要说的话。计算过程就是拿 Query 去和所有 Key 做点积，得到一个分数，表示“你和我的相关性”。分数经过 softmax 归一化后变成权重，再用这个权重对所有 Value 做加权求和，得到当前词的更新表示。打个比方：你在开会时问了一句“预算多少合适”，Key 匹配到“预算”“成本”“报价”这些词的注意力高，于是你吸收的 Value 主要来自这几个词，而不是来自无关的“今天的天气”。每一层 transformer 都在重复这个“找你最该听的内容”的过程。import torch import torch.nn.functional as F def softmax_attention(q, k, v): scores = torch.matmul(q, k.transpose(-2, -1)) scores = scores / (k.shape[-1] ** 0.5) # 缩放，避免点积过大 weights = F.softmax(scores, dim=-1) return torch.matmul(weights, v)这里的缩放因子是维度开根号。为什么要缩放？因为维度越高，点积结果方差越大，softmax 之后容易进入梯度极小的区间，缩放能把数值拉回合理范围。这个细节你在自己手写注意力的时候会深刻体会到。2.3 多头注意力、位置编码与训练稳定三件套实际使用的 Transformer 不是只做一次注意力，而是把向量切成多个子空间，分别做注意力，再把结果拼回来，这叫多头注意力。多头有什么必要？单一注意力只能学一种相关性，多头相当于多组人从不同角度看同一份材料：有的关注语法搭配，有的关注指代关系，有的关注语义相近。最后模型融合这些视角，表达能力就上来了。另一个绕不开的问题是位置编码。注意力本身对位置不敏感，你把“我打你”三个词的顺序打乱，注意力计算完全不受影响，但语义变了。所以模型必须额外注入位置信息。最早的方案是用正弦函数生成固定位置向量，后来演变出可学习位置编码、旋转位置编码等。2024 年的主流开源模型基本都采用相对位置或旋转位置编码，好处是对长文本的泛化更好。训练稳定三件套指的是残差连接、层归一化和掩码。残差连接让第 n 层可以拿到第 n-1 层的原始信息，避免深层网络信息丢失；层归一化让每一层的输入分布不要剧烈波动；掩码则分两类：padding mask 用来遮住填充字符，保证它们不参与注意力；causal mask 让生成模型只能看到当前位置之前的 token，防止偷看未来。理解了这三件事，你再去看模型配置文件里的参数名，就不会是一头雾水。3. 用 transformers 生态把文本分类和生成都跑起来3.1 环境准备：先把版本和 CUDA 的坑填了想在 2024 年顺畅地跑 NLP 实验，最推荐的方式还是基于 Python 生态，使用 transformers 这类成熟库。第一步是创建干净的虚拟环境，推荐 Python 3.10 或 3.11。conda create -n nlp python=3.10 conda activate nlp pip install torch transformers datasets tokenizers accelerate这里有个非常常见的坑：如果你直接pip install torch，在部分平台上会默认安装 CPU 版本。机器有 NVIDIA 显卡却用 CPU 跑，后面一微调就慢得怀疑人生。正确做法是先到 PyTorch 官网按 CUDA 版本安装对应的 wheel，再继续装其他库。另一个坑是版本冲突。transformers 依赖 tokenizers，而某些老项目会把 tokenizers 降到很旧的版本，结果加载模型时报 OSError。遇到这种问题，不要急着整个环境重装，先看报错是不是tokenizer版本不匹配，单独升级即可。如果只是做小规模实验，CPU 也不是不能跑，像 BERT 这类 base 规模模型，CPU 上推理单个短文本花费几十毫秒到几百毫秒，够你调试代码逻辑。3.2 一条 AutoModel 走天下：加载分词器与模型transformers 生态最方便的一点是 AutoClass 机制。你不用关心某个模型内部结构叫什么名字，只要提供模型 ID，库会自动把正确的分词器、模型结构加载回来。from transformers import AutoTokenizer, AutoModelForSequenceClassification model_name = "bert-base-chinese" # 中文场景常用的基础文本模型 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=2)分词器负责把原始文本切成 token，再映射成 ID，同时生成注意力掩码等输入字段。中文文本的切分方式与英文差异很大：英文一个词往往就是一个 token，中文则可能按字或按子词切分。BERT-中文这一类模型通常基于字粒度，好处是不用担心分词错误传导到模型。为什么需要AutoModelForSequenceClassification而不是直接用AutoModel？因为分类任务需要在预训练模型上方加一个分类头，这个类会自动帮你加。同理，生成任务有AutoModelForCausalLM，问答任务有AutoModelForQuestionAnswering。你可以把这些看作“模型骨架加上任务专用头”的组合。3.3 文本分类任务的完整跑通流程跑通一个文本分类 Demo，代码很短，但背后的逻辑很完整。如果你还没微调模型，直接用预训练权重做推理，输出只是随机初始化的结果，意义不大；真正有意义的是先微调再推理。这里先展示推理流程的标准写法，下一章讲微调。texts = ["这个商品的体验超出预期", "物流太慢，等了一周没有动静"] batch = tokenizer( texts, padding=True, # 将句子pad到等长 truncation=True, # 超长截断 max_length=128, return_tensors="pt", ) outputs = model(**batch) preds = outputs.logits.argmax(dim=-1) print(preds)padding=True会统一长度，但 pad 出来的位置必须靠 attention mask 告诉模型不要去注意；truncation=True负责把超过 max_length 的内容扔掉。实际项目里，max_length 的选择要看你文本的真实长度分布，不要拍脑袋定 512。如果绝大多数样本都是 64 token 以内，硬设 512 只会浪费显存和算力。我自己的习惯是先用 tokenizer 统计训练集的长度分布，再选择覆盖 90% 样本的最小长度。比如分布结果显示 95% 的样本在 80 token 以内，就设 96 或 128，不要盲目跟风设 512。3.4 生成式任务不是分类的翻版生成式任务的使用方式完全不同。分类模型拿一段文本，输出一个标签；生成模型拿一段 prompt，输出一段新文本。以开源中文对话模型为例：from transformers import AutoTokenizer, AutoModelForCausalLM model_name = "Qwen/Qwen2.5-1.5B-Instruct" # 开源可用的中文对话模型，也可换成你的本地路径 tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, trust_remote_code=True, torch_dtype="auto", ) prompt = "请用一句话解释什么是检索增强生成。" messages = [{"role": "user", "content": prompt}] text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = tokenizer(text, return_tensors="pt") gen = model.generate( **inputs, max_new_tokens=128, do_sample=True, temperature=0.7, top_p=0.9, ) response = tokenizer.decode(gen[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True) print(response)这里有几个关键点。第一，apply_chat_template会把用户输入包装成带助手前缀的完整消息，你必须用模型配套的模板，不能自己随便拼。第二，max_new_tokens控制生成的回复长度，不是控制输入长度。第三，do_sample=True配合temperature和top_p控制随机性，如果做实体抽取这类确定性任务，建议关闭采样，直接贪心解码，结果更稳。很多人第一次跑生成类任务会被“回答得太啰嗦”或“自问自答”吓到。这通常是模板没用对或者 temperature 太高。把 temperature 降到 0.5 左右，关闭include_special_tokens这类多余输出，效果会立刻干净许多。4. 微调不一定要全量：LoRA 参数高效微调的完整思路4.1 全量微调的显存账：为什么很多人望而却步拿到预训练模型之后，最直觉的做法是整个模型拿去自己的数据上接着训练，这叫全量微调。听起来简单，账却不一定算得过来。7B 参数的模型，用 FP16 存储，光参数就要 14GB。训练时还要保存梯度，又要 14GB。优化器如果用 Adam，还要存一阶和二阶动量，这两项合起来又是 28GB 左右。还没算你的训练数据、中间激活值，一张 24GB 显存的卡早就爆了。很多人第一次尝试微调大模型，错误信息只有一个：CUDA out of memory。所以 2024 年工业界的主流方案是参数高效微调，其中 LoRA 是最普及的一种。它的核心思路是：原模型参数全部冻结，不动；另外训练一小组新增参数，让这组参数学会“该往哪个方向微调”。4.2 LoRA 在做什么：冻结主干，训练旁路低秩矩阵LoRA 的理论基础是低秩分解。研究者发现，大模型微调前后权重的变化量 ΔW 通常是低秩的，也就是说这个变化可以用一个很小的矩阵组合近似。假设原来的权重矩阵是 W，微调后等价于 W' = W + ΔW。LoRA 把 ΔW 拆成两个小矩阵 A 和 B 的乘积，A 的维度是(输入维度, r)，B 的维度是(r, 输出维度)，其中秩 r 一般取 4、8、16。训练时，W 不动，只训练 A 和 B。这样可训练参数量从几十亿变成几百万。你可以把 LoRA 想象成给一个庞大的组织请顾问团队：正式员工工资不变，顾问团队只占很小预算，但他们的建议能让整个组织的输出风格明显改变。from peft import LoraConfig, get_peft_model from transformers import AutoModelForSequenceClassification base_model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=2, load_in_4bit=True, # 进一步压缩显存 ) lora_config = LoraConfig( r=8, # 低秩矩阵的秩，越大可学习容量越大，但显存也更多 lora_alpha=16, # 缩放因子，控制 LoRA 参数对原模型的影响强度 target_modules=["query", "value"], # 只对 attention 层的这两个模块加旁路 lora_dropout=0.05, bias="none", task_type="SEQ_CLS", ) model = get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 可训练参数通常只占 1% 甚至更少为什么target_modules选择 query 和 value？实践中最常见的是把注意力层的 Q、V 矩阵都加上 LoRA，因为注意力层的权重变化对任务影响最直接。有些做法也会加 K、O 和 FFN 层，效果会有提升，但显存和训练时间也随之上升。小数据集上不用一上来就全加，先 Q、V 就够了。4.3 一段能跑的 LoRA 微调脚本与关键参数微调脚本我用 transformers 的 Trainer 来写，它可以省掉自己写训练循环的很多边界处理。数据集用 datasets 库加载，保证格式统一。from datasets import Dataset from transformers import ( Trainer, TrainingArguments, DataCollatorWithPadding, ) # 假设 train_data 是包含 text 和 label 的列表 train_ds = Dataset.from_list([ {"text": "这个商品的体验超出预期", "label": 1}, {"text": "物流太慢，等了一周", "label": 0}, ]) def tokenize_func(batch): return tokenizer(batch["text"], truncation=True, max_length=128) train_ds = train_ds.map(tokenize_func, batched=True) training_args = TrainingArguments( output_dir="./lora_cls", per_device_train_batch_size=16, gradient_accumulation_steps=2, learning_rate=2e-4, num_train_epochs=3, fp16=True, save_strategy="epoch", logging_steps=50, remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_ds, tokenizer=tokenizer, data_collator=DataCollatorWithPadding(tokenizer), ) trainer.train()几个参数值得说明。learning_rate在 LoRA 里通常比全量微调大一个量级，我用 1e-4 到 5e-4 之间的值居多。全量微调切忌直接用这么大的学习率，否则很容易把预训练知识冲掉。gradient_accumulation_steps的作用是把多个小 batch 的梯度累加后再更新，相当于变相增大了 batch size。显存不够时，优先把 per_device_train_batch_size 调小，再用累积步数补回来。DataCollatorWithPadding会自动把同一个 batch 里的样本 pad 到等长，避免手动处理不等长输入。这个细节看着小，但能省掉很多报错时间。4.4 微调完之后的合并、保存与常见心态LoRA 训练完保存的是适配器参数，通常是一个几 MB 到几十 MB 的目录，而不是完整的模型。使用时有两条路：一是原模型加适配器一起加载，推理时先用PeftModel.from_pretrained(base_model, "./lora_cls")加载；二是把 LoRA 权重合并回原模型，得到完整的微调后权重。merged_model = model.merge_and_unload() merged_model.save_pretrained("./lora_cls_merged") tokenizer.save_pretrained("./lora_cls_merged")合并的好处是部署时只需加载一份模型文件，推理速度更快。缺点是合并后的文件还是全量大小，存储成本高。我的经验是：实验阶段保留 LoRA 适配器文件，上线阶段再合并导出。还有一个很多人提过但我必须重复的心态问题：微调不是万能药。如果你的数据量只有几十条，LoRA 也不会给你变出魔法。数据质量永远是第一位。先整理清晰、标签一致的数据，再谈训练参数。小样本情况下，宁可先跑几次全量推理，人工检查 prompt 是否能解决问题，也不要盲目开训练。5. 给模型装一个外接知识库：RAG 检索增强生成的工程拆解5.1 RAG 解决的是幻觉和知识过期，不是包装概念如果你微调过一个 7B 模型，会发现一个很现实的问题：它可以写出通顺的回复，但一本正经地编造不存在的“内部政策”或“产品参数”。原因很简单，模型参数里的知识是训练时定死的，训练数据截止之后的新知识它不可能凭空知道。同时，细粒度的私有知识本来就不可能靠微调全部灌进参数。检索增强生成（RAG，Retrieval-Augmented Generation）的思路是改变信息来源：不强迫模型把答案背在参数里，而是在回答问题时，先从外部知识库检索相关资料，再把资料拼进 prompt，让模型基于资料回答。这相当于考试时允许翻书，比考前把所有内容背下来可靠得多。RAG 最适合的项目形态是：企业知识库问答、私有文档助手、客服助手等。它不需要重新训练模型，知识更新只需更新文档库，成本远低于微调。5.2 搭一条最小可用的 RAG 管线RAG 管线看起来环节多，但拆开就是五步：加载文档、切块、向量化、检索、注入生成。给你一个最简单但能跑通全流程的版本。先做文档切块。切块是 RAG 里最影响效果的一步。我在生产项目里常用的参数是 chunk_size 取 300 到 500 字符，chunk_overlap 取 50 到 80 字符。这个数值不是经验玄学：太小的块召回时容易断章取义，一个完整政策被切成七零八落，模型根本看不出前因后果；太大的块噪声多，检索分数容易被无关内容稀释。from sentence_transformers import SentenceTransformer # 中文场景建议使用支持中文的embedding模型，这里用通用示例 embedder = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") # 假设 docs 是已经切好的文本块列表 doc_chunks = [ "退换货政策：签收后七日内可申请无理由退换货……", "物流说明：工作日下午四点前下单，当天发货……", "售后联系：客服工作时间 9:00-18:00……", ] doc_vecs = embedder.encode(doc_chunks) query = "我买的商品不喜欢，能退吗" query_vec = embedder.encode([query]) # 计算余弦相似度，取 top-3 scores = cosine_similarity(query_vec, doc_vecs)[0] top_idx = scores.argsort()[-3:][::-1] print([doc_chunks[i] for i in top_idx])这一步没有向量数据库也能跑，数据量小时候直接算相似度完全够用。数据量到了百万级，再引入向量检索服务也不迟。拿到检索结果后，拼 prompt 的方式很关键。我的习惯是：请仅根据以下资料回答问题，不要使用资料之外的知识。 资料1：…… 资料2：…… 问题：……首句“仅根据资料回答”能显著减少模型自由发挥的概率。注入的顺序也要注意：最相关的资料放在最前面，因为模型对 prompt 开头和结尾的内容记忆更牢，顺序颠倒可能导致关键信息被长资料淹没。5.3 切块、召回、注入顺序：三个最容易翻车的环节用 RAG 的人十有八九会遇到这几个问题，我挨个说。召回质量差是这个方案最大的痛点。很多人跑通 demo 后发现答案驴唇不对马嘴，第一反应是换更强的生成模型，其实问题往往出在 embedding 模型和切块策略上。优先排查点：查一下召回的 top-3 里到底有没有正确答案。如果答案根本不在召回的文本块里，那再强的 LLM 也答不对。此时你要做的是调整切块大小，或者换更适合领域的中文 embedding 模型，而不是去调生成参数。相似度阈值不要拍脑袋。有人喜欢设“余弦相似度大于 0.7 才算命中”，但不同 embedding 模型的分数分布差异极大。有的模型相似度普遍在 0.6 到 0.8 之间，有的模型集中在 0.2 到 0.4。正确做法是拿一批标注了正确答案的样本，统计分析“正确命中的最低分”和“错误命中的最高分”，再决定阈值。上下文注入长度也要克制。很多人把检索到的所有相关片段全部塞进 prompt，认为越多越好。模型上下文窗口是有限的，塞了 5000 字资料后，真正有用的细节可能被淹没，还拖慢推理速度。我一版建议限定只注入 3 到 5 个强相关片段，总共不超过 1500 字。如果业务确实需要长上下文，优先考虑分段回答。6. 别靠感觉调模型：NLP 项目的评估体系搭建方法6.1 传统的分类指标：别只用准确率NLP 项目的惨痛教训之一，是完全用准确率衡量模型。假设你的数据里 95% 是负样本，模型只要全部预测为负，准确率就有 95%，但它对你的业务毫无价值。必须看精确率、召回率和 F1。精确率关心“模型说是正类的里面，有多少真的为正”，召回率关心“真正的正类里，模型找回了多少”。这两个指标常常互斥，F1 是它们的调和平均。对客服工单分类这类业务，漏掉一个紧急工单的代价很高，就要偏重召回；对垃圾评论过滤，误伤正常用户代价更高，就偏重精确率。分类评估还需要看混淆矩阵。它能告诉你哪些类容易被混在一起，这往往是数据标注不清或类别定义重叠的信号。如果“售后与退换货”两个类别频繁互相误判，回到标注规范去改数据，比继续调参有用得多。6.2 BLEU 和 ROUGE 的局限：生成任务要小心到了生成任务，评估一下子变得困难。很多人沿用机器翻译时代的方法，用 BLEU、ROUGE 这些基于 n-gram 重叠的指标。它们能一定程度上衡量生成文本和标准答案的字面相似度，但局限非常大。“这部手机电池很经用”和“这部手机续航表现相当好”意思几乎一样，但字面 n-gram 重合度很低，BLEU 会给一个很差的分数。反过来，一段词汇完全一样但语序错乱的内容，字面重合度可能很高，实际完全不可读。所以我在生成类项目里，只把 BLEU、ROUGE 当作快速看趋势的粗筛工具，绝不把它当最终质量标准。6.3 LLM-as-Judge：让大模型当评分员，但别完全放手2024 年业界更多采用“用一个大模型给另一个大模型的输出打分”的做法，简称 LLM-as-Judge。方法不复杂：把待评文本、参考标准、评分维度都放进 prompt，让评分模型输出 1 到 5 分或分维度打分。要让打分可靠，核心是写清楚评分规则。比如：请从相关性、完整性、忠实度三个维度打分，每项 1-5 分。 相关性：回答是否紧扣问题。 完整性：是否覆盖问题要求的全部要点。 忠实度：是否基于给定资料，有无编造。 不要因为回答长度长就给高分。其中“不要因为长度长就给高分”这类纠偏提示非常关键。最早我用 LLM 打分时，发现模型偏爱又长又绕的答案，加了这个约束后分数才有区分度。另一个稳定技巧是让评分模型多次采样取平均，或者用两个不同模型互相校验，减少单个模型打分偏好带来的偏差。6.4 攒一个黄金回归集，比写一百行 prompt 更值评估体系的真正核心，不是指标有多复杂，而是你有没有一个固定不变、覆盖面广的回归测试集。我习惯叫它 golden set，里面放三类样本：业务侧最常见的典型问题、之前线上翻过车的 bad case、以及边界条件样本。规模不用大，50 到 200 条常常就够用。每次改动 prompt、微调数据或模型版本，都在这个集上跑一遍，记录分数变化。如果总分提升但某个重要 bad case 变差了，就要谨慎上线。我自己固定每周更新一次 golden set：凡是线上新发现的问题案例，盘点后立刻补充进去。这个习惯会让项目越到后期越稳，因为回归集积累的是真实世界里的坑，而不是拍脑袋想出来的完美问题。7. 上线才是真正的开始：显存估算、推理优化与降级方案7.1 先算账：显存和成本的大致估算很多人开发时用一张消费级显卡跑通模型，就以为部署很容易，真到上线才发现显存不够、响应延迟超标。部署前花十分钟算一笔账，能避免后面手忙脚乱。推理显存的粗略公式是：模型显存约等于参数量乘以每个参数占用的字节数。FP32 是 4 字节，FP16 是 2 字节，INT8 是 1 字节，INT4 约 0.5 字节。比如一个 7B 模型用 FP16 推理，参数至少占 14GB，再加上 KV cache 和运行时开销，实际单卡 24GB 才比较从容。换成 INT4 量化后，7B 模型只要约 4GB 参数空间，很多消费级显卡也能跑。但量化不是免费的。INT4 量化可能让模型在复杂推理任务上出现明显质量下降。我的建议是逐步尝试：先在 FP16 上跑通功能，再试 INT8，如果评估集指标没有明显下滑，再考虑 INT4。上线前必须用黄金回归集重新测一遍，不能只看显存数字。7.2 推理优化的三条路线：量化、连续批处理、工程缓存显存只是第一关，延迟和吞吐才是线上最头疼的问题。按投入产出比排序，我会先说工程缓存。工程缓存指的是把重复的查询结果存起来。很多人第一反应是用精确哈希做缓存，但实际用户问题表述千变万化，完全相同的文本比例很低。更有效的方式是：把用户 query 做 embedding，向量相似度高于阈值时直接返回缓存答案。对客服助手这类场景，Top 20 热点问题的缓存命中率可能达到 30% 以上，响应时间直接从秒级降到毫秒级。第二路线是量化加速。除了降低显存，量化还能减少显存带宽压力，这在 GPU 推理里经常比算力更关键。配合批量推理，吞吐量提升显著。如果你的场景是智能客服这种高并发短文本，量化加批量几乎是标准配置。第三路线是实现连续批处理。传统批处理是攒一批请求再一起推理，缺点是高矮个互相拖累，最短的请求也要等最长的跑完。连续批处理把不同请求的生成过程交错执行，先结束的先返回，从而显著提高 GPU 利用率。开源的推理框架很多已经内置了这个能力，你只需要把模型导出成对应格式，不必自己实现复杂调度。7.3 降级与兜底：模型挂了不能只剩报错生产环境里最容易被忽略的是降级方案。大模型推理服务偶尔会因为长尾输入、显存异常或后端波动而超时，如果没有兜底，用户看到的就是一个转圈后报错的页面，体验非常差。我的建议是至少准备两层降级。第一层：模型服务超时后，返回预设的热门 FAQ 或简短提示，而不是直接报 500。第二层：如果超时率达到阈值，自动把流量切换到 lite 模型或规则匹配，保证核心功能不中断。还有一个小细节：生成模型的超时时间要单独设置。分类模型 200 毫秒能返回，生成模型回答几百 token 可能耗时好几秒。如果复用同样的超时配置，很容易误杀正常请求。我通常按“预估生成长度乘以单 token 预计耗时，再留 50% 余量”来配置超时时间，同时给前端流式输出方案，提升用户等待体验。最后一件事：上线后必须持续监控。不用只看模型指标，更要看业务指标，比如用户问题解决率、转人工率、投诉率。模型指标再漂亮，用户不买账也是白搭。把 golden set、线上日志、人工反馈串成一个循环，每周复盘一次，NLP 项目才能从一个“能跑的模型”变成一个“可靠的系统”。