企业官网建设流程全解析

1. 大模型技术全景的认知框架

1.1 从热搜词看技术演进脉络

把"大模型、预训练、Agent、LLM、微调"这几个词摆在一起，其实已经勾勒出了一条完整的技术链路。预训练是地基，微调是装修，Agent是住进去之后能自己干活的管家，而LLM则是这整栋楼的统称。很多人学大模型容易陷入一个误区：一上来就扎进LoRA怎么调、Qwen怎么部署，结果调通了却说不清楚模型到底在干什么。我见过太多人卡在"能跑通代码但讲不清原理"的阶段，面试或者做技术方案汇报时露怯。

这条链路的内在逻辑是：预训练解决"通识"问题，微调解决"专业"问题，Agent解决"行动"问题。预训练阶段模型在海量文本上学习语言的统计规律，相当于一个人从小学读到大学，什么都学一点；微调阶段用特定领域数据继续训练，相当于读了个硕士博士，专精某个方向；Agent则是给这个毕业生配上手脚和工具箱，让它能查资料、调API、操作软件，真正把知识变成行动。

理解这个框架的意义在于，当你在实际项目中遇到问题时，能快速定位是哪个环节出了毛病。模型回答泛泛而谈？可能是预训练知识够但微调没到位。模型能回答但不会用工具？那是Agent层没搭好。模型在特定任务上胡言乱语？大概率是微调数据质量有问题。这种分层思维能帮你省下大量盲目试错的时间。

1.2 不同角色的学习路径差异

我接触过各种背景想学大模型的人，发现一个规律：不要试图一次性吃透所有环节，而是根据自己的目标倒推需要掌握什么。

如果你是应用开发者，重点应该放在Agent开发和提示词工程上。预训练和微调的底层细节可以暂时跳过，知道概念即可。你需要的是理解LLM的输入输出特性、上下文窗口限制、Token计费逻辑，然后学会用LangChain、LlamaIndex这类框架搭建Agent。这条路径上手快，一两周就能做出能用的东西。

如果你是算法工程师，微调是核心技能。你需要理解LoRA、QLoRA、Adapter这些参数高效微调方法的原理和适用场景，知道什么数据配比能出什么效果，能诊断loss曲线异常。这条路径需要一定的深度学习基础，但不需要从头训练模型。

如果你是研究者或者想深入底层，预训练和模型架构是必修课。Transformer的注意力机制、位置编码、归一化策略、混合专家模型的路由逻辑，这些都需要啃论文加动手实验。这条路径周期最长，但天花板也最高。

我个人的建议是：先花两天时间把整条链路的概念过一遍，然后选一个方向深扎。最怕的是每个环节都浅尝辄止，最后什么都做不出来。

2. 预训练：大模型的知识底座

2.1 预训练到底在做什么

预训练的本质是让模型学会预测下一个Token。给定一段文本，模型不断预测下一个词是什么，预测错了就调整参数，预测对了就强化。这个过程重复几万亿次之后，模型就掌握了语言的语法、事实知识、甚至一定的推理能力。

为什么预测下一个词这么简单的任务能学到这么多东西？因为要准确预测下一个词，模型必须理解上下文。比如"中国的首都是___"，模型要知道"北京"；"苹果公司的CEO是___"，模型要知道"库克"。这些知识不是显式教给模型的，而是从海量文本中自动提取的。

预训练的数据量级是惊人的。以LLaMA系列为例，训练数据达到数万亿Token，涵盖网页、书籍、论文、代码等多种来源。数据处理流程包括去重、质量过滤、敏感内容剔除、Token化等步骤。数据质量直接决定模型能力上限，这也是为什么各家大厂在数据清洗上投入巨大。

训练成本同样惊人。一个百亿参数模型在千卡集群上训练数周是常态，电费就是天文数字。所以绝大多数团队不会从零预训练，而是基于开源模型做继续预训练或微调。

2.2 预训练模型的选择策略

