一线知识管理手记

ResNet50在电商图这种细粒度场景确实有点吃力，尤其同款不同角度，它更偏语义而不是纹理细节，可以试试CLIP或DINOv2这类自监督的，或者直接用电商场景微调过的模型。还有你L2距离配1024维有点吃亏，维度高的时候余弦相似度通常更稳，不妨归一化后换IP试试。另外topK设100有点大，噪声会拉低召回，先降到10到20看看真实分布再说。

我最近也在踩这坑，后来加了个“记忆摘要”层，定期把旧对话压缩成要点再存，冲突时用新指令覆盖旧标签。

vllm的sampling参数和生产环境可能不一致，先检查下temperature、top_p这些是不是默认值，我之前也踩过这坑。

试试Qwen2.5-7B的GPTQ-Int4，中文比Llama强不少，3060跑着也稳。

正常，AI就爱自作主张加依赖，我一般直接删掉换标准库，跑不通再考虑装。

步骤越多模型越容易在中间跑偏，我一般控制在4步以内，关键节点给个约束。

KV cache确实是大头，你每轮把完整历史塞进去，等于KV cache随轮数线性膨胀，3090的24G显存扛不住很正常。滑动窗口是最省事的做法，但别硬切，建议保留系统提示词加最近N轮，N按你显存实测调，一般3到5轮够用。摘要压缩我也试过，用同一个小模型做滚动摘要，效果比想象中好，关键是把实体和结论显式保留下来，别让它自由发挥。vLLM的PagedAttention对KV cache碎片化帮助很大

这个我倒是有类似感受，不过可能跟你的情况稍微有点不一样。我用Cursor写Go的时候，它确实也倾向于把很多东西往一个函数里堆，尤其是接口实现那块，动不动就给你来一大坨，看着就累。后来我发现了，它其实是在模仿你项目里已有的模式，如果你一开始让它生成的时候没给特别明确的约束，它就会默认往“能跑就行”的方向优化，而不是往“好维护”的方向。我现在一般会在.cursorrules里写清楚函数长度上限和模块拆

改需求时最好把原函数贴回去让它只改那一行，不然它真会自由发挥。

你这个切块方式对API文档来说有点粗暴了，500字很可能把一个类的方法和它的说明拆到不同块里，检索出来自然驴唇不对马嘴。我之前做类似的事是把类当单位切，方法级别再单独建一层索引，查询时先定位类再拉方法，召回准确率提升挺明显的。还有个坑是bge对代码和API名称的语义匹配本来就偏弱，试试给每个块加上类名和方法签名的前缀，或者干脆用混合检索加BM25兜底。

DDP的loss曲线奇怪大概率是梯度同步或者学习率没跟着卡数调，我刚开始也踩过这坑，建议先把batch size和lr按线性缩放试试。如果单卡只是显存不够、模型不算超大，其实DDP加gradient checkpointing就够用了，没必要一上来就DeepSpeed。DeepSpeed的ZeRO确实省显存，但配置门槛对新手不太友好，可以先拿Hugging Face Trainer跑通，它内部能直

85%这个数其实不算差了，但卡着上不去确实挺让人难受的。你有没有想过问题可能不在检索这一层，而是在切分策略上？我之前也遇到过类似的情况，后来发现是chunk切得太碎，导致每个片段的语义信息不完整，embedding再强也表达不出来。另外bge-m3虽然强，但它对长文本的处理跟短query之间可能存在语义空间不对齐的问题，你可以试试在入库前对chunk做个摘要或者标题增强。还有个容易忽略的点是Mil

我之前也踩过这个坑，后来干脆把所有工具都包一层 Promise 适配器，callback 和事件监听都用 promisify 转掉，这样调度层只认一种接口就清爽多了。依赖关系我用简单的 DAG 加拓扑排序排执行顺序，超时统一用 Promise.race 兜底，不至于卡死。不过 MCP 这边有没有官方推荐的编排中间件我也挺好奇的，感觉现在都是各写各的轮子。

PyTorch写顺手就别折腾了，TF2也就那样，面试问框架不如多刷两道题。

vLLM默认gpu-memory-utilization是0.9，加载完权重后KV cache会直接把剩下的显存全占了，你3090跑14B AWQ权重就占7G左右，剩下全被cache吃掉当然发不出请求。把utilization降到0.7-0.75，max-model-len设成4096或8192试试，别一上来就拉满。还有确认下你AWQ是不是真4bit，有些标AWQ的其实是fp16伪量化，那14B光

先别急着上reranker，把PDF表格和标题单独提取出来再切，这种技术手册直接按字符切肯定丢上下文。

我也碰到过类似情况，512字切分对中文长对话确实容易把语义切碎，尤其项目进展这种连续叙事。建议先试试改成按对话轮次或者带重叠的滑动窗口切分，成本最低。另外text2vec对“上周”这种时间指向性其实很弱，光靠embedding肯定不行，可以考虑在召回时加个元数据过滤，按时间范围先筛一遍再向量检索。至于时间衰减，我觉得可以作为排序的辅助信号，但别全押在上面，核心还是先解决分段和混合检索的问题。

我最近也在折腾Cline，同样踩过这个坑。后来发现它其实会读当前打开文件的内容，但不会主动去翻整个项目，所以我在prompt里会明确写“请先查看utils.py里的函数，优先复用已有方法”，效果会好不少。另外你可以试试把项目结构或者核心模块的接口说明放在CLAUDE.md里，它每次对话都会带上，比临时去读文件稳定。MCP那个方案我也试过，能读全项目但上下文容易超载，建议只给关键目录权限就行。

`--max-num-seqs`确实得手动设一下，vLLM默认会按显存余量尽量多塞请求，并发一高KV cache就把显存吃满了，我之前跑13B模型也踩过这坑。AWQ 4bit本身占用不大，问题大概率出在调度策略上，你可以试着降到8或者4看看，再把`--max-num-batched-tokens`也限一下。另外动态batching本身就会放大显存波动，建议压测时观察下KV cache的峰值，别光看

我们生产环境是单独部署了embedding服务，MCP server通过内部HTTP调用，向量库的client SDK也封装在MCP server里，但对外只暴露一个search工具。tool和resource我个人觉得语义搜索用tool更合适，因为resource更适合静态内容的按需获取，而检索本身是带参数的动作。返回chunk不统一的问题，可以在工具定义里要求模型必须返回结构化JSON，再在s