企业官网建设流程全解析

大家好，我是你们的老朋友。最近在做大模型工程化落地时，身边不少朋友都在问同一类问题：模型训练好后推理速度太慢怎么办？全量微调和 LoRA 微调到底该怎么选？RAG 里的 Embedding 模型是怎么工作的？LLaMA-Factory 这样的工具到底怎么用起来？

这些问题单独拆开都不算难，但串在一起很容易让人犯晕。尤其是当你既想微调出一个专用模型，又想把它高效部署到 GPU 上，还希望它具备检索增强能力时，涉及的知识点就会从一个点扩散成一个面。

这篇文章我就围绕QAT（量化感知训练）、全量微调、LoRA 微调、LLaMA-Factory、AgentRAG 和 Embedding 模型这几个关键词，把它们串成一条完整的学习链路。无论你是刚开始接触大模型微调的新手，还是已经跑通过一些简单训练、想进一步了解量化部署的开发者，这篇文章的目标都是帮你建立一张清晰的地图。

1. 先搞清楚几个核心概念

在开始动手之前，有必要先把几个高频术语彻底讲清楚。因为这些词在实际交流中经常被混用，而理解偏差往往会直接导致后续技术选型错误。

1.1 什么是模型微调

模型微调（Fine-tuning）是指在预训练模型基础上，使用领域数据或任务数据继续训练，让模型适配特定业务场景的过程。

预训练模型本身已经通过海量文本学到了丰富的语言知识，但它是一个“通用助手”，并不一定了解你的业务术语、写作风格、回复格式或私有知识。微调的本质就是把这套通用能力“调教”成适合特定任务的样子。

举例来说：

• 通用基座模型可以写作文，但如果你希望它生成符合你公司风格的故障报告，就需要用历史故障报告数据做微调。
• 通用基座模型能回答问题，但如果你希望它严格按照企业知识库的口径回答，就需要结合 RAG 或微调来约束。

按训练方式划分，微调通常分为：

这里需要注意，全量微调虽然效果通常更稳定，但显存开销非常大。以 7B 级别模型为例，使用全量微调时显存需求往往超过 60GB，普通单卡很难支撑。这也是为什么 LoRA 这类参数高效微调方法会如此流行。

1.2 全量微调与 LoRA 微调的本质区别

全量微调会对模型的所有权重参数进行梯度更新。它的优点是模型能够最大程度地适应新任务，缺点是训练成本极高，而且每个任务都需要保存一份完整的模型副本。比如一个 7B 的模型，FP16 精度下权重文件就约 14GB，如果同时维护多个业务版本，存储成本会快速膨胀。

LoRA（Low-Rank Adaptation，低秩适配）的核心思想是：冻结预训练模型的原始权重，在模型的线性层旁边插入少量的低秩分解矩阵。训练时只更新这些新增的小矩阵，推理时可以将低秩矩阵合并回原模型，也可以单独保存。

这样做的好处非常明显：

• 可训练参数量大幅减少，通常只有原模型的 0.1% 到 1% 左右。
• 显存开销显著下降，消费级显卡也能完成 7B 甚至更大模型的微调。
• 每个任务只需保存几十到几百 MB 的 LoRA 权重文件，切换任务时动态加载即可。

理解 LoRA 时可以把它想象成“在原模型旁贴了一张便签”。原模型的记忆保持不变，便签上记录的是针对特定任务的调整信息。使用某个任务时只需要取出对应的便签即可。

QLoRA则是 LoRA 的更进一步的版本。它先把预训练模型量化到 4-bit，再在量化后的模型上做 LoRA 微调。这样一来，单卡显存需求可以进一步降低，是目前资源有限环境下微调大模型的主流方案。

1.3 什么是 QAT（量化感知训练）

量化（Quantization）是模型部署中的关键环节。大模型训练完成后的权重通常是 FP16 或 BF16 浮点类型，推理时的显存占用和计算量都很大。如果能把权重从 16-bit 压缩到 8-bit 甚至 4-bit，推理速度会显著提升，显存占用也会大幅下降。

量化方案主要分为两类：

PTQ（Post-Training Quantization，训练后量化）：模型训练完成后再做量化。它不需要重新训练模型，处理速度快，但在低比特量化下容易产生精度损失。对精度敏感的场景，PTQ 往往不够稳。

