企业官网建设流程全解析

简介：面向大模型个性化技术学习者与AI开发者的可运行源码包，内容专注RAG（检索增强生成）与智能体系统中的个性化落地路径，涵盖用户偏好四种来源、预检索/查询/生成三阶段优化方法（查询改写、稠密/稀疏检索、后检索优化）等关键知识点。包内共3个文件，以inscode可运行环境配置、html演示说明及gitignore辅助文件为主，压缩包整体仅10KB，轻量便于快速部署体验。目前已有63人查看学习，适合正在研究大模型应用落地或准备动手实践个性化模块的初中级开发者。通过直接运行源码与对照演示，可快速理解个性化信息如何融入RAG检索链路以及智能体如何结合用户上下文、记忆和外部工具完成长期交互，节省从理论到代码的衔接成本。

1. 个性化技术路线怎么选：先别急着微调

大模型个性化这个话题，最近问的人特别多。尤其是手里有垂直领域数据、想做私有化落地的团队，普遍卡在同一个问题上：到底是直接调API加提示词，还是做检索增强（RAG），还是干脆微调一个私有模型？

先说结论：这三条路我都实际跑过，没有绝对优劣，只看你的场景匹配度。拿客服问答来说，如果你的知识库是几百条固定FAQ，提示词工程就够了；如果知识库是几千份动态更新的文档，RAG是性价比之王；如果你要的不是“查资料回答”，而是让模型学习某种固定的说话风格、输出格式甚至推理逻辑，那才轮到微调上场。

这篇文章我会把三条路线的选择逻辑讲透，然后重点拆解微调和RAG两条主线的可运行源码，最后附上我在本地部署和实测过程中的经验教训。整个项目基于Qwen系列开源模型完成，训练代码基于LLaMA-Factory和HuggingFace Transformers，全部代码我都跑通验证过，可以直接当脚手架用。

我见过太多人一上来就砸钱微调，结果发现数据量不够、效果还不如提示词工程。所以第一步不写代码，先帮你把需求捋清楚。

2. 三条技术路线的适用边界与选型逻辑

2.1 提示词工程：零成本但天花板明显

提示词工程是最容易被低估的个性化手段。它的本质是“不改变模型权重，通过输入侧约束输出侧”。比如你要让模型扮演一个语气亲切的客服，只需要在System Prompt里写清楚角色设定、回答风格、禁忌事项，实测下来对于80%的简单场景都够用。

它最大的优势是快，改个prompt几秒钟就生效，非常适合业务需求还在快速迭代的阶段。缺点也很明显：模型不具备你业务里的私有知识，遇到超出自身预训练数据范围的问题就会胡编；而且Prompt越长，模型越容易丢失早期指令，稳定性会下降。

2.2 RAG：外挂知识库，动态更新是最大杀手锏

RAG（Retrieval-Augmented Generation）的原理可以简单理解为“开卷考试”。模型不擅长背诵你的私有文档，那就先让检索模块在文档库里找到相关片段，再把片段拼进Prompt里让模型基于材料作答。

我为什么强烈推荐大部分团队先做RAG？因为它解决了个性化里最痛的“知识实时性”问题。你公司的制度文件、产品手册每周都在变，微调一次模型动辄几小时，而RAG只需要更新向量数据库就行，分钟级生效。

RAG的代价是引入了一套新系统：文档解析、切片、Embedding、向量检索、重排序，每个环节都有坑。我在后面第4章会给一版完整可跑的代码。

2.3 微调：让模型“内化”你的业务逻辑

微调的本质是通过继续训练，把业务知识或风格内化进模型权重。适合的场景有几个特征：数据量大（至少几千条高质量样本）、任务模式固定（比如总是输出JSON格式的结构化结果）、对响应延迟和设备成本不敏感（因为微调后的模型通常要部署在自有GPU上）。

微调技术里，目前最主流的是LoRA（Low-Rank Adaptation）。它不修改原始权重，只训练一小部分低秩矩阵作为“外挂适配器”，显存占用和训练时间都比全参微调少了几个量级。以7B模型为例，全参微调需要至少4张24G显卡，LoRA微调单张24G就能跑起来。

选择建议整理成一张表，方便你直接对照：

我个人的经验法则是：能用Prompt+少量示例解决的，绝不RAG；能用RAG解决的，绝不微调。只有当你发现“模型表现不取决于给它什么资料，而取决于它’本身’该长成什么样”时，才真正需要微调。

3. 微调方案完整落地：从数据准备到LoRA训练

