企业官网建设流程全解析

简介：《LLM Engineer's Handbook》是一份英文原版PDF电子书，由Paul Iusztin与Maxime Labonne合著，面向希望系统掌握大型语言模型工程化的开发者、算法工程师与AI技术决策者，聚焦从概念设计到生产部署的完整链路。全书覆盖模型选择与架构设计、训练数据准备、模型微调与评估、推理优化及部署可靠性，并结合实践案例讲解数据偏差处理、可解释性设计和资源受限环境下的优化策略；同时讨论隐私、偏见、内容安全等伦理与合规议题，以及LLM未来技术趋势。书中特别强调RAG、微调、量化部署等热门场景，并给出作者实际项目的经验总结与最佳实践，读者可按需跳读。资源为单一PDF文件，压缩包约19.65MB，便于直接阅读、检索与离线学习。目前已有226人学习，适合正在做LLM应用落地或准备进阶的工程师作为案头参考。

1. 把一本大模型工程书拆成能跑的 LLM Twin：它到底教了什么

很多人学大模型应用，路径是“跑通一个 RAG demo → 调 prompt → 上线”，结果一遇到数据质量差、检索不准、微调后模型变傻就卡住。这本《LLM Engineer’s Handbook》走的是一条更重的路：用 Feature/Training/Inference 三管道架构，从零构建一个名为 LLM Twin 的个性化聊天机器人——爬取 GitHub、Medium、个人博客的原始数据，清洗后存入 MongoDB，再通过 RAG 特征管道生成 embedding 进 Qdrant，最后用 LoRA/QLoRA 微调开源模型并部署到 AWS SageMaker。它不是讲单点技术，而是把数据工程、检索增强、监督微调、偏好对齐串成一条完整的生产级链路。适合两类人：一是想从“调 API”升级到“自己训练和部署模型”的工程师，二是已经在做 RAG 或微调、但缺乏系统架构方法论的从业者。整本书最大的价值不是某个算法有多新，而是它示范了“如何把一个 LLM 应用当成软件系统来设计”。

2. 先理解 FTI 三管道架构：为什么 LLM 应用不能只写一个推理接口

2.1 传统 ML 系统的痛点：训练和推理之间那条断裂的线

很多团队做 LLM 应用，第一步是训练或微调一个模型，第二步是写一个 FastAPI 接口，第三步就上线了。这个流程在 demo 阶段跑得通，一旦进入生产就会暴露三个问题。

第一，数据和模型之间没有版本对应关系。训练时用的数据集和线上推理时喂进去的数据可能已经不一致了，用户会观察到模型输出质量忽高忽低，但又定位不到是模型问题还是数据问题。第二，特征计算逻辑在训练和推理链路里各写一遍，很容易出现“训练时用了 A 逻辑，推理时用了 B 逻辑”的偏差。第三，模型更新一次就要重新走一遍手工流程，没有可复现性，出了问题也不知道该回滚到哪一步。

书里给出的方案是把系统拆成三条管道：feature pipeline 负责把原始数据处理成模型可用的特征，training pipeline 负责训练和评估，inference pipeline 负责加载模型并提供在线服务。这个 FTI 架构的核心思想是：特征、训练、推理三者的生命周期独立管理，但通过元数据和工件（artifacts）串联起来。

2.2 三条管道的职责划分与数据流向

具体到 LLM Twin 这个项目，三条管道的边界非常清晰。

Feature pipeline 的输入是 MongoDB 里的原始文档（爬取到的文章、代码仓库内容），输出是 Qdrant 向量数据库里的 embedding 向量。它内部又分为两个子流程：数据清洗与分块，以及 embedding 生成与写入。这里的关键设计是做了两层数据存储——MongoDB 作为原始数据仓库，Qdrant 作为特征存储。为什么不用一个数据库搞定？因为两者的查询模式完全不同：MongoDB 适合按作者、时间、类型做过滤查询，Qdrant 适合做向量相似度检索。混用会导致两边都做不好。

Training pipeline 的输入是经过清洗和格式化的指令数据集，输出是微调后的模型权重。书中用的是 QLoRA，因为消费级 GPU 上跑全参微调不现实。训练完成后，模型会上传到 Hugging Face Hub 作为模型注册中心。Inference pipeline 做的事情则是在 AWS SageMaker 上部署微调后的模型，结合 Qdrant 做检索增强生成。

