企业官网建设流程全解析

在业务中落地大模型应用时，我们常常面临一个核心矛盾：如何让通用大模型精准掌握并运用我们私有的、最新的知识？直接提问往往得到的是过时或通用的答案。本文将系统性地介绍两种主流解决方案——RAG（检索增强生成）与SFT（监督微调），并提供一个从零开始的实战教程，涵盖Embedding模型部署、LangChain框架整合，到最终私有化微调的完整闭环。无论你是希望快速构建一个基于知识库的问答系统，还是想通过微调让模型深度内化你的领域知识，这篇文章都将提供清晰的路径和可运行的代码。

1. 背景与核心概念：RAG与SFT的定位与选择

在深入实战之前，我们必须厘清RAG和SFT各自解决了什么问题，以及它们在不同场景下的优劣。这对于技术选型至关重要。

1.1 RAG：外部知识库的“即时查询”

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思想是“即用即查”。它不改变大语言模型（LLM）本身的参数，而是在用户提问时，先从外部的知识库（如向量数据库）中检索出最相关的文档片段，然后将这些片段和问题一起交给LLM，让它基于这些“参考资料”来生成答案。

优点：

• 知识更新成本低：只需更新向量数据库中的文档，无需重新训练模型。
• 可解释性强：答案来源于检索到的文档，可以追溯来源，增强可信度。
• 避免幻觉：通过提供准确的参考信息，能有效减少模型“胡编乱造”。
• 实现相对简单：技术栈成熟，有LangChain等框架助力，快速上手。

缺点：

• 上下文长度限制：检索到的文档总长度受LLM上下文窗口限制，可能无法涵盖所有相关知识。
• 依赖检索质量：如果检索不到或检索错误，答案质量会急剧下降。
• 无法改变模型“思维”：模型本身对特定领域术语、行话、推理逻辑的理解没有改变。

典型场景：企业知识库问答、产品手册查询、法律条文检索、客服机器人（基于标准文档回答）。

1.2 SFT：让模型“成为”领域专家

SFT（Supervised Fine-Tuning，监督微调）则是通过使用领域特定的高质量问答数据对预训练好的大模型进行额外的训练，从而调整其内部参数，使其输出风格、知识结构和推理方式都更贴近目标领域。

优点：

• 内化知识：模型真正“学会”了领域知识，回答更自然、深入，能进行复杂推理。
• 突破上下文限制：模型本身具备了知识，无需在每次提问时塞入大量参考文档。
• 响应速度快：生成阶段无需额外的检索步骤。

缺点：

• 成本高：需要准备高质量的标注数据，且训练过程消耗大量计算资源（GPU显存）。
• 更新不灵活：一旦知识更新，需要重新收集数据并训练，流程长。
• 灾难性遗忘风险：微调不当可能导致模型忘记原有的通用能力。
• 黑盒性：难以精确解释模型为何给出某个答案。

典型场景：代码助手定制、特定行业（如医疗、金融）报告生成、风格化写作、复杂流程推理。

1.3 如何选择：RAG + SFT的协同

在实践中，RAG和SFT并非互斥，而是可以协同工作，形成更强大的系统。

• 初级阶段/知识快速落地：优先使用RAG，快速验证需求，构建原型。
• 高频/复杂领域任务：在RAG基础上，收集高质量的用户交互数据，对模型进行SFT，使其表现更专业。
• 混合架构：使用SFT微调一个“领域专家”模型，同时结合RAG为其提供最新的、非训练数据内的信息，实现“专家+实时资料库”的效果。

本文的实战路径将遵循这一认知：先搭建一个可用的RAG系统，再在此基础上探讨SFT微调的实践。

2. 环境准备与版本说明

我们将构建一个基于本地部署的RAG系统，并演示微调的准备流程。请确保你的开发环境满足以下要求。

核心环境：

• 操作系统：Linux (Ubuntu 20.04+) 或 macOS，Windows建议使用WSL2。
• Python：3.9 或 3.10（这是多数AI框架兼容性最好的版本）。
• CUDA（如使用NVIDIA GPU）：11.8 或 12.1（需与PyTorch版本匹配）。
• 内存：建议16GB以上。
• 存储：至少20GB可用空间。

