长期主义机器学习成长记

7B模型跑多步工具调用确实容易崩，上下文只是一方面，指令遵循能力弱也是硬伤。生产环境里我们一般用分层记忆：短期保留最近几轮原文，把旧的工具返回结果单独存外部存储，只往prompt里塞摘要和关键字段。LangChain里可以用ConversationSummaryBufferMemory配合自定义的tool output压缩函数，别全丢给模型自己总结，容易丢细节。另外换Qwen2.5-14B或32B

Buffer和Summary可以混着用，短期几轮用Buffer保证细节，长了再触发Summary压缩，不然token确实扛不住。向量库适合跨会话召回，但“刚才那句没回答”这种指代还是得靠最近几轮的原始记录去定位，别全丢进向量里。我之前也踩过把历史硬塞system的坑，结果模型老被带偏，后来改成只保留最近两三轮加一个精简摘要，效果稳多了。你可以先跑个简单版，观察下它在话题切换时到底是丢上下文还是被旧

我之前也踩过这个坑，MCP 本身只是个调度层，它不会自动帮你注入 RANK、LOCAL_RANK、MASTER_ADDR 这些变量。你可以在 tool 的启动脚本里显式 export 这些环境变量，或者干脆包一层 torchrun，让 torchrun 自己去分配 rank。init_process_group 报错大概率就是 MASTER_ADDR 和 WORLD_SIZE 没对上，建议先把这几

这个坑我们踩过，企业微信OAuth2.0拿到的userid跟模型服务那边完全两套体系，硬桥接确实容易出问题。中间层做映射是常见解法，但别自己写session校验，用Redis缓存映射关系能扛住并发，几十个人真不算多。MCP那个auth更适合单点工具调用，放企业微信这种多用户场景确实勉强，建议看看官方的SSE transport配合自定义middleware。现成参考可以翻下github上wecom

我一般会先把接口文档或者类型定义喂给它，哪怕只是注释写清楚入参出参，幻觉能少一大半。温度参数在Cursor里好像调不了，但可以在项目根目录放个.cursorrules文件，把技术栈和禁用库写进去，挺管用的。另外别指望它一次写对，让它先输出伪代码或者分步解释，确认思路对了再生成实现。Celery和APScheduler混用那种，直接在prompt里点名“只用Celery，别引入其他调度库”会好很多。

说实话你这情况跟我上个月一模一样，随机UA和延时只是入门配置，电商反爬看的是行为特征，频率和请求顺序才是重点。我后来试了用AI生成一个简单的会话保持逻辑，配合cookie池，比单纯换Selenium轻量多了，毕竟Selenium开浏览器实例太吃内存，跑几百条还行，上万条容易崩。至于代码重构，建议直接让Cursor按功能拆成模块，比如请求头管理、代理切换、解析逻辑各放一个函数，改起来不容易碰坏别的地

同款双卡4090，当时也卡在70B这档。说句实在话，48G跑FP16本来就是硬撑，OOM不冤，关键是AWQ 4bit那速度真不是正常人能忍的，我后来换成了GPTQ加exllama内核，体感比AWQ快个百分之三四十，代码质量也稍微稳点，但别指望能追平API。 vLLM那套我试过，配置麻烦不说，对双卡通信和调度要求挺高，小项目用起来杀鸡用牛刀，反而容易出一堆莫名奇妙的报错。TensorRT-LLM更

我一般会让AI先输出diff，自己扫一眼再决定合不合并，比直接让它改省心很多。另外试试在系统提示里写死“禁止修改函数签名和数据库字段名”，比每次prompt强调管用。还有个小技巧，把要改的代码块单独复制出来问AI，改完再贴回去，能挡住大半乱动。不过说实话，严格review还是躲不掉的，尤其涉及分页这种边界逻辑。

base64塞JSON这条路我刚开始也走过，后来发现瓶颈根本不在序列化，而是JSON-RPC本身的字符流传输效率太低了。我们现在的做法是MCP server只做协议解析和任务编排，真正的数据走共享存储或者S3预签名URL，模型推理扔给Ray Serve的Deployment，MCP这边拿到引用路径再回传。图片这种大对象直接用minio，tensor就落成npy文件，Agent那边拿到路径自己去拉，

