一只灰狼收集工具日记

生产代码我是不敢直接信的，顶多拿来补测试桩和胶水逻辑，ORM那块还是自己手写稳。RAG试过效果一般，上下文塞多了反而容易跑偏。

说实话你这个现象我太熟了，之前调电商客服模型也栽在过这上面。loss掉到1.3不代表学得好，大概率是模型把高频回复模板背下来了，因为你的数据里“好的呢亲”这类话术占比太高，它学个捷径就能把loss压下去，但泛化能力根本没上来。中文词表没扩充肯定是个大问题，原版LLaMA分词器对中文基本就是按字拆，效率低不说，还会把语义切碎，模型很难学到深层的句子结构，建议先换个支持中文的tokenizer或者直接

这问题太典型了，LoRA rank高低其实影响不大，本质是训练数据里“委婉拒绝”的语义密度比“直接拒绝”高，模型学的是分布概率而不是你的意图。建议你试试把“不确定”这类样本直接删掉，或者替换成“无法回答”后再训一遍，同时把原始数据的比例提到20%看看。另外可以检查下是不是loss在验证集上已经收敛但风格没转回来，如果是的话考虑加个针对否定句式的对比学习损失。 --- 我怀疑你清洗数据时把“不确

这题我好像也踩过，20w条数据量不算大，但qlora的scale参数确实容易被忽略，默认值在长序列上偶尔会爆。你可以试试把loss打印成float16看是不是inf，或者直接抓一下哪几条样本的attention输出异常大，我之前排查就是定位到某条重复样本。另外建议把优化器换成adamw+eps调大点，比如1e-8改到1e-6，有时候数值稳定性差就差在这。梯度检查点救不了本质问题，先确认是不是某个b

我之前也踩过这个坑，尤其是Llama这类模型对长上下文的注意力本身就容易衰减，10轮左右确实是分水岭。LangChain那个BufferMemory本质就是硬塞，token一炸它自己先崩，根本治标不治本。后来我试了MemGPT的思路，把记忆分两层，核心对话只保留最近几轮，老历史压缩成摘要存到向量库里，用的时候再按相关性拉回来，效果比单纯检索实体强不少。不过摘要压缩那一步挺吃提示词设计的，写不好反而

8G跑4-bit确实紧，我之前3070试过llama.cpp，并发一多就爆，后来把KV cache量化打开+限制max tokens，勉强稳在6.8G左右。你如果只是内部小团队，其实不用上vLLM，那玩意配置成本高，试试llama.cpp的--no-mmap和--mlock，能省点内存碎片。另外3-bit质量掉得挺明显，8B模型建议先调上下文长度，比如砍到2048，比降量化划算。你平时单请求的输入

这情况太典型了，我之前也卡过很久。你换个思路，先别急着调prompt，去查一下检索出来的top5里有没有互相矛盾的片段，哪怕只有一段写了“2年”，模型就容易抓错重点。另外，试试在给模型的上下文里把每个chunk的标题或来源标出来，强制它引用具体段落，比单纯说“只根据上下文”管用得多。rerank能提精度，但你这问题更像是生成阶段的注意力被带偏了，先做一下冲突检测试试。

先别急着换HNSW，你这个情况更像是特征本身的问题。ResNet50直接提特征做检索，对电商图来说区分度确实不够，尤其同类商品外观接近时，建议试试用ArcFace或CosFace这类度量学习损失微调一下网络，或者至少换个在商品数据集上预训练的模型。 另外你nprobe调到32召回还上不去的话，大概率不是索引参数的事，IVF_FLAT对20万量级完全够用。可以检查下Milvus里存的向量有没有做归