企业官网建设流程全解析

1. 先搞清楚大模型到底是个什么东西

1.1 一次带团队后的重新出发——为什么需要系统性的学习资料

两年前我刚开始接触大模型的时候，完全靠碎片化学习：今天看一篇讲 Transformer 的文章，明天刷一个 LoRA 的教程，后天再试一个 vLLM 部署的 demo。当时感觉什么都懂一点，可真到做项目时发现自己连“KV Cache 为什么要省显存”都说不清楚，更别提给团队搭一套完整的技术方案了。

后来一次内部技术分享需要我带几个零基础的同学入门，我不得不把脑子里所有关于大模型的知识重新整理成一套系统性资料。那段时间我最大的感受是：大模型入门最大的门槛不是模型本身，而是资料太散。官方的论文偏理论，博客偏零碎，教程偏工具操作，缺的是一张能把原理、微调、部署、开发串起来的地图。

所以这篇文章本质上是一份“整理过的学习地图”。它不打算让你从数学公式推导开始啃，也不会只教你某个工具的默认参数。我会从大模型的底层本质说起，一路聊到提示词工程、上下文工程、微调、本地部署、Agent 框架和评估指标，路上还会穿插不少我实际踩过的坑。适合想系统进入大模型方向、但还缺一张全景图的开发者和技术管理者。

1.2 大模型的三句话本质

不管外面怎么包装，大模型的技术本质可以用三句话讲清楚。

第一句话：它是一个“根据前文预测下一个词”的概率模型。你给它一段文本，它内部计算的是在已出现内容的前提下，下一个词表中每个词出现的概率，然后选一个出来拼进去，再继续预测下一个。这看起来很简单，但所有看似神奇的能力——写代码、做翻译、逻辑推理——都建立在这个朴素的“自回归生成”机制之上。

第二句话：它的知识来自海量语料的预训练。大模型不是在推理时去查数据库，而是在预训练阶段把互联网级别的文本数据“消化”进了参数里。你问它“法国的首都是哪里”，它能回答，不是因为它联网了，而是因为“法国的首都=巴黎”这个模式在训练数据里出现了无数次，被模型以参数的形式记住了。

第三句话：它的能力边界由数据、参数规模和对齐方式共同决定。参数规模越大，模型能容纳的模式就越复杂；数据质量越高，模型推理的上限就越高；对齐方式则决定了模型是否愿意“听你的话”、是否用容易理解的方式输出。过去很多人只盯着参数数量，实际做项目后发现数据和对齐的影响往往更直接。

理解这三句话之后，再去看那些热搜词里的“大模型微调”“大模型部署”“Agent 框架”，就不会觉得是一个个孤立的知识点了。微调是在强化某一类行为，部署是把模型变成服务，Agent 是把模型的生成能力和外部工具接起来。底座都是那个“预测下一个词”的概率模型。

1.3 为什么“大”是一个量变引起质变的问题

“大模型”的“大”，指的不只是参数量大。更关键的是，当模型规模跨过某个阈值之后，会出现一些小型模型不具备的能力，业内叫“涌现能力”。比如几十亿参数的小模型可能连简单的多步推理都做不好，但几百亿参数的模型能自己拆解问题、分步求解，连解释都写得很清楚。

我习惯用“学开车”来类比这件事。你学到某个阶段，对油离配合、方向盘角度、后视镜观察都各有理解，但就是没法把它们顺畅地串起来。直到练习量足够大，各个能力模块突然被“缝合”到一起，你才真正会开车。大模型也是类似——规模变大后，模型不再满足于死记硬背语句，而是能在注意力机制下捕捉到更长距离的语义关系，把语法、常识、推理交织成一套更完整的表示。

这个“量变引起质变”的规律直接影响了工程决策。比如你在本地部署时纠结“到底买多大的显卡、能不能跑 7B 模型”，如果你做的任务是简单分类或摘要，7B 完全够用；但如果要做复杂 Agent 推理，可能就得上 70B 量级，或者用高质量小模型加外部知识库来补足。

2. 核心基础：从 Transformer 到预训练与对齐

2.1 Transformer 的四个关键部件

想做一个合格的大模型工程师，Transformer 的基本结构绕不开。但别怕，不需要你把每个矩阵运算都手推一遍，关键是把四个部件的作用记清楚。