Python包依赖：我们将使用requirements.txt来管理。关键库及其作用如下：

• langchain&langchain-community：RAG应用框架，提供模块化组件。
• sentence-transformers：用于运行本地Embedding模型。
• chromadb：轻量级、开源的向量数据库。
• pypdf&python-docx：用于解析PDF和Word文档。
• unstructured：更强大的非结构化文档解析器。
• transformers&accelerate&peft：来自Hugging Face，用于模型加载和微调。
• bitsandbytes（可选）：用于量化加载，降低微调显存需求。
• torch：深度学习框架。

你可以创建一个新的虚拟环境并安装依赖：

# 创建并激活虚拟环境（以conda为例） conda create -n rag-sft python=3.10 conda activate rag-sft # 安装PyTorch（请根据你的CUDA版本访问PyTorch官网获取正确命令） # 例如，对于CUDA 11.8 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 安装其他依赖 pip install langchain langchain-community sentence-transformers chromadb pypdf python-docx unstructured pip install transformers accelerate peft bitsandbytes

项目结构预览：

rag-sft-project/ ├── data/ # 存放原始知识文档 │ └── your_documents.pdf ├── vector_db/ # ChromaDB数据库持久化目录 ├── scripts/ │ ├── 01_embedding_server.py # Embedding模型服务化脚本 │ ├── 02_build_vectordb.py # 构建向量数据库脚本 │ └── 03_rag_chain.py # RAG问答链脚本 ├── finetune/ │ ├── dataset.py # 数据准备脚本 │ └── train.py # 微调训练脚本 ├── requirements.txt └── README.md

3. 核心组件拆解：Embedding、VectorDB与LangChain

3.1 Embedding模型：将文本转换为向量

Embedding模型是将文本（词、句、段落）映射到高维向量空间的核心，其质量直接决定检索的准确性。我们选择在本地部署sentence-transformers模型，它平衡了性能与资源消耗。

# 示例：使用 sentence-transformers 生成Embedding from sentence_transformers import SentenceTransformer # 加载模型（首次运行会自动下载） # 推荐模型：'all-MiniLM-L6-v2'（英文，速度快），'paraphrase-multilingual-MiniLM-L12-v2'（多语言） model = SentenceTransformer('all-MiniLM-L6-v2') # 生成单个句子的向量 sentence = "This is a sample sentence." embedding = model.encode(sentence) print(f"Embedding shape: {embedding.shape}") # 输出形如 (384,) # 生成多个句子的向量 sentences = ["First sentence.", "Second sentence."] embeddings = model.encode(sentences) print(f"Batch embeddings shape: {embeddings.shape}") # (2, 384)

关键点：向量维度（如384）代表了文本信息的编码密度。相似文本的向量在高维空间中的距离（通常用余弦相似度衡量）会更近。

3.2 向量数据库：存储与检索向量

我们使用ChromaDB，它轻量、易用且与LangChain集成良好。其核心操作是：存储文档内容及其对应的向量，并提供基于向量相似度的检索。

import chromadb from chromadb.config import Settings # 创建或连接一个持久化的客户端 client = chromadb.PersistentClient(path="./vector_db", settings=Settings(allow_reset=True)) # 获取或创建一个集合（Collection），类似数据库中的表 collection = client.get_or_create_collection(name="knowledge_base") # 假设我们有一些文档和它们的ID documents = ["The capital of France is Paris.", "Python is a programming language."] ids = ["doc1", "doc2"] # 生成这些文档的Embedding并添加到集合中 # 注意：在实际LangChain流程中，添加和生成Embedding是自动的 collection.add( documents=documents, ids=ids, # embeddings=... # 如果提供，则直接使用；否则ChromaDB会使用默认的Embedding函数 ) # 进行相似性检索 query = "What is the capital of France?" results = collection.query( query_texts=[query], n_results=2 # 返回最相似的2条 ) print(results['documents']) # 打印检索到的文档