这条数据流的关键约束是：每条管道都可以独立重跑，但要保证版本对齐。比如你更新了 embedding 模型，就必须重新跑 feature pipeline 生成新的向量，否则检索用的向量空间和之前的就不一致了。

2.3 技术选型：为什么是 ZenML、Qdrant、MongoDB 和 SageMaker

这本书的选型很务实，基本是“当前生产环境最主流的方案”。我按自己的理解拆一下每个组件在架构里的位置。

ZenML 是编排层，负责调度 feature pipeline 里的各个 step。它相比 Airflow 的优势是原生支持 ML 场景的 artifact 和 metadata 追踪。每一次 pipeline 运行后，ZenML 会记录每个 step 的输入输出，这意味着你可以随时回溯“这批 embedding 是用哪个版本的清洗代码生成的”。这个能力在排查线上问题时非常关键。

MongoDB 作为数据仓库，存的是爬取下来的原始文档。选它是因为文档结构不固定——GitHub 仓库、Medium 文章、个人博客的字段差异很大，用关系型数据库要先定 schema，改起来太痛苦。Qdrant 作为向量数据库，核心能力是 ANN 检索，支持过滤条件加向量相似度的混合查询。SageMaker 则负责训练和推理的算力，主要看中它对 GPU 实例的弹性管理。

提示：如果你只是做个人项目，SageMaker 可以换成单张 RTX 4090 或者云厂商的按量 GPU 实例。FTI 架构本身不绑定具体云平台，核心是管道拆分和元数据追踪这两个设计决策。

2.4 手写一个最小 FTI 框架：用 ZenML 搭出三条管道的骨架

理解 FTI 最好的方式是动手搭一个最小骨架。这里用一个简化版示例，演示如何用 ZenML 定义包含三个 step 的 feature pipeline。

from zenml import pipeline, step @step def fetch_raw_data(source: str) -> dict: # 模拟从 MongoDB 拉取用户数据 raw_docs = {"source": source, "content": "some article content"} return raw_docs @step def clean_and_chunk(doc: dict) -> list: # 清洗并分块，实际场景里还会做去重和格式化 chunks = [doc["content"][i:i+500] for i in range(0, len(doc["content"]), 500)] return chunks @step def embed_and_load(chunks: list, collection: str) -> None: # 生成 embedding 并写入 Qdrant for chunk in chunks: # 这里省略实际的 embedding 调用和 Qdrant upsert print(f"Embedded chunk into {collection}") return None @pipeline def llm_twin_feature_pipeline(source: str): raw = fetch_raw_data(source) chunks = clean_and_chunk(raw) embed_and_load(chunks, collection="user_articles")

这段代码展示了 feature pipeline 的三个核心阶段：数据获取、清洗分块、embedding 入库。ZenML 用@step装饰器标记每个处理单元，用@pipeline组合成完整流程。实际跑的时候，ZenML 会为每个 step 记录输入输出和运行参数，方便你回溯“这次 pipeline 运行是用了哪批数据”。

参数层面有三个点需要注意。第一，clean_and_chunk里的分块长度和重叠窗口是特征管道的核心参数，直接影响检索质量。第二，embed_and_load里要传入 embedding 模型的名称或版本，这个信息应该由配置管理，而不是硬编码。第三，ZenML 的 pipeline 运行是惰性的——只有显式调用llm_twin_feature_pipeline(source="github")时才会真正执行。生产环境里，这条 pipeline 会被调度器定时触发，实现增量更新。

3. 数据收集与清洗：LLM Twin 的第一公里最容易被低估

3.1 爬虫架构设计：dispatcher 模式解决“多数据源”问题

LLM Twin 的数据源有三种：GitHub 仓库、Medium 文章、自定义博客。如果为每个源写一套独立的数据处理代码，后续新增数据源会越来越痛苦，维护成本成倍增加。书里的做法是设计一个 dispatcher 层，按数据类型路由到对应的 crawler。

核心设计思路是：所有 crawler 继承同一个基类，基类定义了统一的接口（如fetch_data()、parse()），每个 crawler 只需要实现自己的逻辑。dispatcher 根据配置决定实例化哪个 crawler。这样做的好处在于：新增一个数据源时不需要改动已有代码，只需要新建一个 crawler 子类，然后在配置里注册。

