基于大模型生成测试数据：隐私保护与数据效用的新范式-育师

1. 项目概述：当数据脱敏遇上大模型

最近在做一个数据中台项目，客户对数据安全的要求近乎苛刻。他们需要将生产环境的真实数据同步到测试环境，用于新功能的开发和验证，但坚决不允许任何真实用户信息泄露。传统的脱敏方法，比如把“张三”替换成“用户A”，把手机号中间四位打码，我们早就用腻了。这些方法对付简单的查询还行，一旦涉及到复杂业务逻辑的联调测试，问题就来了：生成的数据要么缺乏关联性，导致业务流程跑不通；要么模式太单一，测不出边界情况。

就在我们为这事儿头疼的时候，团队里有人提了一嘴：“现在大模型不是挺火的吗？能不能让它来‘编’数据？” 这个想法一下子点醒了我。我们手头正好有腾讯的混元大模型API权限，为什么不试试用它来生成完全虚构、但又符合业务逻辑的测试数据呢？这不仅仅是简单的替换，而是从源头创造“无效内容”，实现一种更彻底的隐私保护。后来，我看到小米在宣传其屏幕共享功能时，特别强调了“隐私保护”，比如自动模糊聊天窗口、打码个人信息。这背后的逻辑其实是相通的：在数据被使用或展示的环节，主动介入，用“无效”或“不可识别”的信息覆盖真实内容。我们的项目，就是把这种思路应用到了数据供给的源头。

所以，这个“隐私保护新范式”项目，核心就是利用混元大模型，根据真实数据的表结构、字段含义和业务规则，批量生成高质量的、完全虚构的测试数据。它要解决三个核心痛点：第一，彻底杜绝隐私泄露风险，因为数据压根不是真的；第二，提升测试数据质量，让生成的数据更“聪明”，能模拟真实世界的复杂性和多样性；第三，提高数据准备效率，告别手动编写或配置复杂的脱敏规则。

2. 核心思路与技术选型

2.1 为什么是“生成”而非“脱敏”？

传统的数据脱敏（Data Masking）是一种“破坏性”保护。它拿到一份真实数据，然后通过替换、遮蔽、扰动等方式将其变形。这种方法存在几个固有缺陷：

残留风险：脱敏算法若被逆向或规则泄露，存在数据被部分还原的风险。
数据失真：过度脱敏可能导致数据失去统计特性（如分布、关联性），影响测试和开发效果。比如，把所有年龄都替换成“20-30岁”，就无法测试针对老年用户的特定功能。
维护成本高：每张表、每个字段都需要单独配置脱敏规则，业务变更时规则也需要同步更新，非常繁琐。

而我们采用的“生成式”路径，是一种“建设性”保护。它不接触任何真实数据，而是利用大模型对业务知识的理解，从零创造一套全新的、虚拟的数据集。这就像不是给一张真实照片打马赛克，而是让一个画家根据照片的描述（如“一个戴眼镜的男性程序员在咖啡馆”），重新画一张全新的、谁也不认识的肖像。这种方式从根源上切断了与真实个体的关联，实现了更本质的隐私安全。

2.2 为什么选择混元大模型？

市面上大模型很多，选择混元主要基于工程化落地的综合考量：

中文语境与业务理解优势：混元对中文语言、国内常见的业务场景（如身份证号、手机号格式、行政区划、中文人名构成）有天然的深度理解，生成的数据更符合我们的业务背景，无需额外进行大量的“文化对齐”。
可控性与稳定性：作为国内头部厂商的大模型，其API服务在合规性、可用性和稳定性方面更有保障，这对于企业级应用至关重要。我们不需要担心服务突然不可用或政策风险。
功能适配：混元API提供了完善的对话、长文本生成和函数调用能力，特别适合我们这种需要根据结构化规则生成结构化数据的场景。我们可以通过精心设计的提示词（Prompt），将其“约束”成一个高效、准确的数据生成器。

2.3 整体架构设计

我们的系统架构分为四个核心层：

