认真做创作方法手册

我之前也踩过这个坑，ConversationBufferMemory确实不太适合多轮Agent场景，它本质上就是无脑追加，轮次一多肯定爆token。后来我换成ConversationSummaryBufferMemory，设置一个合理的max_token_limit，让它在超限时自动摘要早期对话，稳定了不少。不过摘要本身也有信息损失，尤其是任务进度这种结构化信息，很容易被压没。我现在的做法是把关键

几百条数据微调7B做rerank，说实话量有点不够，模型很容易过拟合到标注风格上，反而把原来embedding的泛化能力带偏了。我之前也踩过类似的坑，后来发现先用LLM对top20做zero-shot打分重排，效果比硬微调稳不少。你检查过微调后模型在验证集上的排序指标吗，还是只看最终生成质量？另外正负例的构造方式也很关键，如果负例太容易区分，训出来的模型实际场景基本没用。

DP显存不均衡太正常了，它本来就是单进程多线程，主卡要负责汇总梯度，多占显存跑不掉。DDP同步BN变慢不一定是设置问题，跨卡通信本身有开销，卡少的时候反而可能不如不同步快，你可以试试SyncBN关掉对比下速度。另外数据加载记得用DistributedSampler，不然每张卡读到的数据会重复，loss那边也要注意别自己手动做all_reduce，DDP已经帮你处理了。

几百万条embedding还要增量更新和过滤，faiss确实会越来越难受，全量重建索引那个等待时间很折磨人。你这个量级和查询并发，我觉得Milvus和Qdrant都能扛，但Milvus组件多，etcd、minio一堆依赖，Docker跑起来资源占用不小，除非上集群不然有点重。Qdrant我实际用过，单机Docker部署很清爽，payload过滤和增量写入都挺顺手，几百万向量内存占用也还能接受。We

预处理肯定放服务端，MCP只管传原始数据，别把它当REST用。

我也遇到过，Claude就是手太痒，尤其画图和进度条这两样，十次有八次自己塞进来。后来我干脆在prompt最后加一句“输出后自己检查一遍，任何我没提到的import都删掉”，稍微好点但还是会漏。现在我的做法是直接告诉它“只写函数，不要写调用和示例”，这样它发挥空间小很多。不过说到底还是得自己扫一眼，完全靠提示词根治不太现实。

我之前也踩过这个坑，后来发现最管用的办法是直接扔一段你们项目里已有的、你觉得写得好的文档给它，然后说“照这个语气和结构来写”。比什么“专业清晰”这种空泛指令强太多了。另外可以顺手加一句“每段不超过三句话，术语保持和参考文档一致”，出来的东西立马接地气。你也可以试试让它先列大纲，你确认完再逐段生成，别一次性让它输出整篇。

7B的CodeLlama确实容易这样，模型容量小的时候指令跟随能力会打折，你压temperature和加约束都只能稍微缓解。可以试试用base版本加few-shot示例，给两三个“函数定义→纯代码body”的样本，比单纯写指令管用。另外CodeLlama的instruct版本对docstring有执念，换成deepseek-coder-6.7b或者starcoder2-7b会好不少，后者补全更干净

试试加--gpu-memory-utilization 0.9，vLLM默认预分配挺激进的，版本新反而容易踩坑。

说实话你遇到的情况太典型了，教程里那些例子基本都是拿来展示“可能性”的，不是拿来解决“稳定性”的。我自己的经验是，Prompt工程的核心不是学那些花哨技巧，而是把它当成一个“接口调试”的过程——你先得把任务拆到足够细，比如对“投诉”的定义，到底哪些关键词、语气、业务规则算？这些不写清楚，GPT默认按它自己的常识跑，结果当然飘。另外你提到的“换个标点结果就变”，这其实说明你的Prompt里有效信息密

说实话你这情况跟我上个月一模一样，也是几百万条embedding赶上线。我最后选了Qdrant，但前提是我们把Docker部署和监控都配好了，直接pip跑demo没问题，生产真不能这么裸奔。Milvus那套etcd加依赖确实劝退，但如果你团队有运维余力，它的分布式扩展上限确实更高，不过单机场景下两者性能差距真没你想的那么大。调参这块HNSW别死磕论文参数，我试下来efConstruction给到2