第一是注意力机制。它让模型在处理当前词时，能同时“回看”前文所有词，并按重要程度分配权重。你可以理解成我们在读一段材料时，眼睛会重点停留在几个关键词上，注意力做的事情就是让模型学会“哪些地方更重要”。

第二是前馈网络。注意力负责从上下文里提取信息，前馈网络则对每个位置的信息做进一步加工和变换，相当于把“提取到的特征”做一次非线性映射。很多论文里的 FFN 层就是干这个的。

第三是层归一化。它负责稳定每一层的输出分布，防止深层网络训练时出现数值爆炸或梯度异常。实际训练大模型时，层归一化的位置和方式都会影响收敛速度，这也是很多研究关注“Pre-Norm 还是 Post-Norm”的原因。

第四是位置编码。注意力机制本身不区分词序，打乱一句话里的词它看到的还是同一批向量，所以必须额外把位置信息加进去。经典的有正弦位置编码和可学习位置编码，后来有了旋转位置编码（RoPE），它也是当前很多大模型处理长上下文的关键基础。

把这四个部件拼起来，再堆叠几十层，就是绝大多数大模型的骨架。后面那些五花八门的模型变体，很多只是在结构细节上做调整，比如换一下归一化位置、把注意力换个稀疏版本、改一下位置编码方式。理解了共通骨架，就不会被新模型的宣传话术带偏。

2.2 预训练阶段到底学到了什么

预训练是一个“干苦力”的阶段。模型拿到的数据往往有数十亿到数万亿个 token，任务只有一个：反复预测下一个词。训练过程中没有人工标注，数据本身既是输入又是答案，所以这种范式也叫自监督学习。

但模型在这个枯燥任务里，无形中学到了三样东西。第一是语言本身的结构：语法、句法、常见搭配。第二是世界知识：因为语料里包含了百科、新闻、书籍、代码，模型把大量事实性信息压缩进了参数。第三是推理的雏形：模型在补全大量逻辑连贯文本时，逐渐学会了“既然前提是这样，那结论大概是什么”这类模式。

有一个经常被误解的点：预训练阶段不求模型“答对问题”，求的是“预测得尽可能准”。这个目标看起来简单，实际训练时会遇到很多工程问题，比如数据配比、学习率调度、loss 震荡、梯度裁剪。当年我试训一个小模型时，最直观的感受是你可能训了几天，loss 曲线看起来还行，但一测生成质量就是“不说人话”。后来才意识到，预训练的好坏高度依赖数据多样性和数据清洗，而不只是堆算力。

现在的模型动辄几万亿 token，单纯靠个人机器去预训练一个像样的模型已经不太现实，所以对大多数工程师而言，更重要的任务是学会在开源基座模型上做微调、对齐、部署和二次开发。

2.3 从预训练到对齐：ChatGPT 这类助手是怎么来的

预训练让模型学会“续写”，但续写出来的内容可能是事实错误、有毒言论或者答非所问。因为互联网语料本身就鱼龙混杂。所以，要把它变成“听话的助手”，还需要对齐阶段。

对齐最常见的方式分两步走。第一步是指令微调（SFT），我们准备大量“问题—标准回答”这样的对话数据，让模型学着按指令要求来输出。这一步解决了“模型不知道你要干嘛”的问题。第二步是基于人类偏好做强化学习，经典的是 RLHF，先训练一个奖励模型来给回答打分，再用强化学习让模型朝着“人类更喜欢的答案”优化。另一个流行的简化版是 DPO，不需要单独训奖励模型，直接从偏好数据里学。

我个人在项目里的体会是，SFT 阶段的效果提升最明显，而 RLHF/DPO 更像“锦上添花”。如果你的场景是固定的客服问答或信息抽取，专注把 SFT 数据做好，性价比往往最高。要在通用对话能力上更进一步，再考虑偏好优化。

2.4 多模态模型的边界在扩展

现在的“大模型”已经不局限于文本了。多模态模型把图像、音频、视频和文本统一映射到一个向量空间里，模型既能看图，也能理解语音，还能按你的要求生成输出。这个能力在真实场景里非常实用，比如“给一张复杂曲线图，让模型直接解读趋势并生成分析文本”“给一段会议录音，让模型总结行动项”。

