认真成长设计修炼册

我也踩过这个坑，之前做合同字段抽取时把prompt写到快两千字，结果模型反而开始自己编条款编号。后来发现一个挺关键的点：长prompt里如果混着“背景说明”和“硬性约束”，模型很容易把前者当软建议、后者当可选项，优先级全乱了。我的做法是把真正不能违反的规则压到三五行以内，背景介绍单独放一段，再用分隔符隔开，效果就稳很多。另外示例也不是越多越好，两三个覆盖边界情况就够了，堆太多反而让模型过度拟合示例

我都是先选中要改的代码块再让Composer动手，不选的话它容易全局乱改，你试试。

4090跑70B基本别想，就算4bit量化也要35G以上显存，双卡还差不多。7B用GGUF Q4_K_M在llama.cpp上体验还行，代码补全够用，但上下文拉到8k以上确实吃力。vLLM显存占用比llama.cpp高不少，不过并发和吞吐强，单卡玩的话还是老老实实llama.cpp吧。4bit质量损失日常用基本感觉不出来，除非你做严谨的数学推理，那还是建议上fp16或者8bit。

我之前也踩过类似的坑，最后发现是MCP Inspector默认连的是stdio传输，而FastMCP跑的是SSE或者streamable-http，两边协议对不上就一直超时。你先确认下服务启动时打印的监听地址是不是127.0.0.1，有时候绑到localhost会解析成IPv6导致连不上。另外DeepSeek那边只是普通OpenAI兼容接口，跟MCP没关系，问题基本都出在本地这层传输配置上。可以用

单张3090跑7B并发10路OOM其实挺常见的，24G显存要装权重、KV cache还有激活值，7B的fp16权重就快15G了，剩下那点空间分给KV cache根本不够几路并发吃。max_num_seqs=256是上限不是预留，真正吃显存的是实际并发的序列长度乘以层数乘以head维度，你请求一多KV cache直接指数级涨。建议先把gpu_memory_utilization拉到0.9甚至0.92

把项目里没装的依赖写进.cursorrules，明确禁止它用，亲测管用。

缝合不同文档的内容，八成是检索阶段就把不相关的chunk召回了，模型只是照着上下文编。固定长度切分很容易把跨段落的语义切断，建议先换成按标题或语义边界切，再把top_k降下来看看召回的都是啥。embedding模型影响的是召回质量，但你现在的问题更像是chunk里本身就混了噪声。先别急着换贵的模型，把切分和召回日志调明白，大概率能解决一大半。

50万其实还好，ResNet50特征对细粒度相似确实吃力，可以试试换更强的骨干或先粗排再精排。

batch推理确实容易让输出飘，试试关掉连续批处理或者固定seed看看？

这个问题我太有共鸣了，之前也踩过一模一样的坑。你说的“忽高忽低”大概率不是模型本身的问题，而是检索层不稳定导致的——同一个问题，每次召回的chunk可能不一样，生成结果自然就飘了。建议先别急着调生成参数，把每次请求的检索结果打日志出来，看看命中的文档片段和相似度分数，对比一下“答得好”和“答得差”那几次的差异，基本就能定位了。chunk切分确实是个重灾区，尤其是知识库里有表格或者跨段落逻辑的时候，

训练样本里没带工具调用轨迹吧？光教它答文档，它自然忘了怎么调工具，得把完整对话和工具返回拼进去。

固定切块肯定不行，先试试语义切块加query改写，表格代码单独处理效果会好很多。

把风格示例放system prompt里，再让它在生成前先复述一遍规范，会稳很多。

我也踩过这个坑，后来发现与其死磕prompt措辞，不如先把任务拆成状态机。每个状态只让模型干一件事，工具调用和总结分成两步走，稳定性会好很多。另外模型能力确实影响很大，同样的prompt换GPT-4和换小模型效果天差地别，建议先固定一个模型再调。你说的动态调整我理解就是给不同模型写不同详细度的指令，这个思路是对的。

验证确实是瓶颈，我后来靠限制改动范围加小步测试才稳下来，模型再强也架不住上下文太散。

Milvus 的标量过滤确实容易踩坑，尤其你用的是时间范围这种高基数条件，它可能会退化成暴力扫描，延迟一下就上去了。我之前也遇到过类似情况，后来把过滤字段单独建了倒排索引才好转。你可以先 explain 看一下执行计划，确认到底走没走索引。20万数据量其实不算大，ES 加向量插件未必更优，但至少过滤这块它更成熟。

2万条客服问答全是同一种语气和句式，跑3个epoch基本就是拿业务话术把底座覆盖了一遍，loss降得漂亮不代表泛化好。LoRA秩如果开得偏大、学习率又给到2e-4，更容易把通用能力带偏。试试把数据掺三成通用对话，epoch压到1，学习率降到1e-4左右再测测。

几百万数据pgvector完全够用，省得再维护一套，HNSW的m和ef_search慢慢试就行。

你这个现象其实挺典型的，LoRA虽然冻结了大部分参数，但低秩适配器照样能带偏整个模型的输出分布。3e-4对7B模型来说确实偏大了，尤其你数据只有500条，梯度更新很容易过拟合到那点内部语料上，把通用能力给挤掉。我自己的经验是LoRA微调学习率最好从1e-4甚至5e-5起步，跑一两个epoch看看loss曲线再决定要不要加。至于r=8其实不算小，rank值更多影响的是能学多复杂的东西，跟遗忘关系没那

A10 24G跑7B确实够，但vLLM启动时KV cache是按gpu-memory-utilization先切一大块预留的，你把0.9调这么高，留给激活值和CUDA context的空间就很小了，并发一上来直接爆。我之前也踩过这个坑，试过降到0.85然后显式加 enforce-eager 或者限制max-num-seqs，会稳很多。碎片化严重的话看看是不是开了enable-prefix-cach