小北_Coder手记

双卡张量并行最省心，量化掉精度换速度不划算，我们7B直接上两张4090稳得很。

这问题我踩过类似的坑，大概率不是缓存的事。你提到Agent拆子查询，我怀疑是ReAct的推理路径把检索范围带偏了，尤其当历史对话里有旧关键词时，新文档的向量就算索引重建了也不容易被选中。建议你先单独测一下直接向量检索新文档能不能命中，排除chunk和overlap的问题，然后再看Agent的prompt里有没有限制检索范围。另外Milvus如果开了分区的，确认新数据是不是写进对了分区，我之前就是分

2000条数据确实太少了，LoRA在这种规模下很容易过拟合，建议先用原版模型做个baseline，再考虑加数据或调低学习率。

我之前也遇到过类似的，最后发现问题出在工具描述的格式上，MCP那个schema里如果字段类型写得不严谨，模型特别容易生成非法JSON。建议你把工具描述写得更具体，比如每个参数加个示例值，然后微调数据里多塞几轮连续调用不同工具的例子，单轮的那种模型很难学会切换。另外后处理可以加个强制解析，如果输出不符合预期就直接回退到最接近的合法调用，别指望模型自己改对。

这问题我太有同感了，7B模型对指令的“宽容度”确实比GPT低不少，尤其量化后更是如此。感觉它更吃精确的动词（比如“提取”“删除”），而且少给点背景反而更能聚焦。我试过把任务拆成两步，先让它列要点再扩写，效果比一步到位稳很多。你试试把“输出格式”换成几个具体的例子喂给它，比写一堆规则管用。

50万这个量级其实不算大，问题大概率出在特征本身而不是索引。ResNet50直接出的特征向量分布很稀疏，高维空间里距离区分度本来就差，建议先试试PCA降维到256维再重新建索引，召回率会有明显提升。另外nprobe调大只是暴力搜，治标不治本，可以考虑换HNSW索引，配合ef参数效果比IVF好很多。粗排精排这个思路是对的，但前期先用faiss的IVFPQ做粗筛，后面接个重排序模型就行，比直接硬怼Mi

我也遇到过类似的情况，当时也是拿CodeLlama-7B微调做内部DSL的代码生成，500条数据，跑完一看，生成的代码里多了很多重复的import和莫名其妙的空行，逻辑上也有点退化。后来排查了一圈，感觉问题可能出在几个方面。 首先500条数据对于LoRA微调代码生成来说确实偏少，尤其是你想让模型“学会”新的API调用风格，而不是仅仅记住几个模式。LoRA本身参数量不大，但核心是它只修改了低秩矩阵