QAT（Quantization-Aware Training，量化感知训练）：在训练或微调过程中就模拟量化的效果。也就是说，前向传播时会把权重和激活值“假装”量化到低比特，再反量化回高精度来计算梯度。通过这种方式，模型在训练阶段就学会了适应量化带来的噪声，最后真正量化部署时，精度损失会比 PTQ 小得多。

可以这样理解：PTQ 是“先练好车，再换轮胎”；QAT 是“从练车时就一直用换好轮胎的车练”。后者对路况的适应能力自然更强。

一个典型的 QAT 流程如下：

预训练/微调模型 ↓ 在训练图中插入伪量化节点（模拟量化误差） ↓ 继续训练若干轮，让模型适应低比特表示 ↓ 导出量化模型（INT8 / INT4） ↓ 部署到推理引擎

实际业务中，如果你发现模型 PTQ 后精度严重下降，尤其是在 4-bit 量化场景，优先考虑 QAT。

1.4 Embedding 模型在 RAG 中的角色

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大模型“先检索、再回答”的架构。它解决了大模型知识过时、幻觉严重、不知道企业内部私有知识的问题。

RAG 的整体流程是：

1. 离线阶段：将文档切分成多个 chunk，使用 Embedding 模型将其向量化，存入向量数据库。
2. 在线阶段：将用户问题同样向量化，在向量数据库中检索最相关的文档片段。
3. 生成阶段：将检索到的片段和用户问题一起组装成 Prompt，交给大模型生成回答。

这里的 Embedding 模型承担的是“文本向量化”的任务。它把一段文本映射成一个高维向量，语义相近的文本在向量空间中的距离也更近。常见的 Embedding 模型包括 OpenAI 的 text-embedding-3-small / text-embedding-3-large、智源的 BGE 系列、阿里通义的 text-embedding-v3、以及各种基于 Sentence-BERT 架构训练的开源模型。

选型时主要关注以下指标：

• 向量维度：维度越高，精度通常越好，但存储和检索成本也越高。
• 最大输入长度：一般 512 或 1024 token，超出部分需要截断。
• 检索效果：可以用 MTEB 等基准来横向对比。
• 部署成本和延迟：是否满足线上服务要求。

1.5 AgentRAG 是什么

AgentRAG 是 RAG 的进阶形态。传统 RAG 只有“检索—生成”两个固定步骤，而 AgentRAG 引入了一个智能体（Agent）来动态规划流程。Agent 会根据用户的问题，决定是否需要检索、检索什么、是否需要多次检索、以及是否需要调用外部工具。

这种设计能显著提升复杂问题的处理能力。比如用户问“对比上季度和这个季度的销售额变化原因”，单一向量检索可能无法一次找到正确答案，而 AgentRAG 可以先检索销售数据、再检索相关事件新闻、再调用计算工具做汇总，最后生成一份结构化回答。

在实际工程中，AgentRAG 会涉及 Agent 框架的选择（如 LangChain、LlamaIndex、Dify、FastGPT 等）、流程编排、工具调用、记忆管理等模块。

1.6 LLaMA-Factory 是什么

LLaMA-Factory 是一个开源的大模型微调工具，它把数据准备、模型加载、全量微调、LoRA/QLoRA 微调、评估、推理等环节整合成了一套标准化流程。它支持 LLaMA、Qwen、DeepSeek、Baichuan、ChatGLM 等主流模型架构，既提供了 Web 界面，也提供了命令行方式，是目前个人开发者和中小企业搭建微调流程的高性价比选择。

2. 环境准备与版本说明

接下来我们进入实战环节。这一节先准备好微调大模型和后续部署所需的环境。

2.1 硬件环境建议

示例环境以 Ubuntu 20.04 / 22.04 + CUDA 11.8 或 12.x 为例。不同 GPU 驱动对应的 CUDA 版本不同，请先通过nvidia-smi查看本机 CUDA 版本。

2.2 创建虚拟环境

推荐使用 Conda 创建独立的 Python 环境，避免不同项目之间出现依赖冲突。

conda create -n llm python=3.10 -y conda activate llm

2.3 安装 PyTorch

LLaMA-Factory 依赖 PyTorch，请到 PyTorch 官网选择对应 CUDA 版本的安装命令。例如：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

注意，cu118是针对 CUDA 11.8 的版本。如果你的环境是 CUDA 12.1，可改为cu121，如果安装的是 CPU 版本，后续无法使用 GPU 训练。版本需要根据你的项目实际情况调整，这里重点是演示配置思路。