from abc import ABC, abstractmethod class BaseCrawler(ABC): def __init__(self, user: str): self.user = user @abstractmethod def fetch_data(self) -> list: """拉取原始数据，返回文档列表""" pass class GitHubCrawler(BaseCrawler): def fetch_data(self) -> list: # 调用 GitHub API 获取用户仓库和 commit 信息 repos = [ {"type": "github", "name": "llm-engineer-handbook", "content": "repo content"} ] return repos class MediumCrawler(BaseCrawler): def fetch_data(self) -> list: # 通过 RSS 或页面解析获取 Medium 文章 articles = [ {"type": "medium", "title": "RAG pipeline design", "content": "article content"} ] return articles def dispatcher(source: str, user: str) -> BaseCrawler: crawlers = { "github": GitHubCrawler, "medium": MediumCrawler, "custom": CustomArticleCrawler, } crawler_cls = crawlers.get(source) if not crawler_cls: raise ValueError(f"Unsupported source: {source}") return crawler_cls(user)

这个 dispatcher 模式我后来在自己项目里也沿用了。它本质上是一个工厂模式，根据字符串配置动态创建对应的处理对象，避免了一长串的if-elif判断。实际使用中还有一个隐藏好处：每个 crawler 可以独立测试和部署，某个数据源挂了不会影响其他数据源。

3.2 ODM 层：用 Pydantic 统一多数据源文档结构

爬虫拿到的是结构各异的原始数据，要统一存进 MongoDB，就需要一个对象文档映射层。书里用的是 Pydantic 定义的 domain entity，理由很直接：Pydantic 能做运行时类型校验和序列化，定义的数据模型既当 schema 用，又当代码里的数据结构用，一举两得。

这一层要解决的关键问题是：不同数据源带来的字段差异。比如 GitHub 数据有stars和language字段，Medium 文章有reading_time和claps，但它们都需要包含content、author、timestamp这些共同的语义字段。ODM 层的做法是定义一个基类UserDocument，包含公共字段，再让各数据源类型继承它做扩展。

from pydantic import BaseModel, Field from datetime import datetime class UserDocument(BaseModel): user_id: str content: str source: str # github / medium / custom timestamp: datetime metadata: dict = Field(default_factory=dict) class GitHubDocument(UserDocument): repo_name: str language: str stars: int class MediumDocument(UserDocument): title: str reading_time: int claps: int

用 Pydantic 做 ODM 层，有一个工程上的好处：数据进入 MongoDB 之前就已经完成校验，脏数据不会入库。比如stars字段如果传入字符串，Pydantic 会直接抛ValidationError，而不是等到查询时才发现类型不对。我一般在生产环境里还会加上一层@validator，对content字段做长度检查，防止空文档进入后续流程。

3.3 去重策略：MD5 哈希比内容比对更快

爬虫跑久了，MongoDB 里必然出现重复文档。同一篇 Medium 文章可能被爬了两次，或者一篇论文在博客和 GitHub 上都有转载。如果不去重，后面的 embedding 阶段会浪费大量算力，查询结果也会重复。

书里提到的做法是基于内容哈希的去重：对文档正文计算 MD5 或 SHA256，在 MongoDB 中建唯一索引。这个方案比语义相似度去重（用 embedding 计算相似度）快得多，适合第一轮粗去重。如果你对数据质量要求更高，可以在这之后再跑一轮基于 embedding 的相似度去重，把“改了几个字的重写文章”也去掉。

import hashlib from pymongo import MongoClient, IndexModel, ASCENDING client = MongoClient("mongodb://localhost:27017/") db = client["llm_twin"] collection = db["raw_documents"] def add_document(doc: dict) -> bool: text = doc["content"] doc["content_hash"] = hashlib.md5(text.encode("utf-8")).hexdigest() try: collection.insert_one(doc) return True except Exception: # 唯一索引冲突说明已存在相同内容的文档 return False # 创建唯一索引：user_id + content_hash 双字段 index = IndexModel( [("user_id", ASCENDING), ("content_hash", ASCENDING)], unique=True, name="unique_user_content" ) collection.create_indexes([index])

这个方案里，唯一索引是去重的主力。双字段索引的意思是：同一个用户下，内容哈希相同的文档只保留一条。这里有个容易踩的坑：如果你只对content_hash建唯一索引，两个不同用户录入了相同内容，第二条会被误杀。所以索引必须带上user_id作为前缀。另外，加哈希字段会影响 MongoDB 的存储空间，大约每 100 万文档增加 16MB，可以忽略不计。

