尧图网站建设 免费方案咨询
ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

首页/资讯中心/资讯详情

从数据爬取到模型训练：构建高质量图片数据集的完整实践指南

发布时间：2026/8/5 5:20:16 尧图网站建设
从数据爬取到模型训练：构建高质量图片数据集的完整实践指南

1. 项目缘起与核心诉求

最近在做一个内容安全相关的项目，需要大量的、高质量的图片数据来训练一个鉴黄模型。这事儿听起来挺高大上，但实际操作起来，第一步“找数据”就让人头大。公开的数据集要么太旧，要么类别不全，要么就是数据量太小，根本喂不饱现在这些“胃口”巨大的深度学习模型。正当我发愁的时候，一个朋友半开玩笑地说：“网上那么多‘学习资料’网站，图片海了去了，你去爬点不就行了？”

这句话点醒了我。确实，互联网上存在大量用户生成内容的平台，其中不乏一些以图片分享为主的站点，它们的内容更新快、种类多、数量庞大，如果能合规、合法地获取并用于模型训练，无疑是一个极佳的数据源。这里的“合规、合法”是绝对的前提，我们讨论的始终是那些公开的、允许爬虫访问的、且内容本身不涉及违法违规的图片资源，用于构建识别和过滤不良内容的正向工具。我们的目标，是打造一个更干净的互联网环境。

所以，这个项目的核心诉求就非常明确了：我需要从一个特定的、图片资源丰富的公开网站（我们姑且称之为“资源站A”）上，自动化地、高效地、稳定地爬取海量图片数据，并经过严格的清洗和标注，最终形成一个可用于训练鉴黄模型的高质量数据集。整个过程，技术上的挑战在于应对网站的反爬机制、设计高效的爬取架构，以及后续繁琐但至关重要的数据清洗工作。

2. 目标网站分析与爬虫策略设计

2.1 目标站点特征剖析

在动手写代码之前，花时间分析目标网站的结构和行为模式是至关重要的，这能避免后续很多无谓的试错。我选择的“资源站A”是一个典型的动态网页（SPA）与静态内容混合的站点。

首先，我通过浏览器的开发者工具（F12）进行了网络请求分析。我发现，网站的主体页面是通过JavaScript动态渲染的，直接请求HTML源码只能得到一个几乎空的框架，真正的图片列表数据是通过XHR（Ajax）请求从后端API获取的JSON数据。这是一个关键发现，意味着传统的基于HTML解析的爬虫（如BeautifulSoup直接抓页面）在这里会失效，我们必须模拟浏览器行为，或者直接找到并调用其数据接口。

其次，我观察了其图片的加载方式。缩略图列表页的图片链接是直接嵌入在JSON数据中的，而点击进入大图详情页后，图片地址有时会带有时间戳或Token参数，这可能是一种简单的防盗链或缓存机制。图片文件本身通常存储在独立的CDN域名下。

最后，我测试了网站的反爬措施。短时间内连续访问列表页，会偶尔遇到请求返回空数据或状态码429（请求过多）的情况。网站还检查了请求头中的User-Agent、Referer等字段。虽然没有特别复杂的验证码，但基本的频率限制和请求头校验是存在的。

2.2 爬虫架构与技术选型

基于以上分析，我设计了如下爬虫架构：

  1. 请求层：使用requests库作为基础。但对于需要执行JavaScript的页面（如果某些关键数据必须通过JS计算生成），则备用Selenium或Playwright。鉴于我们已找到核心的JSON API，优先使用requests模拟API调用，效率更高。
  2. 解析与调度层：由于数据主要来自JSON API，使用Python内置的json库进行解析即可。需要设计一个任务调度器，管理待爬取的页面队列（分页URL或API参数），并控制请求频率。
  3. 数据存储层：图片文件本身使用urllib或requests下载后，直接以二进制形式存储到本地文件夹或对象存储（如AWS S3、阿里云OSS）。图片的元数据（如源URL、爬取时间、可能的标签、所属页面等）则存储到SQLite或MySQL数据库中，便于后续管理和清洗。
  4. 反爬对抗与稳健性：
    • 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?page=2&limit=30的请求。查看其响应，正是一个结构清晰的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:pass@proxy1:port', 'http://user:pass@proxy2: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_number=3, wait_fixed=2000) def make_request(self, url, params=None, use_proxy=True): """发起请求，失败自动重试并切换代理""" 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, params=params, proxies=proxies, timeout=10) 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(f"API 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, params=params) 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_url

4. 图片下载与存储