2.4 安装 LLaMA-Factory

LLaMA-Factory 的安装非常简洁，推荐直接从 GitHub 克隆代码仓库：

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .

安装完成后，可以用下面的命令检查是否安装成功：

llamafactory-cli version

如果希望使用 Web 界面进行低代码微调，推荐同时安装 Gradio 相关组件，新版 LLaMA-Factory 会在安装主依赖时自动处理。

2.5 项目目录结构

整理后的项目结构如下：

LLaMA-Factory/ ├── data/ # 数据集目录 ├── examples/ # 示例配置 ├── src/ # 核心源码 ├── output/ # 训练输出目录（需手动创建） ├── models/ # 模型权重目录（建议单独指定） └── logs/ # 日志目录

实际项目中，我更建议把models目录放在单独的大容量磁盘路径下，因为基座模型权重动辄十几 GB。

3. 在 LLaMA-Factory 上完成 LoRA 微调实战

这一节我们用 Qwen 系列模型作为示例，在 LLaMA-Factory 上完成一次 LoRA 微调，流程覆盖数据准备、模型下载、训练配置、运行训练、模型合并与导出。

3.1 准备训练数据

微调数据推荐使用指令格式。简单来说，每条样本包含用户输入和期望模型给出的回答。LLaMA-Factory 对数据格式有明确约定，支持 Alpaca 格式和 ShareGPT 格式。

以 Alpaca 格式为例，一个 JSON 数据文件的条目结构如下：

[ { "instruction": "请根据下面的需求写出对应的 Python 代码。", "input": "计算列表 [3, 5, 2, 8, 1] 中所有大于 3 的元素之和。", "output": "下面是实现代码：\n\ndef sum_greater_than_three(nums):\n return sum(x for x in nums if x > 3)\n\nprint(sum_greater_than_three([3, 5, 2, 8, 1])) # 输出 13" } ]

如果任务不依赖额外输入，input字段可以留空。

接下来在LLaMA-Factory/data/dataset_info.json中注册数据集。打开该文件，按照已有格式追加条目：

"my_custom_dataset": { "file_name": "my_custom_dataset.json", "columns": { "prompt": "instruction", "query": "input", "response": "output" } }

这里需要特别注意字段映射关系。如果你的 JSON 文件和示例字段名不一致，要在columns中按实际字段名调整。

3.2 选择并下载基座模型

以 Qwen2.5-7B-Instruct 为例，可以从 Hugging Face 或 ModelScope 下载。国内开发者推荐使用 ModelScope 镜像，下载速度更稳定。

pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./models/Qwen2.5-7B-Instruct

下载完成后会形成如下目录：

models/Qwen2.5-7B-Instruct/ ├── config.json ├── generation_config.json ├── model-00001-of-00004.safetensors ├── ... ├── tokenizer.json └── tokenizer_config.json

3.3 使用命令行执行 LoRA 微调

LLaMA-Factory 支持通过llamafactory-cli或 YAML 配置文件方式启动训练。推荐使用 YAML 方式，便于版本管理和参数复现。

创建train_lora.yaml：

# 模型与路径 model_name_or_path: ./models/Qwen2.5-7B-Instruct output_dir: ./output/qwen25-7b-lora dataset: my_custom_dataset template: qwen # 训练策略 finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 # 训练参数 per_device_train_batch_size: 1 gradient_accumulation_steps: 8 learning_rate: 2.0e-4 num_train_epochs: 3.0 lr_scheduler_type: cosine warmup_ratio: 0.03 logging_steps: 10 save_steps: 500 max_length: 2048 # 量化与分布式相关 quantization_bit: 4 quantization_type: nf4 # 其他 bf16: true trust_remote_code: true

这里解释几个关键参数：

• finetuning_type: lora：指定使用 LoRA 微调。
• lora_rank: 16：低秩矩阵的秩，值越大可学习参数量越多，但不一定效果更好。
• lora_alpha: 32：LoRA 缩放系数，通常设置为 rank 的 1 到 2 倍。
• quantization_bit: 4：模型量化位数。这里是 4-bit 量化后训练，也就是 QLoRA。
• gradient_accumulation_steps: 8：梯度累积步数，在显存受限时等效增大 batch size。
• max_length: 2048：输入序列最大长度，超过部分会被截断，可根据数据长度调整。

