企业官网建设流程全解析

简介：第六届中国研究生人工智能创新大赛华为专项赛的赛题详情文档，面向备战的研究生团队与指导教师，也适合关注工业视觉检测、广告推荐算法的技术读者研读。文档共17页，围绕两道赛题展开：赛题一聚焦未知无规则缺陷图像检测，要求在小样本、低参数量、少模型数量的约束下完成已知与未知缺陷的分割与分类，指标以IoU为主；赛题二针对样本稀疏场景下的数值类预测，讨论正负样本比例悬殊、转化延迟与新广告冷启三类难题下的CVR预估方案。文中给出逐条具体要求、竞赛得分与专家评分的权重分配、咨询专家邮箱、MVTec AD与天池等参考数据集，以及ReConPatch、EfficientAD、PLE、ESMM等参考文献，便于据此确定技术路线与实验设计。压缩包仅含1个docx文件，体积576KB，轻量易取，已有189人学习。

1. 从一份赛题清单说起：七道题为什么要一起看

去年帮某高校实验室整理一份研究生人工智能创新大赛专项赛题的应赛方案，七道题摆在会议室白板上，从工业缺陷检测到对话模型安全对抗，跨度大得像七个不相干的领域。负责人问的问题却很朴素：这些题里，哪一道我们的团队能在两个月内交出一份评委挑不出硬伤的方案？赛题详情文档真正的价值不在题目名称，而在它把每道题的样本条件、参数量上限、评分权重、提交物清单都写成了硬性约束。很多人拿到这份清单，第一反应是挑一道看着最眼熟的题冲进去调模型，最后卡在占分更重的专家评审那一栏，因为方案里没有一个能自证的设计闭环。下面按七道赛题拆一套能照着搭的骨架，从选型地图到视觉与非视觉两条实现路径，再到怎么验收答辩。

2. 赛题地图与选型判断：七道题归成三条技术主线

七道题看上去各管各的，真按“输入是什么、输出是什么、约束卡在哪”这三件事过一遍，其实只有三条主线：图像域的检测与识别、结构化数据的预估、以及围绕大模型的系统工程。分类的目的不是写进文档好看，而是决定你的团队该复用哪套代码骨架、该在哪一步就把算力预算算清楚。

2.1 七道赛题的分类与共同约束

先把七道题的约束拉平看。下表按任务形态整理了每条主线对应赛题的核心限制与主要评价指标，注意最后一列——它决定了你方案文档的章节顺序，而不是反过来。

看这张表会发现一个共性：七道题里没有一道是纯粹比精度的。参数量、模型数、单图耗时、迁移成功率，这些“次要指标”在所有赛题里都是硬门槛。方案设计的核心矛盾因此变成同一件事——在受限预算下把精度顶上去，而不是在无约束条件下刷榜。想清楚这一点，后面所有架构决策才有依据。

2.2 选型的三个判断标准

选哪道题，我一般让团队按三个维度打分，每个维度一分到五分，总分低于十的直接放弃，别硬撑。

第一个是数据可得性。赛题提供的是少量真实正负样本，还是只给一个公开参考数据集的下载地址？前者意味着你要把大部分工期花在数据增强和合成上，后者意味着你要先花两三天把数据格式吃透。这两类工作的性质完全不同，前者是算法活，后者是工程活，别混着排期。

第二个是评测口径是否明确。有的赛题把指标公式写死了，比如攻击类赛题直接给出“最终得分 = 攻击成功率 + 1.5 × 迁移成功率”，这种题你能在本地把分数算得和线上一致，迭代方向不会偏。有的赛题只写“考察泛化性”，那就要在方案里自己造一套验证集，用自建指标兜底，否则你根本不知道自己改的那一版是进步还是玄学。

第三个是团队的算力与人力结构。带 NLP 背景的团队去做缺陷检测，前两周基本全耗在数据管线上；反过来，做视觉的团队去碰智能体规划，会在 Prompt 结构和工具检索上反复翻车。这不是能力问题，是路径依赖。选择与既有代码积累重合度最高的那道题，等于白送两周工期。

提示：三条都打完分后，把得分最高和次高的两道题各花半天做一次最小可跑验证——跑通数据加载、跑出一个基线分数、跑通提交格式。半天之后你会对“这题好不好做”有完全不同的判断。

