自动化应用札记

感觉你这是典型的“示例堆多了反而把模型框死”了。我之前也踩过这坑，后来发现与其在prompt里反复强调“缺失就null”，不如在外面加一层规则校验，比如字段值必须能在原文里找到对应片段，否则直接丢弃。另外可以让模型输出置信度或者“无法判断”的标记，配合后处理过滤，比指望它自己老实靠谱多了。表格和指代这种确实难，我现在会把这类文档先单独走一套预处理，拆开再抽，效果稳不少。

我们线上用Qdrant跑了小半年，数据量跟你差不多，单节点内存占用比Milvus友好不少，索引构建几百万条大概十几分钟能搞定，延迟也稳。Milvus功能确实全，但那套etcd加对象存储的依赖，小团队维护起来真挺折腾的，没专职运维慎碰。不过Qdrant分片和横向扩展相对弱一些，你们要是预期数据量还会猛涨，可以先用Qdrant顶着，等真到瓶颈再迁移也不迟。

2e-4对LoRA来说确实偏高了，尤其你还跑了3个epoch，客服数据又单一，灾难性遗忘基本跑不掉。我一般会把lr压到1e-4甚至5e-5，epoch控制在1到2，再掺10%左右的通用指令数据进去。rank=16倒不是主要问题，alpha=32配这个rank有点猛，可以试试alpha=16。评测别只看loss，拿几十条通用问答和业务问答混着人工过一遍，看格式和常识有没有崩最直接。

3000条数据做客服微调确实偏少，模型很容易记住固定话术而不是学会泛化。你学习率2e-4对LoRA来说偏高了，试试降到1e-4甚至5e-5，rank也可以从8起步别一上来就拉大。另外开放域问题变差挺正常的，SFT数据太窄会把基座能力带偏，可以混一些通用指令数据进去，比例大概1:4左右。先别急着上全量SFT，把LoRA的target modules覆盖到所有线性层再跑一轮看看。

我之前也踩过这个坑，光靠prompt真的很难稳住，模型天然就想“抄近路”。后来我的做法是把每一步的输出变成下一步的输入，强制它先产出结构化字段，比如提取完信息后用一个json schema校验，不通过就不让往下走。单纯靠LangGraph绑流程也有点重，可以先在prompt里加个中间产物检查，让它自己回填缺失字段。你可以试试把“提取信息”拆成一个独立的tool call，Agent不调用这个工具就

我也被Cursor坑过，生成LangChain工具节点的时候，它把SerpAPI的api_key写成serp_key，跑起来直接401。后来我的笨办法是把真实请求的curl命令或者requests示例直接贴在函数docstring里，让它照着抄，比贴整篇文档管用。还有个小技巧是写完先别信它，自己用httpx跑一遍最简调用，把响应结构存成fixture再让它基于这个写解析逻辑。另外可以试试在.cur

温度调到0试试，7B确实容易自作主张，我拿14B也偶尔这样。

Top-K调大必须上reranker，不然噪声肯定炸。我一般先粗召回20再精排选3，MRR和命中率都得盯着。

我一般会在任务切换时手动重新贴一遍关键约束，比指望它自己记住靠谱。AGENTS.md有时候确实会被忽略，尤其对话一长，模型注意力就被最近几轮带跑了。可以试试用Cline的memory功能或者单独开一个constraints文件让它每轮读，虽然费点token但一致性稳很多。另外把大任务拆成小步骤、每步结束就总结一次，也能减少它中途跑偏的概率。

几千篇文档用IVF_FLAT有点亏，这个索引更适合大规模场景，小数据量下nprobe不调基本等于随机砍候选集，召回不掉才怪。建议先换HNSW或者直接暴力搜一遍当baseline，确认embedding本身没问题。如果baseline也不理想，那多半是bge-large-zh没加query指令前缀，它检索时query和passage是要分开编码的。另外内积距离记得向量归一化，不然模长会干扰排序。re

这种情况太常见了，我搭RAG的时候也踩过一模一样的坑。你光加一句“严格基于文档回答”基本没用，模型对否定式指令本身就不敏感，尤其top3里如果混了不相关的chunk，它反而更容易被带偏。我的经验是prompt结构比措辞重要，把检索内容用明确的分隔符包起来，比如用XML标签或者三引号，然后指令里写清楚“只使用标签内的信息，标签内没有提到的话直接说不知道”，这样命中率会高不少。另外“不知道”这个兜底一

我们也在纠结这个问题，后来发现MCP最省心的是把embedding和rerank都封在server里，客户端不用管模型版本，换模型只改一处。但并发写入确实头疼，chroma的MCP封装基本没做锁，多个agent同时upsert会偶发覆盖。生产上我们最后自己加了层队列串行化写，读走缓存，性能才稳住。

我一般直接说“用pandas，别优化，别有创意”，它就不乱改了。

7B做多跳确实容易断片，试试把工具返回塞进assistant消息而不是全堆prompt里，结构清晰点会稳不少。

这现象太典型了，2万条数据对全参数微调来说确实容易把基座带偏，尤其法律文书这种领域性强的语料，模型会疯狂往那个方向坍缩。我之前调别的模型也踩过这个坑，2e-5对8B全参其实偏激进，建议先降到5e-6试试，warmup可以适当拉长。LoRA肯定更稳，r设16或32，只训adaptor能保留不少原能力，但摘要质量可能略降，得自己权衡。另外你可以考虑把通用数据按1:5比例混进训练集，能缓解灾难性遗忘，代

4090跑7B按理说绰绰有余，你八成是没给KV cache留够余量，试试把gpu_memory_utilization设到0.85，swap_space调成1到2G，别让vLLM默认把显存全吃满。AWQ慢可能是没开vLLM的量化算子优化，得加--quantization awq_marlin参数才行，纯4bit加载反而亏。另外max_model_len别一上来就8192，先开2048跑通流程，再逐

10万条对BGE-large这种密集向量来说确实是个坎，单纯调Milvus参数治标不治本，召回阶段就丢了语义精度。我建议先上reranker，比如bge-reranker-large，把top50重排到top10，见效最快。另外你可以检查下是不是chunk切得太碎或者重叠太多，10万条里噪声片段比例会放大。embedding策略上，试试混合检索，加个BM25权重，能救回来不少实体匹配的场景。

few-shot在RAG里确实容易翻车，尤其当示例的“标准答案”和检索文档风格差异大时，模型会倾向模仿示例的句式甚至实体，而不是严格遵循上下文。我猜你bge-m3召回的top5本身相关性没问题，但生成阶段注意力被示例带偏了——这其实不是prompt权重问题，而是decoder对示例的“模式复制”优先级高于文档内容。我之前试过把示例改成“问题+文档关键句摘录+答案”的三段式，让模型明确看到示例如何从

这问题太典型了，光靠system prompt提醒没用，得把每步结果显式塞回给下一轮，或者直接上LangChain的memory模块，我现在就是这么干的。

确实，多模态交互的鲁棒性才是真正的拦路虎。我们自己做海外项目时，发现语言模型在中文环境下的表现和英文环境差距明显，更别提不同口音和方言了，边缘设备上的算力还得抠着用，这比调运动控制参数头疼多了。速卖通这个渠道如果能帮他们收集到真实海外家庭场景的corner case，那比实验室里刷一万遍测试都有价值，就看后续数据回流机制怎么设计了。