第三章 良率数据采集：数据格式标准化、数据清洗与预处理、良率数据库搭建

数据采集这件事，听起来好像很简单——把测试机台的数据导出来不就行了？

但我在这个行业干了十几年，见过太多团队在数据采集阶段就埋下了大坑。数据格式五花八门，同一个测试项在不同机台上叫法都不一样，有的叫“VDD_min”，有的叫“VDDMIN”，还有的叫“VDD_Min”。你想想看，这种数据要是直接扔进分析工具，结果能靠谱吗？

所以这一章，咱们就聊聊怎么把数据采集这件事做扎实。

3.1 数据格式标准化：让所有机台说同一种语言

我刚开始带项目的时候，遇到过一件特别头疼的事。ATE机台是Teradyne的，良率分析系统是PDF Solutions的，中间还夹着一个第三方数据转换工具。每次数据对接，都要花两三天去调格式。后来我学乖了——在项目启动前，先把数据格式标准定死。

3.1.1 命名规范

我个人习惯用这套规则，你可以直接拿来用：

数据项	规范格式	示例	说明
测试项名称	大写字母+下划线	VDD_MIN, IDD_MAX	禁止使用空格、连字符、大小写混用
测试结果	PASS/FAIL	PASS	不要用1/0或OK/NG
测量值	浮点数+单位	1.25V, 3.45mA	单位统一用小写
晶圆编号	W+批次+片号	W2403_12	批次和片号用下划线分隔
芯片坐标	X_Y	12_34	从晶圆中心开始计数

3.1.2 数据结构标准化

每一条测试记录，应该包含以下字段：

{
  "wafer_id": "W2403_12",        // 晶圆ID
  "die_x": 12,                    // X坐标
  "die_y": 34,                    // Y坐标
  "test_item": "VDD_MIN",        // 测试项
  "result": "PASS",              // 测试结果
  "value": 1.25,                 // 测量值
  "unit": "V",                   // 单位
  "tester_id": "ATE_03",         // 测试机台ID
  "test_time": "2024-03-15 14:30:00", // 测试时间
  "temperature": 25,             // 测试温度
  "corner": "TT"                 // 工艺角
}

嗯，这里要注意：时间戳一定要统一用UTC。我遇到过不同机台用不同时区的情况，结果分析时序数据时全乱了。

3.2 数据清洗与预处理：把脏数据挡在门外

数据清洗，说白了就是给数据“洗澡”。我在项目中见过太多奇葩数据了——电压值写成负数、电流值超出物理极限、同一个芯片测了两次结果不一样……这些数据如果不处理，分析出来的结论就是垃圾。

3.2.1 常见数据问题

我把这些年踩过的坑总结了一下：

• 缺失值：某个测试项没测到，或者测试机台宕机导致数据丢失
• 异常值：测量值超出物理范围，比如VDD测出-5V
• 重复值：同一个芯片被重复测试，数据重复记录
• 格式错误：数值里混入了字母，比如“1.2V”写成了“1.2V_”
• 逻辑矛盾：测试结果是PASS，但测量值却超出了规格

3.2.2 清洗流程

我一般按这个流程走：

1. 格式校验：检查每个字段是否符合规范，不符合的直接标记为“格式异常”
2. 范围检查：根据物理极限和规格书，剔除超出合理范围的数据
3. 去重处理：按晶圆ID+芯片坐标+测试项去重，保留最后一次测试结果
4. 逻辑校验：检查PASS/FAIL与测量值是否一致
5. 缺失值处理：对于缺失的测试项，用“NA”填充，不要用0或空字符串