2.3 提交物清单与工程骨架

几乎所有赛题都要求同一组东西：模型代码、方案说明文档、在公开测试集上的结果、以及某种形式的可解释性材料。差别只在于比例——有的赛题专家评分权重高到六成，有的把打榜成绩压到五成。这意味着工程骨架要在第一天就按“可复现”来搭，而不是最后一周补文档。

我的习惯是仓库根目录下固定五个文件夹：data/放原始数据与生成脚本，models/放网络定义，train/放训练与验证入口，infer/放提交格式的推理脚本，docs/放方案文档与图表。每个入口脚本只接受一个 YAML 配置作为参数，所有超参、路径、模型变体都写在配置里。这样做的直接好处是，评委按说明文件跑你的代码时不会因为硬编码路径而报错，而“代码规范性/可复现性”在人工评审里是明确列出的评分项。

配置结构大致是这样，字段名不重要，重要的是它把“哪份数据、哪个模型、多少轮、什么尺寸”全部外置了：

# configs/detection_base.yaml data: root: ./data/raw # 原始样本目录 split: ./data/split.json # 训练/验证划分，固定随机种子后生成 image_size: 256 # 训练分辨率，推理时按需调整 augment: strong # 增强策略档位 model: backbone: lightweight_cnn # 轻量骨干，注意参数量预算 feature_dim: 256 coreset_ratio: 0.1 # 正常样本特征保留比例，直接决定内存占用 train: epochs: 60 batch_size: 16 lr: 0.0005

这份配置里有两个参数值得单独说。coreset_ratio控制特征记忆库保留多少正常样本特征，它直接线性影响推理时的内存占用和单图耗时，是小样本异常检测里最容易被忽略的预算旋钮。image_size则同时影响精度和速度，很多方案在 512 上训练、在 256 上推理，精度掉得比预想多，因为缺陷在工业图像里往往只占几十个像素，降采样一次就糊了。通常的做法是在验证集上把几个尺寸各跑一遍，把“精度-耗时”曲线画出来再定，而不是拍脑袋取一个。

3. 视觉类赛题落地：小样本缺陷检测与细粒度识别的一条共用管线

图像方向的三道题（缺陷检测、猫狗细粒度识别、图像质量评估）表面任务不同，底层管线却高度重合：读图、缩放、增强、特征提取、在受限模型体积内做判别。把这条管线搭一次，三道题都能改出来。这一章只讲前两道，质量评估放到下一章，因为它的输出来自回归而非判别。

3.1 数据管线：从少量真实样本到可用训练集

小样本场景下，数据管线的设计权重比模型结构还高。赛题给的少量真实正负样本，直接拿去训一个判别网络，基本必然过拟合——网络会把背景、光照、甚至相机噪声当成类别特征学进去，测试集一换就崩。常规做法是建立三级数据源：真实样本、几何与光度增强样本、以及从公开数据集合成的伪缺陷样本。

增强不是为了凑数量。缺陷检测里有效的增强集中在几类：随机旋转与镜像（应对姿态多样）、局部亮度与对比度扰动（应对光照漂移）、以及把缺陷区域裁剪后贴回正常背景的合成方式（应对缺陷位置随机）。后者需要一张粗略的掩码，如果赛题没给掩码，可以用简单的阈值分割粗提，精度要求不高，因为合成样本只用于预训练阶段，最终微调仍在真实样本上做。

细粒度识别那道题的数据问题刚好相反：品种分类有公开数据可用，个体识别却没有现成的大规模标注，需要自己构造样本对。样本对构造的关键是难负样本挖掘——如果随机从不同个体里抽两张图组成负对，网络很快就能靠背景颜色区分开，学不到真正的个体特征。有效做法是按品种、毛色、拍摄场景做分层抽样，优先构造“同品种不同个体”和“同一个体不同姿态”这两类难对，让网络必须依赖细节特征。

# 构造难负样本对：同品种优先，避免网络走背景捷径 import random from collections import defaultdict def build_hard_pairs(records, n_pairs, same_breed_ratio=0.7): by_breed = defaultdict(list) for r in records: by_breed[r["breed"]].append(r) pairs = [] for _ in range(n_pairs): if random.random() < same_breed_ratio: # 同品种内取两个不同个体，构成难负对 breed = random.choice(list(by_breed.keys())) pool = by_breed[breed] a, b = random.sample(pool, 2) if a["id"] == b["id"]: continue # 同一个体不能当负对 pairs.append((a, b, 0)) else: # 跨品种随机取，构成易负对，用于稳定训练 a, b = random.sample(records, 2) pairs.append((a, b, int(a["id"] == b["id"]))) return pairs