执行训练命令：

llamafactory-cli train train_lora.yaml

3.4 训练过程中的关键观察点

训练开始后会输出类似日志：

{'loss': 1.5234, 'learning_rate': 1.2e-5, 'epoch': 0.02} {'loss': 0.8231, 'learning_rate': 1.5e-5, 'epoch': 0.5} {'loss': 0.5123, 'learning_rate': 1.9e-5, 'epoch': 0.9}

需要重点关注 loss 曲线是否持续下降。如果 loss 波动很大，或长时间居高不下，可以尝试调整学习率或将训练数据重新清洗一遍。训练正常结束后，在output_dir目录下会生成 LoRA 适配器权重。

3.5 测试 LoRA 模型效果

训练完成后，可以先直接在 LoRA 权重基础上做推理验证：

llamafactory-cli chat \ --model_name_or_path ./models/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./output/qwen25-7b-lora \ --template qwen

这时模型会加载 LoRA 权重并进入对话模式。测试时建议准备几条训练集中出现过的类似问题，同时准备训练集之外的问题，分别观察模型的表现。

3.6 导出并合并模型

LoRA 权重通常不能直接用于常规推理框架部署，需要将 LoRA 权重合并回原模型。执行以下命令：

llamafactory-cli export \ --model_name_or_path ./models/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./output/qwen25-7b-lora \ --template qwen \ --finetuning_type lora \ --export_dir ./output/qwen25-7b-lora-merged \ --export_size 4 \ --export_legacy_format false

合并后的模型权重保存在./output/qwen25-7b-lora-merged，可以直接用 vLLM、TGI 等推理框架加载。

3.7 验证微调效果

合并模型完成后，可以通过一段 Python 代码快速验证：

from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "./output/qwen25-7b-lora-merged" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, device_map="auto", torch_dtype="auto", trust_remote_code=True ) prompt = "请根据下面的需求写出对应的 Python 代码：计算列表 [3, 5, 2, 8, 1] 中所有大于 3 的元素之和。" messages = [{"role": "user", "content": prompt}] inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt").to(model.device) outputs = model.generate(inputs, max_new_tokens=512, do_sample=True, temperature=0.6) response = tokenizer.decode(outputs[0][inputs.shape[1]:], skip_special_tokens=True) print(response)

4. 从 LoRA 微调到 QAT 量化部署

微调完成后，接下来要考虑的是部署。很多开发者会在这一步发现：模型虽然效果不错，但推理速度太慢，根本无法满足线上要求。这时候就要引入量化。

4.1 静态 PTQ 与 QAT 的选型判断

如果你对精度损失不敏感，或者模型规模较大、训练资源不足，可以先用 PTQ 方案，也就是直接使用 GPTQ、AWQ、bitsandbytes 等方法量化模型。

如果你已经在微调阶段就跑通了完整训练流程，并且推理端对时延和吞吐要求很高，比如必须使用 4-bit 量化且精度不能下降太多，那么建议做 QAT。

从工程效率角度，我一般建议遵循下面的决策顺序：

1. 先用 PTQ 做 8-bit 量化，观察精度损失。
2. 如果精度可接受，直接部署，节省时间。
3. 如果 8-bit PTQ 精度损失大，或需要进一步压到 4-bit，考虑 QAT。
4. 如果业务数据非常丰富，可以在 QAT 阶段用业务数据继续训练。

4.2 基于 PyTorch 的 QAT 简单示例

QAT 的内部实现细节在不同框架中差异较大。PyTorch 官方提供了torch.ao.quantization模块，对 Transformer 做 QAT 的大致流程如下：

import torch import torch.ao.quantization as quant # 1. 加载训练好的模型 model = AutoModelForCausalLM.from_pretrained( "./output/qwen25-7b-lora-merged", torch_dtype="float32", device_map="cpu", ) # 2. 切换为训练模式，并配置 QAT 配置 model.train() qat_config = torch.ao.quantization.get_default_qat_qconfig("x86") # 3. 在模型中插入伪量化节点（核心步骤） model.qconfig = qat_config # 对不需要量化的层可以设置为 None，例如： # model.lm_head.qconfig = None # 4. 准备 QAT 模型 model_prepared = quant.prepare_qat(model, inplace=False) # 5. 继续训练若干轮，让模型适应低比特表示 # for batch in dataloader: # outputs = model_prepared(**batch) # loss = outputs.loss # loss.backward() # optimizer.step() # 6. 训练结束后切换为推理模式并完成静态量化 model_prepared.eval() model_prepared.to("cpu") model_quantized = quant.convert(model_prepared, inplace=False) # 7. 保存量化后的状态字典 torch.save(model_quantized.state_dict(), "qwen_qat_int8.pt")

