企业官网建设流程全解析

搞科研的人最烦什么？组里积累了上百篇论文、内部标准、实验记录、代码注释，每次想查一个参数或者某个方法的具体出处，都要翻半天。通用大模型能聊，但不能直接用，它不知道你们组的“黑话”，更不敢把敏感资料喂到云端。我这两年把课题组私有大模型这条路完整走了一遍：国产开源底座选型、领域语料构建、RAG检索增强、LoRA/QLoRA高效微调、知识蒸馏、GPTQ/AWQ量化，最后用vLLM把服务拉起来应对多人并发。前后迭代了几个版本才稳定。如果你也在实验室、小团队或项目组里做私有AI，这篇把每个阶段的选型和坑都摊开说，可以直接当落地清单用。

1. 先把“私有AI”这件事拆清楚

1.1 为什么最终没有直接调通用大模型API

很多人第一反应是把数据往通用大模型API里一传，写个Prompt就完事。但在真实课题组里，这有几个绕不过去的问题。

首先是数据边界。论文初稿、未公开的实验数据、合作单位的内部材料，这些东西出了内网就是问题，即便你签了保密协议，心理上也不踏实。其次是成本，API按token计费，RAG场景每次要把检索到的长段落塞进上下文，一天跑几千次，费用肉眼可见地涨。核心问题是可控性：通用API的模型行为不可调，你没法让它强制输出“基于组内规范”“引用指定文档”，也没法在它乱答的时候定位原因。

所以私有化不是炫技，是被需求逼出来的。课题组的数据量通常不算大，几万到几十万条文档，但专业术语密度高、领域知识割裂严重。这种情况下，与其期待一个大模型“记住”所有内容，不如把架构拆成：底座模型负责语言理解和生成，知识库负责事实供给，微调和蒸馏负责行为校准。这样的好处是每一层都能单独替换、评测和回滚。

1.2 国产开源模型选型的判断标准

我见过太多人一上来就挑最大参数量的模型，结果一张卡跑不起来，最后改来改去。选型的核心约束其实是三样：显存、推理延迟、可微调性。

我整理了一个选型表格，适合课题组和小团队参考。

选型时我主要看四条。第一，中文能力和术语理解，不能用跑分掩盖，而是拿你自己领域里五十个“黑话”去试。第二，许可证是否允许商用和模型权重分发，很多国产模型现在都是宽松许可，但你要看一下对“输出内容”和“二次分发”的限制。第三，生态是否跟得上，HuggingFace、ModelScope上有没有量化版，PEFT、LLaMA-Factory、vLLM是否直接支持。第四，微调和部署的社区案例多少，否则遇到问题只能自己啃。

我个人的建议是，预算有限就从7B/8B开始，跑通全链路再往上扩。别小看7B，配合优质的RAG和LoRA微调，很多场景能接近甚至超越未调优的32B模型，而且推理速度快得多。

1.3 “底座+检索+适配”三层架构，各干什么活

项目推进时，我刻意把系统分成了三层，避免一开始就把问题揉成一团。

底座模型层解决“怎么说话”：它决定用词、语法、上下文理解、指令跟随。这一层不要直接承载领域事实，因为大模型的强项不是记忆，而是语言生成。知识检索层解决“说什么”：RAG把用户问题转成向量，去知识库捞相关段落，再把段落拼接成上下文送给模型。这一层负责事实供给，也是后面2、3、4章的重点。行为适配层解决“怎么按你的规矩说话”：LoRA微调和知识蒸馏都在这个层面，让模型输出风格、格式、引用习惯更贴近课题组需求，比如必须给出文档编号、必须承认“未在知识库中找到”。

顺序上我强烈建议“先RAG，再微调”。因为RAG能快速解决事实缺失，微调解决的是风格和行为。如果你什么都没做就微调，模型会把训练数据里的片段背下来，一旦用户问的问题跨文档，它照样幻觉，而且你很难判断是知识库没召回还是模型在瞎编。

2. 领域语料构建与RAG知识库：不是把PDF丢进去就行

2.1 语料采集、清洗与解析

RAG最容易被低估的是前端语料处理。很多人直接把PDF往向量库里一丢，结果召回率惨不忍睹，原因往往是文本里混着页眉页脚、参考文献、图表标签，甚至扫描件全是乱码。