说实话你这个问题太典型了，7B模型在变长输入下compile反而变慢，我这边也踩过同样的坑。动态shape确实是最大的杀手，torch.compile默认会做shape特化，一旦输入长度变了就得重新编译，那个开销比你省下的那点kernel时间多得多。我自己的经验是，如果能把padding到固定长度，或者用max_seq_len截断，compile的收益才体现得出来，否则真不如eager省心。 另

说实话chunk大小真没啥银弹，我最近用langchain的递归切分器调参也调吐了，最后发现跟你embedding模型强相关。bge-large-zh本身对长文本不太友好，我试过超过800字符检索精度就明显掉，现在基本控制在300-500之间。另外建议你别死磕固定值，可以按文档类型混合策略，PDF论文用段落+句子兜底切，代码块单独提取出来走语法树。判断好坏别只看召回，我习惯抽20个query看前三

这问题我上个月刚踩过一遍，110M的BERT转TRT反而变慢太正常了。你注意看下onnxruntime的execution provider是不是真的用上了TRT，有时候CUDA EP和TRT EP混着跑，算子图被拆得稀碎，反而比纯PyTorch的算子融合差。我那次是发现LayerNorm和Gelu被拆成十几个小kernel，每个都有kernel launch开销，12ms变18ms基本就是这浪费

BM25本来就搞不定一词多义，加向量检索才是正解，光调词表治标不治本。

说实话你这配置我试过，问题大概率不在向量召回，Llama 3.2对指令格式特别敏感，你试试把prompt改成让它先复述检索到的内容再回答，效果会好很多。 另外all-MiniLM-L6-v2确实偏弱，换bge-large-zh或者gte-large能明显提升相关度，不过速度会慢点。重排序我建议加上，用bge-reranker-base，top20里重新挑5个，比直接top5靠谱。 Ch

10万条切片真不用纠结，Qdrant单机完全够用，LangChain两边都支持得很好。

固定长度切分确实容易把语义割裂，尤其技术手册里“配置网络”这种概念往往散落在多个章节，单纯按字符数切会让向量检索只匹配字面重合，抓不住真正相关的上下文。我之前也踩过这个坑，后来改成按Markdown标题和段落结构切，再用父子分块（父块存章节摘要，子块存具体段落）做两级检索，效果明显好了不少。另外你提到预处理，建议先把PDF里的页眉页脚、目录和图表说明清理掉，这些噪声特别容易污染embedding。

说实话你这体验太正常了，Q4量化加7B参数在指令遵循上跟在线API的满血版模型本来就不是一个量级，尤其写小红书这种需要强风格控制的场景，差距会更明显。我自己试过类似情况，发现与其纠结温度或few-shot，不如先把系统提示词改成“你是资深小红书运营，输出必须包含3个emoji、每段不超过两行”，把格式硬约束写死，效果会立竿见影。另外你可以试试把任务拆成两步，先让它生成三个标题，再选一个扩写正文，比

这问题我太熟了，上周刚在Milvus上踩完同一个坑。你metadata丢字段大概率不是type写错了，而是MCP的schema定义里漏了filterable这个属性，Chroma那边默认metadata是不参与索引的，必须显式声明成可过滤字段，否则Agent查询时根本不会把条件带进去。另外你存source和page这种字符串加数字的混合类型，field的type最好统一用string，别用int，

这问题我也踩过坑，建议冻结bge只训生成，再把检索片段拼进输入做对比，3:1确实容易背答案。

图片去重这块我试过，用向量检索比感知哈希稳多了，特别是遇到裁剪、加水印或者轻微滤镜的情况，传统哈希基本就废了。日志聚类也有人在做，之前看过一个用Milvus按异常堆栈向量分组的方案，效果还行，但得注意日志文本的embedding质量。其实向量DB在推荐系统、药物分子相似度匹配这些场景都挺能打的，只是RAG太火了，掩盖了其他玩法。GPU既然买了，可以试试把用户行为序列也embedding进去做相似人