这个示例展示的是 CPU 后端 INT8 QAT 的 API 调用顺序。实际项目中，GPU 后端的 4-bit QAT 通常会使用英伟达 TensorRT Model Optimizer 或 Intel Neural Compressor 等更成熟的工具库，这些工具已经把上面的流程封装成了更高层的接口，也在算子层面做了更深入的适配。

需要在本地验证 QAT 效果时，可以把量化后的模型与原始模型放在同一批评测样本上做精度对比。

4.3 QAT 训练时的显存控制

QAT 因为要在反向传播中同时计算权重和激活的量化误差，显存占用通常会高于普通微调。常用的显存优化手段有：

• 使用 8-bit AdamW 优化器。
• 减小 batch size，增加梯度累积步数。
• 对激活值做分块量化，避免一次性保存大量浮点中间结果。
• 使用序列长度较小的子集做 QAT 校准训练。

需要注意的是，QAT 不同于完全从头训练，它是在已经收敛的模型基础上做少量 step 的“适应训练”。学习率通常要设置得更小，训练轮数也很少，一般 1 到 3 个 epoch 甚至几百个 step 就足够。

5. 基于 Embedding 模型搭建 AgentRAG 实战

当微调与量化部署走通之后，另一个高频场景是知识库问答。复杂一点的场景往往不是只靠模型微调就能解决，还需要引入 RAG。

5.1 RAG 的整体架构与角色分工

一个典型的 RAG 系统包含以下组件：

5.2 Embedding 模型选型要点

以开源模型为例，我们可以选择 BGE-M3 这类支持多语言和长文档的模型。选择时要注意以下几点：

• 中文场景优先考虑中文语料上训练或优化的模型。
• 如果文档语言复杂，考虑多语言模型。
• 向量维度影响存储成本和检索速度，不是越高越好。
• 输入长度限制决定了单个 chunk 可以有多大。

加载一个嵌入模型的简单示例：

from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-m3") texts = [ "大模型微调的方法包括全量微调和LoRA微调。", "量化感知训练能够减少量化后的精度损失。" ] embeddings = model.encode(texts, normalize_embeddings=True) print(embeddings.shape) # (2, 1024)

得到向量后，可以接入向量数据库。以 Chroma 为例：

import chromadb from chromadb.utils import embedding_functions client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection( name="knowledge_base", embedding_function=embedding_functions.SentenceTransformerEmbeddingFunction( model_name="BAAI/bge-m3" ) ) # 写入文档 collection.add( documents=[ "全量微调会更新所有模型参数，显存需求较高。", "LoRA 微调冻结了原始权重，通过低秩矩阵实现高效训练。" ], ids=["doc1", "doc2"] ) # 检索 results = collection.query(query_texts=["如何高效微调大模型？"], n_results=2) print(results["documents"])

生产环境中更推荐使用 Milvus 这类独立部署的向量数据库，因为它支持大规模数据、实时写入和更复杂的过滤条件。

5.3 AgentRAG 的简单实现

AgentRAG 和普通 RAG 的区别，在于 Agent 可以根据问题动态决定检索策略。以 LangChain 为例，可以设计一个简单的“检索 Agent”，让大模型自主决定是否调用检索工具。

下面是一个最小化实现思路：

from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain.llms import OpenAI # 示例示意图 from langchain.tools import tool from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings from langchain.prompts import ChatPromptTemplate # 初始化向量数据库 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") vectordb = Chroma(persist_directory="./chroma_db", embedding_function=embeddings) # 定义检索工具 @tool def search_knowledge(query: str) -> str: """根据用户问题检索知识库，返回相关文档片段。""" docs = vectordb.similarity_search(query, k=3) return "\n".join([doc.page_content for doc in docs]) # 模型与提示词 llm = OpenAI(model="gpt-4o-mini", temperature=0)

如果在本地部署环境中跑 AgentRAG，语言模型部分可以换成之前用 LLaMA-Factory 微调后导出的本地模型，并把 Embedding 模型换成开源 BGE 模型。这样可以形成一套完全私有化的知识库问答链路。

