这两年做NLP的朋友应该都有一种很直观的感受：手里的武器库变了。两年前大家见面聊的是分词准不准、词向量训得深不深、CRF还是BiLSTM，现在坐在一起开口就是“你那个RAG的召回率拉起来没有”“微调用QLoRA跑得多卡”。Python生态依然是绝对主战场，但同样的语言，干的事已经完全换了一批。这个系列前几篇把分词、词向量、经典序列模型、Transformers基础都梳理了一遍，这一篇集中聊聊2024年AI时代，用Python做NLP到底应该把重心放在哪里，哪些传统技能不能丢，哪些新工具必须补上，以及一套能直接落地的系统该怎么做出来。
这篇内容适合三类人：一是刚学完NLP基础、想知道下一步往哪儿走的人；二是已经在用大模型API做业务、但总觉得效果飘忽不定的开发者；三是传统NLP转大模型方向、需要一套系统认知框架的工程师。如果你已经跑通了基础的文本分类和相似度计算，这篇正好帮你把这些能力升级成真正的生产级方案。文章里的思路和踩坑记录都来自实际项目，不是什么教科书上的标准答案，但每一条都有据可查、可复现。
1. 从“训练模型”到“组装系统”：2024年NLP的范式转移
1.1 范式转移的本质：不是不用训练了，是训练的位置变了
过去我们做一个文本分类任务，路径是很标准的：清洗数据、切分训练集、用BERT类模型微调、评估F1、上线。这个过程里，模型是项目的中心，所有工作都在围绕“把模型训得更好”展开。2024年的情况完全不一样了：大模型承担了绝大部分的语义理解能力，你不需要再从零教它什么是情感、什么是实体，它本身就已经“懂”了。你的工作重心变成了两件事——怎么把数据喂到它面前，以及怎么把它的输出接回你的业务流程里。
这不是说“不用训练了”，而是训练的形态变了。对于通用能力，你直接用现成的模型；对于私有知识，你通过检索补进去；对于特定的说话方式或输出格式，你再考虑微调。用我常跟人讲的一句话说：以前你是厨师，要从买菜、切菜开始做一道菜；现在你是餐厅老板，后厨有现成的顶级大厨，你要做的是设计菜单、把控上菜流程、处理客人反馈。你依然要干活，但干活的层次完全不同了。
这个转变带来的最大影响其实在工程侧。以前一个NLP项目的技术栈很统一：框架加数据集加显卡。现在呢？系统里可能有向量数据库、有缓存层、有调度多个模型服务的网关、有回流标注数据的闭环。Python依然是串联这一切最好的胶水语言，但你得同时懂prompt设计、检索优化、服务部署，甚至还要会看推理成本账单。
1.2 Python生态的重心迁移：这些库才是当前主线
传统的Jieba分词、HanLP这些库还是挺重要的，但它们的位置已经从“核心引擎”退到了“前置工具”。真正的主线生态变成了这三个方向：
第一个是模型加载与推理方向。拥抱脸家的Transformers库依然是事实标准，但2024年跑大模型的主力工具已经越来越偏向推理优化那一挂，比如vLLM做高并发推理、llama.cpp做CPU推理和边缘部署，还有safetensors做权重格式的管理。你得养成一个习惯：拿到一个开源模型，第一步不是直接load，而是先看它有没有做量化的版本、官方推荐用哪个运行时，这直接决定你在哪里能跑起来。
第二个是应用组装方向。LangChain和LlamaIndex这类框架争议很大，很多人说它们过度封装、版本像过山车，但不可否认它们把RAG、Agent、工具调用这些复杂流程抽象成了可配置的模块。我的态度很明确：项目第一天用它们来搭骨架，效率极高；一旦流程稳定了，核心路径上的关键环节一定要手写或者至少读一遍源码，不然出了问题只能干瞪眼。
第三个是向量检索方向。sentence-transformers负责把文本变成向量，FAISS负责管理这些向量并提供近邻检索，加上Milvus或Qdrant这样的专用向量数据库负责生产级存储。这三个组合起来，就是2024年几乎所有语义搜索和RAG系统的地基。
1.3 成本与效果曲线：什么时候调API，什么时候必须上开源
很多团队一聊到大模型就默认要调商用API。但是你在实际项目里跑两个月就会发现问题：短期看API便宜，但是当你的调用量到了每天几十万次、且每次要传一大段包含上下文的文本时，账单增长速度会超出你的预期。反过来，自己部署开源模型，前期要买卡、要调优、要折腾推理引擎，但是跑起来之后边际成本极低，数据也不用出内网。
我的判断标准是这个：如果你的业务需要极致的通用能力，尤其是逻辑推理、复杂指令跟随、多语言混写，这一类直接用商用API是最靠谱的。如果你的任务相对固定，比如你是做私有知识库问答、特定领域的信息抽取、maybe就是客服意图识别，那开源的7B到14B模型经过合理配置，效果完全可以追平API，成本却能差一个数量级。
另外一个很重要的变量是稳定性。商用API的版本迭代不是你能控制的，今天用的模型明天可能换版本，你的prompt全部要重新调。开源模型没有这个问题，权重锁死了，效果就是确定的。对toB交付项目来说，这种确定性往往比模型能力更重要。
2. 向量检索与语义搜索的实战套路
2.1 为什么2024年语义搜索成了NLP的基操
很多老NLP工程师第一次做向量检索时都会有一个疑问：我们以前用BM25、用TF-IDF不是也能做搜索吗？为什么非要换成向量？答案是两类方法的语义理解能力差了一个维度。
关键词搜索的本质是字面匹配。用户搜“怎么解决登录闪退问题”，如果你的知识库里只有“客户端启动异常”，关键词完全不沾边，它就搜不到。向量搜索的本质是语义匹配——把文本映射到高维空间里的一个点，含义相近的文本距离就近，所以“登录闪退”和“客户端启动异常”这两句话的向量是接近的，即使在字面上一个词都不重叠，也能正确召回。
这个能力在2024年已经不是“加分项”而是“基操”了，因为所有业务都会积累大量非结构化文本，文档、工单、聊天记录，这些内容传统的数据库和ES都只能做字面检索，做不了理解。有了语义搜索，等于给你的存量数据装了一只眼睛。但这里面有个很核心的坑：向量检索不是万能的，它做相似度召回很强，做精确匹配很差。搜订单号、身份证号、版本号这种精确字符串，你必须配合传统检索一起做。这也是后面要讲的混合检索的意义。
2.2 Embedding模型选型：中文场景的实测建议
语义搜索的效果，八成取决于你选Embedding模型而不是算法调优。2024年中文Embedding领域已经卷得比较成熟了，主流选择有BGE系列、M3E、以及各类商用API的向量接口。实测下来，BGE系列在中文语义相似度和检索任务上的综合表现最稳，尤其是它都有配套的量化版本，召回率掉得不多，但内存占用和查询速度改善非常明显。
这里给你一个自查清单：第一，看它有没有专门的检索优化版本，很多Embedding模型在通用语义相似度上表现好，但在“给定query找相关文档”这个任务上并不一定强，检索场景要选有针对性的模型或者用指令跟随的方式调用；第二，看它对最长输入长度的限制，中文场景经常有很长的段落需要向量化，如果模型最多支持512个token，你的长文档就得靠后面讲的切分逻辑来配合；第三，看它的词表里中英文覆盖情况，有些模型对中文缩写和专有名词的支持比较弱，实测会出现同一个实体不同的写法被映射到很远的位置这种问题。
选型的另外一个重点是维度数和索引规模的关系。Embedding维度越高，单个向量占的内存越大，检索时计算量也越大。在百万级文档的场景下，BGE-large的1024维和BGE-small的512维，索引体积和查询延迟能差到4倍。不是所有场景都需要高维度，业务初期直接用small版本往往更划算。
2.3 文本切分（Chunking）策略：决定检索效果的上限
向量检索出来效果差，十有八九不是模型的问题，是文本切分切得不对。这个点特别容易被我刚入门那会儿忽略，觉得切分不就是按长度切吗，有什么技术含量。实际做下来才发现，切分粒度直接决定了目标信息能不能被正确命中。
举个例子，你有一篇3000字的产品操作手册，讲三个功能模块。你按500个字符硬切，很可能把功能A的最后一段和功能B的第一段切进了同一个块，语义被稀释了，query进来之后就没有一个块能精准对应到某个功能。更合理的做法是先按文档结构拆——标题就是天然的边界，把同一标题下的内容作为一个段落单位，如果段落还是太长，再按递归的方式细分，优先保留语义完整性。
实际工程里，切分策略通常有三个层级。第一层是结构切分，利用文档里的换行、标题层级、列表标记来做粗切；第二层是按句子和长度做递归切分，大型模型库都有现成的递归切分器，它会尽量把内容断在句号或换行处，而不是把一句话拦腰截断；第三层是语义切分，用模型判断文本的主题是否发生转折，这个效果最好但成本也最高，一般用在小部分高质量语料的场景。记住一个原则：宁可让每个块短一点、多一点，也不要让一个块里揉进多个主题。块短了召回精度高，切碎了一点召回率也不至于崩，但块长了主题混杂，召回精度必崩。
2.4 FAISS实战：从建立索引到语义检索的完整代码
FAISS是当前最常用的向量检索库，Meta家的开源项目，Python接口非常友好。下面这段代码展示了一个最小的完整检索流程：生成向量、建索引、查询。为了让你能直接跑，我用了sentence-transformers加载一个通用的Embedding模型做演示。
from sentence_transformers import SentenceTransformer import faiss import numpy as np # 1. 加载Embedding模型 model = SentenceTransformer("BAAI/bge-small-zh-v1.5") # 2. 准备文本库 docs = [ "如何重置密码", "登录时提示账号已被锁定应该怎么办", "支持哪些支付方式", "发货之后多久能到", "如何申请售后维修", ] # 3. 向量化文档 doc_vectors = model.encode(docs, normalize_embeddings=True) dimension = doc_vectors.shape[1] # 4. 构建FAISS索引 index = faiss.IndexFlatIP(dimension) # 内积索引配合归一化向量，等价于余弦相似度 index.add(doc_vectors) # 5. 查询 query = "忘记密码了，怎么登录？" query_vector = model.encode([query], normalize_embeddings=True) scores, indices = index.search(query_vector, k=2) print("Top1命中：", docs[indices[0][0]]) print("相似度：", scores[0][0])这段代码跑完之后，你会发现“忘记密码了，怎么登录？”正确命中了第一条“如何重置密码”，而用纯关键词搜索大概率会失败。这就是语义检索第一步的价值。
索引选择方面，IndexFlatIP是暴力精确检索，数据量到了百万级之后延迟会明显上升，这时候要换IVF（倒排量化索引）或者HNSW（基于图的索引）。我实际项目里，百万级文档用HNSW，把查询延迟控制在几十毫秒内完全没问题。另外记得做归一化，这样内积就等于余弦相似度，距离度量的语义更直观。
2.5 别丢掉关键词：混合检索的融合策略
向量检索做了三个月之后我踩过一个很现实的坑：用户搜索一个精确型号，比如“HN-2000”，向量召回把意思相近但型号不同的东西全捞上来了，精确的那条反而排到后面去了。你单独用向量搜索，这是无解的，因为这个模型根本没见过这个型号，它只会按语义泛化。
混合检索就是把词法检索和向量检索一起用。词法端用BM25，擅长匹配专有名词、型号、精确短语；向量端用语义匹配，擅长同义改写和意图理解。两者各返回一批候选文档，然后做结果融合。融合方法有很多：简单点的做加权求和，高级点的用RRF（Reciprocal Rank Fusion，倒数排名融合）。RRF的思路很简单，每个文档在两个结果列表里的排名取倒数，然后相加排序。它不依赖评分分布，所以特别适合两个异构检索器的结果合并。
我的经验是混合检索的收益非常惊人，尤其是涉及代码、合同编号、产品型号这类内容时。在内部知识库问答场景里，纯向量搜索的Recall@10大概在65左右，加上BM25做混合之后能到85以上，这不是调参调出来的差距，是机制的差距。
3. RAG落地：让大模型学会看你的私有文档
3.1 RAG为什么成了私有知识问答的默认解
让我先解释一下RAG解决的是什么问题。大模型的知识截止于它的训练数据，你问它2025年发布的新产品它肯定瞎编，你问你们公司内部的报销流程它也完全不知道。传统上解决这个问题有两种方案：一种是把知识直接写进prompt里，第二种是微调模型。前者受限于上下窗口长度，后者成本高而且更新知识要重新训练。
RAG的思路是把知识放在外部数据库里，每次用户提问时先去数据库里检索相关内容，把检索到的片段作为参考材料拼进prompt，再让模型基于这些材料回答。这个方案本质上不改变模型，只改变模型的输入。它的好处很明显：知识可以随时更新，加一篇新文档马上就能被检索到；回答可以溯源，模型是基于明确的参考材料作答的，能降低胡编乱造的概率。
拆开看，一个RAG系统就是三条管道。一条是文档入库管道，负责把各种格式的文档清洗、切分、向量化后写入向量数据库。第二条是检索管道，负责把用户的问题转成向量，去向量库里找最相关的片段，这一步还经常会配合关键词检索做混合召回。第三条是生成管道，把检索到的片段和原始问题按设计好的模板拼起来，交给大模型生成回答。听起来不复杂，但每一个环节都有几个深坑等在那里。
3.2 从文档到向量：入库管道的完整流程
入库管道的核心目标就一条：让原始文档变成适合检索的向量块。我常用的流程是这样：
第一步是文档解析。PDF、Word、Markdown、HTML，每种格式都有坑。PDF最麻烦，有的扫描件需要OCR识别，有的排版复杂直接抽取文本会乱序。Word要注意分页符和页眉页脚混入正文。我的经验是先统一转成纯文本或者Markdown，再进入后续处理。
第二步是内容清洗。把页眉页脚、页码、超链接、乱码字符这些东西去掉。这一部做不好，向量库里就会混入大量无意义片段，检索时反复被捞出来，非常影响回答质量。
第三步是结构化切分。先用标题层级切出章节块，再对超长块做递归切分，同时尽量让相邻的块之间保留一小段overlap，避免信息被拦腰截断。overlap设为50到100个字符就够了。
第四步才是向量化入库。这里有个容易被忽视的关键点：Embedding模型需要处理的是切分后的块，而不是整篇文档。你要保证入库时用的向量化方式和查询时完全一致，同一个模型、同一套预处理逻辑。很多项目效果不稳定，查了半天发现是入库用了一个模型、查询用了另一个Embedding接口，语义空间根本对不上。
3.3 检索质量的关键：query改写与rerank
很多RAG系统在Demo阶段表现良好，一上真实环境就崩，问题多半出在用户怎么提问。用户在搜索框里打的词经常缺主语、带口语、甚至还有错别字——比如“那个售后政策咋说的来着”。这种query直接做向量化检索，效果肯定不好。专业的做法是加一个query改写环节，让大模型先理解用户的问题，改写成一句规范、完整的搜索语句，再拿改写后的语句去检索。
Query改写之后再往上走一层，就是重排。向量检索的Top20里面，前面几条不一定都是对的，但对的通常都在Top20里。重排器的思路是拿一个交互式匹配模型，把query和每一条候选文档拼成一个输入，让模型计算出更精细的相关性分数，然后基于这个分数重新排序，只取前5条送进生成管道。
重排这一步在效果上的提升是“质变”的。不重排的时候，答案可能精确度只有60%；加了重排，可能直接拉到85%。这个差距不是因为检索模型不好，而是因为初检模型和精排模型的结构本身就不同——初检模型用双塔结构计算向量距离，速度快但粒度粗；精排模型是交互式结构，query和文档在模型内部做token级别的注意力交互，理解粒度细得多。两者配合，一个负责宽召回，一个负责精排序，这才是工业级的标准姿势。
3.4 生成环节：把检索结果变成可信回答
生成管道的代码看起来不起眼，无非是拼一个prompt再调一次模型，但实际的坑特别多。下面这个是我在项目里验证过的一个基础模板结构：
你是一个企业知识库问答助手。请严格基于下面的参考资料回答用户问题。 如果你无法从参考资料中获取答案，请直接回答"资料库中未找到相关信息"，不要编造。 参考资料： [1] 标题：发票报销流程，内容：员工在每月25日前通过系统提交报销申请... [2] 标题：发票类型说明，内容：目前支持的发票类型包括... 用户问题：发票最晚什么时候提交？这个模板的几个关键设计是：明确告诉模型只使用参考资料作答，这是抑制幻觉的第一道防线；要求模型在找不到答案时坦承未知，不要硬编；给资料片段加了引用编号，方便模型在回答里标注对应关系，也方便前端做溯源展示。格式上用了分点编号，让模型更容易在回答里引用，比如“根据资料[1]，报销需在每月25日前提交”。
关于生成参数还有个大坑：temperature。很多人习惯设成0.7甚至更高，但RAG场景下temperature超过0.3之后，回答风格越来越“活泼”，但同时开始出现资料里没有的细节。RAG要的是确定性，要的是忠实于资料，temperature设0.1到0.2就够用了。
最后是回答质量的兜底。项目上线初期我强烈建议加一层答案校验：让大模型检查自己生成的回答是不是都来自参考资料，或者用规则检查是否包含“可能”这类不确定词。如果校验不通过，宁可回答“暂不确定”也不要硬发出去。用户对系统性知识库的信任建立起来很慢，一次瞎编就能毁掉。
4. 本地微调：哪些场景真正值得做
4.1 微调、提示工程、RAG的取舍矩阵
每一个做NLP的同行，在面对一个新需求时都会问自己一个问题：这三条路到底走哪条？我把自己的判断标准整理成了一张表，你按这个表去套基本不会错。
| 需求特征 | 推荐方案 | 原因 |
|---|---|---|
| 知识更新快、内容来自业务文档 | RAG | 文档一改，检索结果立刻变，不需要重新训练 |
| 输出格式必须严格固定 | 提示工程 + 微调 | 简单格式用提示词约束即可，复杂格式再考虑微调 |
| 说话风格、角色感需要统一 | 微调 | 风格是一种隐性特征，提示词很难稳定复制 |
| 模型不知道的私有知识 | RAG | 这是RAG的主场，微调记知识效率低且容易记错 |
| 需要成本极低的批量处理 | 提示工程 | 纯调用API，无需基础设施 |
这里要重点提醒一句：微调不适合用来“教模型新知识”。很多团队第一次做微调，喂了几百篇内部文档进去，指望模型记住业务规则，结果模型在测试集上表现还凑合，换个问题就开始编。为什么？因为微调的本质是调整模型的输出偏好和风格，不是往神经网络的某个角落塞知识。你给它喂再多的文档，它的参数量就那么大，记不住也分不清哪些是事实、哪些是你的偏好。想要知识进得去、出得来，RAG那套检索是标准姿势。微调加RAG的正确关系是：RAG负责提供事实，微调负责规定说话的方式。
4.2 LoRA/QLoRA的原理一句话版
我尽量用一句话讲清楚LoRA的原理：它不修改原始模型的全部参数，而是在每一层权重旁边挂一个低秩的小矩阵，训练时只更新这些小矩阵，最后把更新叠加回原权重上。这样做的好处是训练参数量骤降到原来的千分之一级别，一块消费级显卡就能微调7B甚至14B的模型。量化版的QLoRA更进一步，把原始模型量化到4-bit，进一步压低显存占用。
这块你如果只想上手，记住这几个数字就行：7B参数级别的模型，用QLoRA在单张24GB显存的卡上就能微调；14B级别的，单张48GB或两张24GB也够用。用不上以前那种一个团队凑几台八卡机的日子，这确实是2024年最振奋本地开发者的变化。
4.3 微调全流程的实用配置
数据准备是微调里最关键的环节。主流开源模型都支持对话式微调，数据格式是三段式：instruction（指令）、input（输入）、output（回答）。这里给一个最简单的数据样例：
{"instruction": "将下面的句子改写为更礼貌的说法", "input": "你赶紧把文件发给我", "output": "方便的话，请尽快把文件发送给我，谢谢！"}微调的数据量有个反直觉的结论：不是越多越好，而是要精。网上很多教程一上来就让你攒几万条数据，我实测下来，一个清晰统一的任务，800到2000条高质量数据就能看到明显效果；数据质量不行，五万条也是在教模型学噪音。检查数据时重点看三件事：第一，output里有没有模型无法从input推出的内容；第二，同一个任务的instruction的措辞是否统一，格式混乱会让模型学不到规律；第三，有没有相互矛盾的样本，比如同一种输入场景给了两种相反的期望输出。
训练侧的配置给一个参考值：batch size设4到8，学习率用常量的中等大小不要太大，比如2e-4，训练轮数控制在1到3轮。轮数超过3轮之后很容易过拟合，具体表现是模型在训练集上什么都会，在测试集上开始复读训练数据里的句子。训练完成之后一定要做一次“能力对比”，把微调前后同一个测试集上的输出拉出来并排看，确认微调没有伤到模型的通用能力，这个步骤很关键，因为有些模型微调后任务做得好，但推理能力暴跌。
5. 传统NLP工具在AI时代的正确用法
5.1 清洗和预处理依然是整个链路的命门
大模型输入的是文本，但文本的质量完全由上游的清洗决定。你拿一份从网页爬下来的内容，里面有几十条导航链接文本、广告位文案、乱码的HTML实体，如果不处理干净，后面的向量化和生成都会把这个噪音学进去。这个环节传统NLP的经验完全适用，我甚至觉得越是在大模型时代，清洗这项工作越重要——因为大模型对输入中的格式噪音极其敏感，一个多余的换行都可能影响输出的格式稳定。
实际项目里我始终保有一整套清洗流程：HTML标签去除、全角半角统一、URL和邮箱脱敏、连续空格和空行压缩、特殊符号过滤。不要觉得这些是low活，很多生产级RAG系统检索效果差，不是模型不行，是文档里混着大量导航菜单和版权声明，把向量空间搅浑了。知识库的“干净度”和回答准确率是强相关关系，这个结论在我做过的多个项目里都得到验证。
5.2 分词、词性标注和实体识别的新角色
传统NLP组件在新架构里的位置变了，但并没有消失。最典型的例子是实体识别。大模型虽然能做命名实体抽取，但在特定领域——比如医疗机构名、药品规格、零件型号——它的识别准确率和稳定性远远比不上一个用领域词典加规则构建的小实体识别模块。所以我在RAG链路里经常在检索前加一步：先用规则和词典在query里抽出已知的实体，再用实体去做一次精确匹配。这样既享受了大模型的语义理解，又保住了专有名词的精确性。
分词也是同理。很多人觉得有了BERT之后分词就没用了，其实在中文场景下，分词依然是很多下游环节的稳定基石。比如倒排索引里的词条、实体词典的匹配、敏感词过滤，这些都是基于分词结果工作的。你可以不用分词去训练模型了，但不能不用分词去做精确检索和内容治理。AI时代最好的姿势是把传统组件当成“工具函数”，在必要的位置精准调用，而不是试图用一个大模型包办一切。
5.3 用规则和向量双重做内容安全与质量门禁
大模型生成的内容不可控，这是2024年每个NLP工程师都要面对的课题。我的防线从来不是单靠某一个模型，而是规则和AI一起上。
第一层是规则过滤：敏感词库、正则匹配、格式校验。这一层负责能明确判定的东西，比如身份证号格式不对、包含违禁词、超长输出。规则层最大的价值是确定性和零成本，它不会犯迷糊。
第二层是语义审核：用一个独立的审核模型或API，对模型生成的内容做意图和风险判断。这一层负责规则看不出来的东西，比如一段看起来正常但暗含不良诱导的话术。
第三层是业务校验：用与业务相关的约束条件去检查输出，比如金额单位是否错乱、日期是否在合理范围内、答案是否引用了提供的参考材料。这层能拦住前两层漏掉的“看似合理实则错误”的幻觉内容。我个人体会是，任何生成式应用上线前都值得过一遍这三层门禁，线上翻车的概率能直接降一个数量级。
6. 评估体系与项目踩坑实录
6.1 检索评估：用Recall@k和MRR量化“找到没有”
很多RAG系统上线后说不清自己效果到底行不行，就是因为缺一套量化评估。检索端的评估指标比较简单，最常见的是Recall@k，意思是在前k个返回结果里，包含正确答案的比例。另一个是MRR（倒数排名指标），它关心的是正确结果排在第几位，第一位得1分，第二位得0.5分，以此类推。生产环境里我习惯同时看这两个：Recall@k保证兜底能力，MRR衡量排名的精准度。
做法上要先准备一批评测query，每条query标注它对应的正确文档ID。然后跑检索，计算指标。业务上线前这个评测集必须做好，因为它直接指导你的切分策略、Embedding选型和重排模型要不要加。
6.2 生成评估：三件套的组合拳
生成端的效果评估比检索端难得多，因为没有一个标准的正确答案。我现在工业界的评测方案是三件事叠着用。
第一是自动评测指标。ROUGE和BLEU这类指标已经被证明和人的感受相关性有限，但作为回归测试的底线，至少能发现“这次改动后输出是不是明显变了”。更适合我们的是基于语义相似度计算生成答案和参考答案的一致性，用一批Embedding模型算相似度，拿分数当代理指标。
第二是LLM-as-Judge。让大模型根据一套明确的评分标准给另一个模型的输出打分，比如相关性、忠实性、完整性各打1到5分。我自己的经验是，这个方案已经越来越多被生产团队采用，但要注意：打分模型本身也有偏差，它可能偏爱某些风格的答案。所以评分标准要写得极细，并且定期抽检打分模型的判断合理性。
第三也是最重要的，是人工抽检。不管前两个方案多先进，核心评测集一定保留一部分由人来看。人工审核样本量不用大，每轮改动抽100条左右就够发现趋势性问题。真实项目里最可怕的不是“效果差”，而是“不知道改了之后到底是变好还是变差”，有了这套三件套，每次改动都有依据。
6.3 实践中的五个高频坑
第一是上下文超限。RAG系统为了“多提供些资料给模型参考”，每次拼一堆文档进去，结果超出模型的窗口限制。这个问题不用多解释，核心解法是克制——检索Top5就够了，每个块的长度控制在合理范围，宁缺毋滥。
第二是检索到重复内容。同一份文档在库里存在多个副本，或者切分时重叠太多，向量检索会把内容高度相似的多块都召回，生成模型读到的参考资料大量冗余，回答质量反而下降。入库前的去重这环节不能省。
第三是格式要求传不进生成环节。有时候明明prompt里写了“请用列表回答”，模型还是输出一大段文字。这种情况往往是参考资料的格式干扰了模型对指令的跟随。解法是给prompt加示例输出，而不是反复强调指令本身。
第四是时区、数量单位这些细粒度信息的错误。模型对数字的把握能力早就被诟病，RAG场景里它还会把资料里的数字抄错。上线前一定要针对规则的数值类字段做专项校验。
第五是最容易被忽略的冷启动知识。知识库上线时只有几百篇文档，检索效果会很差，因为向量空间的分布还没被内容撑开。我见过很多项目在早期阶段就下了“这套方案不行”的结论，其实只要先把数据量补齐、再多给点时间做评测迭代，效果会很快提升。
7. 一些让我少走弯路的个人体会
最后分享几个带团队的实战心得，这些是文档里查不到的经验。
第一，做NLP系统永远不要直奔模型。先想清楚数据链路怎么走，数据从哪来、怎么清洗、怎么切分、怎么存储，这些环节决定了系统的天花板。模型只是把数据价值释放出来的最后一步。
第二，Prompt不是写一次就完事的。把线上用户的真实query收集起来，定期复盘失败的case，你会发现很多问题都是query改写没做好、或者知识库缺了某类文档，而不是模型不够聪明。Prompt工程是一个持续运营的事，不是上线前的冲刺。
第三，效果评估要跟业务指标挂钩。技术团队最容易盯着F1值、召回率这些指标自嗨，但老板真正关心的是用户能不能搜到东西、客服转人工率降没降、工单处理时长缩短没有。建议项目启动时就跟业务方对齐一套“技术指标到业务指标”的映射关系，否则优化方向和业务价值之间容易出现偏差。
这几年NLP的演进速度确实快得惊人，但万变不离其宗的还是两条：一是对文本的处理和理解能力，二是把模型能力接进实际业务的工程能力。这两条能力，Python生态依然是目前最顺手的土壤，也值得你继续深耕。
