长期关注项目管理实践笔记

loss降但F1不升反降，这种事儿我也踩过，大概率不是LoRA本身的锅。你验证集F1比原始模型还低，得先看看是不是过拟合到训练集那1万条的分布上了，尤其客服工单这种短文本，类别之间语义重叠可能很严重，模型很容易靠表面词而不是真实意图去分。3个epoch对LoRA来说不算少，rank=8配2e-4的学习率，如果数据没做分层采样或者验证集跟训练集来源差异大，指标掉下来挺正常的。建议你先固定住原始Lla

我之前也这样，后来刻意每周抽半天不用AI，纯手撸一些核心逻辑，慢慢就找回感觉了。其实关键不是写不写得出来，而是你脑子里还有没有那个设计思路，Copilot给的是实现，方向还得自己把控。限流器这种面试常考的东西，建议还是自己多写几遍，不然哪天真被问到就尴尬了。

在prompt里加一句“只用标准库，输出后立刻停止”，我试过比单纯强调“别加功能”管用。

这个坑我们也踩过，torch.compile 对 ReAct 这种每轮 prompt 结构都在变的场景确实很不友好，graph break 基本是必然的。后来我们的做法是把工具调用和 prompt 拼装都留在 eager 里，只对 LLM 前向那一段固定 shape 的部分做 compile，KV Cache 用手动管理的静态 buffer 去接。动态路由那块别硬静态化，收益不大，反而容易把缓存搞

我一般先把无关代码折叠起来再圈选，它就不太容易乱跑了，你可以试试。

loss降不代表学对了，八成是数据里安全回复太多，模型直接摆烂。查下训练集里“建议就医”这类模板占比是不是偏高。

两万条数据top_k给30确实容易灌噪声，我一般先用相似度阈值卡一道，比如0.3以下的直接扔掉，再限制最多8条。你也可以试试先召回20条然后用rerank模型过一遍，比单纯调top_k稳多了。text-embedding-3-small本身对长文本就一般，切块策略可能比top_k更值得调。

大模型微调这块PyTorch就是亲儿子，TF转权重纯属给自己找活干，部署再另想办法吧。

合同条款这种场景光靠调chunk_size确实很难搞，因为关键信息经常跨段落甚至跨页，切碎了语义就断了。你可以先试试按条款标题做结构化切分，别让固定长度硬切，这个改动成本最低。另外bge-small对长文本和数字类细节本身就不太敏感，换个bge-m3或者加个reranker可能比继续调参见效快，reranker其实不贵，值得试。

你这个问题挺典型的，7B LoRA按理说不该这么吃显存，先检查下是不是梯度检查点没开，或者优化器用的还是Adam全量状态。单卡24G跑seq 1024、batch 2理论上够用，除非你还开了flash attention之外的额外缓存。DeepSpeed ZeRO-3对单卡意义不大，分片省的是多卡间的冗余，单卡上反而多一堆通信开销。如果手头有第二张卡，FSDP确实更省心，跟PyTorch原生集成好

loss正常但输出乱码，八成是推理时没加chat template或eos token没对齐。

本地部署和API版确实有差别，API那边通常做了后处理或对齐调优，本地裸模型更容易“放飞”。回答偏长和免责声明多，八成是system没压住，可以试试把system写得更具体，比如限定字数、指定输出格式，比“请直接回答”这种泛泛指令管用。温度别急着调，先固定0.3左右排除随机性，重复输出往往是top_p或重复惩罚没设好。建议去扒一下ChatGLM3官方finetune仓库里的prompt示例，比网上

我之前也踩过这个坑，全塞上下文确实不行，token一多模型注意力就散了。我现在的做法是短期记忆用滑动窗口加摘要，每轮任务状态单独维护一个结构化的state，长期偏好才丢向量库按需检索。关键点是别让向量库管当前任务状态，检索出来的东西太碎了反而干扰模型。可以看看MemGPT或者LangGraph的memory模块，思路挺清晰的。

top-k太多确实容易稀释注意力，建议先压到3再逐步加，同时用query重写把问题聚焦一下。

我也被这问题折磨过，后来改成只圈函数让AI改，别贴整个文件，越界少很多。

可以试试先把向量归一化再用余弦距离，ResNet50直接上L2确实容易翻车。

我们之前也踩过这个坑，A100跑7B量化版并发一高延迟确实顶不住，后来换了双卡张量并行加动态批处理才稳下来。fp8在A100上精度掉得挺明显，意图识别这种任务还是老老实实int8或者awq吧，别为了那点速度牺牲准确率。蒸馏版跟原版差距主要在复杂推理和长尾case上，客服意图这种相对固定的场景其实够用，但得留点badcase兜底策略。

我之前也踩过这个坑，直接拿原始query去搜确实不稳，尤其是口语化的问题。后来改成让LLM先抽关键实体和时间范围，再拼成结构化查询，比如“2023年 公司 营收 财报”，命中率明显好一些。不过改写这块别全交给LLM自由发挥，最好加few-shot示例约束输出格式，不然它容易脑补。另外可以试试混合检索，BM25加向量召回再重排，比单靠改写稳得多。

量化肯定有影响，Q4_K_M跑7B跟在线API的FP16比，指令遵循和格式稳定性会掉一截，这个挺正常的。不过你可以试试在system prompt里把输出格式写死，比如直接规定“只输出文案正文，不要解释，不要分点”，比单纯强调角色管用。另外7B本地模型对few-shot的敏感度比在线大模型高，示例最好控制在2-3条，太多反而容易学乱。任务拆细确实有用，先让它生成标题再单独写正文，比一步到位稳。

这个问题我觉得根子不在检索参数，而在Agent每轮都重新检索、没有把上一轮结论锚定住。可以试试把首轮命中的chunk id和结论写进state，后续轮次强制复用或只做增量校验，别让它自由发挥。投票也行，但得先保证多路召回的是同一份query改写，不然票也是散的。记忆压缩适合长对话，对结论一致性帮助有限。