大模型任务表现差怎么排查？

模型在某类任务上表现差时，我会先把问题变成可复现的失败集合。明确输入、期望输出、当前输出、业务代价和评测脚本，再按来源、长度、难度、语言和失败类型切片。若指标或标签不稳定，任何优化都可能只是追逐噪声，所以先做人工复核和近重复检查。

数据侧要看目标场景是否覆盖、标签是否一致、训练与验证是否泄漏，以及失败样本是否集中在特定模板或时间段。分布漂移可以用特征统计、类别比例、模型置信与真实错误率联合观察。t-SNE适合探索局部可视化，但会扭曲全局距离，不能单独作为样本属于分布外的证据。

系统侧要把基础模型、prompt、检索、工具、后处理和模型本体分开。检索没召回、上下文被截断、格式校验错误，都可能表现为模型能力不足。训练侧检查loss mask、tokenizer、学习率、梯度、checkpoint加载和数据配比，并用少量样本过拟合测试确认实现能学习。

若确定需要微调，就建立可比较基线。LoRA的target modules、rank、alpha、学习率和dropout都是实验变量；更高rank不必然适合复杂任务，解冻norm也不是通用处方。全量微调增加自由度和训练状态，可能改善，也可能过拟合或破坏通用能力，必须放在相同数据与预算下比较。

架构改造只在证据指向容量或信息路径瓶颈时进行。例如长上下文失败要区分位置外推、检索遗漏和prefill成本；结构化输出失败可以先用约束解码与校验。每次实验只改有限变量，并记录目标切片、通用回归、安全与成本，避免局部指标上升却引入其他退化。

最终我会选择能稳定改善真实holdout且成本可接受的最小方案，并保存回滚checkpoint。若多轮微调仍不如检索、规则或产品约束，就停止扩大模型改造。这个流程不需要声称做过某家公司项目，也能完整展示从失败证据到工程决策的方法。

排查优先级应由影响面和可逆性决定。若失败来自错误数据或评测，继续训练只会放大问题；若是后处理或工具接口，可先修系统而不动模型。每个候选修复都要写预期影响的失败桶和停止条件，未改善就回滚。这样能够避免一次改很多超参后无法归因。

若所有切片都没有稳定改善，我会检查题目是否超出当前系统可观测信息，例如输入缺少关键字段或工具没有权限。模型无法从不存在的证据中学习正确答案。此时应调整产品流程或收集信息，而不是继续扩大参数和训练轮数。