业余后端手记

温度0.2其实已经很低了，但量化版确实会引入一些随机性，尤其是Q4以下的量化，补全质量波动挺明显的。你试试换成Q5或Q8的量化版本，或者直接用FP16跑，稳定性会好不少。另外Ollama的默认上下文长度偏短，写长函数时容易丢掉前面的信息，可以调大num_ctx试试。prompt里最好把函数签名和import也带上，光靠注释模型有时候猜不准你要干啥。

这个其实不用等MCP层面支持，Agent自己可以先发一句填充话再调工具啊。我一般是在prompt里明确告诉模型：调用耗时工具前先输出一句“稍等，正在查”，然后再触发tool call，这样体验就顺很多。MCP本身是同步返回没错，但客户端完全可以控制说话和调用的顺序。不过要注意别让模型养成只说话不调用的毛病，得在解析层做点约束。

法律领域做RAG微调embedding翻车还挺常见的，我去年做医疗问答时也踩过类似的坑。你用随机负样本基本等于让模型学“这俩完全不搭边”，但法律术语里很多概念本身就高度相似，比如“定金”和“订金”，随机采样根本区分不出这种细粒度语义，模型反而会把原本拉开的距离又搅混了。换hard negatives确实是个方向，但别一上来就全换，建议先按7:3混着来，hard negative太猛容易导致训练崩溃

5万条切片用PGVector其实够用了，问题大概率不在数据库选型上。text-embedding-3-small对中文语义区分确实偏弱，尤其“年假”和“报销”这种同属HR域的词，向量空间里挨得太近。建议先别急着换Milvus，试试加个BM25关键词召回做混合检索，再拿cross-encoder精排top20，通常能明显改善。你这个阈值调到0.8还混进无关内容，说明是召回源头就不准，光靠阈值卡没用。

混合检索先上，BM25兜口语化漏召，重排权重别拉太高，不然模型容易自己编。

这种情况我也遇到过，开源模型确实容易把多步指令“吃掉”一部分。你可以试试把异常处理单独拆成一条指令，比如先让它只写try/except框架，再往里填requests和解析逻辑。另外在Prompt里明确列出“必须包含：函数定义、超时捕获、HTTP错误捕获”，比“请完整输出”管用得多。我一般还会让它先复述一遍要求再写代码，漏项概率能降不少。

这个坑我踩过，chunk大小真不是拍脑袋定的，得看你文档本身的粒度。像保修政策这种条款型内容，512反而容易把一条完整规则切断，我后来改成按语义段落切，再叠加个小overlap，召回质量明显稳了。256确实太碎，LLM拿到半句话根本没法答。embedding模型差异更关键，ada-002对中文语义其实一般，bge-small轻但泛化弱，text2vec-large中文强可对长文本又不太友好，你那个

5000条数据对7B模型来说确实有点多，特别是如果全是代码审查场景的垂直数据，很容易把模型的通用指令遵循能力带偏。我自己的经验是领域数据和通用数据的比例控制在1:3到1:5之间比较稳，而且通用数据里最好混一些工具调用的负样本，就是那种“不需要调用工具”的对话，让模型学会判断什么时候该触发、什么时候不该触发。MCP的prompt模板也挺关键的，工具描述如果写得过于宽泛，模型很容易过度联想，比如把“写

我也遇到过类似情况，7B int4在vllm上长prompt多并发确实容易显存慢慢爬。你可以先看下是不是开了enable_prefix_caching或者block_size设太大，KV cache碎片化会导致显存回收不及时。另外max_num_seqs=64对两张4090来说有点激进了，试试降到16-24，配合max_model_len限制一下。实在不行换SGLang或者llama.cpp的se

你开了awq但模型本身是不是没转成awq格式？vLLM的--quantization awq要求权重已经是AWQ量化过的，直接拿fp16权重加载反而会按awq去解析，显存和精度都会出问题。另外40G卡跑7B的int8，光权重就7G左右，正常不该冲到38G，建议看下gpu_memory_utilization是不是默认0.9，加上KV cache预分配很容易顶满。可以先把它调到0.7试试，再确认下m

我们当时也是ES栈，百万级向量加HNSW索引后延迟明显上来了，尤其并发一高就抖。后来把分片控制在单分片50万向量以内，堆外内存给足，勉强能扛但运维挺累。真要到千万级或者QPS要求高，还是上Milvus省心，ES适合向量和关键词混合检索的场景。

把关键约束挪到开头或结尾，中间只放背景，亲测比反复强调管用。

同感，我现在写业务逻辑全靠Tab，上次面试手写快排居然卡了半天，真得偶尔关掉Copilot练练手。

我之前也踩过这个坑，问题大概率出在生成端而不是检索端。你试试把检索到的chunk按相关性排个序，只喂top2进去，别一股脑全塞，模型很容易被弱相关的内容带偏。另外256字符确实太碎了，语义完整的段落至少512起步，不然模型看到的都是断头断尾的句子。还有个容易忽略的点：prompt里“仅基于上下文”写太死反而会让模型硬凑答案，可以改成“如果上下文没有明确答案就直说不知道”。

我也遇到过类似情况，Claude特别爱“帮你优化”。我的经验是把要求写死一点，比如“只用pandas，禁止引入任何新库，代码必须保持for循环结构”，它一般就老实了。另外可以在prompt里加一句“这是团队规范，不是性能问题”，它好像更能理解约束的合理性。换工具倒不至于，但确实得多花点心思在指令上。

这个现象我也遇到过，本质就是chunk粒度跟查询意图的匹配问题。关键词类问题需要上下文完整，大chunk优势明显；但操作类问题往往答案就藏在一两句话里，chunk大了反而被无关信息干扰。我现在的做法是给文档做结构化拆分，按标题层级切分而不是固定字数，再配合多路召回，效果比单调参稳定很多。另外bge-small如果量化过，精度损失也不小，有条件可以试试bge-m3或更大量级的模型对比下。

生产环境要加system message锁死角色和格式，另外试试max_tokens设短点，乱码多半是生成长度超了。

试试把最近几轮对话和工具结果直接拼进prompt，做个滑动窗口，比向量库轻量多了。

all-MiniLM-L6-v2做中文检索确实太勉强了，这模型本来就不是为中文优化的。我3090上跑bge-m3一点问题没有，显存占用大概6-7G，推理速度也够用，换完召回率提升还是很明显的。dense-x那些晚交互模型对长文档确实更强，但调参门槛高不少，你先用bge-m3把baseline稳住，后面再考虑要不要折腾。另外chunk策略可以试下按语义段落切，别死守固定大小。

我之前也卡在这块好久，后来发现固定大小真的不如按文档结构来切，比如用标题或者段落边界去分割，能明显减少语义被切碎的情况。overlap的话我一般设chunk的10%-15%，主要为了保住上下文衔接，但太大反而会重复检索。工具上可以试试langchain的RecursiveCharacterTextSplitter，配合自定义分隔符列表，比硬按token切靠谱。另外建议你先拿几个典型问题去跑不同参数