3.3 LangChain：编排RAG流水线

LangChain的核心价值在于“链”（Chain）。它将文档加载、文本分割、向量化、存储、检索、提示词构建、LLM调用等步骤串联成一个可复用的流水线。

核心概念：

• Document Loader：从各种源（文件、网页、数据库）加载文档。
• Text Splitter：将长文档分割成适合嵌入和上下文窗口的小块。
• VectorStore：封装了向量数据库的操作。
• Retriever：从VectorStore中检索相关文档的接口。
• LLM：大语言模型提供商（如OpenAI API，或本地模型如Llama）。
• Chain：将上述组件组合起来的工作流。

4. 完整实战：构建本地RAG知识库问答系统

4.1 步骤一：启动本地Embedding服务

虽然LangChain可以直接调用sentence-transformers，但将其服务化有利于解耦和复用。我们可以创建一个简单的FastAPI服务。

# scripts/01_embedding_server.py from fastapi import FastAPI from pydantic import BaseModel from sentence_transformers import SentenceTransformer import uvicorn app = FastAPI() # 在服务启动时加载模型，避免每次请求重复加载 model = SentenceTransformer('all-MiniLM-L6-v2') class EmbeddingRequest(BaseModel): texts: list[str] class EmbeddingResponse(BaseModel): embeddings: list[list[float]] @app.post("/embed", response_model=EmbeddingResponse) async def get_embeddings(request: EmbeddingRequest): embeddings = model.encode(request.texts).tolist() return EmbeddingResponse(embeddings=embeddings) if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=5000)

运行python scripts/01_embedding_server.py，Embedding服务将在http://localhost:5000启动。

4.2 步骤二：构建向量数据库

接下来，我们编写脚本，将本地data/目录下的文档（如PDF、Word、TXT）进行处理并存入ChromaDB。

# scripts/02_build_vectordb.py import os from langchain_community.document_loaders import DirectoryLoader, PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings # 1. 加载文档 documents = [] data_path = "./data" for root, dirs, files in os.walk(data_path): for file in files: file_path = os.path.join(root, file) if file.endswith('.pdf'): loader = PyPDFLoader(file_path) elif file.endswith('.txt'): loader = TextLoader(file_path, encoding='utf-8') else: continue # 可扩展支持更多格式 documents.extend(loader.load()) print(f"Loaded {len(documents)} documents.") # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个块的最大字符数 chunk_overlap=50, # 块之间的重叠字符数，保持上下文连贯 separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) split_docs = text_splitter.split_documents(documents) print(f"Split into {len(split_docs)} chunks.") # 3. 创建向量存储 # 使用本地sentence-transformers模型 embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2") # 或者使用我们刚启动的Embedding服务 # from langchain.embeddings import OpenAIEmbeddings # embeddings = OpenAIEmbeddings(openai_api_base="http://localhost:5000/v1", openai_api_key="none") # 需适配 # 持久化到本地目录 vectorstore = Chroma.from_documents( documents=split_docs, embedding=embeddings, persist_directory="./vector_db" ) print("Vector database built and persisted successfully.")

4.3 步骤三：实现RAG问答链

现在，我们创建一个问答链，它集成了检索器和LLM。这里我们使用开源的Ollama来本地运行一个轻量级LLM（如llama3.2或qwen2.5:3b），你也可以替换为OpenAI API。