我跑项目时的流程是这样。

第一步是采集。把论文PDF、Word文档、实验报告模板、专利文件、内部SOP全部集中到一个目录，按来源分类。第二步是格式归一化。PDF用PyMuPDF抽取文本，扫描版优先走MinerU或者OCR工具做版面分析，把标题、正文、表格分开。Word和Markdown用pandoc转成统一格式。第三步是清洗。去除页眉页脚、连续的参考文献列表、URL、无意义的换行。这里最容易被忽略的是表格：PDF里表格跨页后，直接抽出来是断的，必须做单元格级别的合并。

清洗后的文档建议统一转成Markdown或JSON结构，保留标题层级关系。这一步看着麻烦，但对后面切分和召回非常有帮助，因为结构信息比纯文本块更容易被检索模型理解。

2.2 Chunk切分、Embedding模型和向量库选型

切分策略是RAG召回率最大的影响因素之一。

最省事的办法是固定长度切分，比如512个token，重叠128个token。这个方案适合内容比较零散的内部制度。但论文和报告有明确的章节结构，我建议做结构感知切分，先按Markdown标题拆成小节，再对超长小节做固定长度兜底，这样每个chunk都自带“章节上下文”。

还有一种进阶方式是“父子chunk”：小chunk负责精确召回，父chunk保存更大上下文。具体做法是检索时只匹配小chunk，返回时把父chunk整体送给模型，既保证命中又避免上下文碎片化。

Embedding模型方面，国产方案现在很能打。BGE-M3是我用得最多的，支持中文、英文、长文本，也能输出稀疏向量用于混合检索。Qwen3-Embedding-0.6B是后起之秀，0.6B参数量很小，中文效果不错，适合内网离线部署。如果你看到有人讨论“docker vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b”，这里要提醒一下：vLLM主要服务生成模型，加载Embedding模型要看镜像版本是否支持Embedding接口，如果支持，模型名写成qwen3-embedding-0.6b就行；如果版本不支持，老老实实用FastAPI加sentence-transformers单独起一个服务，避免给自己添堵。

向量库选型上，轻量场景用Chroma或FAISS就够。数据量上了百万级别，建议Milvus或者Elasticsearch。我并不迷信高性能向量库，因为课题组通常数据量不大，关键是把检索链路做对。

2.3 RAG的召回瓶颈、命中率与重排

RAG最常见的问题是“检索到了但没排到前面”。我用BM25关键词检索和向量检索双路召回，然后把两路结果合并，再用一个重排模型统一打分，效果远比单路向量检索稳。

评测指标上，最该盯的是Hit Rate和MRR。Hit Rate是“答案所在文档片段是否出现在前N个结果”，MRR看的是正确片段排得多靠前。我每次调完切分策略和Embedding模型，都会用一组带标准答案的测试题跑一下，对比改动前后这两个指标。如果Hit Rate低于0.7，说明问题在召回链路，不要急着换大模型。

还有一个容易被忽视的问题：RAG瓶颈往往不在检索，而在“上下文被无关内容污染”。假设你取top_k=5，里面只有一条有用，模型要在一堆噪声里找答案，能力再强也容易翻车。所以我后来把top_k从5降到了3，或者只用重排后的前2条。别贪多，相关性比数量重要。

2.4 RAG知识库能存图片吗

这个问题我被问过很多次。答案是能，但要看你想怎么用。

文本知识库本身没法“理解”图片，路径通常有两种。一种是把图片里的文字提取出来再进入知识库：扫描版论文、图表截图，先走OCR或版面分析，把文字当作正文，图片存一个路径链接。这样做的好处是检索结果能对应到原文档，读起来有据可查。

另一种是真正做多模态检索：图片不用转文字，而是用多模态模型直接生成图片描述文本，描述进入向量库；也可以直接用CLIP类模型做图文联合向量，用户输入文字就能匹配图片。这个方案适合实验装置照片、质谱图、电路板图等场景。我的建议是，如果图片里的关键信息主要是文字，就走第一种；如果图片传达的是视觉特征，再上多模态方案。

2.5 知识割裂问题：Ontology RAG和GraphRAG

