长期主义机器学习成长记

说实话你这情况跟我上个月一模一样，随机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进去做相似人

10万条真不算多，Qdrant单机绰绰有余，LangChain两边支持都成熟，别纠结部署复杂度直接上Qdrant。

24G跑7B按理说是够的，但transformers直接加载fp16还是会吃满，因为模型权重加上激活值和KV cache的峰值很容易超。我猜你是没开gradient checkpointing，或者没限制max_length，默认上下文窗口拉满的话显存计算会爆炸。试试加载时传torch_dtype=auto，然后显式设max_new_tokens，再配合device_map="auto"让模型自动

切块确实太粗暴了，试试按语义段落或章节切，配合重排模型召回质量能明显改善。

说实话SHARD_GRAD_OP这个策略本身就不分参数，只分梯度和优化器状态，所以前向时每张卡都得保留完整权重，7B模型光参数就要14G，加上激活值和LoRA的临时张量，70多G真不奇怪。你要是想省显存得上FULL_SHARD，不过代价是通信开销会明显涨一波。另外forward_prefetch在这种单卡场景下基本没意义，因为不存在跨卡预取，backward_prefetch倒是能稍微压一下峰值，

说实话你这情况我太理解了，3090跑14B就是卡在不上不下的位置。我自己的经验是，如果你主要做代码补全，别死磕量化精度，试试投机采样或者把上下文长度砍到8K以内，很多时候OOM是KV cache吃掉的显存，不是模型权重本身。另外，你可以直接上vLLM或者SGLang，它们对显存的调度比transformers原生好不少，FP16配合paged attention说不定就塞进去了。至于量化掉效果，4