1. 项目缘起与核心诉求最近在做一个内容安全相关的项目需要大量的、高质量的图片数据来训练一个鉴黄模型。这事儿听起来挺高大上但实际操作起来第一步“找数据”就让人头大。公开的数据集要么太旧要么类别不全要么就是数据量太小根本喂不饱现在这些“胃口”巨大的深度学习模型。正当我发愁的时候一个朋友半开玩笑地说“网上那么多‘学习资料’网站图片海了去了你去爬点不就行了”这句话点醒了我。确实互联网上存在大量用户生成内容的平台其中不乏一些以图片分享为主的站点它们的内容更新快、种类多、数量庞大如果能合规、合法地获取并用于模型训练无疑是一个极佳的数据源。这里的“合规、合法”是绝对的前提我们讨论的始终是那些公开的、允许爬虫访问的、且内容本身不涉及违法违规的图片资源用于构建识别和过滤不良内容的正向工具。我们的目标是打造一个更干净的互联网环境。所以这个项目的核心诉求就非常明确了我需要从一个特定的、图片资源丰富的公开网站我们姑且称之为“资源站A”上自动化地、高效地、稳定地爬取海量图片数据并经过严格的清洗和标注最终形成一个可用于训练鉴黄模型的高质量数据集。整个过程技术上的挑战在于应对网站的反爬机制、设计高效的爬取架构以及后续繁琐但至关重要的数据清洗工作。2. 目标网站分析与爬虫策略设计2.1 目标站点特征剖析在动手写代码之前花时间分析目标网站的结构和行为模式是至关重要的这能避免后续很多无谓的试错。我选择的“资源站A”是一个典型的动态网页SPA与静态内容混合的站点。首先我通过浏览器的开发者工具F12进行了网络请求分析。我发现网站的主体页面是通过JavaScript动态渲染的直接请求HTML源码只能得到一个几乎空的框架真正的图片列表数据是通过XHRAjax请求从后端API获取的JSON数据。这是一个关键发现意味着传统的基于HTML解析的爬虫如BeautifulSoup直接抓页面在这里会失效我们必须模拟浏览器行为或者直接找到并调用其数据接口。其次我观察了其图片的加载方式。缩略图列表页的图片链接是直接嵌入在JSON数据中的而点击进入大图详情页后图片地址有时会带有时间戳或Token参数这可能是一种简单的防盗链或缓存机制。图片文件本身通常存储在独立的CDN域名下。最后我测试了网站的反爬措施。短时间内连续访问列表页会偶尔遇到请求返回空数据或状态码429请求过多的情况。网站还检查了请求头中的User-Agent、Referer等字段。虽然没有特别复杂的验证码但基本的频率限制和请求头校验是存在的。2.2 爬虫架构与技术选型基于以上分析我设计了如下爬虫架构请求层使用requests库作为基础。但对于需要执行JavaScript的页面如果某些关键数据必须通过JS计算生成则备用Selenium或Playwright。鉴于我们已找到核心的JSON API优先使用requests模拟API调用效率更高。解析与调度层由于数据主要来自JSON API使用Python内置的json库进行解析即可。需要设计一个任务调度器管理待爬取的页面队列分页URL或API参数并控制请求频率。数据存储层图片文件本身使用urllib或requests下载后直接以二进制形式存储到本地文件夹或对象存储如AWS S3、阿里云OSS。图片的元数据如源URL、爬取时间、可能的标签、所属页面等则存储到SQLite或MySQL数据库中便于后续管理和清洗。反爬对抗与稳健性User-Agent池准备一批常见的浏览器UA字符串随机切换。IP代理池这是应对频率限制的核心。我选择使用几个按量付费的云服务商提供的代理IP服务构建一个简单的代理池在请求失败或遇到429状态码时自动切换IP。请求间隔在请求之间加入随机延时例如time.sleep(random.uniform(1, 3))模拟人类操作。错误重试与断点续爬任何网络请求都可能失败。必须为每个请求设置重试机制如retrying库。同时将爬取进度如已爬取的页码、最后成功的图片ID持久化到文件或数据库确保程序意外中断后可以从断点恢复而不是从头开始。注意法律与道德边界在实施爬取前务必仔细阅读目标网站的robots.txt文件尊重其中定义的爬虫规则。我们的爬取行为应控制频率避免对目标网站服务器造成显著压力。所有数据仅用于公开声明的、正面的技术研究目的内容安全模型训练绝不用于任何商业侵权或非法传播。这是技术人的基本操守。3. 核心爬取流程与代码实现详解3.1 逆向工程定位核心数据接口这是最具技巧性的一步。打开浏览器开发者工具的“网络”(Network)选项卡筛选XHR/Fetch请求然后浏览网站的几个列表页观察哪些请求的响应里包含了我们需要的图片列表信息。很快我发现了形如https://api.resource-site-a.com/v1/list?page2limit30的请求。查看其响应正是一个结构清晰的JSON{ code: 0, data: { items: [ { id: 123456, title: 某图片标题, previewUrl: https://cdn.example.com/thumbs/abc.jpg, detailUrl: https://www.resource-site-a.com/item/123456, width: 800, height: 600, tags: [tag1, tag2] }, // ... 更多图片项 ], hasNext: true, totalPages: 150 } }完美previewUrl是缩略图通常质量较低。我们需要的是原图。继续点击某个图片进入详情页再次观察网络请求。可能会发现另一个API如https://api.resource-site-a.com/v1/item/123456其响应中包含了更高清的图片URLoriginalUrl。至此爬取逻辑清晰了循环构造列表页API请求 - 解析JSON获取一批图片的ID和基本信息 - 对于每个图片ID再请求详情页API获取原图URL - 最后下载原图。3.2 爬虫核心代码模块拆解下面我分模块展示核心代码逻辑1. 配置与请求会话管理import requests import time import random from retrying import retry import json import sqlite3 from urllib.parse import urljoin class ResourceSiteSpider: def __init__(self): self.base_api_url https://api.resource-site-a.com/v1 self.headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.resource-site-a.com/, Accept: application/json, } self.session requests.Session() self.session.headers.update(self.headers) # 代理池示例实际需要从服务获取 self.proxy_list [ http://user:passproxy1:port, http://user:passproxy2:port, ] self.current_proxy_index 0 # 数据库初始化 self.init_database() def init_database(self): self.conn sqlite3.connect(image_data.db) c self.conn.cursor() c.execute(CREATE TABLE IF NOT EXISTS images (id TEXT PRIMARY KEY, title TEXT, preview_url TEXT, original_url TEXT, local_path TEXT, tags TEXT, page INTEGER, crawled_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)) self.conn.commit()2. 带代理和重试的请求函数这是爬虫稳健运行的核心。retry(stop_max_attempt_number3, wait_fixed2000) def make_request(self, url, paramsNone, use_proxyTrue): 发起请求失败自动重试并切换代理 proxies None if use_proxy and self.proxy_list: proxy self.proxy_list[self.current_proxy_index] proxies {http: proxy, https: proxy} try: resp self.session.get(url, paramsparams, proxiesproxies, timeout10) resp.raise_for_status() # 检查HTTP状态码非200则抛出异常 # 如果返回的是JSON检查业务码 if application/json in resp.headers.get(Content-Type, ): data resp.json() if data.get(code) ! 0: # 假设0表示成功 raise Exception(fAPI returned error code: {data.get(code)}) return data return resp.content except (requests.exceptions.RequestException, Exception) as e: print(f请求失败: {url}, 错误: {e}) # 切换代理 if use_proxy and self.proxy_list: self.current_proxy_index (self.current_proxy_index 1) % len(self.proxy_list) print(f切换代理至: {self.proxy_list[self.current_proxy_index]}) # 重试前等待 time.sleep(random.uniform(5, 10)) raise # 触发retry的重试机制3. 列表页爬取与详情页解析def crawl_list_page(self, page): 爬取指定页码的列表 list_url f{self.base_api_url}/list params {page: page, limit: 50} print(f正在爬取列表页第 {page} 页...) data self.make_request(list_url, paramsparams) if not data or data not in data or items not in data[data]: print(f第 {page} 页无数据或响应格式异常) return [] items data[data][items] image_ids [] for item in items: img_id item.get(id) if not img_id: continue # 先存入数据库部分信息 c self.conn.cursor() c.execute(INSERT OR IGNORE INTO images (id, title, preview_url, tags, page) VALUES (?, ?, ?, ?, ?), (img_id, item.get(title), item.get(previewUrl), json.dumps(item.get(tags, [])), page)) self.conn.commit() image_ids.append(img_id) print(f 发现图片 ID: {img_id}) # 随机延时避免请求过快 time.sleep(random.uniform(1, 3)) return image_ids def fetch_image_detail(self, image_id): 获取单张图片的详情与原图URL detail_url f{self.base_api_url}/item/{image_id} data self.make_request(detail_url) if not data or data not in data: print(f获取详情失败: {image_id}) return None detail data[data] original_url detail.get(originalUrl) or detail.get(highResUrl) # 不同网站字段名可能不同 if not original_url: # 如果API没给可能需要从详情页HTML里解析这里就需要用Selenium了 print(f图片 {image_id} 未找到原图URL) return None # 更新数据库中的原图URL c self.conn.cursor() c.execute(UPDATE images SET original_url? WHERE id?, (original_url, image_id)) self.conn.commit() return original_url4. 图片下载与存储def download_image(self, image_id, original_url, save_dir./downloaded_images): 下载图片到本地 import os os.makedirs(save_dir, exist_okTrue) # 根据URL生成文件名避免重复 file_extension original_url.split(.)[-1].split(?)[0] # 处理带参数的URL if file_extension.lower() not in [jpg, jpeg, png, gif, webp]: file_extension jpg # 默认 filename f{image_id}.{file_extension} filepath os.path.join(save_dir, filename) # 如果文件已存在跳过 if os.path.exists(filepath): print(f图片 {image_id} 已存在跳过下载) return filepath try: image_data self.make_request(original_url, use_proxyFalse) # 下载图片可能不需要代理或需不同代理策略 with open(filepath, wb) as f: f.write(image_data) print(f图片下载成功: {image_id} - {filepath}) # 更新数据库中的本地路径 c self.conn.cursor() c.execute(UPDATE images SET local_path? WHERE id?, (filepath, image_id)) self.conn.commit() return filepath except Exception as e: print(f下载图片失败 {image_id}: {e}) return None # 下载后休息一下 time.sleep(random.uniform(0.5, 1.5))5. 主控调度循环def run(self, start_page1, end_page10): 主运行函数 for page in range(start_page, end_page 1): image_ids self.crawl_list_page(page) print(f第 {page} 页共获取到 {len(image_ids)} 个图片ID) for idx, img_id in enumerate(image_ids): print(f 处理第 {idx1}/{len(image_ids)} 张: {img_id}) original_url self.fetch_image_detail(img_id) if original_url: self.download_image(img_id, original_url) # 每处理完一张详情稍作休息 time.sleep(random.uniform(0.3, 0.8)) # 每爬完一页休息更长时间 time.sleep(random.uniform(3, 7)) self.conn.close() print(爬取任务完成) if __name__ __main__: spider ResourceSiteSpider() spider.run(start_page1, end_page5) # 从第1页爬到第5页3.3 实操心得与关键参数调优频率控制是生命线time.sleep的随机区间设置至关重要。列表页之间间隔可以稍长3-7秒详情页之间稍短0.3-0.8秒下载图片后再短0.5-1.5秒。这个节奏需要根据目标网站的实际承受能力和反爬策略动态调整。一开始可以设得保守一些观察日志如果没有被封再尝试逐步缩短间隔找到一个效率与稳定性的平衡点。代理IP的质量与策略免费的代理IP大多不稳定、速度慢。对于这种需要长时间、大规模爬取的项目建议使用付费的代理IP服务最好是那些提供“住宅IP”或“动态IP”的服务被封禁的风险更低。在代码中代理失败后的切换逻辑和重试逻辑要结合好。数据库的作用为什么一定要用数据库如SQLite记录元数据而不仅仅是把图片下载到文件夹原因有三一是便于去重根据id或original_url可以防止重复下载二是记录了图片的来源页码、标签和状态是否已下载、本地路径后续数据清洗和标注时这些信息是宝贵的上下文三是支持断点续爬程序可以从上次中断的页码或最后一个成功的图片ID继续而不是重头开始。异常处理要细致网络请求可能因为超时、连接重置、代理失效、对方服务器返回5xx错误等多种原因失败。retry装饰器配合自定义的make_request方法能够应对大多数临时性故障。但对于永久性错误如IP被永久封禁、图片URL失效则需要记录到单独的日志或错误表中避免循环重试。4. 从原始数据到训练数据集清洗与标注流水线爬取到的原始图片只是原材料距离能用于训练模型的数据集还有很长的路要走。这个过程甚至比爬虫本身更耗时、更需要耐心。4.1 自动化初步清洗首先我们需要对下载的图片进行一轮自动化清洗格式统一与损坏检测使用PIL(Python Imaging Library) 或OpenCV尝试打开每一张图片。无法打开的文件损坏、格式怪异的直接剔除。同时可以将所有图片统一转换为RGB模式的JPG或PNG格式减少后续处理的复杂度。分辨率过滤鉴黄模型通常需要一定清晰度的图片。可以设置一个最低分辨率阈值如 宽度300px 且 高度300px过滤掉尺寸过小的图标或缩略图。去重基于图片内容的去重。计算每张图片的感知哈希pHash或均值哈希aHash将哈希值过于接近的图片视为重复或高度相似只保留其中质量最高如分辨率最大、无压缩痕迹的一张。imagehash库可以很方便地实现这一点。简单内容过滤可选可以使用一个轻量级的预训练模型如MobileNet或规则过滤掉明显与目标无关的图片例如纯色背景、大量文字可能是广告、图标等。这一步要谨慎阈值设得宽松一些避免误伤。4.2 人工标注流程与平台搭建自动化清洗后剩下的图片需要人工进行标注这是构建高质量数据集最关键、最昂贵的一环。我们需要的标签至少包括“正常”SFW和“敏感”NSFW。更细致的标注还可以包括敏感内容的子类别。方案选择小型/起步项目可以使用开源的标注工具如LabelImg更适合目标检测、LabelStudio。自己搭建一个简单的Web界面让标注员在线查看图片并打标签数据直接存入数据库。追求效率与协作我强烈推荐使用现成的数据标注平台服务如国内的Scale AI、Appen或者一些云厂商提供的标注服务。它们提供了任务分发、质量控制、多人协作、进度管理等一系列功能虽然有一定成本但能极大提升标注效率和一致性。标注指南制定在开始标注前必须制定清晰、无歧义的《标注指南》。例如“敏感”图片的定义明确包含哪些具体内容需符合相关法律法规和公序良俗的定义。边界情况处理例如艺术绘画与色情图片的界限医疗教材图片与不良内容的界限。需要提供示例图片进行说明。质量控制引入多人交叉标注和仲裁机制。同一张图片由2-3人独立标注如果结果不一致则由更资深的审核员进行仲裁。计算标注者间的一致性如Cohen‘s Kappa系数以确保标注质量。4.3 数据集的划分与整理标注完成后我们就有了一个带标签的数据集。接下来划分训练集、验证集、测试集通常按70%15%15%或类似比例随机划分。关键点必须确保同一ID或高度相似的图片不会同时出现在训练集和测试集中否则会导致模型评估结果虚高。可以根据图片的源页面或聚类结果来确保划分的独立性。数据增强对于“敏感”类图片通常数量远少于“正常”类为了缓解类别不平衡可以在训练时使用数据增强技术如随机水平翻转、小幅度的旋转、裁剪、颜色抖动等来人工增加其多样性。注意增强操作必须合理不能改变图片的本质类别例如把一张正常图片增强后变成了看起来敏感的样子。格式整理将最终的数据集整理成模型框架所需的格式如TensorFlow的TFRecord、PyTorch的Dataset类定义文件、或简单的“文件路径标签”的CSV列表。5. 模型训练选型与工程化思考有了高质量的数据集我们就可以着手训练鉴黄模型了。这不是本文的重点但可以简要分享我的选型思路和工程化考虑。5.1 模型架构选择目前图像分类任务的主流是卷积神经网络CNN。对于鉴黄这种二分类任务并不需要最新最复杂的模型。轻量级/快速验证MobileNetV2、EfficientNet-B0。它们在速度和精度上有很好的平衡适合需要快速响应或部署在资源受限环境如移动端、边缘设备的场景。追求高精度ResNet-50、EfficientNet-B3/B4。如果计算资源充足且对准确率要求极高可以选择这些更深、更强大的模型。通常在足够大的数据集上这些大模型的上限更高。我的建议是从EfficientNet-B0或ResNet-34开始。它们性能不错训练和推理速度也相对较快是很好的基准模型。可以在上面进行微调Fine-tuning即保留预训练好的特征提取层只替换并重新训练最后的全连接分类层。5.2 训练技巧与陷阱学习率策略使用余弦退火Cosine Annealing或带热重启的余弦退火Cosine Annealing with Warm Restarts学习率调度器这通常比简单的步进衰减效果更好。损失函数由于两类数据可能不平衡使用Focal Loss或带权重的CrossEntropyLoss可以迫使模型更关注难分类的样本。评估指标不要只看准确率Accuracy。对于内容安全这种对“误杀”把正常判为敏感和“漏杀”把敏感判为正常容忍度不同的场景要重点关注精确率Precision和召回率Recall并根据业务需求调整阈值或优化F1分数。过拟合监控密切关注训练损失和验证损失的曲线。如果训练损失持续下降而验证损失早早就开始上升那就是过拟合了。需要加强数据增强、使用Dropout、或收集更多数据。5.3 工程化部署考量模型训练好后如何提供服务API服务化使用 Flask、FastAPI 或 Django 将模型封装成RESTful API。接收图片文件或Base64编码返回分类结果和置信度。高性能推理对于高并发场景可以考虑使用TensorFlow Serving或TorchServe这类专门的模型服务框架它们支持模型版本管理、批量预测、性能监控等。异步处理如果鉴黄是内容上传流程中的一个环节可以考虑将图片推送到消息队列如RabbitMQ、Kafka由后台的消费者进程进行异步识别不阻塞主流程。规则引擎兜底模型不可能100%准确。可以结合一个简单的规则引擎例如识别出某些特定黑名单MD5的图片、或根据文件名、大小等元信息进行过滤作为第一道或最后一道防线。6. 常见问题与避坑指南实录在整个“爬取-清洗-标注-训练”的流水线中我踩过不少坑这里总结一下最典型的几个问题和解决方法。6.1 爬虫阶段问题1爬着爬着就只返回空数据或错误页了。排查首先检查返回的HTTP状态码。如果是403/429大概率是IP或请求频率被限制了。如果是200但内容不对检查请求头特别是Cookie、Referer、User-Agent是否被网站要求更新了。解决加强伪装定期更新User-Agent维持有效的会话Cookie可能需要模拟登录或处理Set-Cookie。降低频率大幅增加请求间隔尤其是在爬取一段时间后。更换IP代理IP池必须足够大且质量要好。遇到封锁及时切换。模拟浏览器对于反爬极强的网站最终可能不得不使用Selenium或Playwright来完全模拟浏览器行为但代价是速度极慢。问题2图片链接下载下来是损坏的或者是一张“图片不存在”的占位图。排查检查下载的图片文件头magic number或者用PIL打开试试。也可能是图片URL本身有过期时间如带Token从列表页获取到详情页再下载时Token已经失效。解决获取到原图URL后应尽快下载不要长时间排队。如果URL带参数仔细分析其生成规律看能否在下载时动态生成有效的参数。6.2 数据清洗与标注阶段问题3标注结果一致性很差不同标注员对同一张图片的判断差异大。原因《标注指南》不够清晰边界案例没有覆盖到。解决立即暂停标注组织所有标注员对分歧大的案例进行讨论统一认识。然后更新和完善《标注指南》增加更多正例和反例。在正式标注前必须进行充分的培训和校准测试。问题4数据集存在严重的类别不平衡正常图片远多于敏感图片。解决数据层面在训练时对敏感类图片进行过采样如复制或对正常类进行欠采样。更高级的方法是使用SMOTE等算法生成合成样本但对图像数据需谨慎。算法层面如前所述使用Focal Loss或调整分类损失的权重。评估层面使用ROC-AUC、PR曲线等对不平衡数据更友好的指标而不是单纯看准确率。6.3 模型训练阶段问题5模型在验证集上准确率很高但上线后效果很差。原因最常见的原因是数据分布不一致。训练验证集来自爬虫数据的早期批次而线上真实数据可能来自不同的时间、不同的子版块分布发生了变化协变量偏移。或者清洗规则过于严格导致训练集“太干净”与线上嘈杂的数据不匹配。解决持续收集线上数据建立反馈闭环将线上难以判定的或判错的图片加入标注流程持续扩充和更新训练数据集。进行更鲁棒的数据增强在训练时加入更多样化的噪声、模糊、压缩模拟等让模型学会关注更本质的特征而非某些特定背景或水印。领域自适应如果条件允许可以使用少量新收集的线上数据对模型进行微调使其适应新的数据分布。问题6模型推理速度太慢无法满足实时性要求。解决模型轻量化将训练好的大模型通过知识蒸馏、剪枝、量化等技术转换为更小、更快的模型。硬件加速使用GPU或专用的AI推理芯片如NVIDIA TensorRT, Intel OpenVINO。缓存机制对于同一张图片可通过MD5判断的重复请求直接返回缓存结果。分级过滤设计一个“快速模型精细模型”的流水线。先用一个极快但精度稍低的模型如二值化的CNN过滤掉绝大部分明显正常的图片只对快速模型存疑的图片再用大模型进行精细判断。这个从“怒爬”数据到构建可用模型的过程是一个典型的、充满挑战的数据工程和机器学习项目。它考验的不仅仅是编码能力更是对问题拆解、系统设计、数据处理和模型调优的综合把握。每一个环节的细节都决定了最终系统的效果。希望我的这些经验能为你类似的项目提供一条相对清晰的路径。记住耐心和持续迭代是成功的关键。
1. 项目缘起与核心诉求最近在做一个内容安全相关的项目需要大量的、高质量的图片数据来训练一个鉴黄模型。这事儿听起来挺高大上但实际操作起来第一步“找数据”就让人头大。公开的数据集要么太旧要么类别不全要么就是数据量太小根本喂不饱现在这些“胃口”巨大的深度学习模型。正当我发愁的时候一个朋友半开玩笑地说“网上那么多‘学习资料’网站图片海了去了你去爬点不就行了”这句话点醒了我。确实互联网上存在大量用户生成内容的平台其中不乏一些以图片分享为主的站点它们的内容更新快、种类多、数量庞大如果能合规、合法地获取并用于模型训练无疑是一个极佳的数据源。这里的“合规、合法”是绝对的前提我们讨论的始终是那些公开的、允许爬虫访问的、且内容本身不涉及违法违规的图片资源用于构建识别和过滤不良内容的正向工具。我们的目标是打造一个更干净的互联网环境。所以这个项目的核心诉求就非常明确了我需要从一个特定的、图片资源丰富的公开网站我们姑且称之为“资源站A”上自动化地、高效地、稳定地爬取海量图片数据并经过严格的清洗和标注最终形成一个可用于训练鉴黄模型的高质量数据集。整个过程技术上的挑战在于应对网站的反爬机制、设计高效的爬取架构以及后续繁琐但至关重要的数据清洗工作。2. 目标网站分析与爬虫策略设计2.1 目标站点特征剖析在动手写代码之前花时间分析目标网站的结构和行为模式是至关重要的这能避免后续很多无谓的试错。我选择的“资源站A”是一个典型的动态网页SPA与静态内容混合的站点。首先我通过浏览器的开发者工具F12进行了网络请求分析。我发现网站的主体页面是通过JavaScript动态渲染的直接请求HTML源码只能得到一个几乎空的框架真正的图片列表数据是通过XHRAjax请求从后端API获取的JSON数据。这是一个关键发现意味着传统的基于HTML解析的爬虫如BeautifulSoup直接抓页面在这里会失效我们必须模拟浏览器行为或者直接找到并调用其数据接口。其次我观察了其图片的加载方式。缩略图列表页的图片链接是直接嵌入在JSON数据中的而点击进入大图详情页后图片地址有时会带有时间戳或Token参数这可能是一种简单的防盗链或缓存机制。图片文件本身通常存储在独立的CDN域名下。最后我测试了网站的反爬措施。短时间内连续访问列表页会偶尔遇到请求返回空数据或状态码429请求过多的情况。网站还检查了请求头中的User-Agent、Referer等字段。虽然没有特别复杂的验证码但基本的频率限制和请求头校验是存在的。2.2 爬虫架构与技术选型基于以上分析我设计了如下爬虫架构请求层使用requests库作为基础。但对于需要执行JavaScript的页面如果某些关键数据必须通过JS计算生成则备用Selenium或Playwright。鉴于我们已找到核心的JSON API优先使用requests模拟API调用效率更高。解析与调度层由于数据主要来自JSON API使用Python内置的json库进行解析即可。需要设计一个任务调度器管理待爬取的页面队列分页URL或API参数并控制请求频率。数据存储层图片文件本身使用urllib或requests下载后直接以二进制形式存储到本地文件夹或对象存储如AWS S3、阿里云OSS。图片的元数据如源URL、爬取时间、可能的标签、所属页面等则存储到SQLite或MySQL数据库中便于后续管理和清洗。反爬对抗与稳健性User-Agent池准备一批常见的浏览器UA字符串随机切换。IP代理池这是应对频率限制的核心。我选择使用几个按量付费的云服务商提供的代理IP服务构建一个简单的代理池在请求失败或遇到429状态码时自动切换IP。请求间隔在请求之间加入随机延时例如time.sleep(random.uniform(1, 3))模拟人类操作。错误重试与断点续爬任何网络请求都可能失败。必须为每个请求设置重试机制如retrying库。同时将爬取进度如已爬取的页码、最后成功的图片ID持久化到文件或数据库确保程序意外中断后可以从断点恢复而不是从头开始。注意法律与道德边界在实施爬取前务必仔细阅读目标网站的robots.txt文件尊重其中定义的爬虫规则。我们的爬取行为应控制频率避免对目标网站服务器造成显著压力。所有数据仅用于公开声明的、正面的技术研究目的内容安全模型训练绝不用于任何商业侵权或非法传播。这是技术人的基本操守。3. 核心爬取流程与代码实现详解3.1 逆向工程定位核心数据接口这是最具技巧性的一步。打开浏览器开发者工具的“网络”(Network)选项卡筛选XHR/Fetch请求然后浏览网站的几个列表页观察哪些请求的响应里包含了我们需要的图片列表信息。很快我发现了形如https://api.resource-site-a.com/v1/list?page2limit30的请求。查看其响应正是一个结构清晰的JSON{ code: 0, data: { items: [ { id: 123456, title: 某图片标题, previewUrl: https://cdn.example.com/thumbs/abc.jpg, detailUrl: https://www.resource-site-a.com/item/123456, width: 800, height: 600, tags: [tag1, tag2] }, // ... 更多图片项 ], hasNext: true, totalPages: 150 } }完美previewUrl是缩略图通常质量较低。我们需要的是原图。继续点击某个图片进入详情页再次观察网络请求。可能会发现另一个API如https://api.resource-site-a.com/v1/item/123456其响应中包含了更高清的图片URLoriginalUrl。至此爬取逻辑清晰了循环构造列表页API请求 - 解析JSON获取一批图片的ID和基本信息 - 对于每个图片ID再请求详情页API获取原图URL - 最后下载原图。3.2 爬虫核心代码模块拆解下面我分模块展示核心代码逻辑1. 配置与请求会话管理import requests import time import random from retrying import retry import json import sqlite3 from urllib.parse import urljoin class ResourceSiteSpider: def __init__(self): self.base_api_url https://api.resource-site-a.com/v1 self.headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.resource-site-a.com/, Accept: application/json, } self.session requests.Session() self.session.headers.update(self.headers) # 代理池示例实际需要从服务获取 self.proxy_list [ http://user:passproxy1:port, http://user:passproxy2:port, ] self.current_proxy_index 0 # 数据库初始化 self.init_database() def init_database(self): self.conn sqlite3.connect(image_data.db) c self.conn.cursor() c.execute(CREATE TABLE IF NOT EXISTS images (id TEXT PRIMARY KEY, title TEXT, preview_url TEXT, original_url TEXT, local_path TEXT, tags TEXT, page INTEGER, crawled_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)) self.conn.commit()2. 带代理和重试的请求函数这是爬虫稳健运行的核心。retry(stop_max_attempt_number3, wait_fixed2000) def make_request(self, url, paramsNone, use_proxyTrue): 发起请求失败自动重试并切换代理 proxies None if use_proxy and self.proxy_list: proxy self.proxy_list[self.current_proxy_index] proxies {http: proxy, https: proxy} try: resp self.session.get(url, paramsparams, proxiesproxies, timeout10) resp.raise_for_status() # 检查HTTP状态码非200则抛出异常 # 如果返回的是JSON检查业务码 if application/json in resp.headers.get(Content-Type, ): data resp.json() if data.get(code) ! 0: # 假设0表示成功 raise Exception(fAPI returned error code: {data.get(code)}) return data return resp.content except (requests.exceptions.RequestException, Exception) as e: print(f请求失败: {url}, 错误: {e}) # 切换代理 if use_proxy and self.proxy_list: self.current_proxy_index (self.current_proxy_index 1) % len(self.proxy_list) print(f切换代理至: {self.proxy_list[self.current_proxy_index]}) # 重试前等待 time.sleep(random.uniform(5, 10)) raise # 触发retry的重试机制3. 列表页爬取与详情页解析def crawl_list_page(self, page): 爬取指定页码的列表 list_url f{self.base_api_url}/list params {page: page, limit: 50} print(f正在爬取列表页第 {page} 页...) data self.make_request(list_url, paramsparams) if not data or data not in data or items not in data[data]: print(f第 {page} 页无数据或响应格式异常) return [] items data[data][items] image_ids [] for item in items: img_id item.get(id) if not img_id: continue # 先存入数据库部分信息 c self.conn.cursor() c.execute(INSERT OR IGNORE INTO images (id, title, preview_url, tags, page) VALUES (?, ?, ?, ?, ?), (img_id, item.get(title), item.get(previewUrl), json.dumps(item.get(tags, [])), page)) self.conn.commit() image_ids.append(img_id) print(f 发现图片 ID: {img_id}) # 随机延时避免请求过快 time.sleep(random.uniform(1, 3)) return image_ids def fetch_image_detail(self, image_id): 获取单张图片的详情与原图URL detail_url f{self.base_api_url}/item/{image_id} data self.make_request(detail_url) if not data or data not in data: print(f获取详情失败: {image_id}) return None detail data[data] original_url detail.get(originalUrl) or detail.get(highResUrl) # 不同网站字段名可能不同 if not original_url: # 如果API没给可能需要从详情页HTML里解析这里就需要用Selenium了 print(f图片 {image_id} 未找到原图URL) return None # 更新数据库中的原图URL c self.conn.cursor() c.execute(UPDATE images SET original_url? WHERE id?, (original_url, image_id)) self.conn.commit() return original_url4. 图片下载与存储def download_image(self, image_id, original_url, save_dir./downloaded_images): 下载图片到本地 import os os.makedirs(save_dir, exist_okTrue) # 根据URL生成文件名避免重复 file_extension original_url.split(.)[-1].split(?)[0] # 处理带参数的URL if file_extension.lower() not in [jpg, jpeg, png, gif, webp]: file_extension jpg # 默认 filename f{image_id}.{file_extension} filepath os.path.join(save_dir, filename) # 如果文件已存在跳过 if os.path.exists(filepath): print(f图片 {image_id} 已存在跳过下载) return filepath try: image_data self.make_request(original_url, use_proxyFalse) # 下载图片可能不需要代理或需不同代理策略 with open(filepath, wb) as f: f.write(image_data) print(f图片下载成功: {image_id} - {filepath}) # 更新数据库中的本地路径 c self.conn.cursor() c.execute(UPDATE images SET local_path? WHERE id?, (filepath, image_id)) self.conn.commit() return filepath except Exception as e: print(f下载图片失败 {image_id}: {e}) return None # 下载后休息一下 time.sleep(random.uniform(0.5, 1.5))5. 主控调度循环def run(self, start_page1, end_page10): 主运行函数 for page in range(start_page, end_page 1): image_ids self.crawl_list_page(page) print(f第 {page} 页共获取到 {len(image_ids)} 个图片ID) for idx, img_id in enumerate(image_ids): print(f 处理第 {idx1}/{len(image_ids)} 张: {img_id}) original_url self.fetch_image_detail(img_id) if original_url: self.download_image(img_id, original_url) # 每处理完一张详情稍作休息 time.sleep(random.uniform(0.3, 0.8)) # 每爬完一页休息更长时间 time.sleep(random.uniform(3, 7)) self.conn.close() print(爬取任务完成) if __name__ __main__: spider ResourceSiteSpider() spider.run(start_page1, end_page5) # 从第1页爬到第5页3.3 实操心得与关键参数调优频率控制是生命线time.sleep的随机区间设置至关重要。列表页之间间隔可以稍长3-7秒详情页之间稍短0.3-0.8秒下载图片后再短0.5-1.5秒。这个节奏需要根据目标网站的实际承受能力和反爬策略动态调整。一开始可以设得保守一些观察日志如果没有被封再尝试逐步缩短间隔找到一个效率与稳定性的平衡点。代理IP的质量与策略免费的代理IP大多不稳定、速度慢。对于这种需要长时间、大规模爬取的项目建议使用付费的代理IP服务最好是那些提供“住宅IP”或“动态IP”的服务被封禁的风险更低。在代码中代理失败后的切换逻辑和重试逻辑要结合好。数据库的作用为什么一定要用数据库如SQLite记录元数据而不仅仅是把图片下载到文件夹原因有三一是便于去重根据id或original_url可以防止重复下载二是记录了图片的来源页码、标签和状态是否已下载、本地路径后续数据清洗和标注时这些信息是宝贵的上下文三是支持断点续爬程序可以从上次中断的页码或最后一个成功的图片ID继续而不是重头开始。异常处理要细致网络请求可能因为超时、连接重置、代理失效、对方服务器返回5xx错误等多种原因失败。retry装饰器配合自定义的make_request方法能够应对大多数临时性故障。但对于永久性错误如IP被永久封禁、图片URL失效则需要记录到单独的日志或错误表中避免循环重试。4. 从原始数据到训练数据集清洗与标注流水线爬取到的原始图片只是原材料距离能用于训练模型的数据集还有很长的路要走。这个过程甚至比爬虫本身更耗时、更需要耐心。4.1 自动化初步清洗首先我们需要对下载的图片进行一轮自动化清洗格式统一与损坏检测使用PIL(Python Imaging Library) 或OpenCV尝试打开每一张图片。无法打开的文件损坏、格式怪异的直接剔除。同时可以将所有图片统一转换为RGB模式的JPG或PNG格式减少后续处理的复杂度。分辨率过滤鉴黄模型通常需要一定清晰度的图片。可以设置一个最低分辨率阈值如 宽度300px 且 高度300px过滤掉尺寸过小的图标或缩略图。去重基于图片内容的去重。计算每张图片的感知哈希pHash或均值哈希aHash将哈希值过于接近的图片视为重复或高度相似只保留其中质量最高如分辨率最大、无压缩痕迹的一张。imagehash库可以很方便地实现这一点。简单内容过滤可选可以使用一个轻量级的预训练模型如MobileNet或规则过滤掉明显与目标无关的图片例如纯色背景、大量文字可能是广告、图标等。这一步要谨慎阈值设得宽松一些避免误伤。4.2 人工标注流程与平台搭建自动化清洗后剩下的图片需要人工进行标注这是构建高质量数据集最关键、最昂贵的一环。我们需要的标签至少包括“正常”SFW和“敏感”NSFW。更细致的标注还可以包括敏感内容的子类别。方案选择小型/起步项目可以使用开源的标注工具如LabelImg更适合目标检测、LabelStudio。自己搭建一个简单的Web界面让标注员在线查看图片并打标签数据直接存入数据库。追求效率与协作我强烈推荐使用现成的数据标注平台服务如国内的Scale AI、Appen或者一些云厂商提供的标注服务。它们提供了任务分发、质量控制、多人协作、进度管理等一系列功能虽然有一定成本但能极大提升标注效率和一致性。标注指南制定在开始标注前必须制定清晰、无歧义的《标注指南》。例如“敏感”图片的定义明确包含哪些具体内容需符合相关法律法规和公序良俗的定义。边界情况处理例如艺术绘画与色情图片的界限医疗教材图片与不良内容的界限。需要提供示例图片进行说明。质量控制引入多人交叉标注和仲裁机制。同一张图片由2-3人独立标注如果结果不一致则由更资深的审核员进行仲裁。计算标注者间的一致性如Cohen‘s Kappa系数以确保标注质量。4.3 数据集的划分与整理标注完成后我们就有了一个带标签的数据集。接下来划分训练集、验证集、测试集通常按70%15%15%或类似比例随机划分。关键点必须确保同一ID或高度相似的图片不会同时出现在训练集和测试集中否则会导致模型评估结果虚高。可以根据图片的源页面或聚类结果来确保划分的独立性。数据增强对于“敏感”类图片通常数量远少于“正常”类为了缓解类别不平衡可以在训练时使用数据增强技术如随机水平翻转、小幅度的旋转、裁剪、颜色抖动等来人工增加其多样性。注意增强操作必须合理不能改变图片的本质类别例如把一张正常图片增强后变成了看起来敏感的样子。格式整理将最终的数据集整理成模型框架所需的格式如TensorFlow的TFRecord、PyTorch的Dataset类定义文件、或简单的“文件路径标签”的CSV列表。5. 模型训练选型与工程化思考有了高质量的数据集我们就可以着手训练鉴黄模型了。这不是本文的重点但可以简要分享我的选型思路和工程化考虑。5.1 模型架构选择目前图像分类任务的主流是卷积神经网络CNN。对于鉴黄这种二分类任务并不需要最新最复杂的模型。轻量级/快速验证MobileNetV2、EfficientNet-B0。它们在速度和精度上有很好的平衡适合需要快速响应或部署在资源受限环境如移动端、边缘设备的场景。追求高精度ResNet-50、EfficientNet-B3/B4。如果计算资源充足且对准确率要求极高可以选择这些更深、更强大的模型。通常在足够大的数据集上这些大模型的上限更高。我的建议是从EfficientNet-B0或ResNet-34开始。它们性能不错训练和推理速度也相对较快是很好的基准模型。可以在上面进行微调Fine-tuning即保留预训练好的特征提取层只替换并重新训练最后的全连接分类层。5.2 训练技巧与陷阱学习率策略使用余弦退火Cosine Annealing或带热重启的余弦退火Cosine Annealing with Warm Restarts学习率调度器这通常比简单的步进衰减效果更好。损失函数由于两类数据可能不平衡使用Focal Loss或带权重的CrossEntropyLoss可以迫使模型更关注难分类的样本。评估指标不要只看准确率Accuracy。对于内容安全这种对“误杀”把正常判为敏感和“漏杀”把敏感判为正常容忍度不同的场景要重点关注精确率Precision和召回率Recall并根据业务需求调整阈值或优化F1分数。过拟合监控密切关注训练损失和验证损失的曲线。如果训练损失持续下降而验证损失早早就开始上升那就是过拟合了。需要加强数据增强、使用Dropout、或收集更多数据。5.3 工程化部署考量模型训练好后如何提供服务API服务化使用 Flask、FastAPI 或 Django 将模型封装成RESTful API。接收图片文件或Base64编码返回分类结果和置信度。高性能推理对于高并发场景可以考虑使用TensorFlow Serving或TorchServe这类专门的模型服务框架它们支持模型版本管理、批量预测、性能监控等。异步处理如果鉴黄是内容上传流程中的一个环节可以考虑将图片推送到消息队列如RabbitMQ、Kafka由后台的消费者进程进行异步识别不阻塞主流程。规则引擎兜底模型不可能100%准确。可以结合一个简单的规则引擎例如识别出某些特定黑名单MD5的图片、或根据文件名、大小等元信息进行过滤作为第一道或最后一道防线。6. 常见问题与避坑指南实录在整个“爬取-清洗-标注-训练”的流水线中我踩过不少坑这里总结一下最典型的几个问题和解决方法。6.1 爬虫阶段问题1爬着爬着就只返回空数据或错误页了。排查首先检查返回的HTTP状态码。如果是403/429大概率是IP或请求频率被限制了。如果是200但内容不对检查请求头特别是Cookie、Referer、User-Agent是否被网站要求更新了。解决加强伪装定期更新User-Agent维持有效的会话Cookie可能需要模拟登录或处理Set-Cookie。降低频率大幅增加请求间隔尤其是在爬取一段时间后。更换IP代理IP池必须足够大且质量要好。遇到封锁及时切换。模拟浏览器对于反爬极强的网站最终可能不得不使用Selenium或Playwright来完全模拟浏览器行为但代价是速度极慢。问题2图片链接下载下来是损坏的或者是一张“图片不存在”的占位图。排查检查下载的图片文件头magic number或者用PIL打开试试。也可能是图片URL本身有过期时间如带Token从列表页获取到详情页再下载时Token已经失效。解决获取到原图URL后应尽快下载不要长时间排队。如果URL带参数仔细分析其生成规律看能否在下载时动态生成有效的参数。6.2 数据清洗与标注阶段问题3标注结果一致性很差不同标注员对同一张图片的判断差异大。原因《标注指南》不够清晰边界案例没有覆盖到。解决立即暂停标注组织所有标注员对分歧大的案例进行讨论统一认识。然后更新和完善《标注指南》增加更多正例和反例。在正式标注前必须进行充分的培训和校准测试。问题4数据集存在严重的类别不平衡正常图片远多于敏感图片。解决数据层面在训练时对敏感类图片进行过采样如复制或对正常类进行欠采样。更高级的方法是使用SMOTE等算法生成合成样本但对图像数据需谨慎。算法层面如前所述使用Focal Loss或调整分类损失的权重。评估层面使用ROC-AUC、PR曲线等对不平衡数据更友好的指标而不是单纯看准确率。6.3 模型训练阶段问题5模型在验证集上准确率很高但上线后效果很差。原因最常见的原因是数据分布不一致。训练验证集来自爬虫数据的早期批次而线上真实数据可能来自不同的时间、不同的子版块分布发生了变化协变量偏移。或者清洗规则过于严格导致训练集“太干净”与线上嘈杂的数据不匹配。解决持续收集线上数据建立反馈闭环将线上难以判定的或判错的图片加入标注流程持续扩充和更新训练数据集。进行更鲁棒的数据增强在训练时加入更多样化的噪声、模糊、压缩模拟等让模型学会关注更本质的特征而非某些特定背景或水印。领域自适应如果条件允许可以使用少量新收集的线上数据对模型进行微调使其适应新的数据分布。问题6模型推理速度太慢无法满足实时性要求。解决模型轻量化将训练好的大模型通过知识蒸馏、剪枝、量化等技术转换为更小、更快的模型。硬件加速使用GPU或专用的AI推理芯片如NVIDIA TensorRT, Intel OpenVINO。缓存机制对于同一张图片可通过MD5判断的重复请求直接返回缓存结果。分级过滤设计一个“快速模型精细模型”的流水线。先用一个极快但精度稍低的模型如二值化的CNN过滤掉绝大部分明显正常的图片只对快速模型存疑的图片再用大模型进行精细判断。这个从“怒爬”数据到构建可用模型的过程是一个典型的、充满挑战的数据工程和机器学习项目。它考验的不仅仅是编码能力更是对问题拆解、系统设计、数据处理和模型调优的综合把握。每一个环节的细节都决定了最终系统的效果。希望我的这些经验能为你类似的项目提供一条相对清晰的路径。记住耐心和持续迭代是成功的关键。