说实话我之前也卡在这块儿，后来发现与其纠结措辞，不如先固定一个“输出格式模板”，比如强制它先给解释再给代码，成功率高不少。另外建议你搞个小的回归测试集，把之前跑不通的case存下来，每次改完提示词就跑一遍，能直观看出是变好了还是变差了，比凭感觉调要靠谱得多。

我最近也有类似的感觉，AI写代码就像滚雪球，前期爽是因为没历史包袱，后期它为了不破坏现有逻辑，就会疯狂打补丁。我后来干脆把某个模块的核心Service彻底推翻重写，只把AI当高级补全用，效果反而好很多。你可以试试阶段性让它做“代码审计”，而不是直接重构，或者隔段时间就手动梳理下状态机，不然真成屎山了。

给范例是最有效的，直接扔一段你认可的开源项目README进去，让它照着那个语气和结构写，比什么形容词都管用。句式长度可以限制一下，比如“每句话不超过25个字，不要用从句”，能明显减少那种绕来绕去的感觉。另外我试过在prompt里加“写完后删掉所有连接词和过渡句，检查一遍，只保留必要的信息”，出来的效果会硬朗很多。你还可以让它先列提纲再逐段填充，别让它一口气生成全文，那股翻译腔多半是长文本里攒出来的

变量位置影响真挺大的，关键信息尽量放前面，我试过放后面模型就有点“失忆”。 分隔符用###这种明显的比啥都强，太花哨的反而容易让模型犯迷糊。

这问题我也踩过坑，光靠system prompt压不住GPT-4的生成惯性。后来我把指令改成“逐句标注引用来源，无依据就明说不知道”，效果好了点，但检索片段本身有歧义时还是会跑偏。你可以试试在检索后加一道重写/过滤逻辑，把冲突表述提前剔除掉再喂给模型，比单纯调prompt更稳。

我之前也试过类似的，加“请”确实让输出更稳，但感觉更像是给模型一个更明确的“语气锚点”，而不是玄学。系统提示里“你是一个专业的客服助手”和“请以专业客服助手的身份回答”差别挺明显的，后者更像是在指令里嵌入了角色约束，可能激活了更多跟身份相关的语义空间。不过我觉得token变多可能也有点影响，毕竟长一点指令会让注意力分布更均匀。你试试把“请”换成“务必”或者“尽量”看看，说不定效果又不一样了。

这问题我太有同感了，Claude在代码库级重构上确实容易“自由发挥”，尤其老项目里那些隐式约定它根本抓不住。你试试把迁移规范压缩成一条条硬性检查清单，比如“禁止改bean名”“必须保留兼容性注释”，让它每改一步先对照清单自检，比单靠系统提示管用。工具的话，Cursor或Aider对项目上下文的理解更细，但本质上还是得靠你把“边界”定义死——AI一旦觉得有“优化空间”就会手痒，这毛病得靠约束喂出来。

说实话你这个问题我也踩过坑，A100 80G跑7B还爆显存，八成不是模型本身的问题，而是vLLM默认把KV cache和中间激活全塞进去了。我试过开量化，用bitsandbytes的8位加载，显存能压到40G上下，但并发一上去照样抖，后来发现瓶颈其实在prefill阶段，长文本4K以上时注意力矩阵太吃显存了。流水线并行倒是有点用，不过vLLM对多卡的支持感觉没TGI那么顺，你如果只有单卡，可以考虑

这问题我太有同感了，few-shot例子其实挺看“边界感”的，你给的例子越具体，模型越容易把里面的细节当成模板去套，尤其是变量名和逻辑分支，反而限制了它的泛化。我自己的经验是，代码任务尽量用1-2个例子，而且要故意挑不同风格的输入输出，暗示“这里只是示意”，不然它真会照着抄。角色设定那个我也踩过坑，说“资深工程师”它就开始给你加类型注解和设计模式，其实你要的可能就是个能跑的脚本，所以我觉得提示词里