3.4 数据收集常见的三个翻车现场

我照着书里的思路做数据收集时，实际遇到的最多的坑有三个。

第一个坑是 Selenium 爬虫被网站反爬机制拦截。现象是本地跑得好好的代码，部署到云服务器上就拿不到数据了。原因是数据中心 IP 被目标网站标记为高风险。解决方法是加随机延迟、用真实浏览器指纹，或者直接放弃渲染型爬虫，改用官方 API 或 RSS 源。

第二个坑是 API 限流。GitHub API 未认证时每小时只有 60 次请求，跑一次爬虫就把配额用完了。解决方法是在请求头加AuthorizationToken，把配额提升到 5000 次/小时。Medium 的爬取则要小心，它的页面结构经常变，今天是这个 class 名，明天就换了。我的经验是把页面解析逻辑隔离成一个独立模块，页面结构变了只改那一个文件。

第三个坑是时区问题。不同数据源返回的时间格式不一致，GitHub 是 ISO 8601，Medium 是 Unix 时间戳。如果不统一转换就直接存 MongoDB，后续按时间过滤时会乱套。我一般在 ODM 层强制转成带时区的 UTC 时间。

4. RAG 特征管道：分块策略与 embedding 选型决定检索质量的上限

4.1 RAG 的核心矛盾：检索质量决定生成质量

RAG 的原理并不复杂——把问题检索相关的文档片段，拼进 prompt 里让模型基于这些内容生成答案。但这里的核心矛盾是：如果检索回来的片段本身不准确，模型再强也生成不出好答案。书里点明了这个因果链：检索质量是 RAG 系统的天花板，而检索质量由两个因素决定——分块策略和 embedding 模型。

分块策略直接决定向量检索的粒度。块太大，一块里包含多个主题，向量会被“平均化”，检索时召回的内容不精准；块太小，语义不完整，模型没有足够的上下文。Embedding 模型决定文本映射到向量空间的方式，不同模型对语义的理解能力差异巨大。而且 embedding 模型更新后，所有历史向量都需要重新生成，这是一个容易忽略的运维成本。

4.2 避坑：RAG 特征管道的五个典型问题

我按自己在项目里遇到的真实情况，整理几条最典型的坑。每一条都是现象、原因、解决三步走。

坑一：Qdrant 集合里出现空白向量

现象是检索时偶尔返回空结果，排查发现集合里有 content 为空字符串的向量。原因是清洗阶段没有过滤空文档，Pydantic 校验也没生效——因为数据是直接通过 Qdrant API upsert 的，绕过了 ODM 层。解决方法是写一个入口校验函数，在 embedding 之前统一检查文档长度，长度低于 50 字符的直接丢弃。

坑二：同一篇文档被重复写入向量库

现象是检索结果里出现两条完全相同的片段。原因是增量同步时只记录了“哪些文档处理过”，没记录“哪些文档已经写入向量库”。如果 pipeline 中途失败重跑，已经写入的向量不会自动清理，重复跑一次就会产生重复向量。解决方法是每次 pipeline 运行前，根据批次 ID 删除对应的旧向量，再执行写入。

坑三：分块时在句子中间切断

现象是检索到的块读起来语义不完整，经常出现“一句话说了一半”。原因是按固定字符长度切分，没有考虑句子边界。解决方法是采用递归分块器，优先按段落和句子边界切，只有当文本长度超过模型最大上下文时才强制截断。实践里我倾向于把块大小设置在 400-600 token，重叠区 50-100 token。

坑四：embedding 模型升级后新旧向量混用

现象是检索效果突然变差，但代码没改过。原因是你在 Hugging Face Hub 上更新了 embedding 模型的权重文件，但向量库里的旧向量没有重新生成。新旧向量在同一个向量空间中不兼容。解决方法是把 embedding 模型的版本号作为 Qdrant 集合名的一部分，比如user_articles_v2，模型升级时重建整个集合。

坑五：把 HTML 标签和 Markdown 语法嵌入向量

现象是检索出来的内容里全是<div>、class=这类噪声。原因是清洗阶段没做格式剥离就分块了。解决方法是分块前统一走一遍清洗管道：先去 HTML 标签，再转纯文本，最后去掉多余空行和特殊字符。

