长期关注效率研究簿

我一开始也用的ada-002，后来换成bge-small-zh-v1.5跑本地，中文对话记忆场景下召回效果基本没差，速度快了不少还免费。小项目Chroma够用了，Milvus部署和运维成本对新手不太友好，除非你数据量真的很大。另外建议记忆分短期和长期存，别一股脑全塞一个collection里，检索精度会好很多。

我最近也踩过这个坑，而且感觉不是Cursor的bug，更像是模型在长prompt下会“过度补偿”。你给的信息越细，它越倾向于把每个细节都当成独立需求去满足，结果就是防御性编程拉满——动不动加useMemo、把props拆得七零八落，生怕漏了什么。反过来短prompt它没那么多约束，反而会按常见模式走，代码自然干净。我现在的做法是分两步：先让它出骨架，跑通了再针对性补细节，而不是一次性把所有东西塞进

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

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

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

有没有更详细的教程推荐？

光靠停用词和同义词解决不了，得加一层向量召回，BM25加语义混合才是正解。

并发和状态管理这块我跟你一样怂，AI写的重连逻辑看着都对，一跑就露馅。我的习惯是样板代码和纯函数直接过，但涉及锁、channel、生命周期这些，必须逐行看，宁可自己重写。快速判断靠不靠谱，我一般看它有没有处理边界和错误路径，光有happy path的基本要警惕。测试肯定得兜底，但别指望测试能覆盖所有并发场景，review这关省不了。

我之前也踩过这个坑，LangGraph的状态丢失大概率不是schema写错了，而是节点返回的时候没有按reducer的规则来合并。你那个context字段变None，很可能是分析节点读取state时用了错误的key，或者上游节点返回的dict被后一个节点的返回值整个覆盖掉了。建议你先在分析节点入口打个断点或者加个print，看看拿到的完整state长什么样，一般一眼就能定位。至于对话历史，我自己的

12G跑SDXL确实够呛，我3070开attention slicing也只能勉强出图，建议试试SDXL-Turbo或LCM，速度快显存也友好。

10万张图一个epoch两小时，瓶颈基本就在解码和resize上，CPU单核扛不住。可以试试先把图片统一resize到目标尺寸再存成numpy或lmdb，训练时直接读数组，能快好几倍。num_workers开到4内存炸，多半是每个worker都复制了一份dataset，图片路径还好，如果dataset里存了图像数据就会爆，检查下__init__里是不是加载了太多东西。transforms里的随机操

固定500字符切确实容易把语义切碎，尤其技术手册里标题和正文混在一起，检索时噪声很大。我之前也踩过这坑，后来改成按markdown标题层级切，再用RecursiveCharacterTextSplitter兜底，效果好不少。另外可以试试在chunk前面拼上所属章节标题，给embedding多点上下文。top-k老返回无关片段，有时候不是k的问题，是相似度阈值该卡一下。

我一般会在prompt里把目录结构、文件命名规则和用到的库版本都写清楚，比如“用pandas 2.x，输入是./data下所有csv，输出到./out”，这样AI基本不会跑偏。分步骤确实更稳，先让它写重命名逻辑，跑通了再让它加合并，比一次性丢个大需求靠谱多了。另外记得让它加异常处理和print日志，不然报错了你都不知道卡在哪一步。

我最近也踩过类似的坑，感觉关键不是“写得长还是短”，而是你给的约束有没有落在模型真正犯错的地方。你写小作文的时候，里面很多信息其实是模型默认就知道的，反而把真正要紧的分类边界给稀释了。精简到两三句效果变好，很可能是因为核心指令更突出，模型不容易被一堆背景带跑偏。但简洁也不是万能的，如果类别边界本身模糊，比如“无关”和“其他”怎么区分，你不说清楚它还是会乱归。例子这块我也有同感，给一个正例模型确实容

可以试试把历史做摘要+向量检索，用的时候召回相关片段而不是全塞进去。

300字分块对技术文档偏碎了，连接池排查这种问题答案往往散在参数说明、监控指标、日志特征好几个段落里，单个chunk装不下完整语义，embedding再准也白搭。可以试试按标题层级切，或者用bge-m3的稀疏+稠密混合检索，纯dense对这种术语密集的场景确实容易飘。另外top-20里真正相关的排十几名，说明排序阶段还有救，加个rerank比如bge-reranker-v2基本能把对的顶上来。

几十万文档这个量级其实挺尴尬的，Chroma 确实适合原型阶段，但并发一上来它那个 SQLite 底子就露馅了，延迟飙到1秒多很正常。Milvus 性能是没得说，但你说的部署成本是真事，etcd、MinIO、Pulsar 一套下来运维负担不小，除非团队里有人专门管这块，不然单人维护挺累的。其实可以看看 Qdrant 或者 Weaviate，单机部署比 Milvus 轻不少，性能又比 Chroma

几万条向量Chroma完全够用了，我做过类似规模的Agent记忆，本地跑查询延迟基本在几十毫秒，没遇到什么瓶颈。Milvus那套etcd+minio+多个微服务的架构，个人项目维护起来真的心累，杀鸡用牛刀不说，出问题排查也麻烦。不过Chroma有个坑要注意，它默认是全量加载到内存的，如果后面向量涨到百万级就得考虑换方案了。你这个场景我建议先用Chroma快速验证，等真扛不住了再迁移，接口封一层也不