普通RAG的问题在于知识割裂。每一条chunk自己是完整的，但不同文档之间的关系没有建立起来。比如A文档说“用方法M做了实验”，B文档说“方法M的参数是xx”，它们各自都能被检索到，但模型不知道这两条信息属于同一个实验链条。

后来我引入Ontology RAG的思路，先建立领域实体和关系清单，比如“实验方法”“参数”“仪器”“样本来源”，然后把文档里的实体抽取出来，链接到知识图谱，检索时把关键实体所在的子图数据作为额外上下文一起送给模型。GraphRAG也是类似逻辑，用图谱组织社区结构，回答跨文档问题明显稳了很多。对课题组来说不需要构建一个庞大本体，先把最核心的“实体-关系”做一个几十条的轻量本体，就足够改善回答的连贯性了。

3. LoRA/QLoRA高效微调：用最小显存改变模型行为

3.1 LoRA和QLoRA的原理，以及为什么能省显存

如果你搞过全参微调，一定清楚7B模型在BF16下全参微调的显存有多恐怖。LoRA的思路是冻结原模型权重，只训练两个低秩矩阵A和B，假装用一个小矩阵逼近“权重变化量”。这样训练参数只占原模型的0.1%到1%，显存需求骤降。

QLoRA在LoRA的基础上更进一步，把底座模型量化成4-bit的NF4格式存储，同时配合分页优化器，把优化器状态放到CPU内存，训练时再从CPU换到GPU。以7B模型为例，全参SFT可能需要60G以上显存，QLoRA在单张24G卡上就能跑。这个“省显存”不是没有代价的，训练速度会变慢，而且量化损失会在梯度回传时引入噪声。但对课题组来说，能在一张卡上完成迭代，比追求极致效果重要得多。

3.2 微调数据构造：质量比数量重要

很多人以为微调就是把文档丢给模型“背书”。一旦你这么做，模型会变得非常“油嘴滑舌”，看似在回答，其实是在重复训练语料里的段落。我踩过这个坑后，总结了一套数据构造方法。

微调数据至少要分三类。第一类是指令问答对，一条指令对应一条标准回答，回答要干净、不啰嗦、带引用格式。第二类是信息抽取或格式转换任务，比如“从这段实验记录中提取反应条件并输出JSON”。第三类是修正样本，把模型之前回答错的、跑偏的案例拿回来，人工修改后做成negative做纠正。比例上我推荐指令问答占70%，格式任务占20%，修正样本占10%。

构造数据时最核心的原则其实很简单：你希望模型上线时怎么回答，训练时就给什么样的回答。不要写那种长篇大论没有来源的答案，模型学到的就是你交给它的生成范式。

3.3 训练参数怎么调：rank、alpha、学习率、epoch

用LLaMA-Factory或PEFT跑LoRA时，我常被问参数怎么设。我的基线做法是：lora_rank=16，lora_alpha=32，target_modules选q_proj、k_proj、v_proj、o_proj，最多再加gate_proj和up_proj，学习率用2e-4到1e-5之间递减，epoch跑1到3轮。你看到lora_alpha=32似乎和rank翻倍没什么关系，其实alpha主要控制更新权重缩放，固定成rank的两倍只是经验值，不必太纠结。

上下文长度方面，RAG喂进来的段落可能很长，微调时建议把max_seq_len设置成1280或2048，至少和线上推理长度一致，避免“训练时短、推理时长”导致的泛化崩坏。数据量上，几千条高质量样本就够看到效果，不需要几十万条。

有一点要特别提一下：LoRA这个缩写在大模型领域是低秩适配，但如果你在通信项目里搜“LoRa通信代码”，那是另一个完全不同的概念。写代码时注意别混在一起，防止拿错库。

3.4 过拟合、遗忘和验证方法

微调最容易踩的两个坑是过拟合和灾难性遗忘。过拟合的表现是训练集loss很低，但验证集和真实问题一塌糊涂。灾难性遗忘更隐蔽：模型会做领域问答了，但通用能力、代码能力变差。

我的做法是每次微调完成后，固定跑三组评测：领域评测集、通用中文能力小测、上一轮微调前的老样本回归测试。如果领域得分涨了，通用分掉了超过5%，就降低epoch或者加大lora_rank，而不是硬着头皮继续练。另外推荐多保存几个checkpoint，用不同的验证集对比，不要只看最后一个epoch。