4.3 分块策略选型：固定长度、递归分割还是语义分块

书里没有固定推荐某一种分块方法，而是给出了适用场景。我根据自己的实践做个补充对比。

固定长度分块实现最简单，按字符数硬切，但语义完整性无法保证，适合对精度要求不高的场景。递归分块是目前最通用的方案，优先按段落切，段落太长再按句子切，句子太长最后按固定长度切。LangChain 里的RecursiveCharacterTextSplitter就是这个逻辑，我用下来的效果是比固定长度好不少，尤其适合网页抓取的文本。语义分块最复杂，用 embedding 判断边界，效果最好但计算成本高，适合对检索质量有极致要求的知识库场景。

分块参数有三个需要关注：块大小、重叠区和块数量上限。块大小直接对应 embedding 模型的输入长度和向量粒度；重叠区用于保证边界上下文不丢失；块数量上限防止一篇超长文档生成几千个向量。实际调参时，我会先固定一个 embedding 模型，然后在测试集上同时跑检索精度，对比不同分块参数的效果，而不是靠感觉调。

4.4 把分块和 embedding 接进 ZenML step

下面这段代码是在 ZenML 里实现分块与 embedding 的完整 step，包含了清洗和写入逻辑。这是整条 feature pipeline 的核心部分。

from zenml import step from qdrant_client import QdrantClient from sentence_transformers import SentenceTransformer from langchain.text_splitter import RecursiveCharacterTextSplitter @step def chunk_and_embed(documents: list, model_name: str, collection: str) -> None: # 初始化 embedding 模型 model = SentenceTransformer(model_name) # 分块器：优先按语义边界切，块大小 500 token，重叠 80 splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", ".", " "], length_function=len, ) # 初始化 Qdrant 客户端，生产环境换成内网地址 qdrant = QdrantClient(host="localhost", port=6333) points = [] for doc in documents: # 清洗：去 HTML 标签和多余空白 text = doc["content"] if len(text) < 50: continue # 过滤过短文档 chunks = splitter.split_text(text) vectors = model.encode(chunks).tolist() for i, (chunk, vector) in enumerate(zip(chunks, vectors)): points.append({ "id": f"{doc['user_id']}-{doc['timestamp']}-{i}", "vector": vector, "payload": { "text": chunk, "user_id": doc["user_id"], "source": doc["source"], "chunk_index": i, } }) qdrant.upsert(collection_name=collection, points=points)

这段代码把三个动作串在一起了。RecursiveCharacterTextSplitter负责智能分块，分隔符数组的顺序代表优先级——先按段落（两个换行）切，再按单换行切，然后是句号和空格。这样切出来的块基本都在语义边界上。SentenceTransformer.encode是一次性批量编码，比逐条编码快很多，但要注意长文本截断问题。如果文档超过模型的 max_seq_length（通常 512 token），需要先截断再编码。

参数方面有两个关键选择。collection_name应该包含 embedding 模型版本，例如user_docs_mxbai-v2，这样模型升级时不会污染旧数据。payload里的user_id和source字段是后续检索过滤的依据，比如“只搜某个用户的 GitHub 内容”，查询时可以用 Qdrant 的 filter 条件精确过滤。

4.5 embedding 选型与向量检索的过滤策略

书里对 embedding 模型没有专门章节，但作为工程实践，选对模型和检索过滤策略直接影响最终效果。我的经验是优先考虑输出维度、上下文长度、多语言支持这三个维度。

输出维度影响存储和计算成本，768 维比 384 维多一倍的存储空间，但语义区分度不一定翻倍。上下文长度决定能编码多长的文本片段，短上下文模型遇到长文本会自动截断，损失语义。多语言支持取决于你的业务场景，如果只有中文文档，选一个在中文上表现好的模型比选一个通用模型更重要。

检索过滤策略上，Qdrant 支持在向量搜索前加 payload filter。比如做 LLM Twin 的场景，用户问“我去年写的关于 RAG 的文章”，可以先按user_id过滤，再按时间范围过滤，最后做向量检索。这个顺序很关键——先缩小候选集再做相似度计算，响应速度会快很多。

5. 监督微调与偏好对齐：从 LoRA 到 QLoRA 的参数边界

5.1 什么时候应该微调，什么时候应该停在 RAG 阶段