这段代码里same_breed_ratio是控制难度分布的核心参数，取 0.7 意味着七成负对来自同品种内部，网络没法靠“这是猫还是狗”这种粗特征蒙混。id字段是个体标识，必须保证同一只宠物在不同照片下的 id 一致，否则整个训练目标就错了。实际项目里这一步通常需要人工校验一批，因为自动聚类出来的 id 常常把相似个体合并成一个。

3.2 异常检测模型的分层结构

未知缺陷检测的难点在“未知”两个字：训练时只有正常样本，测试时可能冒出训练集中从未出现的缺陷类型。这就排除了常规的分类思路，只能用“先学正常、再把偏离正常的判为异常”的范式。工程上比较稳的结构是三层：特征提取骨干、正常样本特征记忆库、以及基于距离的异常打分与分割。

骨干选轻量的，因为参数量是明确评分项。特征提取时不做全局池化，而是保留 patch 级特征图，因为最终要输出分割结果，需要空间分辨率。记忆库阶段把全部正常样本的 patch 特征聚成一个子集，用 coreset 方法把冗余特征剔掉，只保留有代表性的那批。推理时对每个测试 patch 特征找最近邻，用距离作为异常分数，再上采样回原图尺寸得到分割图。

import torch import torch.nn.functional as F class PatchMemoryDetector: def __init__(self, backbone, coreset_ratio=0.1): self.backbone = backbone.eval() self.memory = None # 形状 [N, C] 的正常特征库 self.coreset_ratio = coreset_ratio @torch.no_grad() def fit(self, normal_loader): feats = [] for imgs, _ in normal_loader: fmap = self.backbone(imgs) # [B, C, H, W] patch 级特征 b, c, h, w = fmap.shape feats.append(fmap.permute(0, 2, 3, 1).reshape(-1, c)) feats = torch.cat(feats, dim=0) # 随机子采样作为 coreset 的轻量替代，数据量大时换成 k-center 贪心 keep = max(1, int(len(feats) * self.coreset_ratio)) idx = torch.randperm(len(feats))[:keep] self.memory = F.normalize(feats[idx], dim=1) # 归一化后才能用余弦距离 @torch.no_grad() def predict(self, img, topk=3): fmap = self.backbone(img) # [1, C, H, W] c = fmap.shape[1] q = F.normalize(fmap.permute(0, 2, 3, 1).reshape(-1, c), dim=1) sim = q @ self.memory.T # 余弦相似度矩阵 top = sim.topk(topk, dim=1).values.mean(dim=1) # 取前 k 个近邻平均，抗噪 score_map = (1 - top).reshape(fmap.shape[2:]) # 双线性上采样回原图分辨率，得到分割结果 return F.interpolate(score_map[None, None], size=img.shape[-2:], mode="bilinear")

这段代码里有两个设计选择值得说明。特征做了 L2 归一化，是为了让余弦相似度替代欧氏距离，前者对特征幅值不敏感，跨批次更稳。topk取 3 而不是 1，是因为单个最近邻容易被噪声特征带偏，取前几个的平均能压掉这类离群点。coreset_ratio直接决定内存占用，工业场景下正常样本可能上万张，全存特征会爆内存，实测 0.05 到 0.1 之间精度损失很小。

3.3 轻量化与推理效率的平衡

模型体积和单图耗时是白纸黑字的评分项，很多方案精度刷得漂亮，最后栽在这两项上。轻量化的手段无非几条：换小骨干、剪通道、量化、以及推理侧的批处理与并行。前三条改模型，后一条改流程，而流程改造通常收益更高、风险更低。

先说量化。训练后动态量化把权重从 fp32 压到 int8，体积直接降到四分之一，精度损失在分类和检测主干上一般在零点几个点。麻烦在于有些算子不支持量化，转换后推理变慢，所以量化后必须重新测一遍单图耗时，不能只看体积。剪枝要谨慎，非结构化剪枝虽然能砍掉大量参数，但实际推理速度取决于硬件是否支持稀疏计算，多数情况下体积降了、速度没变，属于看着好看但没用的指标。

