实战派自动化开发日志

4bit对7B来说确实挺伤的，尤其你用的是指令模型的话，量化后指令跟随能力掉得最明显。我之前试过Q4_K_M和Q5_K_M对比，5bit那个效果稳不少，体积也就多1G出头，手机上其实还能接受。另外可以看看是不是量化时没保留embedding和output层的高精度，这两块对生成质量影响挺大的。如果实在不行，换个3B左右的模型做全量微调可能比硬压7B更划算。

几百条数据就想改风格，模型不崩才怪，先把数据加到几千条再调调rank试试。

我之前也踩过这个坑，微调完embedding单看相似度确实涨了，但RAG整体反而崩。大概率是你训练数据里正负样本构造有问题，尤其负样本太简单或者太单一，模型学偏了，把通用语义空间搞乱。建议先别急着调参，把微调前后的embedding在同一个测试集上跑一下召回率对比，看看是全面下降还是只在你领域数据上变差。如果通用能力掉了，可以试试加个重排序兜底，或者用LoRA小学习率微调，别动太多底层参数。

在CLAUDE.md里加一句“只写我指定的用例，多余的一律删”试试，我这么干后它老实多了。

GPT-3.5工具调用本来就拉胯，换4o或Claude立马稳，别在3.5上死磕。

这个现象我在vLLM离线跑多轮对话时也踩过，基本可以确定不是你的history截断没生效，而是OfflineBatch每次调用都会新建sequence并把旧的KV cache留在显存里，直到engine被销毁或者显存压力触发调度器回收。你可以先确认一下是不是每轮都在用同一个LLM实例反复generate，如果是的话，试试在每轮结束后显式调用一下llm.llm_engine.reset_prefix

温度调到0试试，还飘就加个json schema约束输出。

把完整历史拼接去embedding确实容易翻车，语义被拉平了，实体指代也糊。我一般只把最近一两轮原文带上，更早的做摘要或抽成关键词，再用混合检索兜底，BM25对实体名匹配很管用。MCP那边可以加个中间层先做query改写和实体抽取，再决定查什么。你也可以试试按轮次分别检索再合并，别一股脑塞进去。

先摘要再传更实际，分段返回会让tool变复杂，我一般用map-reduce先压再喂。

你这个情况我踩过类似的坑，大概率不是embedding模型的锅。bge-m3本身中文检索能力挺能打的，换gte-Qwen2提升可能有但不会质变，别急着花钱换模型。你描述的现象更像是chunk把完整流程切碎了——报销流程这种内容往往跨好几个段落，512的chunk很可能第一条只覆盖了概述，后面步骤被切到别的块里，向量检索时语义又被稀释了。建议先做个实验：把chunk_size拉到1024甚至更大，o

MCP和传统RAG其实不是替代关系，更像是给RAG装了个调度层。你原来那套向量检索还是照常跑，只不过现在检索器可以封装成一个MCP工具，LLM需要的时候自己去调，而不是你硬编码在流程里。这跟直接写function calling的区别主要在于标准化和复用性，function calling每家API格式不一样，MCP想统一这套协议，工具定义一次到处能用，而且能动态发现工具，不用每次改代码。但说实话

刚入门，这个对我帮助很大。

Milvus集群模式运维挺重的，小团队慎入。Qdrant单机性能不错，但分布式还在完善中。

你这个问题挺典型的，我前段时间部署ALBERT也踩过类似的坑。除了no_grad和empty_cache，最容易被忽略的是你把每个batch的输出append到列表里，如果这些tensor还挂在计算图或者CUDA上，引用不释放显存就不会回收。尤其是输出里如果有logits这种大张量，累积几百个batch直接爆炸。建议你检查一下append的时候是不是把tensor直接存进去了，可以改成.detac

我上周也被这个坑折腾了一整个晚上，症状跟你几乎一模一样，一直卡在connecting然后timeout。后来发现是Claude Code启动MCP服务器时的环境变量没继承，尤其是PATH，官方filesystem模板里用的node命令在GUI启动的环境里根本找不到，换成绝对路径就通了。你可以先手动在终端跑一下那条command，看能不能正常起来，如果终端能跑但Claude Code不行，那基本就是

只敢用来写测试和边缘胶水逻辑，核心业务还是得自己盯。RAG喂公司代码库确实有用，但检索质量不行照样白搭。

bge-reranker-base 拉胯其实挺正常的，base 版本本身容量就小，对中文长文本的语义区分度有限，你换成 bge-reranker-v2-m3 或者 bge-reranker-large 再试试，感受会差很多。cohere 的 rerank 确实强，但它是闭源且针对英文优化得更多，拿来比不太公平，而且走 API 有延迟和成本问题，本地知识库场景未必划算。还有个容易被忽略的点，你 ch

先试试混合检索吧，BM25+向量召回互补一下，比单靠embedding稳很多。 我也踩过这坑，后来加了rerank模型才好转，你可以试试cohere那个。

你这情况我遇到过类似的，问题大概率出在LoRA只微调了生成层，没动embedding，但生成和检索共用一套底座时，微调后的分布偏移会反向污染向量表征。建议你试试冻结LLM，单独用对比学习微调一个检索头，或者干脆把FAQ数据同时拿去做向量模型的领域适配，两边分开优化再拼起来，可能比指望一个模型兼顾俩任务靠谱。另外你召回用的是什么向量模型？如果也是ChatGLM3-6B的embedding输出，那基本

说实话这问题我太有共鸣了，刚用Cursor那会儿也差点被它气回VSCode。xlrd这个坑我踩过，它其实从2.0开始就彻底放弃xlsx了，但补全模型好像还停留在老数据上，你可以试试在prompt里直接写“用openpyxl或pandas read_excel处理xlsx”，把库名点出来它一般就老实了。另外关于iterrows，我后来发现一个歪招，就是先手动写一行vectorized的示例代码，再让