稳步前行机器学习成长记

我们线上用的方案是短期记忆只保留最近3轮原始对话，更早的走异步摘要，但摘要不塞回主prompt，而是作为可检索的记忆条目单独存向量库。这样Agent调工具时只带当前任务相关的记忆片段，不会被整段历史带偏。关键点是摘要里要显式抽出时间、订单号这类实体，不然“昨天”这种指代还是没法对齐。纯靠内存摘要确实容易在多步工具调用里丢上下文，建议把记忆做成带元数据的独立层。

“发工号定绩效”这比喻挺形象，不过我更关心它怎么处理Agent间异步通信的时序问题。之前用LangGraph也踩过状态机的坑，平台层封装确实能省不少事，但抽象一旦厚了，调试时连日志都看不懂。绩效指标那块我也存疑，Agent的“产出”怎么量化？如果只是简单统计调用次数或token消耗，那跟真实任务完成度可能完全脱节。

千万级2048维用HNSW确实吃内存，M=16已经算保守了，但efConstruction=200建索引时也占不少。你可以试试HNSW配上SQ8量化，内存能砍到四分之一左右，召回掉得比IVF_PQ少很多。IVF_PQ召回低主要是PQ段数没调好，2048维建议拆成32到64段，nprobe给到32以上再试试。数据再翻几倍的话单机肯定扛不住，早点上分布式分片，不然查询延迟会更难看。

几百条数据微调7B做rerank，感觉数据量有点悬，模型很容易过拟合到标注里的表面模式，泛化反而崩了。你试过先用cross-encoder那种小模型跑个baseline吗，有时候比硬微调LLM稳。另外检查下正负例的构造，如果负例太“硬”或者太“软”，训练信号会很乱。我之前也踩过类似的坑，最后发现把rerank当分类任务做，加个margin loss会好不少。

我之前也卡在这个坎上，后来发现Agent跑起来显存大头其实是KV cache，不是模型本身。你可以试试把上下文长度压到4k以内，再开个prefix caching，能省不少。vLLM对工具调用确实不太友好，我现在换成了llama.cpp的server模式，功能调用用grammar约束输出，稳定很多。不过多轮一长还是得手动清历史，不然照样爆。真要上生产的话，感觉还是得双卡或者直接走API，本地折腾性

我之前也踩过这个坑，切分粒度其实跟你的query类型强相关。如果用户问的是具体细节，块太大反而噪声多；问的是概括性问题，块太小又缺上下文。建议你先拿十几条真实query做个召回测试，看看top3里到底缺了什么，再反推切法。重叠率我一般设10%-20%，太高会重复召回，太低容易断语义。

我最近也遇到类似情况，感觉Cursor的Agent模式在跨文件上下文上确实有点“手伸太长”。它为了补全逻辑，会自动去找相关的模块和测试，结果就顺手把别的文件也改了。我后来在prompt里加了“只允许修改当前文件，其他文件只读”这样的约束，命中率会高不少。 另一个坑是它容易把已有断言当成待修正的对象，尤其是老项目里写法不太统一的时候。你可以试试在描述里明确说“保留现有断言，只新增边界用例”，或者干

我之前也踩过这个坑，苹果公司财报检索出苹果种植，基本就是embedding没区分开语义空间。你可以在Prompt里加一句让模型自己先做相关性打分再回答，比如“请先判断每段和问题的相关程度，只保留最相关的2-3段作为依据，其余忽略”，这招对 deadline 紧的情况挺管用，不用改检索链路。 不过说实话，光靠Prompt筛效果有限，模型有时候会硬着头皮把不相关的也编进去。更稳一点的做法是加个cr

16G显存跑7B做Agent确实挺紧的，尤其LangChain那套工具调用会反复塞prompt，上下文一长直接炸。我之前也踩过这个坑，后来发现关键不在框架，而是每轮把完整历史都塞回去，显存不爆才怪。可以试试把记忆做成分层摘要，只保留最近几轮原文，早期对话压缩成短摘要再喂给模型，能省不少。量化到4bit我实际用下来，工具调用和简单规划基本没啥问题，但涉及多步推理、参数格式要求严格的场景会偶尔出错，建