从实现原理上看，多模态模型通常保留一个文本大模型作为“大脑”，再训练一个视觉编码器把图片切成 patch 向量，通过投影层接入文本向量序列。这样模型以后看到的就是一段“图+文”混合序列，照样做注意力计算。音频也是类似思路。所以你现在看到的一些所谓多模态模型，骨架仍然是大语言模型，只是把输入侧的“感觉器官”接进来了。

我在实际项目里试过用多模态模型做图像版式解析，效果确实比单模型流快了不少，但也要注意，多模态模型的输入侧编码往往更消耗显存，图片分辨率稍高一些，KV Cache 就蹭蹭往上涨。如果做批处理，最好先在预处理阶段压缩图片尺寸，否则服务端容易被显存打满。

3. 提示词工程与上下文工程：数据进出的第一道闸门

3.1 提示词工程不是“咒语”，是接口设计

很多初学者喜欢把提示词工程当成“念咒语”，觉得只要在 Prompt 里加上“请你认真思考”模型就会变聪明，这其实是一种误读。提示词工程的本质是接口设计：你在跟一个概率模型描述任务边界、输入格式、输出约束和判断标准。

写提示词时，最重要的是明确性。我在团队里反复强调一个原则：如果一段需求你自己都说不清楚，那模型肯定更不明白。比如“帮我总结这段话”，就是个很模糊的提示词；改成“用不超过三句话总结这段文本，并标出文本里涉及的风险点”，模型输出的可用性会高一个量级。

其次是角色设定。给模型一个明确的身份，相当于给任务定了一个“信息筛选器”。比如“你是一位具有十年经验的数据库管理员”，模型在生成时会更倾向于使用技术语言和标准术语，减少无关发挥。不过角色设定也不是万能的，它本质上是给注意力机制一个倾向性信号，效果大小取决于模型是否在训练阶段见过足够多的类似角色数据。

第三是少样本示例。最可靠的提示词优化方式是给 1-3 个输入输出对，让模型照着示例的模式来。这比在系统提示里写一百字要求都管用。我常用“给正例不给反例”的方式：把理想输出完整写出来，模型很快能模仿格式，比单纯说“不要输出多余内容”有效。

3.2 上下文工程的三个维度和长文本策略

提示词只是一次性输入，但真实项目里的上下文往往是动态变化的，涉及上下文工程。它有三个重要维度。

第一个维度是上下文窗口的管理。模型的上下文窗口是有限的，要把最重要的信息放在最前面和最后面，中间部分容易被“稀释”。这个是注意力分布导致的客观现象，不是玄学。实际写作 Prompt 时，系统指令放开头，关键数据放结尾，中间放背景材料。

第二个维度是内容的组织与引用。当上下文里包含大量文档时，不要一股脑全塞进去。先做检索，再按相关度排序，然后把检索结果压缩或改写，再拼到上下文里。理想情况下，你给模型的不是“原文”，而是“把问题相关的关键信息提取并整理后的材料”。

第三个维度是结构化输出。让模型输出纯 JSON 或 Markdown 表格，能极大方便下游程序解析。主流模型都支持在指令里声明输出格式，配合“JSON mode”或函数调用接口会更稳定。

我见过很多项目在上下文工程上偷懒，把整本书塞进上下文，结果模型生成的回答越来越“飘”。正确做法是把文档做切片、过滤、摘要，控制进到模型里的 token 数。说实话，上下文工程的 ROI 比很多花哨的微调方案高得多。

3.3 提示词模板与最佳实践速查

下面是一个我自己常用的提示词模板，基本适用大多数文本任务。

你是【角色描述】，擅长【技能范围】。 任务：【一句话说清楚要做什么】。 要求： 1. 输出格式：Markdown / JSON / 表格 2. 约束条件：字数限制、不要编造、引用原文时标注来源 3. 处理边界：如果信息不足，明确说“无法判断”，不要猜测 输入内容： 【具体待处理数据】 请开始处理。

这个模板的核心逻辑是“角色先入、任务明确、约束清晰、数据独立”。它不一定完美，但至少保证模型的注意力焦点不会被杂讯带偏。

写提示词时有几个常见误区要避免。一是把提示词写得过长，大量重复且无关的“原则”反而会稀释关键信息。二是过度使用否定句式，模型对“不要如何如何”的遵从度不如“必须如何如何”。三是忘记给模型退路，任务信息不够时，模型也会硬着头皮编一个答案，所以最好在约束里显式允许它说“不知道”。