面对Hugging Face上成千上万的预训练模型，怎么选？我总结了一个决策树：

选模型不能只看榜单分数。Open LLM Leaderboard上的排名有参考价值，但实际表现要看你的具体任务。我见过榜单排名很高的模型在特定领域问答上不如小模型的情况。最靠谱的方法是拿你的真实数据做小规模评测，跑个几百条测试用例，看准确率、响应速度、输出格式稳定性。

还有一个容易被忽略的点：模型的Tokenizer会影响中文处理效果。有些英文模型的中文Tokenizer词表很小，一个中文字被拆成多个Token，导致上下文窗口浪费、推理速度慢、语义丢失。选中文模型时一定要看词表大小和中文Token占比。

2.3 继续预训练与领域适配

当你手头有大量领域文本（比如医疗病历、法律文书、金融研报），想让模型更懂这个领域，继续预训练是一个选择。做法是在领域语料上以较小的学习率继续训练，让模型调整参数分布。

继续预训练的关键参数：

• 学习率：通常设为原始预训练的1/10到1/100，比如1e-5到1e-6。太大容易灾难性遗忘，太小则学不到新知识。
• 数据配比：领域数据和通用数据的比例建议在1:1到1:10之间。纯领域数据会导致通用能力下降。
• 训练步数：不是越多越好。通常1-3个Epoch就够了，过多会过拟合。
• 序列长度：根据领域文本特点设置。法律文书可能很长，需要4096甚至8192；对话数据可以短一些。

踩过的坑：有一次用纯医疗数据继续预训练，结果模型连"今天天气怎么样"都回答不好了。后来混入30%通用数据，通用能力保住了，医疗问答也提升了。这个配比需要反复实验。

继续预训练的成本比微调高一个数量级，但效果也更根本。如果你的领域和通用领域差异极大（比如古文、代码、数学证明），继续预训练值得投入。如果只是想让模型学会特定任务的输出格式，直接微调更划算。

3. 微调：让通用模型变成领域专家

3.1 全量微调与参数高效微调的选择

微调分两条路：全量微调和参数高效微调。全量微调更新所有参数，效果最好但成本最高。一个7B模型全量微调需要多张A100，显存占用超过100GB。参数高效微调只更新一小部分参数，比如LoRA只训练低秩矩阵，显存占用降到十几GB，单卡就能跑。

LoRA的原理可以用一个类比解释：假设原始权重是一个大矩阵，全量微调是把这个矩阵每个元素都改一遍；LoRA是认为微调带来的变化可以用两个小矩阵相乘来近似，只训练这两个小矩阵。这样参数量从几十亿降到几百万，但效果能接近全量微调。

QLoRA更进一步，把原始模型量化到4-bit，再在上面加LoRA。这样7B模型微调只需要6GB显存，消费级显卡就能跑。代价是训练速度慢一些，精度损失一点点，但性价比极高。

3.2 LoRA微调实战：以Qwen为例

下面是一套可直接复现的LoRA微调流程。环境准备：

pip install transformers datasets peft accelerate bitsandbytes pip install modelscope # 国内下载模型方便

数据准备是关键。指令微调数据通常构造成JSON格式：

[ { "instruction": "判断以下文本的情感倾向", "input": "这家餐厅的服务态度太差了，等了一个小时都没上菜", "output": "负面" } ]

数据质量比数量重要。我试过用500条精心标注的数据超过5000条噪声数据的效果。标注时要确保：指令清晰无歧义、输入输出格式统一、覆盖各种边界情况、没有重复样本。

训练脚本核心参数：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=8, # 秩，越大容量越强但参数越多 lora_alpha=32, # 缩放因子，通常设为r的2-4倍 target_modules=["q_proj", "v_proj", "k_proj", "o_proj"], lora_dropout=0.1, bias="none", task_type="CAUSAL_LM" ) training_args = TrainingArguments( per_device_train_batch_size=4, gradient_accumulation_steps=4, learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_strategy="epoch", fp16=True, )

