去年公司官网被一波分布式爬虫搞崩了服务器带宽直接打满商品数据被爬了个底朝天。运维紧急上了传统WAF的规则引擎IP限速、UA黑名单、Cookie校验一套下来脚本小子是拦住了但对付用代理池无头浏览器行为模拟的高级爬虫根本没用——人家IP换得比你封得快UA和行为模拟得和真人一模一样规则完全拦不住。更烦的是误报率高得离谱把很多正常访问的客户都封了运营部天天找我们投诉头都大了。被逼无奈我带着团队折腾了两个月基于Transformer搭了一套爬虫异常流量检测模型上线之后效果直接拉满高级爬虫拦截率从原来的58%升到94%误报率从30%降到2%服务器再也没被爬虫打崩过。今天把整个项目从原理、数据、模型、训练到部署的全流程分享出来全是工业界能直接落地的干货踩过的坑也都给大家列得明明白白。一、为什么传统爬虫检测方案搞不定了先给大家掰扯清楚我们之前用的传统方案到底输在哪。第一种是规则引擎这是最常用的比如限制单IP每分钟请求超过60次就封拉黑带HeadlessChrome的UA校验Cookie和Session。这套东西对付刚学爬虫的脚本小子确实有用但对付现在的高级爬虫就是个摆设人家用代理池每个IP只发5次请求你根本没法限速用Playwright/Puppeteer改了所有自动化特征UA和正常浏览器一模一样甚至能模拟鼠标移动、页面停留、随机点击你靠规则根本分不出来。而且规则要不停更新爬虫换个玩法你就得连夜改规则根本跟不上。第二种是传统机器学习比如随机森林、SVM靠人工提取特征比如访问频率、页面停留时间、请求路径的熵值、请求间隔的方差。这套比规则引擎强点但最大的问题是太依赖人工特征工程全靠工程师的经验你想不到的特征模型就学不到。而且泛化能力极差爬虫换个行为模式之前的特征就没用了模型效果直接跳水。第三种是LSTM这类循环神经网络能处理时序的访问序列比传统机器学习强但LSTM处理长序列的时候容易梯度消失而且并行能力差训练慢推理延迟高生产环境高并发的时候根本扛不住。这时候我们就盯上了Transformer。大家都知道Transformer在NLP里封神但很少有人知道它在时序行为序列的建模上效果比LSTM好太多。用户的访问行为本身就是一个时序序列每一条HTTP请求就是一个tokenTransformer的自注意力机制能自动捕捉序列里的长距离依赖比如正常用户的访问路径是「首页→搜索→商品详情→加购→下单」有完整的上下文逻辑而爬虫的访问是「商品详情页→商品详情页→商品详情页」循环重复没有逻辑。哪怕是模拟得再好的爬虫行为序列的上下文和真人还是有本质区别Transformer能精准抓到这些差异这就是它的核心优势。二、数据是模型的上限采集、标注与预处理做工业级的模型永远是数据第一模型第二。我见过太多人拿公开数据集练手模型准确率99%一上线就拉胯就是因为数据和真实生产环境差太远。先说说我们的数据源公司官网连续3个月的Nginx访问日志加上WAF拦截的爬虫日志、蜜罐捕获的恶意请求一共2000万条原始日志。第一步是标注这是最花时间也最关键的一步标注错了模型再牛也没用。我们的标注规则是正样本爬虫WAF明确拦截的恶意IP、蜜罐捕获的请求、已知的爬虫IP段、循环访问敏感接口的IP最后人工抽样校验保证标注准确率95%以上。负样本正常用户有完整登录、浏览、加购、下单行为的用户排除掉有异常行为的同样人工抽样校验。这里踩了第一个大坑一开始我图省事按请求标注把同一个用户的部分请求标成正常部分标成爬虫结果模型训练出来完全没用。后来改成按用户用Session ID设备指纹唯一标识标注同一个用户的所有请求要么全是正常要么全是爬虫才解决了这个问题。第二步是日志解析与序列构建。爬虫检测看的不是单条请求而是用户的整个行为序列所以我们要把原始日志转换成按用户聚合的、按时间排序的请求序列。先给大家看我们的Nginx日志格式这是我们提前定制好的包含了所有需要的字段log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_cookie $request_time $upstream_response_time;我们用Python写了个解析脚本把每条日志解析成结构化数据提取出用户标识、请求时间、请求方法、请求路径、状态码、UA、Referer、请求大小、响应时间这些核心字段然后按用户分组按请求时间升序排序生成每个用户的访问序列。这里有个关键参数序列长度。我们试了10、20、30、50这几个值最后定了30。太短了捕捉不到完整的行为模式太长了大部分用户的序列不够需要大量padding反而引入噪声训练也慢。每个用户的序列超过30条的截断最近的30条不足30条的用0做padding。第三步是特征工程我们把特征分成两类离散特征和连续特征分别处理离散特征请求方法、请求路径、HTTP状态码、设备类型、Referer类型。这些特征我们先做词表映射低频的词统一归为然后做Embedding统一映射到16维的向量空间。连续特征请求间隔时间和上一条请求的时间差、请求体大小、响应时间、页面停留时间、分钟级请求频率。这些特征我们先做异常值截断然后用Min-Max归一化到0-1区间避免不同量级的特征影响模型效果。这里又踩了个坑一开始我没做连续特征的归一化请求间隔时间有的是几毫秒有的是十几分钟量级差了几十万倍模型训练的时候直接梯度爆炸损失函数根本不收敛后来做了归一化一下就稳了。三、模型架构设计针对爬虫检测优化的Transformer很多人一听到Transformer就觉得是BERT那种几十层的大模型工业界根本没法部署。其实不是我们针对爬虫检测的场景做了大量的简化和优化最终的模型只有2层Encoder参数量不到500万单条推理延迟不到10ms完全能满足生产环境的高并发要求。先给大家讲清楚整个模型的核心逻辑我们把用户的30条请求序列当成一个30个token的句子每个token对应一条请求的特征向量通过Transformer Encoder捕捉序列里的上下文依赖最后通过分类头输出「正常/爬虫」的二分类结果。整个模型分为4个核心模块我一个个给大家讲同时附上PyTorch的实现代码大家可以直接参考。第一个模块是输入嵌入层。我们要把离散特征和连续特征融合成每个token的特征向量。离散特征每个离散特征先经过独立的Embedding层映射到16维向量然后把所有离散特征的Embedding拼接起来。连续特征先经过LayerNorm做标准化然后和离散特征的Embedding拼接得到每个token的初始特征向量维度固定为128维。位置编码Transformer本身是无序的而我们的请求序列是严格按时间排序的所以必须加入位置编码。这里我们没用原生Transformer的正弦位置编码而是用了可学习的位置编码在我们的场景里效果比固定的正弦编码好3个百分点。第二个模块是Transformer Encoder层。我们只用了2层Encoder足够捕捉行为序列的特征再多就容易过拟合。每个Encoder里包含两个子层多头自注意力层头数设为8每个头的维度是16刚好和我们的token维度匹配。自注意力机制能让模型自动学习序列里的哪些请求之间有强关联比如正常用户的搜索请求和后续的商品详情请求就是强关联的而爬虫的循环请求之间没有关联。前馈网络FFN两层全连接中间用ReLU激活加了Dropout防止过拟合。每个子层都加了残差连接和LayerNorm和原生Transformer的结构一致保证梯度能正常传播。第三个模块是序列聚合层。Encoder输出的是30个token的特征向量我们要把它聚合成一个固定维度的向量用来做分类。这里我们参考了BERT的做法在序列的最前面加入了一个专属的CLS token这个token的输出就是整个序列的全局特征表示比全局平均池化的效果更好。第四个模块是分类头。我们把CLS token的128维特征向量输入到两层全连接层第一层128维→64维ReLU激活Dropout0.3第二层64维→1维Sigmoid激活输出0-1之间的概率值大于0.5判定为爬虫小于0.5判定为正常用户。下面是完整的模型实现代码注释都给大家写清楚了importtorchimporttorch.nnasnnimporttorch.nn.functionalasFclassTransformerCrawlerDetector(nn.Module):def__init__(self,vocab_sizes:dict,embed_dim:int16,seq_len:int30,d_model:int128,nhead:int8,num_layers:int2,dropout:float0.3,num_continuous_features:int5):super().__init__()self.d_modeld_model self.seq_lenseq_len# 离散特征的Embedding层self.embedding_layersnn.ModuleDict()forfeat_name,vocab_sizeinvocab_sizes.items():self.embedding_layers[feat_name]nn.Embedding(vocab_size,embed_dim)# 计算输入总维度映射到d_modeltotal_embed_dimlen(vocab_sizes)*embed_dimnum_continuous_features self.input_projnn.Linear(total_embed_dim,d_model)# 可学习的位置编码 CLS tokenself.pos_embeddingnn.Embedding(seq_len1,d_model)self.cls_tokennn.Parameter(torch.randn(1,1,d_model))# Transformer Encoder核心层encoder_layernn.TransformerEncoderLayer(d_modeld_model,nheadnhead,dim_feedforwardd_model*4,dropoutdropout,batch_firstTrue)self.transformer_encodernn.TransformerEncoder(encoder_layer,num_layersnum_layers)# 分类头self.classifiernn.Sequential(nn.Linear(d_model,d_model//2),nn.ReLU(),nn.Dropout(dropout),nn.Linear(d_model//2,1),nn.Sigmoid())self.dropoutnn.Dropout(dropout)self.normnn.LayerNorm(num_continuous_features)defforward(self,discrete_features:dict,continuous_features:torch.Tensor):batch_sizecontinuous_features.shape[0]# 离散特征Embedding与拼接embed_list[]forfeat_name,embed_layerinself.embedding_layers.items():featdiscrete_features[feat_name]embedembed_layer(feat)embed_list.append(embed)discrete_embedtorch.cat(embed_list,dim-1)# 连续特征标准化continuous_normself.norm(continuous_features)# 特征融合与维度映射concat_feattorch.cat([discrete_embed,continuous_norm],dim-1)token_embself.input_proj(concat_feat)# 加入CLS tokencls_tokensself.cls_token.repeat(batch_size,1,1)token_embtorch.cat([cls_tokens,token_emb],dim1)# 加入位置编码pos_idstorch.arange(token_emb.shape[1],devicetoken_emb.device).unsqueeze(0)pos_embself.pos_embedding(pos_ids)xself.dropout(token_embpos_emb)# Transformer编码encoder_outself.transformer_encoder(x)# 取CLS特征做分类cls_outencoder_out[:,0,:]outself.classifier(cls_out)returnout四、模型训练与效果评估从实验室到生产的关键一步模型搭好了训练的细节直接决定了上线后的效果这里的坑一点不比模型设计少。首先是数据集划分这里有个90%的人都会踩的大坑千万不能按请求划分数据集很多人把所有请求打乱70%训练30%测试结果测试准确率99%一上线就拉胯。为什么因为同一个用户的请求一部分在训练集一部分在测试集模型直接记住了这个用户的特征测试集的准确率完全是虚高的。我们的做法是按用户ID划分数据集同一个用户的所有请求只能出现在训练集、验证集、测试集其中一个里面。最终的划分比例是70%训练15%验证15%测试完全保证了数据的隔离测试集的效果就是上线后的真实效果。然后是样本不均衡的问题。我们的数据集里爬虫样本只占10%正常用户占90%样本极度不均衡。如果直接用普通的BCELoss模型会直接把所有样本都预测成正常用户准确率90%但完全没有任何拦截能力。我们的解决方案是用Focal Loss它能自动降低易分样本正常用户的权重提高难分样本高级爬虫的权重完美解决样本不均衡的问题。同时我们对训练集里的爬虫样本做了过采样进一步平衡样本分布。接下来是训练的超参数设置都是我们调了几十轮得到的最优值优化器AdamW权重衰减1e-4学习率初始1e-4每5个epoch衰减一半batch_size64训练epoch20加入早停机制验证集AUC连续3个epoch不上涨就停止训练防止过拟合设备单张RTX 3090训练一轮只需要15分钟非常快训练完成后我们做了全面的效果评估和传统方案做了横向对比结果如下方案类型准确率精准率召回率F1值AUC误报率(FPR)传统规则引擎82%65%58%0.610.7530%随机森林人工特征91%83%78%0.800.8912%LSTM时序模型95%89%87%0.880.945%我们的Transformer模型98%96%94%0.950.992%这个结果超出了我们的预期Transformer模型的爬虫召回率拦截率达到了94%比传统规则引擎高了36个百分点而误报率只有2%比原来降了90%多。上线之后运营再也没找过我们投诉误封的问题服务器的带宽占用也降了60%效果立竿见影。这里还要提一句工业界的爬虫检测误报率比召回率重要100倍。你漏了10个爬虫最多就是被爬点数据但你误封了1个付费客户损失的就是真金白银。所以我们上线的时候把分类阈值从0.5调到了0.7进一步降低误报率哪怕牺牲一点召回率也绝对不能误封正常用户。五、生产环境部署让模型真正跑起来模型训练得再好不能落地部署就是个玩具。我们的部署方案完全贴合公司现有的技术栈做到了低延迟、高可用、易扩展。先给大家看整个实时检测的数据流前端Nginx的访问日志实时通过Filebeat同步到Kafka集群。Flink消费Kafka里的日志数据按用户Session做窗口聚合解析生成每个用户的30条请求序列提取对应的特征。Flink调用我们的模型推理服务对每个用户的序列做推理输出爬虫概率。对于概率超过阈值的用户直接把IP和设备指纹推给WAF实时拉黑或者弹出人机验证完成闭环。然后是模型推理服务的部署这里我们做了大量的优化保证高并发下的低延迟模型格式转换把训练好的PyTorch模型转换成ONNX格式去掉训练相关的算子减小模型体积。推理加速用ONNX Runtime做推理引擎开启CPU优化单条序列的推理延迟从原来的100ms降到了8ms以内完全能满足每秒几千次的请求量。服务部署用FastAPI搭了一个轻量的HTTP推理服务用Gunicorn多进程部署配合Nginx做负载均衡保证服务的高可用。模型迭代我们每周会用新的日志数据对模型做一次微调保证模型能跟上爬虫的新玩法效果不会衰减。上线半年来这套系统稳定运行拦截了超过500万次恶意爬虫请求没有出现过一次服务宕机误报率一直稳定在2%以内完全达到了我们的设计目标。六、踩坑总结与优化方向整个项目做下来踩了无数的坑很多都是网上的教程不会告诉你的这里给大家总结一下避免大家再走弯路数据泄露是头号杀手一定要按用户划分数据集绝对不能按请求划分不然模型的效果全是假的。标注质量决定模型上限花再多时间在标注上都不为过标注错了再牛的模型也救不回来。样本不均衡必须处理工业界的异常检测场景几乎都是样本不均衡的Focal Loss是你的好朋友。模型不是越深越好2层Encoder就足够了6层、12层的模型不仅训练慢还很容易过拟合泛化能力反而更差。误报率永远是第一位的工业界落地一定要优先保证低误报率再去追求高召回率不然只会给自己找麻烦。当然这套系统还有很多可以优化的地方我们也在持续迭代加入用户的前端行为特征比如鼠标移动轨迹、键盘输入行为、页面点击事件这些特征能更精准地区分真人与无头浏览器对付高级爬虫的效果会更好。用对比学习解决标注不足的问题标注数据永远是稀缺的我们正在尝试用对比学习用大量的无标注数据预训练模型再用少量标注数据微调进一步提升模型的泛化能力。轻量化模型优化尝试用DistilBERT、MobileBERT这类轻量化模型进一步降低推理延迟适配边缘节点的部署需求。加入图神经网络把用户的访问路径构建成图结构用GNN捕捉更复杂的行为模式提升对新型爬虫的检测能力。从最开始被爬虫搞崩服务器的焦头烂额到现在这套稳定运行的检测系统整个过程让我深刻体会到工业界的AI项目从来不是拼模型有多复杂而是拼对业务场景的理解拼数据的质量拼落地的细节。只有真正贴合业务需求的模型才是有价值的模型。