阿航_Java手记
Lv.1Developer，关注技术原理与工程落地，技术方向以数据工程为主。持续整理业务数据解读、数据清洗与建模和可复用的工程方法；偏爱把复杂问题拆成清晰步骤。
发表的评论
top_k这事儿真没法拍脑袋定死，我自己的经验是先跑个验证集看相似度分布，一般0.7以下的基本就是噪声了，直接砍掉比固定k值稳。另外你提到模型上限，text-embedding-3-small本身维度就低，对长文本的语义捕获一般，建议先按段落切分再检索，别整个文档丢进去，不然top_k调再大也白搭。还有个土办法，把top_k从5到20跑一遍，用BLEU或者人工看几轮答案，选个拐点就行，别迷信什么公
Cursor适合当结对编程的副驾，别让它当主驾，小步验收+给足上下文才是正解。 把需求拆细点再喂给它，别一上来就甩整个模块，diff能小一半。
2e-5对全参微调确实偏高，LoRA能保住通用能力，法律任务效果也不会差太多。
试试把embedding换成bge-small，显存占用能少一半，vLLM配LangChain用0.6.0版本基本不报错。
说实话我觉得你有点被带偏了，1536维和384维在RAG里差距真没网上说的那么玄乎，召回率更多取决于你切块方式和检索策略。PCA降维没必要，除非你向量库查询延迟实在扛不住，否则别折腾。换模型肯定要重新生成全量向量，这个躲不掉，所以建议一开始就定好模型别老换。我项目里基本固定一个模型，只有数据量涨到几千万级才考虑换更小的，动态调整太费劲了。你先用现在的试跑一波，看实际效果再决定，别被理论带节奏。
我之前也遇到过类似情况，4090双卡跑8B用LoRA其实batch size 2+累积4步是够的，但loss抖大概率不是batch的问题，你试试把学习率降到1e-4以下，另外LoRA rank设成16甚至8就够了，32对客服任务有点浪费。长文本平均500 tokens确实吃显存，可以把max length截到384，或者用flash attention省显存。还有个坑是梯度累积步数多了要配合war
有没有更详细的教程推荐？
我个人经验是按章节标题固定切，再配合检索后做个信息合并，效果比纯调大小靠谱。