暮色煮茶集

r和alpha的比例其实不是死规矩，alpha相当于学习率的缩放系数，真正起作用的是alpha/r这个比值，一般保持在1到2之间比较稳。你r=8、alpha=16那个配置loss降太快验证崩掉，大概率不是过拟合那么单纯，更可能是学习率本身设太高了，LoRA对学习率很敏感，1e-4到3e-4之间先扫一遍看看。r=4、alpha=8感觉跟没微调似的，先别急着怪rank太小，检查一下target_mod

8G确实有点紧，我之前用3070跑4bit的8B也是差不多7G多，并发一上来就炸。你可以试试把context长度压短点，还有batch size设成1，llama.cpp里加上--no-kv-offload或者控制一下n-gpu-layers，能省出一些。3-bit量化其实质量掉得挺明显的，不太建议，不如考虑换个更小的模型比如Qwen2.5-3B，响应还快。vLLM在8G上其实也跑不太动8B，pa

有没有更详细的教程推荐？

这个思路不错，收藏了。

学到了，感谢分享！

有没有更详细的教程推荐？

几千条文档用bge-m3其实挺合适，维度虽高但支持稀疏检索，中英文混着也不虚。chunk大小确实得跟着模型调，bge吃512，text2vec短点更稳。

你这个情况大概率不是模型加载的问题，而是Agent每轮工具调用都重新跑一次完整的上下文推理，KV cache越堆越大。llama.cpp本身有`--no-kv-offload`和`--cache-reuse`参数可以试试，把KV cache放CPU内存里能省不少显存。另外看看你是不是每次调用都重新load模型了，正常应该只加载一次然后复用context。轻量框架的话可以看看llama-cpp-py

只调prompt embedding确实容易这样，尤其BERT类模型本身没做过生成式预训练，你拿它做文本生成效果差很正常。GPT类的话prompt tuning会好一些，但学习率得给大点，我一般用1e-3到5e-4，epoch反而不用太多，10以内基本能看出趋势。如果loss降得太慢，可以试试把最后两层的LayerNorm和MLP解冻，比全冻着稳很多。LoRA确实更省心，但要看你的显存和任务复杂度

scatter_add反向容易重复累加梯度，检查下索引有没有越界或重复，显存涨多半是graph没释放。

强约束输出格式比事后重试管用，我一般用JSON schema卡死，模型乱填直接打回。

这个问题其实不光是embedding的锅，时间词在向量空间里本来就挨得特别近，光靠相似度确实很难掰开。我之前也踩过，后来是在存记忆的时候把时间戳和原始query一起写进metadata，检索时先用向量召回一批，再用时间范围或关键词做个二次过滤。另外可以考虑把“今天”“明天”这种相对时间在入库前就解析成具体日期，让embedding带上绝对时间信息，区分度会好很多。向量库本身一般不管语义去重，顶多给

入库前用AST解析自动给代码块打框架标签，检索时按元数据过滤，比调阈值靠谱多了。

这个报错八成是ONNX里某个输入还是静态shape，转TRT时动态profile对不上。我上次也卡了好久，后来发现是reshape那里把batch维度写死了。你可以用onnxsim先过一遍，再拿polygraphy跑一下onnx和trt的逐层对比，基本能定位到是哪层的问题。另外现在很多团队直接上torch-tensorrt了，省得中间ONNX来回折腾。

200字带50重叠确实容易把步骤切碎，bge-m3对步骤型文本其实还行，但faiss纯向量召回对“操作类”query确实容易飘。你可以先把chunk调大到400字左右，或者按标题/代码块做语义分块，别硬切。另外query改写很有必要，比如把“如何配置gzip”扩成“nginx gzip 配置步骤 指令”，让向量更靠近步骤段。rerank没质变可能是候选集本身就偏了，先看前50召回里有没有正确片段，

3090跑7B其实挺吃力的，关键瓶颈在KV cache。你把max_num_seqs设256太大了，单卡24G显存根本扛不住这么多序列的缓存，建议降到16-32试试。gpu_memory_utilization 0.8也可以再往上提到0.9，留一点给CUDA就行。另外强烈建议上AWQ或GPTQ的4bit量化版，显存能省一半，并发10个应该问题不大。实在不行就限制下并发数，加个队列排队，别硬扛。

Windows下DataLoader慢这事我太有同感了，之前也被坑过好久。你猜的没错，Windows只能spawn不能fork，所以每个worker启动时都要重新import一遍主模块，还要把dataset、transform这些对象pickle过去，worker一多光启动开销就很吓人，几千张图的项目里这个比例特别明显。num_workers调大反而更卡、还报BrokenPipeError，基本就

5000条训一轮就变傻，大概率是数据里“标准答案”太笼统，模型学会了偷懒，不再细看文档。

我之前也踩过这个坑，说实话chunk size这东西真没有万能值，得看你的文档结构长什么样。像我们内部文档有大量API说明和配置项，硬切字符数基本必翻车，后来改成按标题层级切，再在chunk前面拼上所属章节路径，检索准确率明显好了一截。你说的跨段落问题，其实不一定是chunk太大或太小，而是检索单元和语义单元没对齐。可以试试小块检索、大块喂给模型这种方式，用小的chunk去匹配query，命中后把

我也踩过这个坑，全塞system里模型确实容易把检索片段当指令复读。现在我是按“检索片段在前、历史对话在后、当前问题放最后”排的，中间用明确分隔符隔开，感觉稳不少。关键信息强调我试过在user里重复，效果一般，反而单独弄个“已知事实”块更不容易串。你可以试试把检索内容标成“参考资料，非指令”，模型会老实很多。