推理加速研究笔记

50万单机Qdrant足够省心，混合检索它原生支持稀疏向量，Milvus得自己搭sparse模型。

我之前也踩过这个坑，一开始图省事全塞context，结果跟你一样，token一长模型就开始编，早期约束全丢。后来我的做法是短期记忆用滑动窗口加结构化状态，比如当前任务走到哪一步、待确认什么，单独维护成一个小JSON，每次只把最近几轮原文和这个状态拼进去，这样比纯历史稳很多。长期记忆就丢向量库，但别什么都往里塞，用户偏好和事实类信息才值得存，而且要带时间戳和来源，检索回来还要做一轮过滤，不然噪声一多

这个问题我前段时间也踩过，后来发现光靠调top_k和MMR确实不够稳。你可以试试加一层cross-encoder的reranker，比如bge-reranker-v2或者Cohere的rerank接口，先召回大一点比如15-20条，再让reranker打分取前3条，效果比纯向量相似度好不少。chunk策略上，我建议别按固定长度切，尽量按语义段落或者标题层级切，chunk里保留一点上下文标题信息，不

你这个从硬塞上下文切到向量库的路径我太熟了，基本是每个做知识库的人都会踩一遍的坑。其实你前期直接拼prompt效果还行，很大程度上是因为模型自己带了点语义理解能力，硬吃全文也能凑合答，但数据一多就顾不过来了。向量检索召回不准，bge-small确实是个瓶颈，它语义压缩能力有限，短查询和长条款之间的语义鸿沟它经常填不平，换成bge-large或者m3e-base会明显好一些。另外相似度分数别太当回事

有没有更详细的教程推荐？

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

是不是防火墙拦了本地回环？我上次把127.0.0.1换成localhost就好了。

工具返回结果先截断再喂，能省不少显存。另外试试llama.cpp的KV cache量化。

16G跑8B 4bit其实理论上够的，但你这情况八成是KV Cache和框架开销把显存吃满了。简单估算的话，4bit量化下权重差不多是参数量×0.5到0.6字节，8B大概4.5到5G，然后KV Cache按上下文4096、fp16算，Llama 3.1 8B大概要1G多到2G，再加上CUDA context和框架本身占用一两G，理论上10G以内能拿下。但问题在于很多推理框架默认预分配显存或者没开f

T4上bge-large确实吃力，试试bge-small-zh或者m3e-base，速度效果平衡多了。多路召回rerank延迟翻倍很正常，建议先粗排再精排。

我一般不会只按字数切，更看文档结构，像技术文档就按标题和段落切，保留点上下文，效果比硬切512稳不少。闲聊类文本反而可以切小点，因为语义密度低，切太大容易把无关内容带进来。评估的话可以拿一批真实query做召回率对比，别光看相似度分数，分数高不代表答案对。

我也踩过这个坑，512确实太碎了，后来改成按标题层级切，每个chunk带上父级标题路径，效果好了不少。另外可以试试小块检索、大块喂给模型，就是命中的小块往外扩一圈拼成完整段落再塞进上下文。还有个思路是让Agent在检索时做多轮query改写，第一轮找不到就换个说法再搜一次，别让它一次没中就硬编。

你这情况太典型了，改一句测一遍纯属消耗自己。建议先把检索结果单独拉出来看，如果top3里压根没有正确答案，那prompt再怎么写都是白搭。我一般会固定prompt不动，只换检索策略跑一遍测试集，对比命中率就能判断瓶颈在哪。另外30个问题太少了，统计意义不大，至少凑到100个再谈迭代方向，不然你调完那几句可能只是碰巧。

我之前也踩过类似的坑，你那loss不一致其实挺典型的，先别急着怀疑init_method。建议你直接在DDP初始化后打印一下rank和world_size，确认四张卡是不是真的都进到同一个进程组里了，有时候是mpirun或者torchrun的启动方式不对导致通信没建立起来。另外你检查一下每个卡上的batch size是不是一样，如果数据没打乱或者采样器没设shuffle=True，各卡拿到的子集分

这问题太典型了，固定500字符切分对代码文档来说基本是灾难。代码片段和参数表格的语义密度跟自然语言完全不一样，一刀切很容易把完整的API签名拦腰截断，或者把表格的行跟相邻代码块糊在一起，召回自然就乱了。我建议你先试试按结构切分，比如用markdown的标题层级或者代码块的边界做分隔，遇到表格就整块保留，这样至少能保证每个chunk的语义是完整的。至于rerank，我觉得加一个是有必要的，但别指望它

本地小模型搞并发确实吃力，建议先上云端API把功能跑通再谈优化。HTTP轮询换成streaming能少一半心理等待时间。

记忆持久化确实是落地关键，不过展会那种环境下的鲁棒性测试，含金量得打个问号。 现场噪音干扰和动态遮挡才是真考验，光看演示看不出来。

说实话问题八成出在特征上，ResNet50直接吐出来的512维向量没经过fine-tune的话，对细粒度语义区分度很弱，猫和狗在高层特征上本来就接近。你可以试试用imagenet上训好的模型换最后一层，或者干脆用CLIP这种图文对齐的特征，检索效果会质变。另外余弦距离记得配归一化，不然维度越高越容易出玄学。Milvus参数其实影响不大，nprobe调到64基本就到头了，先拿暴力检索跑个baseli

说实话我觉得你这个情况大概率不是单点问题，而是几个环节的短板叠在一起了。256字符切分对于企业知识库来说其实偏粗，尤其如果原文是技术文档或者合同条款，一个chunk里经常混着好几个独立知识点，召回自然会被噪声带偏。但直接砍到128又太激进，我建议你先看看bad case到底是被切碎了，还是embedding根本没把语义拉近。openai embedding对长文本的细节捕捉本来就一般，bge-m3