参数选择经验：

• r值：简单任务4-8够用，复杂任务可以到16-32。再大收益递减。
• target_modules：至少包含q_proj和v_proj。加上k_proj和o_proj效果更好但参数翻倍。
• 学习率：LoRA通常用1e-4到3e-4，比全量微调大一个数量级。
• Epoch数：1-3个Epoch。超过3个容易过拟合，表现为训练loss持续下降但验证loss上升。

3.3 微调效果评估与迭代

微调完了怎么判断好不好？不能只看训练loss。我通常从三个维度评估：

自动指标：对于分类任务看准确率、F1；对于生成任务看BLEU、ROUGE。但这些指标和人类感受有差距，只能做参考。

人工评估：随机抽100条测试样本，人工判断输出是否合理。重点看：格式是否正确、内容是否准确、有没有胡编乱造、语气是否合适。

对抗测试：故意输入边界情况，看模型是否稳定。比如输入空字符串、超长文本、包含特殊符号、和训练数据分布差异大的样本。

一个常见问题：微调后模型变得"只会做微调任务"，通用对话能力下降。这叫灾难性遗忘。解决办法是在微调数据中混入10%-20%的通用指令数据，或者降低学习率、减少训练步数。

如果效果不达标，排查顺序是：数据质量→数据量→超参数→模型选择。大多数时候问题出在数据上，而不是模型或参数。

4. Agent：让大模型从"会说"到"会做"

4.1 Agent的核心组件与工作原理

Agent这个词听起来玄乎，拆开看就是大模型+工具+记忆+规划。大模型是大脑，工具是手脚，记忆是笔记本，规划是做事的方法论。

一个典型的Agent工作循环：

1. 感知：接收用户输入，理解意图
2. 规划：拆解任务，决定先做什么后做什么
3. 行动：调用工具执行具体操作
4. 观察：获取工具返回结果
5. 反思：判断是否完成目标，没完成则回到步骤2

举个例子，用户说"帮我查一下明天北京的天气，如果下雨就提醒我带伞"。Agent的思考过程是：先调用天气API查北京明天天气→得到结果"中雨"→判断条件"下雨"成立→生成提醒"明天北京有中雨，记得带伞"。

这个过程中，大模型负责理解意图和生成决策，工具负责获取实时信息，记忆负责保存上下文，规划负责拆解步骤。四者缺一不可。

4.2 主流Agent框架对比与选型

选框架的原则是：能用简单方案解决就不要上复杂框架。我见过有人用LangChain搭了一个Agent，结果发现核心逻辑就是一个if-else加一次API调用。过度工程化是Agent开发中最常见的坑。

对于大多数场景，我的建议是：先用原生API加简单函数调用实现，遇到瓶颈再引入框架。这样你对每个环节都有掌控力，调试也方便。

4.3 从零搭建一个Agent的实操

以"论文助手Agent"为例，功能是：用户给一个研究主题，Agent自动搜索相关论文、总结要点、生成综述。

工具定义：

tools = [ { "name": "search_papers", "description": "根据关键词搜索学术论文，返回标题和摘要", "parameters": { "query": {"type": "string", "description": "搜索关键词"} } }, { "name": "summarize", "description": "对给定文本进行摘要", "parameters": { "text": {"type": "string", "description": "待摘要文本"} } } ]

Agent主循环：

def agent_loop(user_input, max_steps=10): messages = [{"role": "system", "content": SYSTEM_PROMPT}] messages.append({"role": "user", "content": user_input}) for step in range(max_steps): response = llm.chat(messages, tools=tools) if response.tool_calls: for tool_call in response.tool_calls: result = execute_tool(tool_call) messages.append({"role": "tool", "content": result}) else: return response.content return "达到最大步数限制"

关键设计点：