还有一个小技巧：如果只想提升RAG场景下的回答风格，不需要把训练数据里的“知识”喂给模型。给模型一批“带着上下文回答问题”的样本，让它学会“只能根据给定段落回答，不要展开想象”，这比让它背知识点有效得多。

4. 知识蒸馏：让小模型从大模型身上学

4.1 为什么蒸馏通常放在微调之后

蒸馏这步经常被忽略。课题组一开始直接上7B模型，效果还不错，但并发一上来，单卡推理吞吐跟不上了。换更小模型比如3B/4B，效果又下降。蒸馏就是用来弥补这个差距的：用一个更大的教师模型生成领域偏好数据，再拿这些数据训练小模型，让小模型“继承”教师模型的输出习惯。

顺序上，我建议先把LoRA/QLoRA微调跑通，让模型具备领域基础，然后再做蒸馏。因为蒸馏的核心是“教师模型要教得对”，如果教师模型本身连你们组的术语都不熟，生成的训练数据就是垃圾。顺序反了，蒸馏只会放大问题。

4.2 蒸馏数据怎么生成：教师模型、提示词与清洗

我的教师模型选的是一个参数量更大的开源模型，比如Qwen2.5-32B或者DeepSeek系列。虽然显存大了点，但只做离线生成，不跑线上推理，所以可控。

生成蒸馏数据的提示词模板有几个要点。先给模型一段领域原始文档，再给一个问题，要求它“只根据文档内容回答，不要添加任何外部知识”，并且输出格式固定成“结论+依据原文位置”。一次生成一条数据后，我会跑一个简单的规则校验：回答里是否出现了原文的关键字，是否包含“我猜测”“可能是”这类模糊表述，如果有就标记为候选坏数据。

生成完毕后务必做去重和难度筛选。大模型生成相似问题很频繁，重复数据会害了小模型，让它在同一地方反复过拟合。我建议对生成数据做Embedding去重，相似度大于0.95的直接丢弃。

4.3 温度、软标签和训练细节

知识蒸馏有两种常见姿势。一种是纯“伪标签”方式，拿教师模型的输出当硬文本训练学生模型，这本质上就是SFT。另一种是更标准的蒸馏：教师模型输出每个token的概率分布，学生模型用KL散度去逼近这个分布，重点照顾高概率候选词。

训练时温度T很重要。T太高，概率分布被抹平，小模型学到的都是些“都差不多”的错误信号；T太低，软标签退化成硬标签，蒸馏就没有意义。我习惯先用T=2.0做前几轮，再在后续轮次降到1.0或0.5，让模型先学粗糙规律，再收紧到真实数据。

如果你嫌软标签蒸馏实现麻烦，可以先跑硬文本伪标签蒸馏，效果也不错。关键是生成数据的教师模型质量要高，且学生模型必须和教师模型同系列或至少Tokenizer基本一致，否则分布差距过大，蒸馏损失很难收敛。

5. 量化压缩：GPTQ/AWQ怎么选，以及量化后怎么不掉点

5.1 GPTQ和AWQ的本质区别

模型训练好后，部署前的最后一步是量化。常见的两个方案是GPTQ和AWQ。

GPTQ的思路是逐层量化，同时最小化“量化后权重和原始权重”之间的误差，用一种近似二阶优化的方式，把每一层对整体输出的影响考虑进去。AWQ的思路不一样，它直接观察激活值的分布，找出那些对激活贡献大的重要权重通道，量化的过程中为这些通道保留更高精度。简单说，GPTQ更关注权重本身，AWQ更关注权重在实际输入下的影响力。

我自己的经验是，AWQ在低比特位（4-bit）下通常比GPTQ更稳，尤其在带领域微调LoRA适配器的模型上。GPTQ在高比特位（8-bit）或者校准数据足够充足时表现也很好。两者最终效果差别不会特别大，真正影响部署体验的是生态支持度：vLLM对AWQ和GPTQ都支持，但老版本对某些模型的兼容性有差异，选之前先看vLLM文档。

5.2 量化实操细节：校准集、group size和显存