很多场景根本不需要微调。如果你只是需要让模型回答某个知识领域的问题，RAG 是成本最低的方案——不需要训练，不需要 GPU，只需要维护一个向量库。微调的适用场景是你要改变模型的“行为方式”，而不是给它补充知识。

书里指出了几个真正需要微调的信号：输出格式不符合产品需求（比如必须输出 JSON，但基础模型总爱加多余解释）；模型的语气和风格和产品定位不匹配；基础模型在特定任务上的表现有上限，prompt 优化已经到头。相反，如果只是“模型不知道某些信息”，RAG 就能解决，不要贸然进入微调，否则你会同时面对数据清洗、训练调参、过拟合、评测四重问题。

5.2 LoRA 和 QLoRA 的选择边界：显存不够时的务实方案

全参微调的开源模型参数动辄 70 亿起，单张 24GB 显存的消费级显卡跑不起来。LoRA 的思路是冻结原模型权重，只训练注入的低秩分解矩阵。训练参数量大幅减少，显存占用和训练时间都大幅下降。QLoRA 更进一步，把模型权重量化到 4-bit，训练时显存占用可以压到 6GB 以内。

选 LoRA 还是 QLoRA，我的判断标准是：如果你的显存不少于 24GB，优先 LoRA，因为量化会带来小幅精度损失，效果上限更高。如果显存是 8GB 到 16GB，只能用 QLoRA。另外，QLoRA 需要支持 4-bit 的bitsandbytes库配合transformers才能跑，环境安装容易出问题。我建议先在 Colab 或云端试通 QLoRA，再到本地复现。

5.3 训练参数的工程解读：不是抄参数，是理解每个数字的敏感度

书里的第五章给了微调训练的具体参数表。我按自己的踩坑经历重新解读一遍。

学习率是最敏感的超参数。LoRA 微调常见范围是 1e-4 到 2e-4，太小会导致 loss 降不下去，太大模型会直接发散，生成的结果变成乱码。余弦退火调度器配合 warmup 比例 3% 是通用默认，前几步走小步幅让优化器稳定下来，再逐步加大更新幅度。

批次大小受显存限制，但注意梯度累积步数是一个隐藏参数。实际批次大小 = per_device_batch_size × gradient_accumulation_steps。如果你只有一块 24GB 显卡，per_device_batch_size 设为 2，累积步数 4，等效批次就是 8。这个参数影响训练稳定性和收敛速度，不要为了追求等效批次而把累积步数设得过大。

最大长度和时间段。把 max_length 设为 1024 或 2048 取决于你的数据分布。如果大多数指令样本长度在 800 token 以内，设 2048 会浪费算力。epoch 数在 LoRA 微调里通常是 2 到 3，超过 3 会有过拟合风险——典型现象是训练 loss 持续下降，但验证集上的生成质量反而变差。权重衰减 0.01 是默认值，主要用来防止低秩矩阵学到过大的权重值。

梯度检查点必须以牺牲约 20% 训练速度为代价换取显存。如果你显存够，不需要开；如果显存不够，这是比减小 batch size 更优的解法。

5.4 偏好对齐数据集：让模型学会说“不知道”

最后一章讲的是基于人类偏好的对齐。监督微调解决的是“模型会怎么回答”，偏好对齐解决的是“模型应该怎么回答”。书里强调的一个原则是：好的偏好数据要包含拒绝回答的样本。

实际做偏好数据生成时，一个常见做法是：用同一个 prompt 生成多个候选答案，然后让人工或更强模型排序。这个过程中你会发现，模型经常编造不存在的知识来填充答案。与其让模型学会“更有说服力地编”，不如让它学会诚实地说“我不知道”。实现方式是构造 preference pair 时，把包含不确定性表达的数据标记为优选。