5.4 微调模型与 RAG 的互补关系

需要强调的是，微调和 RAG 并不互斥，它们解决的是不同问题：

最佳实践是：用微调改变模型的“行为习惯”（如格式、语气、工具的调用方式），用 RAG 补足“事实知识”（如企业内部文档、实时数据）。两者结合使用效果通常最好。

6. 常见问题与排查思路

在实际操作中，无论是微调还是量化部署，碰到报错都很正常。下面整理几组高频问题。

6.1 LLaMA-Factory 训练相关

6.2 量化部署相关

6.3 RAG 效果相关

提供一套通用排查步骤：

1. 先打日志，确认用户问题是否成功转成向量。
2. 直接打印检索出的文档，确认相关文档是否被正确召回。
3. 检查最终 Prompt 中的上下文是否包含了检索内容。
4. 如果召回正常但回答仍不对，问题大概率在生成模型或 Prompt 构造上。

7. 最佳实践与工程建议

7.1 微调项目中的数据管理

数据质量直接决定微调效果。这里分享几条我在实际项目中总结的经验：

• 至少准备 500 到 1000 条高质量样本起步，样本太少时优先考虑 few-shot 或 RAG。
• 每条样本的指令应该明确，回答应该干净、无冗余。
• 训练集和验证集要分离，不要用同一批数据既训练又评估。
• 对数据进行去重、脱敏、格式检查。
• 保留一份原始数据作为基准，数据集每次更新时都要做版本记录。

7.2 实验管理的工程化建议

微调是一个反复试错的过程，建议从一开始就对实验进行规范管理：

• 每一次实验对应一个独立输出目录，命名包含模型名、方法、时间。
• 将训练参数保存到 YAML 中，并和输出权重放在一起。
• 记录每次实验的 loss 曲线图和评测结果。
• 使用 TensorBoard 或 W&B 追踪训练过程。

7.3 量化部署的生产注意事项

量化不是单纯的模型压缩，它涉及推理框架、算子支持和硬件适配。生产环境部署时注意以下几点：

• 先在小流量环境验证量化模型的精度和性能。
• 保留原始 FP16 模型作为回退版本。
• 建立量化前后效果的回归评测集。
• 对时延、吞吐、首 token 延迟分别压测，避免只看整体吞吐。
• 如果使用了 QAT，注意训练环境与部署环境的算子兼容性。

7.4 RAG 系统上线后的持续优化

RAG 系统上线后需要持续运营，而不是部署完就结束。

• 对线上问答效果做定期抽检，发现问题补充知识。
• 监控向量库的写入质量和召回率。
• 当数据量变大时，考虑引入混合检索，比如关键字检索与向量检索的结合。
• 对敏感业务，加入权限管控，确保用户只能检索到自己有权限的文档。
• 对 AgentRAG 中 Agent 的每一步决策都要记录日志，否则很难排查问题。

8. 总结与学习路线

走到这里，你已经把大模型微调、量化部署和 RAG 应用这条链路走了一遍。

本文主要梳理了这些关键知识点：

• 全量微调、Freeze 微调与 LoRA/QLoRA 微调的联系与区别。
• QAT 量化感知训练的基本原理，以及和 PTQ 相比的优劣势。
• 使用 LLaMA-Factory 完成 LoRA 微调的完整流程，从数据准备到模型导出。
• Embedding 模型在 RAG 中的作用与选型要点。
• AgentRAG 与普通 RAG 的差异，以及一个最小实现思路。
• 微调、量化、RAG 三者在实际业务中的配合方式。

下一步可以继续学习的方向有很多：

• 如果你想深入 QAT，可以研究英伟达 TensorRT Model Optimizer 中 QAT 的实现方式。
• 如果你想提升微调效果，可以学习数据集构建、DPO 偏好对齐和奖励模型训练。
• 如果你想做好 RAG，可以研究 rerank 模型、混合检索、query 改写和评估体系。

最后给你一条建议：不要试图一次把全链路都学到底，最好的方式是先跑通一个小模型、小数据集的端到端流程，再逐步扩大规模优化细节。动手永远是学习大模型工程最好的老师。

如果这篇文章对你理解 QAT、LoRA 微调、LLaMA-Factory 和 AgentRAG 有帮助，可以收藏备用。也欢迎在评论区分享你在微调或部署过程中遇到的坑，一起交流解决方案。