def download_image(self, image_id, original_url, save_dir="./downloaded_images"): """下载图片到本地""" import os os.makedirs(save_dir, exist_ok=True) # 根据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_proxy=False) # 下载图片可能不需要代理，或需不同代理策略 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_page=1, end_page=10): """主运行函数""" 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" 处理第 {idx+1}/{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_page=1, end_page=5) # 从第1页爬到第5页

3.3 实操心得与关键参数调优

  1. 频率控制是生命线：time.sleep的随机区间设置至关重要。列表页之间间隔可以稍长（3-7秒），详情页之间稍短（0.3-0.8秒），下载图片后再短（0.5-1.5秒）。这个节奏需要根据目标网站的实际承受能力和反爬策略动态调整。一开始可以设得保守一些，观察日志，如果没有被封，再尝试逐步缩短间隔，找到一个效率与稳定性的平衡点。

  2. 代理IP的质量与策略：免费的代理IP大多不稳定、速度慢。对于这种需要长时间、大规模爬取的项目，建议使用付费的代理IP服务，最好是那些提供“住宅IP”或“动态IP”的服务，被封禁的风险更低。在代码中，代理失败后的切换逻辑和重试逻辑要结合好。

  3. 数据库的作用：为什么一定要用数据库（如SQLite）记录元数据，而不仅仅是把图片下载到文件夹？原因有三：一是便于去重，根据id或original_url可以防止重复下载；二是记录了图片的来源（页码、标签）和状态（是否已下载、本地路径），后续数据清洗和标注时，这些信息是宝贵的上下文；三是支持断点续爬，程序可以从上次中断的页码或最后一个成功的图片ID继续，而不是重头开始。

  4. 异常处理要细致：网络请求可能因为超时、连接重置、代理失效、对方服务器返回5xx错误等多种原因失败。@retry装饰器配合自定义的make_request方法，能够应对大多数临时性故障。但对于永久性错误（如IP被永久封禁、图片URL失效），则需要记录到单独的日志或错误表中，避免循环重试。

4. 从原始数据到训练数据集：清洗与标注流水线

爬取到的原始图片只是原材料，距离能用于训练模型的数据集还有很长的路要走。这个过程甚至比爬虫本身更耗时、更需要耐心。

4.1 自动化初步清洗

首先，我们需要对下载的图片进行一轮自动化清洗：

  1. 格式统一与损坏检测：使用PIL(Python Imaging Library) 或OpenCV尝试打开每一张图片。无法打开的（文件损坏）、格式怪异的，直接剔除。同时，可以将所有图片统一转换为RGB模式的JPG或PNG格式，减少后续处理的复杂度。
  2. 分辨率过滤：鉴黄模型通常需要一定清晰度的图片。可以设置一个最低分辨率阈值（如 宽度>300px 且 高度>300px），过滤掉尺寸过小的图标或缩略图。
  3. 去重：基于图片内容的去重。计算每张图片的感知哈希（pHash）或均值哈希（aHash），将哈希值过于接近的图片视为重复或高度相似，只保留其中质量最高（如分辨率最大、无压缩痕迹）的一张。imagehash库可以很方便地实现这一点。
  4. 简单内容过滤（可选）：可以使用一个轻量级的预训练模型（如MobileNet）或规则，过滤掉明显与目标无关的图片，例如纯色背景、大量文字（可能是广告）、图标等。这一步要谨慎，阈值设得宽松一些，避免误伤。

4.2 人工标注流程与平台搭建

自动化清洗后，剩下的图片需要人工进行标注，这是构建高质量数据集最关键、最昂贵的一环。我们需要的标签至少包括：“正常”（SFW）和“敏感”（NSFW）。更细致的标注还可以包括敏感内容的子类别。

方案选择：

  • 小型/起步项目：可以使用开源的标注工具，如LabelImg（更适合目标检测）、LabelStudio。自己搭建一个简单的Web界面，让标注员在线查看图片并打标签，数据直接存入数据库。
  • 追求效率与协作：我强烈推荐使用现成的数据标注平台服务，如国内的Scale AI、Appen，或者一些云厂商提供的标注服务。它们提供了任务分发、质量控制、多人协作、进度管理等一系列功能，虽然有一定成本，但能极大提升标注效率和一致性。

标注指南制定：在开始标注前，必须制定清晰、无歧义的《标注指南》。例如：

  • “敏感”图片的定义：明确包含哪些具体内容（需符合相关法律法规和公序良俗的定义）。
  • 边界情况处理：例如，艺术绘画与色情图片的界限；医疗教材图片与不良内容的界限。需要提供示例图片进行说明。
  • 质量控制：引入多人交叉标注和仲裁机制。同一张图片由2-3人独立标注，如果结果不一致，则由更资深的审核员进行仲裁。计算标注者间的一致性（如Cohen‘s Kappa系数），以确保标注质量。