# scripts/03_rag_chain.py from langchain.chains import RetrievalQA from langchain.llms import Ollama from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma from langchain.prompts import PromptTemplate # 1. 加载已构建的向量数据库 embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2") vectorstore = Chroma(persist_directory="./vector_db", embedding_function=embeddings) # 2. 创建检索器 retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) # 检索4个最相关的块 # 3. 初始化本地LLM（确保已安装并运行Ollama，且拉取了对应模型） llm = Ollama(model="llama3.2", temperature=0.1) # temperature控制创造性 # 4. 定义自定义提示词模板，指导LLM基于上下文回答 prompt_template = """请根据以下上下文信息来回答问题。如果你不知道答案，就诚实地回答不知道，不要编造信息。 上下文： {context} 问题：{question} 请基于上下文给出答案：""" PROMPT = PromptTemplate( template=prompt_template, input_variables=["context", "question"] ) # 5. 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 将检索到的所有文档“塞”进上下文 retriever=retriever, chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True # 返回源文档用于溯源 ) # 6. 进行问答 if __name__ == "__main__": while True: query = input("\n请输入你的问题 (输入 'quit' 退出): ") if query.lower() == 'quit': break result = qa_chain({"query": query}) print(f"\n答案：{result['result']}") print("\n参考来源：") for i, doc in enumerate(result['source_documents']): print(f"[{i+1}] {doc.page_content[:200]}...") # 打印片段

运行此脚本，一个基于你私有文档的本地智能问答系统就搭建完成了。

5. 迈向SFT：私有化模型微调实战

当RAG系统运行一段时间后，你可能会积累一些高质量的问答记录。这些数据可以用来微调一个更懂你业务的模型。我们以使用Qwen2.5-1.5B模型和LoRA（低秩适配）微调为例，这是一种参数高效微调方法，能大幅降低显存需求。

5.1 数据准备

微调需要格式化的指令数据。通常是一个JSONL文件，每行包含一条instruction（指令）、input（可选输入）、output（期望输出）。

# finetune/dataset.py import json # 假设我们从RAG日志或人工标注中获得了以下数据 qa_pairs = [ { "instruction": "根据公司政策，年假如何计算？", "input": "", "output": "员工入职满一年后，每年享有10天带薪年假。年假计算周期为自然年，可分段休假，最小休假单位为0.5天。" }, { "instruction": "请报销流程是什么？", "input": "差旅费用报销", "output": "差旅费用报销需在行程结束后30天内提交。步骤：1. 在OA系统填写《差旅费报销单》；2. 粘贴所有原始发票；3. 经部门经理审批；4. 提交至财务部。" }, # ... 更多数据 ] # 保存为JSONL格式 with open('./finetune/train_data.jsonl', 'w', encoding='utf-8') as f: for item in qa_pairs: f.write(json.dumps(item, ensure_ascii=False) + '\n') print("训练数据已保存。")

5.2 使用LLaMA-Factory进行微调

LLaMA-Factory是一个功能强大且易于使用的大模型微调框架，支持多种模型和微调方法（全参、LoRA、QLoRA等）。我们使用其命令行工具进行微调。

首先，安装LLaMA-Factory：

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .[torch,metrics]

准备一个配置文件finetune/qa_finetune.yaml：

# 模型配置 model_name_or_path: Qwen/Qwen2.5-1.5B # Hugging Face模型ID # 数据配置 dataset_dir: ./finetune dataset: train_data.jsonl template: qwen2.5 # 使用与模型匹配的模板 # 训练配置 finetuning_type: lora # 使用LoRA微调 lora_target: all # 对所有线性层应用LoRA output_dir: ./output per_device_train_batch_size: 4 gradient_accumulation_steps: 4 learning_rate: 1e-4 num_train_epochs: 3 logging_steps: 10 save_steps: 100 # 节省显存配置（如果显存不足） quantization_bit: 4 # 使用4位量化（QLoRA）

运行微调命令：

cd LLaMA-Factory llamafactory-cli train \ --stage sft \ --do_train \ --model_name_or_path Qwen/Qwen2.5-1.5B \ --dataset_dir ../finetune \ --dataset train_data.jsonl \ --template qwen2.5 \ --finetuning_type lora \ --output_dir ../output \ --overwrite_cache \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --lr_scheduler_type cosine \ --logging_steps 10 \ --save_steps 100 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --plot_loss \ --quantization_bit 4 # 如果显存小于8GB，建议启用

训练完成后，在output目录下会得到适配器权重（adapter_model.bin）。你可以使用LLaMA-Factory的推理脚本或整合到LangChain中使用微调后的模型。