• 最大步数限制：防止Agent陷入死循环。通常10-20步足够。
• 工具描述要清晰：大模型根据描述决定调用哪个工具。描述模糊会导致错误调用。
• 错误处理：工具调用失败时，把错误信息返回给模型，让它决定重试还是换方法。
• 上下文管理：步数多了上下文会超长，需要做摘要或截断。

实测经验：Agent的稳定性比单次对话差很多。单次对话准确率90%的模型，在10步Agent任务中成功率可能只有30%。因为每一步的小错误会累积。解决办法是增加验证步骤，每步执行后让模型确认结果是否合理。

4.4 Agent的并发与性能优化

当Agent从demo走向生产，并发是绕不开的坎。一个Agent请求可能包含多次LLM调用和工具调用，响应时间从几秒到几十秒不等。如果每个请求都同步处理，服务器很快就被打满。

优化思路分三层：

请求层：用异步IO处理并发请求。Python的asyncio配合aiohttp可以轻松支撑几百并发。关键是所有IO操作都要异步化，包括LLM API调用、数据库查询、外部工具调用。

缓存层：很多Agent请求是重复的。比如多个用户问同一个问题，或者Agent在循环中重复调用同一个工具。加一层语义缓存，相似问题直接返回缓存结果，能大幅降低LLM调用次数。

模型层：不是所有步骤都需要大模型。简单的意图分类、参数提取可以用小模型甚至规则引擎。只在关键决策点调用大模型。这样既省成本又提速度。

5. 提示词工程与上下文工程

5.1 提示词工程的核心原则

提示词工程不是"玄学"，有明确的原则可循。我总结为四条：

明确角色：告诉模型"你是一个资深律师"比"帮我分析合同"效果好得多。角色设定会激活模型在该领域的知识。

提供示例：Few-shot比Zero-shot稳定。给2-3个输入输出示例，模型就能模仿格式和风格。示例要覆盖典型情况和边界情况。

分步思考：复杂任务让模型"一步一步思考"。这能显著提升推理准确率。原理是给模型更多计算步骤，相当于让它打草稿。

约束输出：明确指定输出格式。比如"以JSON格式返回，包含name、age、city三个字段"。这样后续程序处理方便。

一个反直觉的发现：提示词不是越长越好。过长的提示词会稀释关键信息，模型可能抓不住重点。我试过把提示词从500字精简到200字，效果反而提升。关键是信息密度，不是长度。

5.2 上下文工程：比提示词更重要的能力

提示词工程关注"怎么说"，上下文工程关注"给模型看什么"。在实际应用中，后者往往更重要。

上下文工程的核心问题是：在有限的上下文窗口内，放哪些信息能最大化模型表现。这涉及信息的检索、排序、压缩、拼接。

以RAG（检索增强生成）为例，流程是：用户提问→检索相关文档→把文档和问题一起给模型→模型生成回答。这里每个环节都有优化空间：

• 检索：用向量检索还是关键词检索？混合检索通常更好。检索多少条？太多会超上下文，太少可能漏关键信息。通常5-10条。
• 排序：检索回来的文档按相关性排序，最相关的放最前面。模型对开头和结尾的信息更敏感。
• 压缩：长文档只保留和问题相关的段落。可以用小模型做抽取式摘要。
• 拼接：文档之间加分隔符，标注来源。格式清晰能帮助模型定位信息。

一个实用技巧：在上下文末尾重复一遍核心问题。模型对最近的内容注意力更强，这样能防止它"忘了"要回答什么。

5.3 提示词与上下文的协同优化

提示词和上下文不是孤立的。好的提示词会指导模型如何利用上下文。比如：

你是一个客服助手。根据以下知识库内容回答用户问题。 如果知识库中没有相关信息，直接说"这个问题我需要转接人工客服"，不要编造。 知识库： {context} 用户问题：{question}

这个提示词做了三件事：设定角色、给出知识库、规定不知道时的行为。三者配合才能产出可靠回答。

优化是一个迭代过程。我的做法是：先写一版提示词，跑100条测试用例，看哪些错了，分析错误原因，针对性修改提示词或调整上下文策略，再跑测试。循环几轮后效果会明显提升。

