稳步前行商业成长记

法律文书分类这个场景我踩过类似的坑，两万条数据其实不算少了，BERT-base微调够用，问题大概率不在模型容量上。验证集F1比原模型掉4个点这事挺反常的，你确认过标签质量吗？法律文书里相邻类别边界很模糊，标注一致性差的话模型越训越偏很正常。另外你提到训练集和验证集loss差距拉大，过拟合是一方面，但更可能是验证集分布和训练集不一致，比如按时间划分还是随机划分，这个影响很大。类别不均衡到200条那个

两个few-shot确实偏少，尤其是知识库问答这种对字段完整性要求高的场景，建议加到4-6个，覆盖不同题型和边界情况。不过GPT-4o本身输出就有随机性，光靠prompt很难完全锁死，可以试试把temperature调低到0.2以下看看稳定性有没有改善。另外漏字段的问题，与其在提示词里反复强调，不如在输出格式上做约束，比如要求按JSON输出再解析，缺字段直接报错重试，比靠模型自觉靠谱。语气跑偏的话

7B跑多步工具调用确实容易断片，我拿Qwen2.5-7B试过类似流程，两步以上就开始漏参数或者瞎编工具名。你调temperature和context其实帮助不大，瓶颈在模型本身对function calling的稳定性，换成14B会明显好转但也不是万能药。另外Ollama的默认超时和并发设置也偏保守，可以先把num_predict和请求超时放宽试试，排除是框架卡住而不是模型卡住。真要跑顺Agent

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

学到了，感谢分享！

这个思路不错，收藏了。

这个思路不错，收藏了。

可以先按产品实体把检索结果拆开，再让模型分别抽取后合并，比硬塞给LLM靠谱。

5000条垂直数据其实LoRA够用了，术语胡说八道大概率是数据质量或覆盖度的问题，不是r太小。你把r拉到16或32试试，alpha同步翻倍，同时检查下训练数据里专业术语出现频率够不够。单卡3090全量微调7B基本没戏，除非上QLoRA+梯度检查点，但那样还不如把LoRA调明白。建议先拿500条做消融实验，对比不同r和lora_target的效果，别急着换方案。

量化确实有影响，4bit之后模型对长距离依赖的保持能力会下降，32K是理论上限，实际有效上下文可能就8K左右。你这种跨文件重构，我试过用RAG把相关的接口和工具类一起喂进去，比单丢一个Service类稳不少。不过提示词里最好明确让它先列出要改的变量和import，再动手改代码，不然它还是会漏。

口语化query和制度文档的语义gap确实挺坑的，BGE对“工资啥时候发”这种问法可能真不如query改写来得直接。我一般会先看召回列表里有没有正确文档，有的话就是排序问题，加个rerank基本能救；没有的话就得回头查chunk切分和embedding了。固定200字切确实容易把条文切碎，试试按标题层级切或者加overlap。golden set一定要早点建，拿真实用户问法去测，别自己编问题，不然

你这个情况其实挺常见的，LoRA做FIM类任务翻车不一定说明LoRA本身不行，更可能是任务和数据匹配出了问题。代码补全这种任务对“精确续写”要求很高，基座模型本身在预训练时见过海量代码，你拿10万条数据去微调，反而可能把它原本的分布带偏了，尤其3个epoch对LoRA来说已经不少了，容易过拟合到你自己数据的风格上。另外你挖空的方式如果是固定中间一段，模型可能学到的是“填中间”而不是真正理解上下文，

4000就炸可能是max_model_len没跟rope_scaling对齐，先确认模型原生上下文多大再调。

我一般先做一轮重排，再用一个相似度阈值卡掉明显不相关的片段，剩下的按分数从高到低拼，凑够预算就停。还可以把相邻的chunk合并成一段，减少重复内容占的token。实在拿不准就加个轻量级的小模型做二次筛选，让它判断每个片段跟问题到底相不相关，比单纯调低TopK灵活多了。

你这情况我第一反应就是lists设太少了，20万条数据用lists=100，平均每个簇2000个向量，对高维语义空间来说簇内区分度直接稀释掉了，长尾问题基本就是被大簇吞了。pgvector官方建议是rows/1000以下、sqrt(rows)以上，你这量级可以试试lists=400到800，probes也跟着提到20-50跑个召回对比。另外你用L2配bge有点亏，bge系列是归一化过的，余弦和内积

让它重构前先自己理清接口边界，别全丢给AI，越改越乱是常态。