# 伪代码示例：数据清洗逻辑
def clean_test_data(raw_data):
    # 1. 格式校验
    if not check_format(raw_data):
        mark_as_error(raw_data, "FORMAT_ERROR")
        return
    
    # 2. 范围检查
    if raw_data.value < PHYSICAL_MIN or raw_data.value > PHYSICAL_MAX:
        mark_as_error(raw_data, "OUT_OF_RANGE")
        return
    
    # 3. 去重
    if is_duplicate(raw_data):
        mark_as_duplicate(raw_data)
        return
    
    # 4. 逻辑校验
    if raw_data.result == "PASS" and raw_data.value > SPEC_LIMIT:
        mark_as_error(raw_data, "LOGIC_CONFLICT")
        return
    
    # 5. 写入清洗后的数据库
    write_to_clean_db(raw_data)

3.3 良率数据库搭建：让数据“活”起来

数据清洗完了，接下来就是怎么存的问题。我见过很多团队把数据存在Excel里，或者散落在各个文件夹的CSV文件中。说实话，这种管理方式，良率分析基本靠猜。

我个人强烈建议搭建一个良率数据库。为什么？因为只有结构化的数据，才能支撑起后续的统计分析、根因定位和良率预测。

3.3.1 数据库架构设计

我常用的架构是三层结构：

3.3.2 表结构设计

我建议至少建这几张表：

表名	用途	关键字段
raw_test_data	存储原始测试数据	wafer_id, die_x, die_y, test_item, value, tester_id, test_time
clean_test_data	存储清洗后的数据	同上 + clean_flag, quality_score
wafer_info	晶圆基本信息	wafer_id, lot_id, process_node, fab, test_date
test_spec	测试规格参数	test_item, spec_min, spec_max, unit, corner
yield_summary	良率汇总统计	wafer_id, total_dies, pass_dies, fail_dies, yield_rate
bin_distribution	Bin分布统计	wafer_id, bin_code, bin_count, bin_percentage

3.3.3 数据库选型建议

根据项目规模不同，我推荐不同的方案：

• 小规模项目（月产量<1000片晶圆）：SQLite就够了，轻量、易部署、不需要专门的DBA
• 中等规模项目（月产量1000-10000片）：PostgreSQL，支持复杂查询和并行处理
• 大规模项目（月产量>10000片）：分布式数据库，比如ClickHouse或TimescaleDB，专门针对时序数据优化

3.4 数据采集的自动化与监控

数据采集不能靠人工手动操作。我见过有些团队，每次流片回来，测试工程师手动导出数据、手动清洗、手动导入数据库。这种操作方式，不仅效率低，而且容易出错。

我建议搭建一个自动化数据采集流水线：

1. 自动触发：ATE机台测试完成后，自动触发数据上传脚本
2. 自动清洗：数据上传后，自动执行清洗流程，生成清洗报告
3. 自动入库：清洗通过的数据，自动写入数据库
4. 自动告警：如果数据质量评分低于阈值，自动发送告警邮件

# 自动化流水线伪代码
def data_pipeline():
    # 1. 监听ATE机台完成信号
    while True:
        signal = listen_for_test_complete()
        if signal:
            # 2. 下载原始数据
            raw_file = download_raw_data(signal.tester_id, signal.lot_id)
            
            # 3. 执行清洗
            clean_data = clean_test_data(raw_file)
            
            # 4. 质量评分
            score = calculate_quality_score(clean_data)
            
            # 5. 写入数据库
            if score > QUALITY_THRESHOLD:
                write_to_clean_db(clean_data)
            else:
                send_alert("数据质量异常", f"评分: {score}")
            
            # 6. 记录日志
            log_pipeline_execution(signal, score)

嗯，这里要特别强调一下：自动化不等于无人值守。我建议每天安排一个人值班，检查自动化流水线的运行状态。毕竟机器也会出错，人眼扫一遍更放心。

3.5 本章小结

数据采集是整个良率提升工作的基础。基础不牢，地动山摇。我见过太多团队在数据分析阶段才发现数据有问题，然后回头去补数据、改数据，浪费了大量时间。

所以，我的建议是：

• 在项目启动前，把数据格式标准定死
• 在数据入库前，把脏数据清洗干净
• 在数据分析前，把数据库架构搭好

这三步走扎实了，后面的良率分析才能事半功倍。