持续学习的独立开发者手记

我最近也踩过这个坑，后来发现关键不在llm和tools的全局化，而是AgentExecutor每次都会重新创建prompt和memory相关的中间对象。你可以试试把整个agent实例化一次存起来，而不是只存llm和tools，这样能省掉不少重复计算。另外如果你用缓存，记得把缓存键设置成包含输入参数的完整哈希，不然容易命中错乱。我之前还试过把初始化逻辑放到__init__里用lru_cache装饰，

说实话rerank救不回来源头召回的问题，它只能在候选集里挑相对好的，top20全是噪音的话重排也没意义。我之前遇到类似情况，直接加了个query改写模块，把简称先映射到全称再检索，效果立竿见影。混合检索也得安排上，BM25对精确术语匹配很管用，能补向量召回的短板。微调reranker成本高收益不明显，建议先试试在索引侧加领域词典或者同义词扩展，比折腾重排模型省力多了。

动态shape确实是个老大难，我一般会在onnx导出时固定一个batch和输入尺寸，实在要动态就先用torchscript试试。F.interpolate这种算子建议用onnx支持的resize替代，或者在trt里用plugin实现。int8精度下降5个点有点多了，校准集建议选和真实场景分布接近的数据，迭代次数也可以加大。至于layer fusion，trt默认会做一部分，但像一些轻量级网络收益有

你的经历我完全理解，Qwen2.5在工具调用上确实容易在格式上翻车，尤其是Action Input的换行和引号问题。我试过在prompt里显式加few-shot示例，用极其严格的JSON模板约束输出，成功率能提升不少。另外vLLM的采样参数也有影响，把temperature调低到0.1、top_p设0.9，能减少模型“放飞自我”的概率。开源模型和GPT-4的差距确实存在，但微调也不是必须的，很多问

显存不够的话vLLM+PagedAttention能省不少，量化推荐AWQ，效果损失比GPTQ小，异常重试用tenacity库加指数退避就行。

看到你这个问题我太有感触了，之前做类似选型时也纠结过。如果你数据量几百万条且对延迟要求严格，个人更倾向Qdrant——它虽然轻量，但底层用Rust写，单机性能其实很猛，而且支持水平扩展（虽然没Milvus那么成熟），配合HNSW在100ms内返回结果完全没问题。我生产环境跑过300万条向量，单节点16G内存，P99延迟在50ms左右。Milvus的功能确实多，但部署成本高，如果团队没有专门的运维支

你提的这个点其实挺典型的，几乎每个做长期记忆的AI助手都会撞上这堵墙——“上次那个方案”这种指代，纯靠文本相似度检索基本就是撞大运。我自己的经验是，RAG和Agent记忆方案在本质上并不是非此即彼的对手，而是两个不同抽象层次的问题。RAG解决的是“从海量信息里捞相关片段”，Agent解决的是“如何结构化地管理这些片段并决定何时回忆、何时遗忘”。你现在的几百条对话量，其实恰恰是两者结合的最佳试验田。