调度与任务管理层：负责接收数据生成请求，解析目标表结构，拆解生成任务，并调度执行。我们使用Python的Celery作为异步任务队列，方便管理大批量表的数据生成任务。
提示词工程层：这是系统的“大脑”。我们将数据库表的元数据（表名、字段名、类型、注释、主外键关系）转换成大模型能理解的指令。这是最核心、最需要打磨的部分。
大模型调用与适配层：封装对混元大模型API的调用，处理token限制、响应解析、错误重试和费用监控。我们在这里实现了请求批处理和流式响应处理，以优化性能和成本。
数据质量校验与写入层：对模型生成的数据进行基础校验（如非空、格式、枚举值），并最终批量写入目标测试数据库。我们还会引入简单的逻辑规则校验，比如“订单金额必须大于0”。

整个流程可以概括为：“定义需求 -> 构建提示 -> 调用模型 -> 校验落地”。接下来，我们深入最关键的提示词构建环节。

3. 核心实战：如何设计提示词让大模型成为“数据生成专家”

让大模型生成数据，不是简单地说“给我100条用户数据”。那样生成的结果会五花八门，无法使用。关键在于通过提示词对其进行严格的“规训”。

3.1 基础提示词框架

一个有效的提示词必须包含以下几个部分：

你是一个专业的测试数据生成器。请严格遵循以下要求生成虚构的、符合中国常见业务场景的测试数据。 【表结构信息】 1. 表名：`user_info` (用户信息表) 2. 字段定义： - `id`: 整数，主键，自增长（无需生成） - `username`: 字符串，用户名，由字母、数字、下划线组成，长度6-12位。 - `real_name`: 字符串，真实姓名，虚构的中文姓名。 - `id_card`: 字符串，身份证号，符合中国18位身份证号规则，但必须是完全虚构无效的号码。 - `phone`: 字符串，手机号，符合中国11位手机号格式（1开头），但必须是完全虚构无效的号码。 - `email`: 字符串，电子邮箱，符合常见邮箱格式，域名请使用虚构的如 `@testdemo.com`。 - `age`: 整数，年龄范围18-65岁。 - `gender`: 整数，性别（0:未知，1:男，2:女）。 - `city`: 字符串，居住城市，中国地级市名称。 - `create_time`: 日期时间，数据创建时间，请生成近一年内的随机时间。 【生成要求】 1. 生成数量：10条。 2. 数据格式：请以纯JSON数组格式输出，每条记录对应一个JSON对象，键名与上述字段名严格一致。 3. 数据质量：所有数据必须是**完全虚构**的，不得与任何真实人物、事件、信息关联。姓名、证件号、手机号等敏感信息必须是无意义的随机组合，但需符合格式规范。 4. 数据多样性：请在合理范围内尽量使数据分布多样，例如城市不要全部相同，年龄均匀分布，性别比例均衡。 5. 逻辑性：数据应具备基本的逻辑性，例如年龄与出生年份（可从身份证号中推导）不应有巨大矛盾。 请开始生成：

注意：在提示词中反复强调“完全虚构”、“无效”、“无意义”是至关重要的。这不仅是给模型的指令，也是在审计层面证明我们生成过程不依赖真实数据的重要依据。

3.2 处理复杂关联关系

单表生成相对简单，真正的挑战在于多张有关联的表。例如，orders（订单表）里有user_id关联user_info.id，order_items（订单商品表）里又有order_id关联orders.id。

我们的策略是分步生成与回溯填充：

先主后子：首先生成主表（如user_info）的数据，并记录下生成的虚拟主键ID列表。

关联提示：在生成子表（如orders）的提示词中，明确加入关联约束。

【关联约束】 - `user_id` 字段的值，必须从以下已有的虚拟用户ID列表中随机选取：[10001, 10002, 10003, ... 10010]。

循环迭代：生成orders后，再将其生成的虚拟订单ID列表作为约束，用于生成order_items。
数据回溯：对于某些需要反查的字段，比如订单总金额应该等于其下所有商品金额之和，我们可以在生成order_items时计算一个总和，然后回过头来更新orders表中的金额字段。这可能需要一个小型的后处理脚本。

3.3 提升数据真实性与复杂度的技巧

要让生成的数据不仅仅是“合规的垃圾”，而是“有用的虚构数据”，需要一些技巧：