量化不是把模型文件改小就完事，你还需要一个校准数据集。这个校准集不能随便用几个句子，最好从你的领域语料里采样，覆盖多种句式和长度，让量化过程“看到”线上数据的样子。

以AutoAWQ为例，我常用参数是--quant_method awq --bits 4 --group_size 128，group_size代表每128个权重共享一个缩放因子。group_size越小，量化越精细，模型质量更高，但显存和计算开销也更大。如果硬件紧张，可以试试group_size=256，效果差距不算大。

这里有一个经验坑：量化后的模型不要在推理时再叠加QLoRA训练时的NF4底座。你没看错，QLoRA的底座量化是训练时用的，和静态度量化不是一回事。正确做法是先把LoRA适配器融合回全精度或者半精度模型，然后再做GPTQ/AWQ量化，最后让vLLM加载量化产物。顺序错了，模型输出会翻车。

5.3 量化真的会掉点吗

量化一定会有损失，但好的量化流程可以把损失控制在可接受范围。我在量化前后会跑同一组领域测试题，分别记录生成结果的BLEU、ROUGE或者更主观的“关键信息是否完整”。如果量化后关键信息丢失，说明校准集或者量化参数有问题，别硬上。

还有，量化和蒸馏是可以叠加的。你可以在SFT之后先蒸馏一个更小的模型，再做量化，最终部署的模型可能只有原始教师模型的几分之一大小，但效果仍然不错。这条链路我测下来比较稳，不要跳过任何一步。

6. 本地化部署与高并发推理：vLLM是当前最优解

6.1 vLLM为什么快：PagedAttention和连续批处理

模型有了，量化完了，下一步是把服务拉起来。如果只给自己一个人用，Ollama或LM Studio就够了，但课题组里好几个人同时问问题，还要接知识库API，普通推理框架扛不住高并发。

vLLM的核心是PagedAttention，把KV缓存切成固定大小的块，像操作系统的虚拟内存一样按需分配，避免碎片化显存浪费。另一个是连续批处理，请求不再等整个批次跑完再切换，而是动态插入和挤出，GPU利用率高了不少。实测下来，7B量化模型在vLLM上比普通HuggingFace管线吞吐至少快两三倍，这是很直观的体感。

顺带说一句，SGLang作为一种竞品方案也有自己的优势，但vLLM的社区和生态更成熟，遇到问题更容易找到答案。

6.2 用Docker快速部署服务

部署我用的是Docker加vllm/vllm-openai镜像。最简命令长这样：

docker run --gpus all \ -p 8000:8000 \ --shm-size=8g \ vllm/vllm-openai:v0.27.1 \ --model Qwen/Qwen2.5-7B-Instruct \ --quantization awq \ --served-model-name qwen7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

参数解释一下。--quantization awq告诉vLLM按AWQ量化权重加载；--served-model-name是暴露给客户端的模型名；--max-model-len限制最大上下文长度，过大会预占KV缓存，导致并发上不去；--gpu-memory-utilization 0.9表示允许vLLM占用90%显存，留一点余量给CUDA上下文和临时张量。

如果你的模型是自定义的本地路径，把--model参数改成/models/your-model-path并挂载数据卷。如果还想在同一个Docker环境里加载qwen3-embedding-0.6b做Embedding，先确认当前vLLM版本支持Embedding接口，并把模型名写成qwen3-embedding-0.6b；保险起见，Embedding服务我还是推荐分开部署，别跟生成服务挤在一起。

6.3 并发参数调优和接口对接

加载完成后，本地就有一个兼容OpenAI的API服务，跑一个简单请求验证：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen7b","messages":[{"role":"user","content":"把知识库里关于某方法的段落总结成三条要点"}]}'

如果你想压测并发，注意监控两个指标：TTFT（首token延迟）和吞吐（tokens/s）。--max-num-seqs控制并发序列数，太低会浪费算力，太高会频繁抢占KV缓存。我一般从16开始调，观察显存峰值和TTFT曲线。如果TTFT突然飙升，说明并发已经撞到显存上限，需要降--max-model-len或--max-num-seqs。

6.4 Ollama、LM Studio和vLLM/SGLang的适用边界