4. 微调：不改变模型灵魂，只调整它的行为习惯

4.1 什么时候该微调，什么时候不该微调

微调是我被问得最多的话题之一，但很多问题的答案其实是“不该微调”。在动手前，先做一道选择题。

如果你的目标是让模型改变回答风格、遵守一套固定的输出格式、或者适应一个定义明确的专业任务，先试提示词。如果需要把最新的内部知识引入，先做检索增强生成（RAG）。只有在提示词和 RAG 都解决不了，比如你的任务有独特的输入输出映射规则、领域术语密集、且你有一定量的高质量标注数据时，才考虑微调。

我见过不少团队一上来就微调，结果把 7B 模型微调得连通用对话能力都丢了。原因是微调阶段的数据分布太单一，模型只记住了你给的那几百条样本的模式，原本预训练时建立的能力反而被覆盖。所以微调不是“越做越强”，它本质上是一种“能力转移”。你想让模型更擅长 A 任务，就得接受它在 B 任务上可能略有退化。

4.2 常用微调方案对比：全参、LoRA、QLoRA

微调方案主要分两类：全参微调和参数高效微调。参数高效微调里最有代表性的是 LoRA 和 QLoRA。它们的区别直接决定了你需要多少显存。

全参微调要更新模型所有参数，显存占用最大，训练出的效果通常也最上限，但对个人开发者的小机器来说基本不现实。LoRA 的做法是在模型的线性层旁挂一个低秩矩阵，只训练这部分新增的少量参数，原模型参数冻结不变。这样效果往往能逼近全参微调，而可训练参数量通常是原模型的 1% 以内。QLoRA 更进一步，先把模型量化成 4-bit 来压缩显存，再做 LoRA 训练，让单卡跑大模型微调成为可能。

我整理过一个对比表格，供做硬件选型时参考。

这里的显存数值只是估测，实际会因序列长度、批量大小、优化器而浮动。但至少能帮你在项目规划阶段快速判断硬件够不够用。

4.3 一个基于LoRA的微调流程和显存估算

我拿一个 7B 模型的 QLoRA 微调流程举例。流程本身不复杂，重点是环境准备和参数选择。

第一步，准备数据集。Hugging Face 的datasets库可以直接加载，也可以把自己的 JSON 文件整理成统一格式。

from datasets import load_dataset dataset = load_dataset("json", data_files="train.json")["train"] print(dataset[0])

每条样本建议带上instruction、input、output三个字段，便于套用模板。别小看这一步，数据格式统一了，后面处理函数才能写得简单。

第二步，加载模型和分词器，做 4-bit 量化配置。

import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig quant_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.bfloat16 ) model = AutoModelForCausalLM.from_pretrained( "your-org/your-7b-model", quantization_config=quant_config, device_map="auto" ) tokenizer = AutoTokenizer.from_pretrained("your-org/your-7b-model")

第三步，配置 LoRA 参数。

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05 ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

r和lora_alpha是 LoRA 里最重要的两个超参。简单理解，r控制低秩矩阵的宽度，r越大可学习参数越多，但并不是越大越好，8 到 16 是常见起点。lora_alpha是缩放系数，一般设置为r的两倍。

第四步，创建训练器并开始训练。这里的关键参数是学习率、批次大小和最大长度。我一般用学习率 2e-4 到 5e-4，批次大小根据显存调整到 1 或 2，配合梯度累积达到等效批次 16。

关于显存估算，有一个通用公式思路：模型权重大小 + 梯度 + 优化器状态 + 激活值。7B 模型如果全用 bf16 加载，权重约 14GB；LoRA 训练时优化器状态只维护低秩参数，所以额外占得不多；激活值和 KV Cache 随序列长度增加而增加。用 QLoRA 的情况下，4-bit 模型权重约 3.5GB，训练时实际占用通常可以压到 10GB 上下。这也是为什么很多人说“消费级显卡也能微调”。

4.4 微调数据质量与常见翻车点

微调项目的成败，数据质量占七成，模型和代码只占三成。以下三条是我反复踩过的坑，值得拿出来反复说。

第一条：数据要“均匀”。如果你的训练集里 80% 是“闲聊问答”，只有 20% 是“专业任务问答”，模型微调后会倾向于把一切输入都往闲聊上带。解决方式是按任务类型做均衡采样，或者给不同类型数据分配不同权重。

