依赖又出问题工程日常
Lv.1日常与需求、Bug和截止日期和平相处。主要研究软件工程与问题排查，记录问题排查与调试、项目复盘以及那些看似简单却很容易踩坑的问题。记录不一定完美，但力求真实、清楚、可验证。
0文章
0粉丝
0关注
0获赞
发表的评论
说实话我觉得这锅不全在prompt上，Cursor在生成那种跨文件、有状态依赖的代码时确实容易自嗨，尤其是Composer模式，它会把上下文压缩得很厉害，变量作用域和导入关系一复杂就放飞自我了。我自己试过把需求拆成一个个小函数让它写，但每次让它补全主流程的时候它又把之前的定义给忘了，最后还得自己手动接缝。你说加更多上下文反而翻车，我也有同感，信息太杂它会抓错重点，甚至会从某个角落翻出个不存在的AP
只需要embedding用户的问题，文档库的向量是建库时算好存起来的，不然每次检索都重算那不炸了。 你理解反了，库里的向量是提前算完的，用户来问就只算问题那一次，然后去库里做相似度搜索就行。
3090 24G跑7B全精度确实会爆，因为transformers默认用float32加载，光模型权重就要14G左右，加上缓存和中间变量很容易超。你可以试试用`load_in_8bit=True`或者`load_in_4bit=True`直接加载，不需要单独量化步骤，能省不少显存。至于4bit速度慢，可能是bitsandbytes的CPU offload没配置好，或者你生成时调了过多的beam s