6. 常见问题与排查技巧实录

6.1 微调与Agent开发中的典型问题

6.2 独家避坑经验

数据标注的坑：标注人员理解不一致会导致数据矛盾。解决办法是先标100条，开会对齐标准，再批量标注。标注指南要具体到每个边界情况怎么处理。

显存溢出的坑：QLoRA微调时，如果序列长度设太长（比如4096），即使4-bit量化也可能OOM。解决办法是先用512长度跑通，再逐步增加。或者用梯度检查点换显存。

Agent工具调用的坑：工具返回结果太长会撑爆上下文。比如搜索返回10篇论文全文。解决办法是工具内部先做摘要，只返回关键信息。

模型选择的坑：不要盲目追求大参数。7B模型微调后在小任务上可能超过70B零样本。关键是匹配任务复杂度和数据量。

评估的坑：自动指标高不代表实际好用。一定要人工看输出。我见过BLEU很高但回答完全不可用的案例。

6.3 性能优化速查

当系统变慢时，按以下顺序排查：

1. LLM调用次数：一个请求调了几次LLM？能合并吗？
2. 上下文长度：是不是塞了太多无关信息？
3. 工具延迟：哪个工具最慢？能缓存吗？
4. 并发瓶颈：是IO密集还是CPU密集？异步了吗？
5. 模型大小：能用小模型吗？能量化吗？

这套排查流程帮我解决过很多线上问题。大多数性能问题不是模型本身慢，而是架构设计不合理。

7. 技术选型的决策逻辑

7.1 从需求倒推技术栈

技术选型没有标准答案，只有适不适合。我的决策框架是：

第一步：明确任务类型。是分类、生成、问答还是Agent？分类任务小模型微调就够；生成任务需要大模型；Agent需要模型+工具+规划。

第二步：评估数据情况。有多少标注数据？数据质量如何？数据少就用提示词工程+Few-shot；数据多就微调。

第三步：确定延迟要求。实时对话要求首字延迟<1秒，可以用小模型或流式输出；离线批处理可以用大模型慢慢跑。

第四步：算成本账。API调用按Token计费，自部署按GPU小时计费。高频调用自部署划算，低频调用API划算。

7.2 不同规模团队的选择建议

个人开发者：优先用API，省去部署运维。需要微调时用QLoRA+消费级显卡。Agent用LangChain快速搭建。

小团队（3-10人）：可以自部署7B-14B模型，用vLLM做推理加速。微调用LoRA。Agent自研核心逻辑，外围用开源框架。

中大团队：自部署70B级别模型，做继续预训练和全量微调。Agent平台化，支持多业务接入。建立数据飞轮，持续迭代。

一个反直觉的建议：不要过早追求自研模型。用API+提示词工程能解决80%的问题。剩下20%再考虑微调。自研模型的门槛比想象中高，数据、算力、人才缺一不可。

7.3 技术演进与个人学习节奏

大模型领域变化极快，今天的最优解明天可能就过时了。但底层原理相对稳定：Transformer架构、注意力机制、梯度下降、强化学习。把底层学扎实，上层工具怎么变都能快速适应。

我的学习节奏是：每周花2小时看新论文和开源项目，保持对前沿的敏感；每月做一个小项目，把新学的东西落地；每季度复盘一次，更新自己的技术栈。

不要焦虑跟不上。这个领域足够大，每个人都能找到自己的位置。有人擅长底层训练，有人擅长应用开发，有人擅长产品设计。找到自己的差异化优势，比盲目追新更重要。

最后分享一个我常用的学习方法：费曼技巧。学完一个概念后，试着用最简单的话讲给不懂的人听。如果讲不清楚，说明自己没真懂。我写这篇综述的过程，也是对自己知识体系的一次梳理。很多之前模糊的地方，在写的过程中变清晰了。输出是最好的输入，这话在大模型学习上同样成立。