大模型应用相关问题记录
1.DPO的缺点是什么？
主要还是依赖于偏好数据，易过拟合，导致OOD问题。
qwen的回答：
数据依赖性高 DPO需要大量高质量的偏好数据进行训练，而这类数据的收集和标注成本较高，限制了其在数据稀缺场景中的应用。
易过拟合偏好数据 DPO在训练过程中容易快速过拟合偏好数据集，导致模型对训练数据分布外的样本泛化能力不足。例如，DeepMind的研究表明其可能生成不可预料的输出。
损失函数设计局限 DPO的损失函数仅通过对比学习增强“偏好”与“非偏好”响应的差异，但未直接约束响应本身的绝对质量。这可能导致模型对两者均赋予较低概率（甚至负值），影响实际效果。
依赖参考模型 DPO需要预训练的参考模型来隐式计算奖励信号，这增加了实现复杂度，且参考模型的质量直接影响优化结果。相比之下，ORPO等算法无需参考模型。
适用范围受限 对于需要复杂策略或长期规划的任务（如多步骤推理），DPO的效果可能弱于基于强化学习的RLHF（Reinforcement Learning
with Human Feedback）方法。泛化能力不足 DPO训练的模型可能过度依赖训练数据的分布，对未见过的输入或复杂场景适应性较差，导致输出不稳定或偏离预期。
总结来看，DPO虽简化了训练流程，但其数据需求、过拟合风险及设计局限性使其在复杂任务和泛化场景中面临挑战。后续改进方法（如IPO、KTO）已尝试通过调整损失函数或引入无参考模型设计来缓解这些问题。
2.怎么判断大模型在某个场景下有没有专业知识
1. 核心能力测试
- 任务准确性：通过具体任务（如文本生成、问答、翻译等）的输出结果，评估模型的逻辑性、流畅度和事实正确性。例如，生成新闻时需清晰阐述事件因果。
- 泛化能力：测试模型在未见过的数据或跨领域场景中的表现，如处理不同主题或语言风格的输入。
- 鲁棒性：通过对抗样本或噪声输入，检验模型对扰动的抵抗能力（如抗干扰性）。
2. 性能指标分析
- 响应效率：测量模型的响应时间（如TP99、TP95），评估高负载下的稳定性。TP99越低，说明服务能为99%的请求提供快速响应。
- 资源消耗：监控CPU、GPU、内存占用率，结合计算效率（单位时间处理数据量）判断部署可行性。
- 长期可靠性：测试模型长时间运行的稳定性及故障恢复能力。
3. 业务适配性验证
- 定制化需求匹配：根据场景特点设计测试用例。例如，客服场景需评估多轮对话连贯性和用户满意度。
- 成本效益：对比模型的性能提升与资源消耗、部署成本的平衡，避免过度追求高指标而忽略实际收益。
4. 主观与客观结合评估
- 人工评分：采用分级打分法（如4分制）对输出质量进行主观评价，覆盖内容准确性、逻辑性、安全性等维度。
- 自动化指标：使用准确率、召回率、F1分数等量化指标，结合任务类型选择合适标准（如文本分类用准确率，生成任务用BLEU）。
5. 安全性与合规性
- 内容安全性：测试模型是否生成有害、偏见或违规内容，确保符合法律法规和伦理要求。
- 隐私保护：验证模型是否泄露训练数据中的敏感信息（如个人信息）。
总结 需结合场景特点选择核心指标（如客服场景侧重响应速度和对话连贯性，内容生成侧重逻辑性和多样性），并通过定量指标+定性分析+业务验证的三维评估方法，综合判断模型是否适配当前需求。
3.GRPO的缺点
其实就是DAPO的改进。
裁剪偏移（Clip-Shifting），促进系统多样性并允许自适应采样；
动态采样（Dynamic Sampling），提高训练效率和稳定性；
Token级策略梯度损失（Token-Level Policy Gradient Loss），在长思维链 RL 场景中至关重要；
溢出奖励塑造（Overflowing Reward Shaping），减少奖励噪声并稳定训练。
1.第一个不同点是DAPO去掉了KL散度的惩罚。这是因为文章认为这种训练生成长思维链的推理模型本身与原来的指令模型生成的内容本身差别就很大，所有不需要减小它们差异的这种限制。
2.另外clip的参数 的low和high是不一样的，也就是对重要性采样（新旧策略生成每个回答的比例）的限制不一样了。
3.GRPO是对每个回答的奖励除以回答中token的数量，然后再不同回答间做一个平均（按照文章的说法是按照样本级别计算目标函数值），而DAPO是对一个问题的所有回答的所有token的奖励求和，再除以总的token做一个平均，另外DAPO还加了一个条件，就是正确答案的数量大于0且小于G，如果G=32，也就是这32个回答不能没有正确答案，也不能全都是正确答案。
4.DAPO使用的是奖励机制，而不是reward model，这是为了防止reward hacking。
4.SFT后不起效怎么办
1. 数据问题排查
- 数据与场景不匹配 检查SFT数据是否覆盖当前场景的典型任务。例如，若目标场景涉及多轮对话的Topic切换，需确保训练数据包含与Session相关和无关的Query样本。若数据分布偏离实际需求，需补充场景特异性数据（如节日活动数据需提前灌入）。
- 数据量与多样性不足 若数据量过少或缺乏多样性，模型可能无法学习到有效模式。建议通过数据增强或引入外部相关数据提升泛化性。
2. 训练参数与方法优化
- 学习率与Epoch调整 学习率过高可能导致训练不稳定，过低则收敛慢；Epoch过多可能引发过拟合（如灾难性遗忘）。建议逐步调低学习率（如从5e-5到1e-5），并限制Epoch数（如3-5轮）。
- 采用参数高效微调（PEFT） 若全参数微调效果差，可改用LoRA、P-Tuning等PEFT方法，既能减少计算开销，又能缓解对通用能力的破坏。
3. 模型能力与场景适配性分析
- 领域过度聚焦导致遗忘 若SFT集中在狭窄领域，可能牺牲通用能力。需权衡领域特化与通用性，或通过持续预训练恢复基础能力。
- 任务复杂度与模型容量匹配 对于复杂任务（如多步骤推理），可能需更大模型或结合RLHF等强化学习方法提升效果。
4. 业务需求与技术路线再评估
- 是否必须使用SFT？ 若场景需求可通过Prompt工程（如Few-Shot示例）解决，则优先避免SFT，以减少资源消耗。
- 模型迭代与回退 若SFT后效果仍差，可回退至基础模型，或结合模型迭代策略（如渐进式微调）逐步适配新场景。
5. 其他潜在原因
- 过拟合与评估偏差 检查验证集是否与训练集分布一致，避免过拟合训练数据。若验证指标波动大，可能需引入早停（Early Stopping）或正则化方法。
- 硬件与实现问题 确保训练框架无Bug，资源（如GPU显存）充足，避免因硬件限制导致训练中断或精度损失。
总结 建议按以下优先级排查：
- 数据质量 → 2. 训练参数 → 3. 模型方法 → 4. 业务适配性 若问题仍存在，可参考文献尝试模型回退或迭代优化。