import random def generate_preference_pair(prompt: str, model_a_output: str, model_b_output: str): if "I don't know" in model_a_output and "I don't know" not in model_b_output: return { "prompt": prompt, "chosen": model_a_output, # 诚实的回答反而被优选 "rejected": model_b_output, # 编造的回答被拒绝 } return None

这段代码揭示了偏好数据构建里的一个细节：模型输出的质量和事实正确性未必相关。一个编得流畅但错误的答案，和一个磕绊但诚实的答案，在偏好对齐数据集里应该选后者。这个原则如果你的产品面向真实用户，非常重要——用户被误导一次就会失去信任。

偏好数据集的数量不需要像指令数据集那么庞大。几千条精挑细选的 preference pair 就足够让模型的行为发生明显变化。书里推荐的是先关注数据质量，再关注数量。

5.5 微调完成后的验证清单

微调结束不是以训练 loss 降到最低为标志。我的习惯是跑完一批固定的验证 prompt，人工对比微调前后模型的输出差异。验证集通常包含三类样本：指令跟随能力测试（看格式是否符合要求）、知识问答测试（看是否引入了幻觉）、安全边界测试（看是否拒绝回答不当问题）。

第二类比第一类更容易翻车——模型可能学会了输出格式，但同时在知识问答里产生更多幻觉。如果出现这种情况，优先怀疑训练数据里混入了低质量样本。一个实用的排查手段是把训练集中 loss 最高的 top 50 个样本捞出来肉眼检查，大概率能发现问题数据。

6. 数据去污染与模型评估：一个容易被忽略但决定模型上限的动手技巧

数据去污染在微调流程里处于一个尴尬的位置——所有人都在口头强调它的重要性，但真正动手去做的团队很少。我在读完这本书后专门为它写过一组工具脚本，这里分享一个完整可复用的做法，包含实现代码和判断标准。

去污染的目的是：确保训练数据里不包含测试集中的内容。如果你用一篇已经存在于测试集里的文章作为训练样本，模型相当于提前看到过答案，评估分数会虚高，上线后真实效果打回原形。这个问题的隐蔽性在于，你很难通过肉眼判断两条文本是否“语义等同”——可能只是改写了一下。

我的做法是两步走。第一步，n-gram 重叠检测，把潜在的重复项快速筛出来；第二步，对筛出的候选做 embedding 相似度比对，确认是否真的重复。

from sentence_transformers import SentenceTransformer, util import json model = SentenceTransformer("all-MiniLM-L6-v2") def ngram_overlap_score(text_a: str, text_b: str, n: int = 8) -> float: """计算两个文本的 n-gram 重叠比例，用于粗略检测""" def get_ngrams(text, n): words = text.lower().split() return set(" ".join(words[i:i+n]) for i in range(len(words) - n + 1)) grams_a = get_ngrams(text_a, n) grams_b = get_ngrams(text_b, n) if not grams_a or not grams_b: return 0.0 overlap = len(grams_a & grams_b) / min(len(grams_a), len(grams_b)) return overlap def embedding_similarity(text_a: str, text_b: str) -> float: """用 embedding 余弦相似度确认语义重复""" vec_a = model.encode(text_a) vec_b = model.encode(text_b) return float(util.cos_sim(vec_a, vec_b)) # 示例：检查训练集里是否混入了测试集文档 train_docs = json.load(open("train_data.json")) test_docs = json.load(open("test_data.json")) for train_doc in train_docs: for test_doc in test_docs: n_score = ngram_overlap_score(train_doc["content"], test_doc["content"]) if n_score > 0.6: emb_score = embedding_similarity(train_doc["content"], test_doc["content"]) if emb_score > 0.85: print(f"疑似重复: train_id={train_doc['id']}, test_id={test_doc['id']}, ngram={n_score:.2f}, emb={emb_score:.2f}")

参数上，ngram 重叠率阈值 0.6 是一个经验值，对应“大量连续 8 个词相同”的情况。embedding 相似度阈值 0.85 需要根据你选的 embedding 模型调整，MiniLM 的分布下 0.85 是比较稳妥的分界值。如果你用的是更强的模型（比如 BGE-M3），阈值可以提到 0.9。

去污染做完之后，下一步是模型评估。我的习惯是用一个固定的评估集，每次微调后跑一遍，连续对比多轮的得分变化。评估集不能太小，至少 200 条 prompt，覆盖生成、分类、抽取三种任务类型。用同一套评估集、同一个评估脚本、同一个评估模型，才能连续对比不同训练版本的效果差异。如果评估集换来换去，你看到的分数波动可能只是评估集差异，不是模型真实的进步。

从那以后，我每次准备训练集都会强制走一遍去污染流程，习惯性地把训练集和测试集同时保存到本地，跑完 n-gram 检测再做一次 embedding 相似度比对，确认没有重叠再动手微调。这一步省下来的时间，远大于排查一次“模型评估虚高但上线效果差”的翻车现场。希望帮到你。

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