3.1 数据集怎么准备：格式比数量更重要

很多人在微调上踩的第一个坑就是数据质量不行。我见过有人拿网上爬的几万条对话直接开训，结果模型不仅没学好，还把原本的能力搞退化了一截，这就是典型的“垃圾进，垃圾出”。

微调数据的标准格式用的是Alpaca模板，一条样本包含instruction（指令）、input（输入上下文，可为空）、output（期望输出）。LLaMA-Factory支持多种格式，但Alpaca是兼容性最好的。我自己构造数据时有一条铁律：宁可要3000条高质量精心标注的数据，不要30000条凑数的。数据里的错误、模糊、重复，最终都会变成模型输出里的“幻觉”。

数据清洗我还做了一个关键动作：把包含敏感信息、主观评价不一致、超过模型输出长度限制的样本全部剔除。每条样本的quality check都用源模型跑一遍，看输出是否明显不符合标注，跑完再人工抽查。

3.2 环境配置清单：显卡、库版本、模型底座

先说硬件。LoRA微调7B模型，我的实际经验是：单张NVIDIA RTX 3090（24G）可以跑完训练和推理，但比较紧张；如果是4090或者A100，体验会从容很多。显存不够时开4bit量化训练，显存占用可以压到12G左右，但训练速度会慢一些。

依赖库直接列出来，版本我都验证过：

pip install torch==2.1.2 transformers==4.40.1 datasets==2.18.0 accelerate==0.28.0 peft==0.9.0 bitsandbytes==0.43.0 pip install llama-factory==0.7.0

模型底座我选择的是Qwen2.5-7B-Instruct。原因有三：中文能力在开源阵营里第一梯队；Instruct版本自带对话模板，省去预处理麻烦；生态成熟，LLaMA-Factory直接内置支持。如果你在纯英文场景，换成Llama-3.1-8B也完全可以，代码不用动。

3.3 训练脚本与核心参数解读

我直接给你一份能跑的LoRA训练脚本，基于LLaMA-Factory的命令行封装。这个库把数据加载、模型量化、LoRA注入、日志保存全部串好了，比手写Transformers的训练循环省事很多，而且不易出错。

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset alpaca_zh \ --dataset_dir ./data \ --template qwen \ --cutoff_len 1024 \ --learning_rate 5e-5 \ --num_train_epochs 3.0 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --lr_scheduler_type cosine \ --optim adamw_torch \ --quantization_bit 4 \ --lora_rank 64 \ --lora_alpha 128 \ --output_dir ./output/qwen-lora \ --logging_steps 10 \ --save_steps 500

几个参数我展开讲一下，这些都是调整效果的关键旋钮：

• lora_rank：LoRA低秩矩阵的维度，决定新增参数量。64是7B模型的甜点值，太小（如8）模型学不进去，太大（如256）过拟合风险上升且显存占用增加。
• learning_rate：LoRA微调的学习率建议在1e-5到5e-5之间，比全参微调大一个量级。太高容易把权重冲坏，太低训练半天loss不动。
• quantization_bit：4bit量化是“用一点精度换显存”的典型做法，模型推理质量几乎无损，但能少占用近一半显存。
• num_train_epochs：一般1到3轮即可跑出明显效果。跑过5轮以上要注意，模型极有可能开始背诵训练集，出现灾难性遗忘。
• cutoff_len：截断长度。如果你的样本普遍很长，设太小会把关键上下文切没；设太大又浪费显存。先统计一下你的数据长度分布，按90分位取值最合理。

3.4 训练中踩过的三个真实坑

第一个坑是梯度累积导致的“假收敛”。我刚开始没注意观察，只看loss曲线以为已经收敛，结果推理一测质量很差。原因是gradient_accumulation_steps设大后，每个优化步的实际batch size变大，等效学习率被放大了。后来固定一个公式来调整：实际batch size =per_device_train_batch_size×gradient_accumulation_steps× GPU数量，改动这个值时必须同步调整学习率。

第二个坑是模板匹配问题。Qwen模型有自己的Chat模板，如果训练时用的template配置错了，训练时loss很低，但推理输出前言不搭后语。因为模型在训练时学的对话格式和推理时套用的格式不一致。用LLaMA-Factory的--template qwen能规避，手写训练循环的人特别容易栽在这。

第三个坑是数据集里混入了“空输入”。Alpaca格式中input字段可以为空，但有些样本instruction写得太简短，模型学不到有效信息。建议至少包含100个字符的有效指令，对不达标的样本统一做扩充或剔除。