第二条：数据要“去污染”。我在一个项目里把网络抓取的问答数据直接拿去微调，结果里面混了大量已有模型生成的文本，模型学了一堆自问自答的套话，真实场景表现很差。现在宁愿多花时间做人工清洗，也不愿意图省事直接灌数据。

第三条：警惕“微调后变傻”。很多人在微调后用几个样例测试，觉得效果不错，就以为万事大吉。实际上一旦测试集也被微调数据“污染”了，指标会有幻觉般的提升，到线上才发现模型对通用问题的回答质量陡降。正确的做法是建立一份与训练集不重叠的评测集，并且评测集最好从真实业务请求里采样。

5. 本地部署与推理加速：从模型参数到可用服务

5.1 本地部署的取舍与典型硬件配备

本地部署大模型这几年热度一直很高。大家想把它跑在自己电脑上的原因各有不同：有的是因为数据敏感，不敢把业务数据发送到外部 API；有的是想省下按 token 付费的钱；还有的就是想折腾一下，把个人电脑变成一台“随身 AI 工作站”。

本地部署的取舍核心是“三权衡量”：效果、成本和隐私。想效果好，得用大参数模型，就需要堆更多显存；想把成本压到最低，就得接受量化带来的效果损失。我的建议是，先明确你的任务难度，再倒推模型尺寸和硬件需求，而不是反过来先买了显卡再去找模型。

粗略估算显存有个简单办法：模型权重 GB 数 ≈ 参数量（B）× 精度字节数。7B 模型用 FP16/BF16 是 14GB 左右；用 INT4 量化后能压到 4-5GB。推理时还得叠加上下文占用的 KV Cache，长对话时这部分增长很快。所以运行 7B INT4 模型，实际推荐显存至少 6GB，跑长上下文建议 12GB。

我把自己试过的一些档位整理成了表格：

以上数值都是经验值，实际请以运行日志为准。

5.2 量化：把大象装进冰箱的三个压缩档位

量化是本地部署最核心的优化手段，本质上是用更少的比特数来近似表示模型权重。模型参数原本用 16 位浮点存，现在用 8 位或 4 位整数存，大幅缩小体积，代价是精度下降。

当前主流的量化路线大概有三种。第一种是训练后量化，代表有 GPTQ、AWQ，适用 GPU 推理，能把模型压到 4-bit，且效果损失较小。第二种是 GGUF 格式，主要配合 llama.cpp 使用，可以在 CPU 上跑，也支持 GPU 加速，适合消费级设备。第三种是主流的“动态量化”思路，比如 vLLM 支持的 FP8/INT8，它们在推理引擎层面兼顾吞吐和效果。

选量化方案时，我一般建议先试低精度但效果损失最小的方案。如果你有一张 24GB 显存，跑 7B 模型完全不需要量化，保留 BF16 精度效果最好；如果显卡只有 6-8GB，再考虑 INT4 量化。另一个经验是，量化对“逻辑推理类任务”的影响比对“简单分类任务”更大，所以如果你做的是复杂 Agent，别把量化档位压得太狠。

5.3 推理引擎的选择：vLLM 与 llama.cpp 等

模型选好、量化做完，下一步就是选推理引擎。推理引擎决定你服务的吞吐、延迟和显存效率。我用得最多的是 vLLM 和 llama.cpp 系工具，它们各有所长。

vLLM 主打高吞吐 GPU 推理，核心优势是 PagedAttention 和连续批处理。PagedAttention 把 KV Cache 切成小块按需管理，显存利用率高；连续批处理则让多个请求穿插执行，空闲的 GPU 资源能被充分填满。我用 vLLM 在单卡上部署 7B 模型，实测并发 20 路请求时，吞吐比普通原生生成高了数倍。

llama.cpp 则更适合轻量部署和边缘设备，它把模型量化成 GGUF 格式后，可以 CPU 推理，也能把一部分层卸载到 GPU 加速。优点是环境约束小，缺点是并发能力弱，不适合做高吞吐服务。

如果你只是个人电脑里用，推荐 Ollama。它封装了模型管理、下载、启动服务这些琐事，一条命令就能跑起一个 Chat 服务，底层用 llama.cpp 或自带兼容层。我在本地把 7B 模型通过 Ollama 跑起来后，配合一个 Web UI 就能给团队做演示，非常方便。