推理侧并行是赛题明确提到的加分项。图片之间相互独立，完全可以多进程或多流并行，把吞吐拉上去而不影响单图延迟。做法上，读图和前处理丢进一个进程池，模型推理放在主进程按批凑齐后一次前向，写结果再异步落到文件。

# 推理批处理：把零散请求凑成固定 batch，提高吞吐 import torch def batch_infer(model, image_paths, batch_size=8, device="cpu"): results = [] with torch.no_grad(): for i in range(0, len(image_paths), batch_size): chunk = image_paths[i:i + batch_size] imgs = torch.stack([preprocess(p) for p in chunk]).to(device) scores = model.predict(imgs) # 摄像头场景下按批前向 results.extend(to_submission(chunk, scores)) return results

batch_size要按设备内存和延迟要求调，赛题要求报单张耗时的话，批处理反而会让单张统计口径变复杂，所以更稳妥的做法是同时记录“批处理总耗时 / 图片数”和“单张端到端耗时”，两个数都写进说明文档。这是在答辩时能救命的细节：评委问“你报的 12 毫秒是怎么测的”，你能立刻答出测量口径，而不是含糊过去。

注意：体积和速度不是一回事。赛题里两个指标分开计分，别用“我参数量小了所以速度快”这种推导去写文档，必须有实测数据支撑，两类数据分开列表呈现。

4. 非视觉类赛题落地：稀疏转化预估、智能体规划与质量评分

剩下几道题分布在完全不同的技术栈上，但工程方法论是一致的：先把任务拆成“表示、决策、评估”三层，再逐层找受限条件下最省的实现路径。

4.1 稀疏正样本与延迟反馈的建模

转化率预估那道题给出了一组很直观的数字：正负样本比例能到一比一万。这个比例下，直接训一个二分类器，模型会倾向于把所有样本判成负例，因为这样损失最低。这不是模型能力问题，是目标函数和任务目标不匹配。

通用解法是多任务建模：把“曝光到点击”和“点击到转化”拆成两个子任务，共享底层特征，用点击任务的稠密样本来帮转化任务学表征。这样即使转化样本极少，底层嵌入仍有足够的梯度信号。延迟反馈的处理思路是把“还没转化”和“确定不转化”区分开——前者只是观察窗口不够长，硬当负例是在教模型学错东西。工程上通常引入一个时间衰减权重，或者用一个小的辅助网络建模转化延迟分布，训练时按期望转化概率给样本加软标签。