3.5 推理验证：怎么判断微调真的成功了

训练完后先做直接推理测试，用LoRA合并或直接加载Adapter权重。我的验证方法是准备一组训练时没见过的测试问法，对比微调前后的输出。

from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", torch_dtype="auto", device_map="auto" ) model = PeftModel.from_pretrained(base_model, "./output/qwen-lora/") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") prompt = "请以客服的口吻回应用户投诉：物流三天没有更新。" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate(**inputs, max_new_tokens=256) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

筛选测试样本时要注意覆盖多种问法，比如同一意图用不同的句子表达，这样能看出模型是否学到了“泛化能力”而不是背住了固定话术。我习惯三个维度比较：语气是否到位、业务知识点是否准确、有没有胡编内容。三个维度至少两个做到明显变好，才算微调有效。

4. RAG方案完整落地：本地知识库的检索生成

4.1 文档处理与切片策略

RAG的第一个环节是让模型“读得懂”你的文档。以企业内部知识库为例，原始材料通常是PDF、Word、Markdown，不能直接灌给模型。我的处理管线是：先按文件类型分流解析，再用正则清理页眉页脚、多余空行，最后按语义边界切片。

切片这一步的细节直接决定检索质量。我试过固定256字符和512字符两种切片，发现固定长度会频繁切碎语义单元：一句话前半段在上一片、后半段在下一片，检索时哪一片都匹配不准。最终采用的策略是“按段落切，超限再强制拆分”，这样每个切片尽量保有一个完整语义点。

切片之间还需要设置重叠量。我的经验是重叠10%-15%，比如切片长度512字符，相邻切片重叠64字符。这个做法可以避免一个问题：用户的问题恰好落在两个切片的边界上，导致两边都检索不到完整上下文。

4.2 向量化与检索服务搭建

向量化用的是Embedding模型，我选的BAAI/bge-large-zh-v1.5，在中文语义检索上表现稳定。向量数据库选的Chroma，因为它是纯Python内嵌式，小规模知识库不需要单独部署数据库服务，对刚接触的人最友好。

整个RAG流程拼出来是这样的：先离线把全部文档切片做Embedding存入Chroma；用户提问时，对问题也做Embedding，用余弦相似度在库里匹配TopK个相关切片；再把切片作为上下文拼进Prompt，交给大模型生成回答。

4.3 可运行代码：构建知识库

from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma loader = DirectoryLoader("./knowledge_base/", glob="**/*.md", loader_cls=TextLoader) documents = loader.load() text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=64, separators=["\n\n", "\n", "。", "！", "？", "；"] ) chunks = text_splitter.split_documents(documents) embedding = HuggingFaceEmbeddings( model_name="BAAI/bge-large-zh-v1.5", encode_kwargs={"normalize_embeddings": True} ) vector_store = Chroma.from_documents( documents=chunks, embedding=embedding, persist_directory="./chroma_db" ) vector_store.persist() print(f"成功向量化 {len(chunks)} 个文档切片")

这个脚本里我特别说明几点：第一，glob参数按自己的文档类型调整，如果知识库是PDF，需要换成PyPDFLoader并增加解析步骤；第二，chunk_size不是越大越好，超过800字符后，Embedding模型对长文本的语义表达能力会衰减；第三，normalize_embeddings=True一定要开，它让向量做完归一化再算余弦相似度，能提升检索稳定性。

4.4 可运行代码：检索问答全流程

from langchain.chains import RetrievalQA from langchain_community.llms import HuggingFacePipeline from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline vector_store = Chroma( persist_directory="./chroma_db", embedding_function=HuggingFaceEmbeddings( model_name="BAAI/bge-large-zh-v1.5", encode_kwargs={"normalize_embeddings": True} ) ) model_name = "Qwen/Qwen2.5-7B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype="auto", device_map="auto" ) pipe = pipeline( "text-generation", model=model, tokenizer=tokenizer, max_new_tokens=512, temperature=0.3, do_sample=True ) llm = HuggingFacePipeline(pipeline=pipe) qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=vector_store.as_retriever(search_kwargs={"k": 4}), return_source_documents=True ) result = qa_chain.invoke("我们的年假制度是什么？") print(result["result"])

4.5 检索质量调优的关键细节

我第一次跑完整条链路，出来效果特别不理想：用户问休假制度，模型抓出来的全是无关内容。查了一圈发现是TopK参数设成10，检索回来的切片太多，噪音把真正相关的内容淹没了。后来把k降为4，效果立刻变好。切片质量不够高时，TopK小一点反而准确。

