暮色敲键盘集
Lv.1把零散灵感沉淀为可复用的方法，关注技术学习与数字生活，记录持续成长、方法总结和真实实践中的思考；关注技术选择背后的成本与边界。希望这些经验能帮你少踩几个坑。
发表的评论
我之前也遇到过类似问题，后来换了方案。
写得挺好，建议补充一些性能数据。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
温度0.7配top_p0.9其实已经挺飘了，尤其是你还要求结构化输出，这俩参数叠在一起就是在鼓励模型自由发挥。我自己做类似工具时会把温度压到0.2以下，top_p干脆设成1，格式稳定性会好很多，代价是文案稍微死板一点。另外你说的“时好时坏”很可能不是Prompt本身的问题，而是输出被截断或者模型在长上下文里注意力漂移了，可以试试把字段要求写成JSON schema那种硬约束，再配合function
我们之前也踩过这个坑，A100 80G跑Qwen2.5-7B用vLLM，并发一上去TTFT确实会飙，后来发现主要卡在prefill阶段的调度上。建议你先别急着上4卡TP，TP的通信开销在2秒延迟目标下未必划算，反而2卡各跑一个实例加个前置负载均衡更稳。AWQ 4bit我们测过知识库问答场景，掉点其实还好，大概1-2个点，但吞吐能翻不少，性价比挺高的。你们并发峰值大概多少？如果是几十路以内，单卡调好
两张4090跑7B LoRA按理说不该这么容易炸，你先把batch_size真正压到1、max_length砍到512或768试试，很多人OOM其实是序列长度在吃显存。还有gradient_checkpointing一定要开，能省不少激活值，代价就是慢一点，但比OOM强。4bit量化loss偏高挺常见的，compute dtype设成bf16、double quant打开，再确认下target_m
分块策略比换模型更关键，建议先按语义切再调top_k。
文档一多模型就抓不住重点，建议先做重排再塞进prompt，不然全是噪音。
batch size 4 在 2048 序列长度下 OOM 挺正常的，QLoRA 省的是模型权重显存，激活值该占还是占。gradient checkpointing 基本必开，能帮你把激活显存压下来一大截，再配合 gradient accumulation 把有效 batch 凑上去就行。代码补全和对话微调差别不小，代码那边序列更长、loss 更集中在局部 token，学习率通常可以低一点，epo
几万份PDF单机跑，说实话pgvector加HNSW索引完全够用了，你数据量还没到非要上Milvus的程度。Chroma慢主要是它默认索引和持久化方式不太适合大批量，换Qdrant会轻不少，docker一条命令就起来，性能也比Chroma稳。我这边类似规模的知识库就是用Qdrant配bge-m3，召回和延迟都挺满意。除非以后要上亿级向量或者多租户，不然pgvector省运维省心，别折腾太重的。
先别急着加rerank，查一下切分粒度，长文本切太粗embedding确实会偏泛。混合检索值得试，BM25对关键词命中帮助挺大。
写代码我一般temperature压到0.2左右，top_p基本不动，开源模型改prompt比调参管用多了。
你贴的报错是加载checkpoint时shape对不上，跟模型定义其实没关系。检查一下你保存权重的时候是不是用了DataParallel或者多卡训练，那样fc2.weight会多出一个卡数的维度，恢复时得用`model.module.load_state_dict`或者去掉`module.`前缀。另外你标题里说Linear(128,10)，但报错期望的是64，这俩数字对不上，建议先把实际打印的模型
我们线上也是bge-m3加faiss那套，top-k拉20再精排是比较稳的。bge-reranker直接用就行，不用纠结cross-encoder，它本身就是。粗排召回20-50，精排取前3-5给LLM，基本能压住废话。另外去重和按段落切比关键词加权更管用，可以试试。
PDF技术手册这种文档，bge-m3其实已经算挺能打的了，但召回不稳大概率不是embedding的锅。你切块512/128对说明书类文档偏大了，很多参数表、步骤说明被拦腰截断，关键信息散在两三个chunk里，换问法就出来说明语义匹配本身没大问题，是粒度问题。建议先试试按标题层级或段落结构切，别死磕固定长度。rerank可以先上bge-reranker-v2-m3，跟bge-m3同源，性价比高，能明
Markdown文档建议按标题切，别硬卡字数，代码块单独拎出来处理，效果会稳很多。