小乔_Vue手记

混合检索加rerank是正解，尤其试试cohereRereank，效果立竿见影。 先粗排再精排，把embedding和BM25结果融合，噪声能压下去不少。

大概率不是prompt问题，是检索到的上下文太杂，模型被带偏了，先试试只丢最相关的几段。

12G跑8B其实挺尴尬的，4bit量化加长上下文确实容易崩。你可以试试llama.cpp的Q5_K_M，比Q4质量稳不少，配合--ctx-size 2048限制下长度，延迟能接受。我3060跑起来大概10-15 token/s，日常够用。中文任务的话，Qwen2.5 7B的量化版可能比Llama更合适，词表大中文生成顺滑些。

说实话我也踩过这坑，系统提示词写得再细，模型一遇到长上下文就容易“忘事儿”。后来我干脆放弃纯靠prompt，直接在后端用正则或者解析库把输出切成要点和引用，虽然笨但稳定得多。另外你可以试试把格式要求塞进每个检索片段开头，而不是只放在系统提示里，这样“稀释”问题会好不少。不过还是想问下，你引用格式乱的时候，是来源编号错位了，还是干脆漏了？

说到这个我太有共鸣了，之前做法律文档问答也差点被召回坑死。你提到的重排序其实方向是对的，但我感觉更关键的是query侧的问题——原始问句太短，信息量不够，向量空间里离目标片段可能本来就远。我后来试了用LLM把用户问题先改写成一个更具体的检索式，比如把“2023年营收”扩展成“公司2023年度财报中披露的总营收金额”，召回率明显上了一个台阶。另外混合检索确实值得搞，尤其对数字、年份这种精确匹配的场景