这个思路确实比暴力替换靠谱多了，我之前改其他软件皮肤也踩过类似的坑。直接覆盖asar文件那套操作，当时用着挺爽，结果软件一更新就全乱了，有时候连启动都成问题，还得手动回滚。模块化注入这个方向我觉得是对的，本质上就是把皮肤当成一个外挂层来处理，跟核心逻辑解耦，这样版本迭代的时候至少不会互相拖累。不过有个问题想请教一下，Dream Skin这种动态加载的方式，会不会在启动速度上有影响？毕竟多了一层注入

我一般是分成两类处理：纯CRUD或者工具函数这种，review一遍没啥问题就直接合了；但像你说的并发、连接池、状态机这些，基本都会自己重写或者大改。AI写这类代码最大的坑是它看起来逻辑自洽，但边界条件经常漏，比如重连时没清timer、没释放旧连接。我的习惯是让它先把测试用例写出来，我再顺着测试去读实现，能省不少事。

结构化模板确实有用，但别指望它能包治百病。我之前做日志解析也踩过类似的坑，后来发现关键不只是模板长什么样，而是你有没有把“判断标准”写进去。比如你让它提取异常栈，得明确告诉它什么算异常栈、遇到多行堆栈怎么处理、日志里没有业务上下文时该输出什么，而不是让它自由发挥。角色+任务+输出格式+约束这套框架里，约束条件其实是最容易被忽略但最影响稳定性的部分。另外temperature调到0不一定就稳，有时候

加一句“别用polars，同事只看得懂pandas，循环别改推导式”，一般就老实了。

我踩过类似的坑，后来改成每个 Agent 只读写自己那份子状态，节点之间靠 reducer 合并，就不会互相覆盖了。LangGraph 的 Annotated 加上自定义 reducer 挺好用的，像研究结果往 messages 里 append 而不是直接赋值。共享的东西别全塞一个 dict，按领域拆成几个 channel 会清爽很多。实在要跨 Agent 传大对象，我一般丢个引用 id，让下游

A100 40G跑7B确实不该这么慢，建议先确认下是不是没开continuous batching，vLLM默认是开的但TGI要手动配。另外max_num_seqs和gpu_memory_utilization这两个参数调一下试试，吞吐差挺多的。量化的话可以上AWQ或GPTQ，7B量化后显存占用能降不少，延迟也会好一些。并发高内存飙可能是KV cache没限制好，看看max_model_len是不

几百个函数确实太少了，LoRA在这种规模下很容易把训练集背下来，但学不到泛化的代码结构。我试过类似任务，当时用500个样本微调，loss也是卡在某个平台期，后来加了数据增强（比如把函数体随机删几行、换变量名）才勉强往下走。你BLEU只有0.4其实不全是过拟合的问题，代码补全本身对输出格式敏感，BLEU对token顺序太严格，建议也看看编辑距离或者精确匹配率。24G显存跑rank=16爆掉有点意外，

试试让LLM先对每段打个相关度分再选，或者干脆用Cohere的Rerank，几行代码搞定，比调prompt省心多了。

你这情况我太熟了，代码RAG跟纯文本完全是两码事。函数粒度切chunk其实挺理想，但bge-m3在代码语义上确实吃亏，它更擅长自然语言，代码里的符号、依赖关系它根本抓不住。我觉得你问题不在rerank，而是召回源就有偏差——工具函数和配置文件表面文本可能跟“用户登录”有弱关联，但业务逻辑上八竿子打不着，cross-encoder只看字面相似度，自然会把它们顶上去。 建议你先别急着换模型，把元数据

说实话你这个问题我太有感触了，之前用LoRA调一个8B模型做意图识别也栽过类似的跟头。5000条对话听着不少，但分摊到不同业务场景里，每个场景可能就几百条，LoRA低秩更新本来就更适合学通用风格而不是强记具体业务边界，数据一稀疏它就容易把相似问题揉成一团。你loss降到0.3其实已经说明拟合得差不多了，这时候更可能是过拟合了训练集的表面模式，比如把“投诉”和“售后”的回复模板串起来。rank和al

4090跑7B按理说真不该爆，你试试把--gpu-memory-utilization设到0.85左右，vLLM默认有时候会预留太多给KV cache。另外gptq在vLLM里确实不如AWQ省心，我之前换AWQ后同样长度显存占用直接降了1-2G，你可以考虑重新量化下模型。还有，max-model-len别硬顶8192，代码补全场景其实没必要那么长，设个4096然后用--enable-prefix-