用户研究增长记

T4这卡确实瓶颈在显存带宽上，16G看着够用但7B fp16的权重读取太吃带宽了，首token慢很正常。我之前试过把max_model_len调小到2K，吞吐能上来一些，但你要先确认业务场景能不能接受这个长度限制。量化的话int8基本不影响效果，可以先试AWQ或GPTQ，4bit确实会掉点但代码任务影响不大，建议直接看下lmdeploy的AWQ方案，配T4效果比vLLM稳。还有个小技巧，把KV c

说实话你这个量级真不太建议直接上GraphRAG，2万份文档的实体关系图谱构建和更新够你们三人团队喝一壶的，而且会议纪要这种非结构化文本提取关系很容易翻车。我自己试过类似场景，先把Chunk size调到256加50%重叠，再上一个强点的reranker比如bge-reranker-v2-m3，召回率能提升不少，关键是调参成本低。另外你提到跨段落问题，可以试试给chunk加个摘要前缀或者用pare

这问题我太有同感了，纯向量检索在记忆场景里就是会这样，语义相近但时间久远的片段干扰特别大。你光调阈值确实不行，我后来是把时间衰减直接做成一个加权因子乘在相似度分数上，效果立刻好了很多。另外chunk切割千万别按固定长度，最好按对话轮次切，每轮完整保留，不然语义本来就散的片段检索出来更乱。你可以试试先粗筛再精排，比如取top50后用时间权重重排，比单纯调阈值灵活多了。

同感，这块真的挺头疼的。我最近也在折腾RAG，试过256、512、1024几个档位，感觉没有绝对“最稳”的数值，完全取决于文档类型和检索场景。 你提到的“切片太大不精准，太小丢上下文”我深有体会。比如技术手册里经常有“参数A=10”这种关键信息，用512切片检索时，如果参数刚好在切片边界附近，很容易被切丢；但用1024切片吧，新闻稿那种全文重复性高的内容，检索出来的top3可能全是同一段废话。

说实话看到2.3的loss一直下不去，我也遇到过类似的情况，特别能理解这种卡住的感觉。我自己的经验是，2.x对于微调7B模型来说确实偏高，正常微调后loss一般能降到1.5甚至更低（看任务复杂度），所以肯定是有问题的。 不过我倒觉得未必是rank值的问题，8对于LoRA来说不算太小，尤其数据量只有2万条的情况下。我反而想追问一下数据这边：你提到每条100-200 tokens，那每条数据里问题和