下面是一张对比表，方便按场景选型。

5.4 完整部署流程速览

这里给一套我常用的 vLLM 部署流程，适合快速把一个 Hugging Face 模型变成 OpenAI 兼容接口。

第一步，安装依赖。建议用独立的虚拟环境。

pip install vllm

第二步，启动服务。注意模型格式要能被 vLLM 识别。

vllm serve your-org/your-7b-model \ --served-model-name test-model \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

这里的max-model-len控制最大上下文长度，设得太高会占用大量显存，建议按实际需求来。gpu-memory-utilization表示允许 vLLM 使用显卡显存的比例，调高能缓存更多 KV，但别顶到 1.0，容易把其他显存需求挤爆。

第三步，测试接口。

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "test-model", "messages": [{"role": "user", "content": "你好，介绍一下你自己"}], "temperature": 0.7 }'

返回正常就说明服务起好了。后续接 LangChain 或者 Spring AI 这类框架时，只需把接口地址指到http://localhost:8000/v1即可。

部署阶段还有两个容易踩的坑：一是模型路径写错，vLLM 对模型文件结构要求比较严格，缺少config.json或格式不是最新版会直接报错；二是并发高时 OOM，这时候优先减小max-model-len，其次是调低gpu-memory-utilization。

6. Agent 与开发落地：把大模型接进真实业务流程

6.1 Agent 基本结构与主流框架

如果说部署是把大模型变成一台“发动机”，Agent 就是给它装上“方向盘、后视镜和工具箱”。一个完整的 Agent 至少要包含四个部分：大模型作为决策中枢、工具调用能力、记忆系统、任务规划机制。

大模型负责理解用户目标并拆解成子任务；工具让它可以查数据库、调 API、操作文件；记忆分短期（当前会话上下文）和长期（向量库等外部存储）；规划机制则解决“多步任务怎么拆、顺序怎么定、失败怎么重试”的问题。这四个部分组合起来，才让模型从“回答问题”升级为“完成任务”。

主流框架方面，我简单列几个常用的。LangChain 生态最全，适合快速搭原型；LlamaIndex 专注于数据检索和 RAG 场景；AutoGen 主打多智能体协作，让多个 Agent 互相讨论；CrewAI 把 Agent 组织成“角色团队”，适合模拟工作流；Spring AI 是 Java 生态的接入层，我在做 Java 后端项目时用过，和 Spring Boot 集成很顺。

选框架没有绝对标准，我一般看两点：社区活跃度和自定义灵活性。框架只是骨架，真到了生产环境，定制逻辑往往比默认组件更重要。

6.2 RAG：先检索再生成，缓解幻觉的关键策略

Agent 系统里最常用的外挂记忆就是 RAG，全称是“检索增强生成”。它的思路很简单：在让模型回答问题前，先从外部知识库检索相关文档片段，把检索结果拼进上下文，再让模型基于这些材料生成回答。

RAG 能有效缓解幻觉，因为模型不再硬凭参数里的记忆回答，而是有“参考资料”可以依赖。同时，知识库是独立维护的，业务文档更新后不需要重新微调模型，只要把新文档切块入库，模型就能用到最新知识。这个特性让 RAG 在企业私有化部署中特别受欢迎。

一个完整 RAG 链路通常包括文档解析、分块、向量化、向量检索、重排序、生成。文档先按标题或语义切块，每块切得不长不短，太短丢失上下文，太长给嵌入模型带来噪音；再用嵌入模型把每块转成向量，存入向量数据库；查询时把用户问题也转成向量，检索 Top-K 相关块；最后用重排序模型把召回结果精排一遍，把最相关的片段拼进 Prompt。

我在一个企业知识库项目里用 RAG 替换了纯模型回答之后，引用准确性大幅上升，用户也不再轻易“撞见幻觉”。但要注意，RAG 不是银弹，文档质量差、检索召回不准、分块策略不对，都会让最终回答质量打折。

6.3 评估：没有指标，就没有优化的方向盘

做大模型项目，最容易陷入“感觉还行”的状态。没有评估指标，你就不知道这次改 Prompt 到底变好了还是变坏了，也不知道微调后的模型该不该上线。我强烈建议任何项目从一开始就建立一套轻量级评测集。