4.3 数据集的划分与整理

标注完成后，我们就有了一个带标签的数据集。接下来：

  1. 划分训练集、验证集、测试集：通常按70%：15%：15%或类似比例随机划分。关键点：必须确保同一ID或高度相似的图片不会同时出现在训练集和测试集中，否则会导致模型评估结果虚高。可以根据图片的源页面或聚类结果来确保划分的独立性。
  2. 数据增强：对于“敏感”类图片（通常数量远少于“正常”类），为了缓解类别不平衡，可以在训练时使用数据增强技术，如随机水平翻转、小幅度的旋转、裁剪、颜色抖动等，来人工增加其多样性。注意，增强操作必须合理，不能改变图片的本质类别（例如，把一张正常图片增强后变成了看起来敏感的样子）。
  3. 格式整理：将最终的数据集整理成模型框架所需的格式，如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 训练技巧与陷阱

  1. 学习率策略：使用余弦退火（Cosine Annealing）或带热重启的余弦退火（Cosine Annealing with Warm Restarts）学习率调度器，这通常比简单的步进衰减效果更好。
  2. 损失函数：由于两类数据可能不平衡，使用Focal Loss或带权重的CrossEntropyLoss可以迫使模型更关注难分类的样本。
  3. 评估指标：不要只看准确率（Accuracy）。对于内容安全这种对“误杀”（把正常判为敏感）和“漏杀”（把敏感判为正常）容忍度不同的场景，要重点关注精确率（Precision）和召回率（Recall），并根据业务需求调整阈值或优化F1分数。
  4. 过拟合监控：密切关注训练损失和验证损失的曲线。如果训练损失持续下降而验证损失早早就开始上升，那就是过拟合了。需要加强数据增强、使用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：数据集存在严重的类别不平衡，正常图片远多于敏感图片。

  • 解决：
    1. 数据层面：在训练时对敏感类图片进行过采样（如复制），或对正常类进行欠采样。更高级的方法是使用SMOTE等算法生成合成样本（但对图像数据需谨慎）。
    2. 算法层面：如前所述，使用Focal Loss或调整分类损失的权重。
    3. 评估层面：使用ROC-AUC、PR曲线等对不平衡数据更友好的指标，而不是单纯看准确率。

6.3 模型训练阶段

问题5：模型在验证集上准确率很高，但上线后效果很差。

  • 原因：最常见的原因是数据分布不一致。训练验证集来自爬虫数据的早期批次，而线上真实数据可能来自不同的时间、不同的子版块，分布发生了变化（协变量偏移）。或者，清洗规则过于严格，导致训练集“太干净”，与线上嘈杂的数据不匹配。
  • 解决：
    • 持续收集线上数据：建立反馈闭环，将线上难以判定的或判错的图片，加入标注流程，持续扩充和更新训练数据集。
    • 进行更鲁棒的数据增强：在训练时加入更多样化的噪声、模糊、压缩模拟等，让模型学会关注更本质的特征，而非某些特定背景或水印。
    • 领域自适应：如果条件允许，可以使用少量新收集的线上数据，对模型进行微调，使其适应新的数据分布。

问题6：模型推理速度太慢，无法满足实时性要求。

  • 解决：
    • 模型轻量化：将训练好的大模型通过知识蒸馏、剪枝、量化等技术，转换为更小、更快的模型。
    • 硬件加速：使用GPU或专用的AI推理芯片（如NVIDIA TensorRT, Intel OpenVINO）。
    • 缓存机制：对于同一张图片（可通过MD5判断）的重复请求，直接返回缓存结果。
    • 分级过滤：设计一个“快速模型+精细模型”的流水线。先用一个极快但精度稍低的模型（如二值化的CNN）过滤掉绝大部分明显正常的图片，只对快速模型存疑的图片，再用大模型进行精细判断。

这个从“怒爬”数据到构建可用模型的过程，是一个典型的、充满挑战的数据工程和机器学习项目。它考验的不仅仅是编码能力，更是对问题拆解、系统设计、数据处理和模型调优的综合把握。每一个环节的细节都决定了最终系统的效果。希望我的这些经验，能为你类似的项目提供一条相对清晰的路径。记住，耐心和持续迭代是成功的关键。

网站建设 视觉设计 SEO优化
返回列表