引入业务规则：在提示词中加入业务逻辑。例如，“订单状态为‘已支付’时，pay_time必须晚于create_time”；“商品库存stock不能为负数”。
模拟数据分布：不要总是均匀分布。可以指示模型：“城市分布请大致符合一线城市30%、二线城市50%、其他城市20%的比例”；“用户年龄呈正态分布，集中在25-40岁”。
生成文本类字段：对于商品描述、用户反馈等文本字段，可以要求模型生成“通顺但无实际意义的短句”，用于测试前端显示和搜索功能，例如：“这是一款用于测试的商品描述，其材质轻盈且功能多样，适用于多种测试场景。”
处理枚举值：将数据库中的枚举类型（如status: (‘pending’， ‘paid’， ‘shipped’， ‘cancelled’)）明确列在提示词中，让模型从中选择。

4. 系统实现与工程化细节

4.1 从提示词到可执行代码

我们构建了一个Python的核心生成类。以下是一个高度简化的示例，展示核心思路：

import json import random from typing import Dict, List import requests # 假设使用HTTP API调用混元 class DataGenerator: def __init__(self, api_key: str, base_url: str): self.api_key = api_key self.base_url = base_url self.headers = {'Authorization': f'Bearer {api_key}', 'Content-Type': 'application/json'} def build_prompt(self, table_schema: Dict, record_count: int, constraints: List[str] = None) -> str: """根据表结构构建提示词""" prompt = f"""你是一个专业的测试数据生成器。请严格遵循以下要求生成虚构的、符合中国常见业务场景的测试数据。 【表结构信息】 1. 表名：`{table_schema['name']}` 2. 字段定义： """ for field in table_schema['fields']: prompt += f" - `{field['name']}`: {field['type']}, {field['comment']}\n" prompt += f""" 【生成要求】 1. 生成数量：{record_count}条。 2. 数据格式：请以纯JSON数组格式输出。 3. 数据质量：所有数据必须完全虚构，敏感信息符合格式但无效。 """ if constraints: prompt += "4. 关联约束：\n" for c in constraints: prompt += f" - {c}\n" prompt += "\n请开始生成：" return prompt def call_llm(self, prompt: str) -> str: """调用混元大模型API""" payload = { "model": "hunyuan", # 模型名称 "messages": [{"role": "user", "content": prompt}], "temperature": 0.7, # 控制随机性，0.7能平衡创造性和一致性 "max_tokens": 4000 } try: response = requests.post(f"{self.base_url}/chat/completions", json=payload, headers=self.headers, timeout=60) response.raise_for_status() result = response.json() return result['choices'][0]['message']['content'] except Exception as e: print(f"API调用失败: {e}") # 这里应实现重试机制 return None def parse_and_validate(self, llm_output: str, table_schema: Dict) -> List[Dict]: """解析模型输出并进行基础校验""" try: data = json.loads(llm_output.strip()) except json.JSONDecodeError: # 有时模型输出会包含额外解释，尝试提取JSON部分 # 这里可以写更健壮的提取逻辑，比如用正则匹配第一个`[`和最后一个`]` print("解析JSON失败，尝试清理输出...") return [] validated_data = [] for record in data: valid = True for field in table_schema['fields']: fname = field['name'] ftype = field['type'] # 基础校验：字段是否存在、非空（如果要求非空）、类型粗略匹配 if fname not in record and field.get('nullable') == False: valid = False break # 可以在这里添加更多自定义校验函数，如手机号格式、枚举值检查 if fname == 'phone' and record.get(fname): if not self._validate_phone_format(record[fname]): valid = False break if valid: validated_data.append(record) return validated_data def generate_for_table(self, schema: Dict, count: int) -> List[Dict]: """为单表生成数据的主流程""" prompt = self.build_prompt(schema, count) print(f"生成提示词:\n{prompt[:500]}...") # 打印部分提示词用于调试 llm_response = self.call_llm(prompt) if not llm_response: return [] return self.parse_and_validate(llm_response, schema) @staticmethod def _validate_phone_format(phone: str) -> bool: """简单的手机号格式校验（仅格式，不验证号段）""" import re pattern = r'^1[3-9]\d{9}$' return bool(re.match(pattern, phone)) # 使用示例 if __name__ == '__main__': generator = DataGenerator(api_key='your_api_key', base_url='https://api.example.com') user_table_schema = { 'name': 'user_info', 'fields': [ {'name': 'username', 'type': 'varchar(50)', 'comment': '用户名，6-12位字母数字下划线', 'nullable': False}, {'name': 'real_name', 'type': 'varchar(20)', 'comment': '虚构中文姓名', 'nullable': False}, {'name': 'phone', 'type': 'varchar(11)', 'comment': '虚构11位手机号', 'nullable': False}, {'name': 'age', 'type': 'int', 'comment': '年龄18-65', 'nullable': True}, ] } fake_users = generator.generate_for_table(user_table_schema, 5) print(f"生成 {len(fake_users)} 条用户数据:") for user in fake_users: print(user)