评测集不用很大，先收集 100-300 条代表性业务问题就行，覆盖不同难度和不同场景。每次改动后，把这些问题统一跑一遍，再按统一标准打分。打分方式分几种：规则类指标适合看格式，比如 JSON 解析成功率；传统文本指标适合看相似度，比如 ROUGE/BLEU；对开放问答任务，我比较推荐“LLM-as-Judge”，用一个更强的大模型给输出打分，效率和一致性都很好。

这里也有个陷阱：让模型给自己打分时，必须给它明确的评分维度，比如“内容准确性”“逻辑连贯性”“是否遵循格式”，否则评分标准会漂移。另一个常见问题是线上指标和测试集指标不一致，因为线上问题分布跟手工构造的评测集差距很大。所以评测集要持续从真实日志中补充，甚至做定期“盲测”，才能让指标真正服务于优化。

7. 学习路径与避坑手册

7.1 三个月路线图参考

系统性入门不用追求面面俱到，而是要有节奏地建立“原理—提示词—微调—部署—开发”这条完整链路。我给自己带过的同学排过一份三个月路线图，放在这里供参考。

第 1-2 周，重点是原理和上手体验。先花时间把 Transformer、预训练、对齐这三大概念搞清楚，不需要看完整数学推导，但要知道每个模块负责解决什么问题。同时找一个大模型 chat 页面或本地 Ollama 环境，每天做提示词实验，感受温度、系统提示、少样本这些变量对输出的影响。

第 3-6 周，切入提示词工程和上下文工程，并开始做项目练习。可以选一个真实场景，比如“从客户工单里抽取结构化信息”，把提示词、JSON 输出、错误处理都做成一个小闭环。这个阶段的目标是能产出稳定可用的 Prompt。

第 7-8 周，学习微调和数据。建议拿一个小模型完整跑一遍 QLoRA 微调流程，重点理解数据格式、训练参数和评测方法。不求一次调出完美模型，而是把“微调为什么会变好/变坏”的感觉建立起来。

第 9-10 周，学习本地部署和推理加速。用 vLLM 或者 Ollama 在本地部署一个模型，跑通 OpenAI 兼容接口，再试着用量化把模型压小，记录不同量化档位的效果差异。

第 11-12 周，做 Agent 综合项目。把前面用到的模型、RAG、结构化输出串起来，搭建一个能解决实际问题的智能体，比如“企业内部文档问答机器人”或者“智能客服助手”。

7.2 常见问题速查表

我整理了项目实战中最常遇到的问题和排查思路，做成速查表，方便没有任何排查头绪的时候先翻一翻。

这张表只能给一个入口级别的思路。真到线上环境，还需要配合日志、监控和链路追踪来看，但至少能在踩坑时快速定位方向。

7.3 我踩过的几个坑（实操心得）

最后分享几条我在实操过程中真正摔过的跟头。第一，太迷信“大参数模型”。早期做项目时总想上 70B，结果部署和推理成本都压不住。后来换了 7B 模型配合 RAG 和精心设计的 Prompt，任务效果反而更稳定，成本和延迟还大幅下降。模型大小只是手段，不是目标。

第二，忽略上下文窗口的静默截断。有次排查线上问答效果差，发现历史会话很长之后模型开始“失忆”，翻日志才看到长文本被 tokenizer 截断。后来我在接入层主动检测输入长度，超过阈值就做历史摘要压缩，问题解决得很快。

第三，在评测上省时间。早期微调完一个模型，凭几组样例感觉不错就部署上线，结果线上问题跟样例分布完全不是一回事，被迫回滚。现在我把评测集当成工程的一部分，每次改动必跑评测，把“感觉”换成“数据”。

第四，用量化一刀切。有一版为了压显存，把模型从 BF16 直接压到 INT4，复杂 Agent 任务立刻出现推理逻辑断裂。后来针对性做混合精度部署，只对某些层做低比特量化，才恢复稳定。

做这个系统性入门资料整理的过程中，我自己最大的收获是：大模型方向是个“宽而深”的领域，真正重要的不是记住某个模型的名字或某个库的参数，而是建立一套“从原理到落地的因果链”。资料可以散，但认知不能散。如果你顺着这篇文章的顺序把每一条链路都摸一遍，再遇到各种新模型和新工具，你看到的不再是孤立的碎片，而是一个大体系里各自分工的零件。到那时，你就真正入门了。