import torch import torch.nn as nn class ShareBottomCVR(nn.Module): def __init__(self, feat_dim, emb_dim=64): super().__init__() self.bottom = nn.Sequential( # 共享底层，喂给两个任务 nn.Linear(feat_dim, 256), nn.ReLU(), nn.Linear(256, emb_dim), nn.ReLU(), ) self.ctr_head = nn.Linear(emb_dim, 1) # 点击头，样本稠密 self.cvr_head = nn.Linear(emb_dim, 1) # 转化头，样本稀疏 def forward(self, x): h = self.bottom(x) ctr = torch.sigmoid(self.ctr_head(h)).squeeze(-1) cvr = torch.sigmoid(self.cvr_head(h)).squeeze(-1) return ctr, cvr def esmm_loss(ctr_pred, cvr_pred, click, convert, delay_weight): bce = nn.functional.binary_cross_entropy loss_ctr = bce(ctr_pred, click) # 只在点击样本上监督转化头，未点击样本不参与 mask = click > 0.5 if mask.sum() == 0: return loss_ctr loss_cvr = bce(cvr_pred[mask], convert[mask], weight=delay_weight[mask]) return loss_ctr + loss_cvr

代码里delay_weight是关键参数，取值来自“样本产生到观测截止的时长”——观测窗口越长，越有把握把未转化判为真负例，权重越接近 1；窗口短的样本权重压低。mask那一行体现的是全空间建模的基本约束：没有点击就谈不上转化，转化头只在点击样本上有监督信号。把这两个细节写进方案文档，往往比多刷零点几个点的指标更能说明你理解这道题在考什么。

4.2 智能体工作流：工具检索与多步规划

智能体那道题的规模约束很明确：工具池上千个，需要多步甚至并行的设备操控规划，还要能应对没见过的工具。直接把这些工具描述全部塞进 Prompt，上下文长度先爆炸，模型的工具选择准确率也会随候选数上升而下降。

标准结构分两段：检索加规划。检索阶段把用户 query 编码成向量，在工具描述库里做召回，取前若干个候选；规划阶段把候选工具的结构化描述喂给模型，让它输出结构化的动作序列。工具描述必须结构化——名字、功能、参数、前置条件、副作用，缺一项都会让模型在生成参数时瞎猜。

# 工具检索：先用向量召回压候选，再交给模型做规划 def retrieve_tools(query, tool_index, topk=8): q_vec = tool_index.encode(query) # query 向量化 scores = tool_index.search(q_vec, topk * 3) # 多召回一些，留过滤余量 # 按设备类型与权限过滤，避免召回不可执行工具 return [t for t in scores if t["available"]][:topk] PLAN_PROMPT = """你是设备控制规划器。可用工具： {tools} 用户请求：{query} 请输出 JSON 动作序列，每步包含 tool、params、depends_on。 无法完成时输出 {{"error": "原因"}}，不要编造工具。"""

topk取 8 左右是个经验值，太多会淹没模型注意力，太少可能漏掉正确工具。depends_on字段用来表达步骤间的依赖，并行分支就靠它来标识——这是多步规划里最容易被简化掉、又最影响得分的地方，因为很多方案的输出只是顺序列表，无法表达“这两步可以同时做”。

评估数据集的自建要求同样值得花时间。一千条以上的用例，每条至少要有 query、期望工具序列、期望参数、是否可完成这四列。构造时按能力维度分层：单步单设备、单步多设备、多步串行、多步并行、以及无法完成需要拒答的场景。最后一类最容易被忽略，但恰恰是评委会重点看的泛化能力。

4.3 图像质量评估的多维度打分

质量评估那道题的特殊之处在于输出不是类别也不是框，而是与主观评分对齐的连续值，而且要求分五个维度独立打分。评价指标用两个相关系数：衡量线性相关性的 PLCC 和衡量秩序一致性的 SROCC，两者都逼近 1 才算好。

这类任务上，传统方法与深度方法各有优势。传统指标计算快、无需训练，但对 GAN 类失真和真实退化场景不敏感；深度方法精度高，但容易在跨数据集时掉点。比较稳的策略是做特征级融合：把多个传统指标的输出作为额外通道，和深度特征拼接后一起回归。这样模型至少不会比最好的单传统指标更差，同时保留深度特征的拟合能力。

import numpy as np from scipy.stats import pearsonr, spearmanr def evaluate_iqa(pred, mos): pred, mos = np.asarray(pred), np.asarray(mos) # PLCC 前先做单调映射，消除尺度差异带来的偏差 fitted = np.polyfit(pred, mos, 3) mapped = np.polyval(fitted, pred) plcc = pearsonr(mapped, mos)[0] srocc = spearmanr(pred, mos)[0] return {"PLCC": round(plcc, 4), "SROCC": round(srocc, 4)}

这段代码里最容易被省略的是那个三次多项式拟合。PLCC 衡量的是线性相关性，但模型输出的尺度与主观分数天然不一致，直接算会把分数压得很低。做一次非线性映射再算 PLCC 是这类评测的标准处理，写进方案文档能避免评委质疑指标口径。另外注意推理必须走 CPU，赛题对这一点有明文约定，别在说明文件里写错。

5. 避坑与排查：五个让方案在复现环节翻车的细节

做过几轮这类比赛方案之后，我发现大多数扣分不是模型不行，而是方案在复现和自洽上出了岔子。下面五条是出现频率最高的，每条都按现象、原因、解法写清楚，遇到时直接照着排查。

第一条：本地分数漂亮，换设备跑崩。

现象是自己机器上验证集指标稳定，按说明文件换一台机器启动，第一轮就报显存不足或者结果完全对不上。原因多半是训练和推理走了两条代码路径，验证时用的是训练框架内的评估函数，提交时另写了一份推理脚本，预处理细节悄悄变了——归一化均值不同、插值方式不同、颜色通道顺序不同。解法是把预处理收敛成一个函数，训练、验证、提交三条路径全部调用同一个实现，并在文档里写明输入尺寸、归一化参数、通道顺序。这条看起来低级，但真的是血泪经验，我见过不止一个队伍在这一步丢分。

第二条：增强把标签一起变了。

现象是检测类任务训练 loss 正常下降，验证分割 IoU 却卡在很低的水平不动。原因是增强库里对图像和掩码用了不同的随机变换，图旋转了九十度、掩码没转，网络学到的是错位的监督信号。解法是图像与掩码共用同一个随机种子和同一组几何参数，只在图像上做光度变换。更稳妥的做法是写一个小脚本，随机抽几张增强后的样本把图和掩码叠在一起可视化，肉眼看一遍，比读十遍文档管用。

第三条：模型数量悄悄超了预算。

现象是方案里写“使用单一模型”，实际推理链路里跑了骨干、检测头、后处理分类器三个网络，参数量和体积统计时只算了骨干。原因是多人协作时各自的模型定义分散在不同文件，没人做总量核对。解法是在仓库里加一个统计脚本，遍历所有参与推理的模块，把参数量和存储文件大小加总输出，每次提交前跑一遍。这类自动核对脚本写一次能用到底，属于典型的后悔药。

第四条：自建评估集和训练集串了。

现象是智能体或代码生成类赛题自建评估集上准确率奇高，专家评审一测就掉。原因是构造评估用例时顺手复用了训练用的工具定义和模板，评估集和训练分布高度重叠，测出来的只是记忆能力。解法是评估集按能力维度分层抽样，并在构造阶段就留出一部分“训练时从未见过”的工具或模板作为留出集，单独报一组分数。方案文档里把这两组分数分开列，比只报一个高分更有说服力。

第五条：指标口径和赛题给的不一致。

现象是方案里报的攻击成功率、迁移成功率，和按赛题公式算出来的对不上。原因是理解偏差——有的队伍把迁移成功的样本也算进基础成功率里重复计数，有的把变体数和用例数搞混。解法是把赛题给的公式原样抄进代码注释，写一个单元测试用几个手算的例子验证实现正确，再开始跑实验。公式类的东西一旦口径错了，后面所有调优都是在错误的方向上努力。

6. 验收与答辩：把评分权重翻译成一份自检清单

到了收尾阶段，最有效的动作不是继续调模型，而是把赛题的评分表摊开，逐项问自己“这一条我拿什么证据支撑”。七道赛题里专家评分普遍占到四成到六成，考察的是新颖性、合理性、泛化性这些没法自动打分的东西，而它们全部要靠文档里的证据说话。

我一般的做法是建一张三列的自检表：评分项、我的支撑材料、材料在文档的第几节。第一列直接抄赛题原文的评分维度，不改写、不合并，因为评委就是按这张表打分的；第二列写具体到文件名的证据，比如“参数量对比表”“公开测试集逐类结果”“迁移实验记录”；第三列是导航，让评委能在三十秒内翻到对应位置。填不满的行就是你的短板，工期还有余量就补，没余量就在文档里主动说明局限，别留空。

答辩环节还有一个容易被忽视的技巧：把可解释性材料做成能当场演示的东西。缺陷检测类赛题明确要求说明“模型哪些关键节点对哪些缺陷特征产生价值”，纯文字描述很难让人信服，做成一张热力图叠加在分割结果上，配一句“模型关注区域与人工标注掩码的重合度是多少”，说服力立刻不一样。同理，智能体类赛题把失败案例也放进演示里，说明哪类 query 会拒答、为什么拒答，比只展示成功案例更能体现方案边界清楚。

最后是复现环节的心理准备。评委按你的说明文件跑代码，最怕遇到的是“跑不通但不知道哪一步错”。所以说明文件里除了正常流程，我会额外写一节常见故障：依赖版本、数据集目录结构、预期运行时长、以及每个阶段该看到什么输出。这一节花不了半小时，但它决定了评委对你的第一印象是“这人做事靠谱”还是“又一份跑不起来的代码”。

从那以后我每次交方案前，都强制走一遍“换台机器从零跑通”的流程，哪怕时间再紧也不跳过——因为真正让方案翻车的从来不是模型不够新，而是那些你以为不会出问题的地方。希望这套结构能帮到你。

本文还有配套的精品资源，点击获取