旷野望月集
Lv.1把键盘敲过的夜晚整理成文字，关注技术学习与数字生活，记录项目实践记录、学习路径整理和真实实践中的思考；不追求堆砌概念，只记录验证过的经验。保持好奇，保持实践，也保持独立判断。
发表的评论
几万条数据就变慢，感觉不像是数据量的问题，更像是ChromaDB的HNSW参数没调好，默认的ef和M值偏保守，你先把ef_search调大试试。我之前在类似配置上跑过十万级，调完参数后延迟能压到几十毫秒，4核16G完全够用。Milvus单机版其实也没想象中重，但多跑一个组件就多一份运维负担，Agent本身还要吃内存，能省则省。真不够用的话可以看看Qdrant，部署比Milvus轻，过滤和持久化做得
你这个问题基本就是计算图把历史全串上了，detach历史tensor如果只detach了输入没detach中间激活，backward照样会往回传。可以试试每个step只对当前步的loss做backward，历史部分用no_grad编码成hidden state或者embedding存着，模型参数更新只走当前步的计算图。截断BPTT是最省事的，隔几步断一次图，效果差点但显存稳。另外确认下optimi
A10 24G跑7B按理说是够的，但vLLM这玩意儿对显存的计算比我们想象的要"贪"一些。你max-model-len设4096，gpu-memory-utilization 0.9，看起来留了10%余量，但vLLM启动时profile的峰值显存和实际压测时的峰值经常对不上，尤其是KV cache的block分配策略，并发一上来它会按最大并发去预留block，很容易就把那点余量吃穿了。我之前也踩过
你这个问题我踩过一模一样的坑，5万切片用text-embedding-3-small其实够用，换Milvus大概率不会有什么质变，别在这上面花冤枉钱。真正的问题很可能是纯向量召回本身就是个粗筛，你指望它top5直接准是不现实的，混进报销流程这种就是典型的语义漂移——年假和报销在embedding空间里可能都落在“公司制度流程”这个大簇里。我建议你先把召回数量放大到50甚至100，然后接一个cros
14B单卡A100跑vLLM绰绰有余，5-10人并发基本无压力，部署也不复杂，流式输出原生支持。
Milvus集群运维确实重，小团队Qdrant更省心，但数据量上亿后Milvus的分布式优势就出来了。
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
我也踩过这个坑，agent为了过测试真的啥都敢改，后来加了个diff范围白名单才稍微好点，就是提前根据issue定位到大概涉及哪些文件，超出范围直接打回。你那个禁止改测试文件的约束思路对，但还得加上“单次改动行数上限”和“必须跑全量测试”，不然它专挑局部测试骗过去。中间层的话可以看看有没有现成的AST diff工具做二次校验，比纯文本diff靠谱。这方向我觉得能做，但得接受它只能处理低风险bug，
16G跑Agent确实紧，试试4bit量化加小模型做规划，影响没那么大。
800字工具描述确实会让prefill拖后腿，试试精简下prompt或开chunked prefill看看。
你这个问题大概率出在检索结果没做精排。top_k=10直接喂给LLM，噪声肯定多，加个rerank模型比如bge-reranker或者cohere的，先粗召回再精排取前3-4条，效果会好很多。另外Prompt里可以明确写“只根据以下上下文回答，无关信息直接忽略”，但别指望光靠Prompt解决，检索质量才是根。你chunk重叠128有点大，试试降到64，减少冗余片段干扰。
多工具串联确实容易崩，我后来是把流程拆成固定步骤，用LangGraph做状态机，每个节点只负责一个工具，反而稳很多。ReAct那种自由发挥适合简单任务，步骤一多就容易绕圈。prompt里把工具调用顺序和依赖关系写死也有帮助，别让它自己规划。
我之前也踩过一模一样的坑，后来发现八成是tool description写得太模糊，模型压根分不清啥时候该调哪个。你试试把每个工具的输入输出格式和适用场景写清楚，再在prompt里明确要求“拿到搜索结果后必须调用Python工具”。另外max_iterations别设太大，配合early_stopping能少很多死循环。如果还不行，建议直接换LangGraph手动控制流程，比ReAct模板稳得多。