效率工具手记

分块策略确实值得再调调，512个token对技术文档来说可能太长了，尤其“卡纸”这种关键信息埋在段落中间，embedding会被其他内容稀释。我之前试过按标题和章节切，再配合小窗口重叠，效果提升很明显。另外中文长尾词确实容易吃亏，text-embedding-3-small对专业术语的语义理解有限，建议你拿几个典型问题对比一下，看看是不是某些词压根没被正确向量化。

我最近也在搞类似的，LangChain里加个向量库做长期记忆挺好用的，把每次周报的要点存成embedding，下次生成前先检索相关历史。不过跟你说实话，别指望system prompt全扛，那玩意儿一长就完蛋。我试过用ConversationSummaryBufferMemory，自动压缩旧对话，比手动塞摘要省心多了。你那个工作流具体怎么设计的？Agent是每次重新起对话还是持续会话？

2000条数据做全参微调都够呛，LoRA在这种小数据集上特别容易过拟合，rank=8可能都偏大了。建议先拿原版base模型跑一遍你的测试集，看看哪些问题本来就答不对，再对比微调后的差异，这样能定位是数据问题还是训练问题。另外可以试试只微调Q层或者把学习率降到1e-4，加个验证集早停。你数据里产品名出现频率均匀吗？如果长尾太多，模型很容易把高频词带走。

大概率是切分太粗+没rerank，bge-m3对长段落语义会稀释，先试下滑动窗口切分，再不行就加个bge-reranker，比混合检索见效快。

我最近也踩过类似的坑，vllm的rope_scaling调起来确实容易显存失控。建议先确认下是不是mcp协议层对输入做了额外截断，有些框架会在应用层再套一层tokenizer限制。另外可以试试先不调scaling，单纯把max_model_len设到模型原生支持的极限（比如4K），然后分批处理长输入，虽然慢但至少能跑通。你用的具体是哪个基座模型？不同架构对长上下文的容忍度差挺多的。

这个case我太熟了，去年我带队做代码生成模型微调的时候，踩的坑比你这还深。先说结论：loss卡在1.2下不去，不是LoRA本身的问题，而是你整个训练范式跟“代码翻译”这个任务不匹配。我拆开来讲，结合我实际翻车三次的经历。 首先，2000条数据做代码翻译微调，量其实不算少，但关键是质量。你说的“真实项目代码对”，我猜是从开源仓库里扒的？这里有个致命陷阱：Python和Java的AST结构差异巨大