Transformer 从机器翻译架构发展为今天多数语言与多模态模型的基础。它的自注意力机制能让序列中的不同位置直接交换信息，也便于并行训练。但进入某个行业后，通用能力并不会自动变成稳定的业务结果。
所谓“垂直深耕”，不是把行业文档全塞进一个模型，更不是先花巨资从头预训练。它是一套逐层增加复杂度的方法：先锁定任务，再整理数据和工具，建立检索与评测，只有确有收益时才修改模型参数。
## 从任务而不是行业名称开始
“做医疗 AI”“做制造业大模型”范围过大，无法定义正确答案。一个可执行任务应包含明确输入、输出、使用者和验收条件，例如从设备维修记录中提取故障部件，或根据最新手册为工程师生成带引用的排查步骤。
同一行业的任务差异很大。分类需要稳定标签，问答需要知识检索，排程需要约束求解，设备控制还依赖实时传感器。Transformer 可能负责理解语言，但不必承担所有计算。
先记录当前流程需要多少时间、错误出现在哪里、哪些步骤必须人工判断。没有这条基线，就无法知道模型带来的是实际改善，还是只生成了更流畅的中间文本。
## Transformer 提供的是表示能力
原始 Transformer 用缩放点积注意力、多头机制和位置表示处理序列，不再依赖循环网络逐词运行。预训练模型由此能学习广泛的语言模式，再通过提示、检索或参数更新适应任务。
注意力并不等于模型自动知道行业事实。它只决定当前输入中的信息怎样相互作用。模型参数里可能包含某些公开知识，却无法保证版本、新鲜度和企业内部定义。
垂直系统因此需要把三种信息分开：通用语言与推理模式放在模型参数中；频繁变化的事实通过检索或工具提供；确定性规则交给普通程序执行。
## 建立领域词典和对象模型
很多失败不是模型太小，而是团队对术语没有统一定义。同一个缩写在不同部门可能含义不同，同一设备也可能有商品名、资产编号和历史别名。
在训练之前，先建立最小对象模型：有哪些实体、关键字段、允许的关系和稳定标识。把同义词、缩写、单位和枚举值纳入数据字典，并把真实输入映射到这些对象。
对象模型不必一开始覆盖全公司，只要支持目标任务。它会同时服务检索过滤、结构化输出、工具参数和评测标签，使模型之外的系统拥有共同语言。
## 先做不改参数的基线
第一版应优先尝试清晰指令、少量示例、结构化输出和确定性校验。若基础模型已经能完成任务，直接微调会增加训练、版本和部署负担。
提示基线要固定模型版本、模板、解码参数和测试集。少样本示例应覆盖典型边界，而不是只展示最简单的成功案例。输出用 JSON Schema 等结构约束，业务程序再检查必填字段、单位和跨字段逻辑。
这一步的意义不只是省钱。它建立了后续所有方法的对照组，让团队知道检索、LoRA 或继续预训练究竟改善了什么。
## 知识变化快时优先检索
RAG 将模型的参数化记忆与可更新的外部资料结合。对产品手册、研究报告、设备记录和内部流程等知识密集任务，检索比把所有事实写入权重更容易更新和引用。
文档入库时保留来源、版本、生效时间、对象 ID 和访问范围。分块应尊重章节、表单或记录边界，不要机械按固定字符切断关键关系。查询阶段可结合关键词与向量召回，再用重排器筛选。
评测要把召回和生成分开。先看正确证据是否进入候选，再看模型是否忠实使用。若源片段根本没有找到，继续调生成提示通常解决不了问题。
## 长上下文不能替代知识工程
上下文窗口变大后，可以一次放入更多资料，但容量并不保证利用率。无关页面会稀释关键证据，相似版本还可能相互冲突，成本和延迟也随输入增加。
更稳妥的做法是先根据对象、时间和任务过滤，再检索少量高相关片段。对于必须通读的长合同或技术手册，可以先生成章节级索引，按问题逐层定位，而不是每次从第一页送到最后一页。
需要跨文档综合时，记录每个结论对应的来源。模型可以组织语言，来源关系由系统保存，方便用户复核和数据更新后重新运行。
## 工具调用负责实时状态与动作
库存、价格、设备读数和订单状态会变化，不适合靠模型记忆。应用把查询与操作封装成明确工具，模型负责选择工具和准备参数，实际请求由代码执行。
工具返回结构化结果，包含状态、时间和稳定 ID。读取动作可以自动进行，写入动作先生成预览并等待确认。数值计算、排程和约束检查也尽量交给确定性组件。
这样构建的垂直能力并不全在 Transformer 里，而是分布在模型、检索、工具和业务规则之间。系统更容易测量，也更容易在模型换代时迁移。
## 何时使用 LoRA 等参数高效微调
当任务长期稳定，提示已经很长，且错误集中在固定格式、术语或操作风格时，可以尝试微调。LoRA 冻结原有权重，只训练插入的低秩矩阵，显著减少可训练参数和显存需求。
微调数据应来自经过验证的真实任务，包含正常、边界、拒答和纠错样本。训练集与测试集按时间、客户或来源切分，避免相似模板泄漏。先做小规模实验，与提示基线比较，而不是一开始就训练所有数据。
微调适合改变行为，不适合频繁更新事实。若每周变化的产品信息被写入权重，更新和追溯都会变得困难。
## 何时考虑领域继续预训练
“Don't Stop Pretraining”研究表明，在领域文本上继续预训练可以改善下游任务。但它比提示、RAG 和 LoRA 更昂贵，也更难判断数据质量。
只有当模型持续无法处理领域语言结构，且拥有规模可观、质量稳定的无标注语料时，才值得做领域自适应预训练。典型信号包括分词效率差、专业表达理解弱，并且这些问题横跨多个下游任务。
实验时保留通用评测，观察模型是否过度偏向领域语言而损失基础能力。训练数据需要去重、过滤模板噪声和保存版本，并与后续指令微调分开记录。
## 评测集决定深耕方向
垂直评测不能只使用公开问答题。它应从实际流程抽样，包含常见输入、长尾、信息缺失、冲突来源、超长文档、工具失败和需要人工确认的情形。
指标按照任务拆分。抽取看字段准确率和漏项，检索看召回与排序，生成看证据一致性，工具流程看端到端完成率和副作用是否正确。再加上延迟、成本、人工修改率和失败恢复时间。
每次改提示、索引、模型或工具都运行同一套回归测试。平均分之外，还要查看最差子类，因为垂直场景的少数关键错误可能比大量普通成功更重要。
## 数据闭环不是自动收集一切
上线后应记录输入类型、检索结果、工具状态、模型输出和人工修改，但不是把所有对话无差别加入训练。先对失败分类：知识没找到、术语误解、格式错误、工具参数错误，还是流程本身不清楚。
不同失败有不同修复方式。知识问题更新索引，格式问题调整 Schema 或微调，工具错误修改接口，流程歧义需要产品重新设计。只有确实属于模型行为的样本，才进入训练候选。
新数据加入前要去重、验证和保留来源。否则闭环会把偶然修改、错误答案和过时规则不断放大。
## 部署优化从真实负载出发
模型选型不仅看参数和榜单，还要在目标硬件上测首词延迟、持续吞吐、上下文长度、KV 缓存和峰值显存。批处理、量化、缓存和模型路由都可能比换一个更小模型更有效。
高频简单请求可以走轻量模型，复杂或低置信度请求再升级。检索与工具也要设置超时、重试和降级。模型不可用时，系统至少能返回原始资料或保存任务，而不是生成猜测。
每次发布绑定代码、提示、模型、索引和数据版本。出现退化时能回滚整个组合，而不是只退回某一个权重文件。
## 一条九十天落地路线
前 30 天选择一个窄任务，整理对象模型和五十到两百个真实评测样本，建立提示与结构化输出基线。第 31 到 60 天接入带版本的检索和必要工具，分别评测召回、生成与端到端流程。
第 61 到 90 天分析剩余错误。如果主要问题是稳定行为，再尝试 LoRA；如果多类任务都受领域语言限制，再设计小规模继续预训练实验。同时在真实硬件和真实流量下测成本、延迟与人工修改。
每个阶段都设置退出条件。若简单方案已达到业务目标，就不为“拥有自己的垂直模型”继续增加复杂度。
## 深耕的结果是一套系统能力
Transformer 是强大的通用表示器，却不是行业流程本身。垂直优势来自对任务的精确定义、可维护的数据、可靠检索、确定性工具、持续评测和一线反馈。
模型参数只是其中一层。把每类问题放到最适合的组件中，并用真实任务不断验证，才是比堆数据、追参数和换模型更持久的垂直方法论。
## 参考资料