4.2 性能、成本与批量处理优化

直接为每张表、每批数据调用API，成本和延迟都不可接受。我们做了如下优化：

批量生成：在提示词中一次性请求更多数据，比如100条甚至500条。混元大模型支持的长文本能力足以应对。这能极大减少API调用次数。
模板与缓存：对于结构固定的表，其提示词模板是固定的。我们可以预编译这些模板，只需替换变量（如生成数量、关联ID列表）。对于枚举值等静态信息，甚至可以缓存起来重复使用。
异步与流式处理：使用异步请求库（如aiohttp）并发处理多张表的数据生成。对于超大批量，可以考虑将任务拆分成多个子任务并行执行。
成本监控：大模型API按Token收费。我们需要估算每次请求的输入输出Token数，并设置每日/每月预算告警。在提示词设计上也要力求精炼，避免冗余。

4.3 数据质量保障闭环

生成的数据不能直接入库，必须经过质检：

格式校验：如前述代码中的手机号、邮箱正则校验。
业务规则校验：编写轻量级规则引擎。例如，检查订单金额是否为正数，优惠券是否在有效期内，收货地址城市是否在配送范围内等。这些规则可以通过一个配置文件来管理。
关联一致性校验：检查外键关联是否存在。例如，所有订单的user_id是否都在已生成的用户ID集合中。这通常在所有相关表数据生成完成后，由一个统一的校验脚本来执行。
抽样人工审核：在初期，对生成的数据进行人工抽样检查，评估其真实性和合理性，并据此迭代优化提示词。

5. 常见问题、踩坑记录与进阶思考

5.1 实战中遇到的那些“坑”

模型“自由发挥”过度：早期提示词不够严格，模型生成了“北京市海淀区腾讯大厦”这种过于真实的地址，或“张伟”这种极高频的真实姓名。解决方案：在提示词中强化“完全虚构”、“无意义”、“随机组合”等指令，并为“姓名”、“地址”等字段提供更具体的虚构规则，例如“姓名请使用不常见的汉字组合”。
JSON格式输出不稳定：模型有时会在JSON前后添加解释性文字，导致解析失败。解决方案：在提示词末尾明确要求“只输出JSON数组，不要有任何其他解释”。并在解析代码中增加健壮性，尝试从响应文本中提取JSON部分。
关联数据生成顺序死锁：A表依赖B表的ID，B表又依赖A表的ID。解决方案：仔细分析业务关系，总有一方是可以先生成的（如用户先于订单）。对于环状依赖，可以分阶段生成：第一阶段生成所有基础实体（用户、商品），第二阶段生成关联实体（订单），第三阶段生成关联详情（订单商品）。
生成效率瓶颈：对于有数百万条数据需求的压测场景，完全依赖大模型生成成本太高。解决方案：采用“混合生成”策略。基础、规律性强的数据（如ID、时间戳、状态码）用脚本批量生成；只有需要复杂逻辑、文本描述或高度仿真的字段（如用户名、商品标题、用户评论）才调用大模型生成。

5.2 与“小米屏幕共享隐私保护”的联想

这个热词给了我们一个很好的产品化启示。小米的屏幕共享功能，是在数据展示层实时进行隐私保护。我们的数据生成方案，是在数据供给层提前完成隐私保护。两者可以结合：

我们可以开发一个“数据安全预览”功能。当开发或测试人员通过工具查询测试数据库时，系统可以对接大模型，对查询结果中仍未脱敏的少量特殊字段（如AI生成的模拟评论中的偶然敏感词）进行实时二次擦除或替换，实现双保险。
其技术本质都是“识别敏感模式 -> 应用保护策略”。小米识别的是屏幕上的文本框、头像框；我们识别的是数据表中的字段语义和内容模式。