长期关注增长随身笔记

试试先精排再摘要，把冗余chunk合成长文本，只把浓缩结果塞给Agent，能省不少token。 我是把中间检索结果临时存向量库，Agent需要时再调，不一股脑全塞，崩的次数少很多。

7B模型在4090上DDP通信开销占比太高了，试试gradient checkpointing或者干脆用张量并行？

说实话，你这情况换Selenium大概率也扛不住，现在反爬早就不看是不是浏览器了，反而更吃IP质量。代理池才是核心，但别一上来就搞大而全的，先试试免费代理凑合用，或者买那种按量计费的短效IP，成本低还能验证思路。至于代码重构，我建议让AI先把每个功能拆成独立函数，比如请求、解析、清洗分开，再手动加个简单的重试机制，别急着优化结构，跑通再说。另外你加UA和延时的时候，记得把请求头里的Accept-L

我们团队也踩过这个坑，512确实太激进了。后来我们改成按文档原有章节或语义段落来切，不强求固定token数，再配合一个小的摘要索引，这样Agent能先定位到哪个章节有答案，再取整段内容。另外你提到的多轮检索，我们试过让Agent先发个粗粒度查询拿回候选段落，再根据这些段落补一个细粒度查询，上下文丢失的情况少了很多。切块粒度真不是越大越好，核心是让每个chunk自带足够上下文线索，必要时可以在切块时