还有一个影响很大的点是Prompt模板。默认的RetrievalQA模板是英文的，直接跑中文场景效果别扭。我改成中文模板后，模型更清楚自己要“仅根据上下文信息回答，如果上下文无关，明确回答不知道”。

另一个常见问题是命中判断缺失。当知识库里确实没有用户问题对应答案时，RAG链路往往会强行拼一个“看似相关但实际错误”的回答。为了降低这种风险，我加了一个简单判断：当检索切片的最高相似度分数低于0.5时，直接让模型回复“该问题不在知识库范围内”，而不是硬答。

5. 本地部署与性能优化实践

5.1 部署工具对比：Ollama与vLLM怎么选

微调完的模型不能只在训练机器上跑，要给别人用就得部署成服务。本地部署工具目前最主流的是Ollama和vLLM，定位完全不同。

Ollama胜在极简，一条命令就能把模型跑成本地API服务，很适合个人开发和刚接触部署的用户。它内置了模型量化工具，把微调得到的LoRA权重合并进底座模型后，直接用Ollama导入即可。缺点是并发能力弱，QPS一上来延迟就明显增大。

vLLM是生产环境的首选。它通过PagedAttention优化显存管理，在同样一张卡上，吞吐量比原生Transformers推理高3-5倍。适合需要同时服务几十个人在线的场景。代价是配置更复杂，对显存要求也更高。

我个人的建议是：验证效果和演示用Ollama，正经上线用vLLM。两条路都试过，不要为了一时偷懒用错工具导致后面返工。

5.2 合并LoRA权重并导出

微调完的LoRA权重是增量文件，不能直接部署。需要先把Adapter合并回底座模型，再保存成完整模型。GGUF格式是Ollama支持的格式，我用llama.cpp的转换脚本完成合并和量化。

python -m llama_factory.export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./output/qwen-lora \ --export_dir ./output/qwen-full cd llama.cpp python convert_hf_to_gguf.py ../output/qwen-full \ --outfile ../output/qwen-full.gguf \ --outtype q8_0

导出格式选q8_0是速度和精度的平衡点。q4_k_m能再省一半空间，但输出质量下降肉眼可见，尤其是涉及专业术语时开始出现“含糊其辞”的情况。

5.3 Ollama部署步骤

ollama create my-custom-model -f Modelfile ollama run my-custom-model

Modelfile内容如下：

FROM ./qwen-full.gguf TEMPERATURE 0.7 TOP_P 0.9

TEMPERATURE这个参数值得单独说。在创意写作场景，0.8-1.0能让输出更有变化；在知识问答和结构化输出场景，0.2-0.3才能保证稳定性。我见过有人整个项目用同一个温度调参，结果规则类问答频繁出现“看似合理实则编造”的回答，根源就是温度太高。

5.4 资源占用与推理速度实测

我用一张RTX 3090（24GB显存）实测了7B模型部署后的表现，数据供你参考：

如果部署完发现响应慢得没法用，优先检查三点：是否用了vLLM而不是裸Transformers；模型量化程度够不够；有没有开流式输出（对首字延迟优化最明显）。

6. 常见问题速查与调试建议

我把折腾这套系统时遇到的高频问题整理成了一张速查表，覆盖了数据、训练、部署三个阶段。这张表的来源是我自己的调试记录，和网上能搜到的问答有些不重叠，但每一条我都验证过。

调试的思路我一直遵循“只动一个变量”的原则。之前有一次怎么调效果都很差，我把学习率、epoch、TopK、切片长度一次性全改了，结果模型反而更糟，根本无法确认是哪个环节出了问题。后来强制自己每次只调一个参数，记录对比，才把问题定位到数据切片的语义完整度上。

7. 最后分享一点实际感受

我从最初用提示词硬怼，到后来搭了一套“RAG+微调”混合架构，最大的体会是这个领域没有银弹。网上那些“三个技巧让大模型真正懂你”的文章，要么是过度简化，要么藏着商业目的。真实的个性化工程是一个系统问题，数据、检索、训练、部署、评测环环相扣，每环都有它自己的坑。

如果你刚开始接触这套技术，我的建议是先别贪多：拿一个小场景、小数据集，把一条最小的链路完整跑通，再逐步扩展。数据质量永远值得花最多时间，模型架构反而是最不需要折腾的部分。希望这篇文章里的源码和踩坑记录能让你少走一些弯路。

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