第二章 数据采集阶段的常见问题
数据采集是整个训练Pipeline的入口，也是问题最容易爆发的阶段。我见过不少团队花了大量精力调模型，结果发现是训练数据本身就有问题——这就像用歪了的尺子去量东西，再怎么量也量不准。这一章，我们来聊聊数据采集阶段最常见的四类坑。
数据源连通性故障
数据源连不上，后面的一切都白搭。这个问题看着简单，但在实际生产环境中踩坑的概率极高。
典型表现：Pipeline启动后，第一步就卡在数据读取阶段，日志里全是连接超时或拒绝访问的信息。我个人习惯在写采集代码之前，先单独测试一下数据源的连通性。
数据源连通性的常见故障原因，我整理了一个表格：
| 故障类型 | 典型错误日志 | 排查方向 |
|---|---|---|
| 连接超时 | Connection timed out |
网络配置、防火墙、目标服务状态 |
| 认证失败 | Authentication failed |
凭据正确性、权限变更、Token过期 |
| DNS解析失败 | Name or service not known |
DNS配置、域名有效性 |
| 连接池耗尽 | Too many connections |
并发数限制、连接释放策略 |
爬虫/API采集异常
数据源能连上了，不代表就万事大吉了。爬虫和API采集的过程里，花样比你想的要多。
常见问题列表：
- HTTP状态码异常：4xx（客户端错误）和5xx（服务端错误）都需要处理。比如401代表需要重新认证，429代表触发了限流。我个人习惯把常见的HTTP状态码和对应的处理策略写成一个映射字典。
- 反爬机制：很多网站会对高频访问做限制。IP被封、User-Agent被检测、验证码弹出等等。你想想看，如果某个爬虫任务连续返回同一段HTML代码（比如验证码页面），那就说明被限制了。
- 返回格式异常：API返回的数据格式可能和预期不一致。比如应该返回JSON，结果返回了HTML错误页。或者JSON的key变了，导致解析失败。
- 限流和频率限制：有些API的Rate Limit非常严格，超出后直接拒绝服务。我建议在采集代码里加入指数退避的重试策略。
# 示例：一个带有重试机制的API采集函数
import requests
import time
def fetch_data_with_retry(url, retries=3, backoff_factor=2):
for attempt in range(retries):
try:
response = requests.get(url, timeout=10)
response.raise_for_status()
return response.json()
except requests.exceptions.HTTPError as e:
if e.response.status_code == 429:
wait = backoff_factor ** attempt
time.sleep(wait)
else:
raise
except requests.exceptions.ConnectionError:
if attempt == retries - 1:
raise
time.sleep(backoff_factor ** attempt)
核心原则：采集代码必须有完善的异常捕获和日志记录。不要只捕获一个Exception然后静默处理，那样问题会被隐藏很久。
数据量不足与分布偏差
终于把数据采集回来了，但一看统计结果，心凉了半截。数据量不足，或者数据分布跟真实场景对不上，这种情况下训练出来的模型基本是废的。
数据量不足：这个好理解，样本太少，模型学不到足够的规律。但什么是"足够"？这取决于你的任务复杂度。简单分类任务可能几千条就够，复杂的NLP或图像任务可能需要百万级。我个人习惯的底线是：每个类别或关键特征维度至少有1000条以上。
数据分布偏差：这个坑更隐蔽。举个例子：你要训练一个狗品种识别模型，但采集到的数据80%都是金毛猎犬，剩下的品种加起来才20%。模型会学得很偏。同样的道理，如果采集时间集中在白天，那夜间场景的数据就是缺失的。
| 偏差类型 | 具体表现 | 应对措施 |
|---|---|---|
| 类别不均衡 | 某些类别样本极少 | 重采样、生成合成样本 |
| 时间偏差 | 采集时段固定 | 多时段、跨周期采集 |
| 地域偏差 | 只采集了特定区域 | 扩展数据源地域范围 |
| 来源偏差 | 数据来源单一 | 引入多个独立数据源 |
数据时效性与过期问题
有些数据是有"保质期"的。用过期数据训练出来的模型，很可能做出错误的判断。特别是在金融、电商、舆情分析这类场景下，时效性尤其重要。
数据过期的判断标准：
- 业务场景变化：去年双十一的促销策略跟今年完全不同，用去年的数据预测今年的销量？大概率要翻车。
- 周期性调整：季度末、年末的数据与日常数据差异巨大。采集时必须标注时间戳，这样在训练时可以根据时间窗口进行筛选。
- 版本更新：如果数据来自某个软件或平台，它的接口或数据格式升级后，旧数据就失效了。我遇到过API版本从v1升到v2，返回的字段名都变了，旧数据的解析代码直接报错。
# 检查数据时效性的示例逻辑
from datetime import datetime, timedelta
def is_data_stale(data_timestamp, max_age_days=30):
"""检查数据是否超过最大保存期限"""
age = datetime.now() - data_timestamp
return age > timedelta(days=max_age_days)
# 在数据采集后立即记录时间戳
def collect_with_timestamp(data):
return {
'data': data,
'collected_at': datetime.now().isoformat()
}
数据采集是整个Pipeline的起点，也是成本最低的优化点。如果在采集阶段就把这些常见问题处理掉，后面的特征工程、模型训练能少掉很多坑。嗯，我记得有句话说得很好——"垃圾进，垃圾出"（Garbage In, Garbage Out）。数据质量不过关，后面的模型能力再强也无力回天。把这些基础打牢，你的训练Pipeline才算真正站稳了脚跟。