5.3 整合微调模型到LangChain

将微调后的模型（原始模型+LoRA权重）加载到LangChain中，替换之前Ollama的LLM。

from langchain.llms import HuggingFacePipeline from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline from peft import PeftModel # 1. 加载基础模型和分词器 base_model_name = "Qwen/Qwen2.5-1.5B" model = AutoModelForCausalLM.from_pretrained(base_model_name, device_map="auto", torch_dtype=torch.float16) tokenizer = AutoTokenizer.from_pretrained(base_model_name) # 2. 加载LoRA适配器权重 lora_path = "./output" model = PeftModel.from_pretrained(model, lora_path) # 3. 创建文本生成管道 pipe = pipeline( "text-generation", model=model, tokenizer=tokenizer, max_new_tokens=512, temperature=0.1, do_sample=True, ) # 4. 封装为LangChain的LLM custom_llm = HuggingFacePipeline(pipeline=pipe) # 5. 替换之前qa_chain中的llm # qa_chain.llm = custom_llm

6. 常见问题与排查思路

在构建RAG和进行SFT的过程中，你可能会遇到以下典型问题。

7. 最佳实践与工程建议

7.1 RAG系统优化

1. 分块策略精细化：不要只用一种分块大小。对于结构化文档（如Markdown），可以按标题分块；对于代码，按函数或类分块。可以混合多种分块策略，存入同一个向量库。
2. 元数据过滤：在存储文档块时，同时存储元数据（如来源文件、章节标题、创建日期）。检索时，除了向量相似度，还可以结合元数据进行过滤，提升精度。
3. 重排序（Re-ranking）：在向量检索出Top K个结果后，使用一个更精细但更慢的交叉编码器模型对它们进行重排序，只将最相关的几个片段送入LLM，这能显著提升答案质量。
4. Hybrid Search：结合关键词搜索（如BM25）和向量搜索，取长补短。ChromaDB等现代向量库已支持混合搜索。
5. 缓存机制：对常见问题的检索结果和LLM回答进行缓存，能极大降低响应延迟和API成本。

7.2 SFT微调工程化

1. 数据质量至上：微调效果90%取决于数据。确保数据准确、多样、无矛盾。指令应清晰，输出应是该指令下的“最佳答案”。建议先通过RAG系统收集真实用户问题，再进行人工清洗和标注。
2. 使用验证集：务必从训练数据中留出10-20%作为验证集，用于监控训练过程，防止过拟合。
3. 渐进式微调：不要一开始就用全部数据训练很多轮次。尝试先用小批量数据训练1-2轮，评估效果，再逐步增加数据和轮次。
4. 评估指标：除了损失函数，应设计业务相关的评估指标，如通过一组标准问题，对比微调前后答案的准确性和流畅度。
5. 版本管理：对训练数据、模型检查点、训练配置进行严格的版本控制（如使用DVC、Git LFS）。

7.3 生产环境部署考量

1. 服务化：将Embedding服务、RAG问答API、微调模型推理服务都封装成独立的API（如使用FastAPI），便于扩展和维护。
2. 监控与日志：记录每一次问答的查询、检索到的文档、LLM的输入输出、耗时和用户反馈。这对于分析系统瓶颈和迭代优化至关重要。
3. 安全与权限：如果知识库包含敏感信息，需要在检索前加入权限校验层，确保用户只能检索其有权访问的内容。
4. 成本控制：如果使用商用LLM API，需设置用量监控和限流。对于本地模型，则需关注GPU资源的利用率调度。

从RAG到SFT，是一个从快速验证到深度定制的过程。RAG让你在几天内就能搭建一个可用的知识问答系统，是验证想法和收集数据的利器。而SFT则是将你的私有数据“注入”模型，打造真正专属AI助手的必经之路。建议从RAG起步，在业务中跑通流程、积累数据，当遇到RAG的瓶颈（如对复杂推理要求高、回答风格需高度一致）时，再启动SFT项目。两者结合，方能构建出既精准又智能的企业级大模型应用。