2025年高频两个刺猬面试题及答案

2025年高频两个刺猬面试题及答案在大模型微调过程中，遇到样本类别不均衡且计算资源有限的情况下，如何设计微调策略以提升目标任务效果？首先需明确问题核心：类别不均衡会导致模型偏向多数类，资源限制（如GPU显存、训练时长）要求策略具备参数效率。以医疗领域的病理图像分类任务为例，假设正样本（罕见病）占比仅5%，负样本（常见病症）占95%，且可用资源为单张A100GPU（40GB显存），需设计兼顾效果与效率的微调方案。第一步是数据层优化。传统过采样易导致过拟合，需结合智能采样与数据增强。对少数类采用SMOTE（合成少数类过采样技术）提供新样本时，需注意医学图像的特殊性——直接插值可能破坏病理特征，因此可改用基于扩散模型的条件提供（如ControlNet引导提供符合病理结构的新样本），提供后通过领域专家人工校验确保有效性。对多数类采用欠采样时，需保留多样性，可通过K-means聚类选取各簇中心样本，避免丢失关键特征（如常见炎症的不同阶段表现）。同时引入多模态数据增强：对图像进行局部遮挡（如随机擦除非病灶区域）、颜色空间变换（模拟不同设备的成像差异），文本描述（若有标注）采用回译（中→英→中）或基于小模型的同义替换（如将“轻度水肿”替换为“轻微组织液渗出”），增强模型对特征的泛化能力。第二步是模型层适配。全参数微调在资源有限时不可行（如LLaMA-7B全参数微调需约28GB显存），应选择参数高效微调（PEFT）方法。优先尝试QLoRA（量化低秩适配器）：将预训练模型权重4位量化（降低显存占用约60%），仅训练低秩适配器（秩r设为8-16，可训练参数占比＜1%），同时冻结预训练层。针对类别不均衡，可在适配器层后添加类别感知模块：在注意力机制中引入类别权重，对少数类样本的注意力头分配更高权重（如通过可训练的门控参数调整各头输出的融合比例）。若任务为分类，输出层改用FocalLoss替代交叉熵，通过调节γ（建议γ=2）降低多数类易分类样本的损失贡献，提升少数类难分类样本的学习权重。第三步是训练策略调整。采用分层训练：初期冻结底层特征提取层（如大模型的前1/3层），仅训练顶层适配器与输出层（减少计算量），待损失稳定后解冻部分底层（如中间1/3层），用更小学习率（如1e-6）微调，避免破坏预训练的通用特征。学习率调度采用warmup+余弦衰减，warmup步数设为总步数的10%，防止初期训练不稳定。批大小受限于显存，可采用梯度累积（如累积4步相当于批大小×4），但需注意累积过程中梯度噪声可能影响训练稳定性，可配合梯度裁剪（范数≤1.0）。第四步是评估与优化。传统准确率无法反映不均衡问题，需重点监控F1-score（平衡精确率与召回率）、AUC-ROC（衡量分类器区分能力）及混淆矩阵中的少数类召回率（Recall）。若少数类召回率不足，可尝试：①在验证集上做类别加权的早停（如早停指标=0.7×少数类F1+0.3×多数类F1）；②引入自训练（Self-Training）：用当前模型对无标注数据中的高置信度样本（如概率＞0.95）打标，补充少数类样本；③模型融合：训练多个不同种子的QLoRA模型，对预测结果做软投票（概率加权），提升稳定性。落地时需注意：若推理环境显存受限（如边缘设备），可对微调后的模型做进一步压缩——将适配器与预训练模型合并后，进行8位量化（如使用GPTQ），或通过知识蒸馏（用微调后的大模型作为教师，训练小模型学生），在保持90%以上效果的同时降低计算量。例如，某医疗AI公司在皮肤癌分类任务中，通过上述策略将少数类（黑色素瘤）的F1从0.62提升至0.81，训练时间从72小时缩短至12小时（单卡A100），推理延迟降低40%（量化后）。在微服务架构中，当核心交易链路需要同时满足强一致性与高可用性时，如何设计分布式事务方案？需结合具体业务场景说明实现细节与权衡点。以电商平台的“下单-扣库存-支付”核心链路为例，用户下单需同时创建订单、扣减库存、锁定支付额度，要求这三个操作要么全部成功，要么全部回滚（强一致性），同时系统需支持高并发（如大促期间QPS10万+），传统XA协议因长事务锁等待易导致性能瓶颈，需设计混合方案。首先明确业务特性：订单创建（O）、库存扣减（S）、支付锁定（P）三个服务独立部署，存在网络分区可能（CAP理论中的P必然存在）。强一致性要求O、S、P的状态最终一致，但高可用要求在部分节点故障时仍能响应（避免全局锁）。需权衡CA中的A（可用）与C（一致），实际采用“最终一致性+补偿机制”，但关键步骤通过同步确认实现强一致。方案设计分三阶段：1.前置校验阶段（强一致检查）：用户提交订单时，先通过库存服务预检查可用库存（S.check(sku_id)），支付服务预检查可用额度（P.check(user_id)）。这两步需同步调用，且结果在短时间内（如5秒）有效。为避免超卖，库存服务需维护“已锁定库存”字段，预检查时计算可用库存=总库存-已锁定库存-已销售库存。若检查通过，提供预订单（O.pre_create），状态为“待确认”，并记录校验时的库存版本号（如Redis中的CAS版本）、支付额度版本。此阶段通过同步RPC调用保证检查的实时性，但若任一服务不可用（如库存服务宕机），需快速失败并返回“库存不足”，牺牲部分请求的可用性以避免后续不一致。2.事务执行阶段（柔性事务+同步确认）：预校验通过后，进入正式执行。采用TCC（Try-Confirm-Cancel）模式，但针对关键步骤优化：Try阶段：订单服务：创建正式订单（O.create），状态为“处理中”，记录库存版本、支付版本。库存服务：锁定库存（S.lock(sku_id,num)），将“已锁定库存”增加num，使用CAS（Compare-And-Swap）保证原子性（如Redis的INCRBY并校验不超过总库存）。若CAS失败（说明预检查后库存被其他请求修改），返回失败，触发Cancel。支付服务：锁定额度（P.lock(user_id,amount)），同样使用CAS操作（如数据库乐观锁，更新可用额度=可用额度-amount，where可用额度≥amount）。若失败（额度被其他交易占用），触发Cancel。Confirm阶段：若Try全部成功，订单服务发送Confirm消息：库存服务：扣减锁定库存（S.confirm(sku_id,num)），已锁定库存-=num，已销售库存+=num。支付服务：扣减锁定额度（P.confirm(user_id,amount)），可用额度-=amount，已使用额度+=amount。订单服务：更新订单状态为“已支付”。Cancel阶段：若任一Try失败（如库存锁定CAS失败），订单服务发送Cancel消息：库存服务：释放锁定库存（S.cancel(sku_id,num)），已锁定库存-=num（需幂等设计，防止重复调用）。支付服务：释放锁定额度（P.cancel(user_id,amount)），可用额度+=amount（同样需幂等）。订单服务：更新订单状态为“失败”。3.补偿与监控阶段（解决异步失败）：TCC的Try/Confirm/Cancel均通过消息队列（如RocketMQ）异步执行，但可能存在消息丢失或服务超时。需设计：幂等性保障：每个操作携带全局唯一事务ID（如UUID），服务端通过Redis或数据库记录已处理的事务ID，重复请求直接返回成功。超时重试：消息队列设置重试策略（如指数退避：1s、3s、10s、30s），最多重试5次。若仍失败，触发人工介入（如将事务ID写入死信队列，由运营后台手动处理）。状态校验：订单服务定时（如每5分钟）扫描“处理中”状态的订单，调用库存、支付服务查询当前锁定状态。若库存已锁定但支付未锁定，触发Cancel；若两者均锁定但超过支付超时时间（如30分钟未支付），触发Cancel并释放资源。分布式链路追踪：通过OpenTelemetry记录每个操作的调用链，包括时间戳、服务节点、返回状态，便于快速定位失败节点（如库存服务在第3次重试时因数据库慢查询超时）。权衡点分析：一致性与性能：TCC的Try阶段通过CAS保证了库存和支付的原子操作，避免了长事务锁（对比XA的全局锁，TCC的锁仅在Try阶段短暂持有），提升了并发能力。但Confirm/Cancel的异步执行可能导致短暂不一致（如用户看到订单已创建但库存未扣减），需通过前端状态提示（如“库存确认中”）降低用户感知。可用性与复杂度：引入消息队列和重试机制提升了系统可用性（部分服务短暂故障时可重试），但增加了开发复杂度（需处理幂等、重试、状态机）。实际落地中，可使用成熟的TCC框架（如Seata）减少代码量，但需根据业务特性调整（如Seata的AT模式默认使用全局锁，不适合高并发场景，需切换为TCC模式）。成本与可靠性：定时任务和链路追踪增加了服务器资源消耗（如扫描订单的定时器需单独部署实例），但相比人工排查故障的成本更低。某头部电商的大促实践显示，该方案可支持QPS15万+，事务成功率99.98%，故障恢复平均耗时从30分钟缩短至5分钟（通过自动重试和链路追踪快速定位问题）。关键实现细节：库存服务的CAS设计：使用Redis的INCRBY和WATCH命令实现原子锁定。例如，Lua脚本：```lualocallocked=redis.call('HINCRBY','stock:'..sku_id,'locked',num)localtotal=redis.call('HGET','stock:'..sku_id,'total')iflocked>totalthenredis.call('HINCRBY','stock:'..sku_id,'locked',-num)return0-锁定失败elsereturn1-锁定成功end```支付服务的乐观锁：数据库表设计中增加version字段，扣减时：```sqlupdateaccountsetavailable=availableamount,version=versio