小北Dev手记

试试把上一轮检索到的文档片段也塞进query里，比纯拼对话历史更聚焦。

我也遇到过类似情况，感觉CoT不是万能钥匙。像那种步骤间强依赖、中间结果需要精确保持的运算题，硬加“一步步来”反而容易让模型在中间自我干扰。我后来只在需要解释思路或者多跳推理的场景用CoT，纯计算题就直接问，准确率反而更稳。你可以试试把推理模板收得更死，比如限定每步只做一件事、不许回头改前面的结论，看看会不会好点。

3060 12G跑7B长文本确实紧，我试过AWQ比GPTQ在这个场景下稳一点，4bit下10K能撑住但得把vLLM的gpu_memory_utilization调到0.9左右，别留太多余量。Flash Attention其实vLLM新版默认就开了，你要确认下是不是真生效了，有时候CUDA版本对不上就悄悄回退了。StreamingLLM我跑出来也是时好时坏，感觉对总结类任务不太友好，容易丢中间的关键

写得挺好，建议补充一些性能数据。

7b模型本身指令遵循就弱一些，q4量化再掉点精度，跟云端API确实没法比。我跑qwen2.5的时候发现它对prompt格式特别敏感，few-shot示例的格式和分隔符稍微不一致就容易乱套，你试试把示例精简到一两个、格式统一成模型训练时的对话模板看看。另外fp16还飘的话，可能得看下ollama的默认采样参数，temperature和repeat_penalty跟官方API不一定一样，调一下说不定就

prompt 1.5k tokens的话prefill占比不小，QPS上不去挺正常的。你这个显存跑满但利用率才30%，感觉是KV cache把max_num_seqs撑太大了，调度反而变慢，可以试试降到64-128看看。另外确认下是不是开了enable_prefix_caching或者chunked prefill，版本太旧确实会有调度上的坑，建议升到最新版对比下。还有压测的并发数和请求方式也影响

自己写状态机吧，LangChain那套解析对长CoT真不太行，我也踩过这坑。

几百万数据量、100ms延迟这两个条件其实Qdrant完全扛得住，我这边四百万条用Qdrant单节点，p99也就三四十毫秒。Milvus功能确实全，但你要是团队没人专门维护，etcd加minio那套组合拳够喝一壶的，小项目容易过度设计。HNSW的m和ef_construct别照抄默认值，m太高内存吃不消，ef_construct太小召回率会掉，建议先在真实数据上跑个召回率对比再定。另外Qdrant

学到了，感谢分享！

学到了，感谢分享！

7B模型做function calling确实容易翻车，我拿qwen2.5-7b试过类似场景，参数漏字段、格式跑偏都很常见。建议先确认你用的推理框架有没有正确注入tool的schema，vllm和ollama对这块支持差别挺大的。另外prompt里最好给一两个完整的调用示例，few-shot对7B提升很明显。想更稳的话可以看看xlam-7b或者gorilla相关的微调版本，专门为工具调用训过的，比

我现在的用法是两个配合着来，Cursor Agent适合从零搭骨架，但一定要在干净的git分支上跑，改乱了直接reset比手动回滚省心。Claude Code那边你可以试试配个allowlist，把常用的只读命令和测试命令放行，就不用每次都确认了。真正写业务逻辑的时候我反而会切回普通模式，Agent全自动跑CRUD这种重复代码还行，稍微有点上下文依赖就容易翻车。

显存一路涨到OOM，八成是某个地方把计算图留住了。重点查一下你的loss是不是累加到了列表里，或者验证阶段忘了加torch.no_grad()，这两个坑我踩过好几次。可以装个torch.cuda.memory_summary()打一下快照，再配合pytorch_memlab按行看，基本能定位到是哪一层在漏。另外DeepLabV3+的ASPP里如果有循环反复forward同一批数据，也容易出这问题，

ResNet50在电商场景确实有点吃力，它本来就不是为细粒度商品匹配设计的。你可以试试CLIP或DINOv2这类模型，或者用ArcFace在商品数据上微调一下，embedding质量会好很多。另外L2距离对归一化特征不太合适，换成cosine再试试，效果可能立竿见影。nlist和nprobe调到合理范围就行，别在这上面花太多精力，瓶颈大概率在特征端。

我之前也踩过这个坑，后来发现光靠删旧chunk不够，Chroma的索引有时候没真正刷新，得确认delete和add是不是原子操作。你可以试试在metadata里加个version或updated_at字段，检索时用filter强制只查最新版本，比rerank后再筛更靠谱。另外embedding模型如果没换，新旧内容的向量空间其实是一样的，top-k确实容易混进旧的，建议把过期文档直接软删除或者单独

我也卡在这块，后来用摘要压缩历史对话，短期只留最近几轮，感觉token省了不少。

这个问题挺常见的，我一开始也踩过类似的坑。你提到的`Annotated`加`operator.add`，关键在于它得写在**父图**的state定义上，而不是子Agent自己的state里。子Agent返回的如果是整个state的更新，LangGraph默认是按key做浅合并，但遇到嵌套结构或者字段类型不一致时，就很容易直接替换掉。尤其是tool返回的结果如果是个dict，节点返回时又没包在正确的

新手直接PyTorch吧，调试起来直观，踩坑也少。

两张4090跑7B的LoRA按理说不至于batch size只能开2，你先确认下是不是把max_length直接拉到2048甚至更高了？长文本那块特别吃激活显存，超过1500 tokens的样本建议单独拎出来做长度分桶，别跟短样本混在一个batch里，不然padding浪费的显存很吓人。loss跳水又回落这种情况，我第一反应是学习率2e-4对LoRA偏高了，尤其你batch小、梯度噪声大，试试降到

500的chunk对这种技术手册确实偏小了，参数说明经常跨段，切完语义就断了。可以试试按标题层级做递归切分，或者用MarkdownHeaderTextSplitter保留结构信息。Reranker值得加，bge-reranker这类模型对Top20重排效果挺明显，成本也不高。另外embedding模型换成bge-m3或者多语言版，中文手册的召回会好不少。