很多人搞不清楚Ollama和vLLM的关系。我的判断是：Ollama适合单机快速体验，模型管理方便，但不适合精细控制并发和上下文，也不方便接复杂知识库链路。LM Studio适合没有Linux环境的人做模型预览。vLLM和SGLang才是生产级选择。

Java后端团队接入时，可以用LangChain4j的Easy RAG功能，它把文档解析、向量化、检索和LLM调用串好了，能快速把vLLM的OpenAI接口配置进去。我之前帮一个组搭过，用LangChain4j的EmbeddingStore和AiServices，配置文件里指向http://localhost:8000/v1即可，省去自己写RAG管道的功夫。

如果模型换成DeepSeek系列，vLLM部署方式基本一样，只是模型名和分词器不同。需要注意显存，DeepSeek的MoE结构虽然参数量大，但激活参数小，用vLLM部署时配置--max-num-seqs要更保守，因为MoE的显存行为跟Dense模型不太一样。

7. 常见问题与排查实录

7.1 知识库召回不准怎么办

我会按这个顺序排查。第一，检查切分粒度，是不是把一句话劈成了两半，建议改成结构切分或父子chunk。第二，换Embedding模型，BGE-M3和Qwen3-Embedding值得一试。第三，加混合检索，向量+BM25双路召回。第四，加重排模型，BGE-reranker通常能把正确片段提到前两名。每改一步就重跑一次Hit Rate，别凭感觉。

7.2 微调后模型乱回答、套话多怎么办

套话多说明训练数据里有大量“正确的废话”。把训练数据翻出来看看，如果很多回答都是在讲通用原则而不是结合给定上下文，模型自然学会敷衍了。建议把RAG场景下的回答改成“先给结论，再引用原文编号，最后给一句解释”，并把这种格式固化到数据集里。

乱回答另一个常见原因是训练时没有加系统提示。在LLaMA-Factory里要确保每条指令都带系统提示模板，否则模型上线时面对系统提示会手足无措。

7.3 部署时显存溢出或吞吐太低

显存溢出第一件事看--gpu-memory-utilization，留太少会崩，开到0.9通常安全。然后看--max-model-len，8K看起来不算长，但KV缓存会占掉大量显存，降到4K试试。如果并发一直上不去，考虑加一张卡，用--tensor-parallel-size 2做张量并行。

吞吐太低先看--max-num-seqs是不是太小，再检查是否卡在单个长请求上。长请求会占住连续显存，导致后续请求排队。可以用多路短请求压测，把平均吞吐调到稳定值。

7.4 热词里那些“坑”汇总

这段时间搜“RAG知识库能存储图片嘛”的人特别多，我在第2.4节已经给了方案：图像转文本后入库，或者用多模态向量。搜“取得了RAG知识割裂问题”的，建议直接上轻量本体/知识图谱方案，而不是继续堆更多chunk。

搜“LoRA微调”的人容易把LoRA和通信里的LoRa搞混，其实两者毫无关系。不要被网上的模型帖子带偏，找教程时认准“低秩适配”这个关键词。

最后提一句，很多社区里流行的绘画类LoRA权重，本质是风格迁移，和课题组做私有AI的场景差得很远。不需要在这些权重上花时间，也别把时间投入任何与学术和项目无关的敏感内容上。专注自己的数据，做出来的模型才是真正有用的。

8. 我想说的最后一件事

这套链路走完，我最大的体会是顺序千万别乱。先做好语料清洗和RAG，再利用LoRA做行为微调，蒸馏负责压缩，量化负责部署，最后用vLLM扛并发。每一步都有各自的目的，跳步或者回头重做，成本都很大。

很多团队一上来就想微调，忽略语料和检索，最后模型聊天很顺畅，但一问到具体实验记录就露馅。还有的拼命堆参数，把rank开到128，结果模型只会背训练样本。做私有AI和做科研一样，先把评测集建好，再谈优化。我给自己的规矩是：任何一次改动，都要有领域测试集的分数变化做依据，没有评测的“感觉变好了”都是假象。

接下来如果条件允许，我会把每个阶段的脚本和配置整理成一套可直接复用的模板，再配合一套自动评测流程，让课题组可以快速把新文档加进去。毕竟私有AI的价值不在于模型能聊，而在于它真正变成了组内知识的检索助手和写作助手。