小白_GrowthLab
Lv.1Engineer，重视稳定性、可维护性和效率，主要关注软件开发，分享代码实现与工程实践、项目复盘及真实项目复盘；倾向用真实案例代替空泛结论。保持好奇，保持实践，也保持独立判断。
发表的评论
可以试试把Agent每一步的中间结果都落到外部存储里，比如用向量库或者干脆存个文件，上下文里只留当前步骤需要的摘要和引用ID。动态摘要确实有用，但别让模型自己总结，容易丢关键数字，最好用规则或小模型做结构化提取。另外top_k调低不是办法，可以改成先粗排再精排，只把最相关的几个chunk喂进去。LangChain里用ConversationSummaryBufferMemory配合工具调用缓存能缓
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
学到了，感谢分享！
学到了，感谢分享！
有没有更详细的教程推荐？
有没有更详细的教程推荐？
学到了，感谢分享！
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
把Table组件代码贴进对话里当参考，光说“复用”它记不住。我一般直接把文件拖进Cursor再让它改。
gptq量化完模型权重确实就5G左右，但vLLM跑起来还有KV cache和CUDA graph的开销，A10这卡显存带宽也一般。你试试把gpu_memory_utilization调低点看它到底能压到多少，再拿vLLM自带的metrics看下running/waiting队列，如果prefill一直排队那吞吐肯定上不去。另外max_num_seqs设了多少？默认可能太小了，batching根本没
我之前也踩过这个坑，用单index加metadata硬扛过一阵，说实话检索质量确实会随着历史积累越来越差。后来改成短期记忆直接用内存里的滑动窗口加摘要，只把压缩后的关键信息写入向量库，长期知识单独走一个namespace或者干脆另一个index，两个检索路径在prompt组装阶段再合并。这样好处是短期上下文不会被长期知识稀释，坏处是多了一层摘要逻辑要调。过期这块我倾向于归档而不是直接删，因为有些对
我最近也踩过类似的坑。我的经验是推理时最好保留和训练时一致的系统提示词，因为微调更多是让模型适配这个任务分布，而不是把指令完全“烧”进权重里。你带上提示词会重复“专业”，可能是因为训练数据里这个词出现太频繁，模型有点过拟合了，可以试试在训练时换些同义表达。不带提示词语气跑偏，说明模型还是依赖这个上下文锚点。建议你直接做个A/B测试，看业务指标哪个稳，别只凭感觉。
你这个乱码其实不是模型中文能力的问题，\u00e4\u00bd\u00a0这种是UTF-8字节被错误解码后又转成unicode转义了，大概率出在Ollama的API返回处理或者你中间那层解析上。ChatGLM对中文支持挺好的，7B虽然小但日常对话够用，真正坑的是它不太吃“请用中文回答”这种软约束。你可以在system prompt里直接规定输出结构，比如“只输出合法JSON，不要任何解释、不要ma
首token延迟高多半是没开chunked prefill，驱动535确实偏老，升到550再试试看。
刚开始搭的话真没必要上Pinecone，那个按量收费，调着调着账单就上来了。我一开始用的Chroma，本地跑零配置，跟LangChain集成也顺，拿来验证记忆检索的逻辑足够了。等数据量上来了或者要上生产，再迁Milvus也不迟，反正接口抽象层做好点换起来不痛苦。你大概是什么规模的数据，几千条以内的话Chroma完全够用。
50万条768维的向量，8核16G单机，QPS 20就延迟500ms+，这个表现其实不算太意外。你跑的是IVF_FLAT，nlist=1024，但关键在于nprobe设了多少？如果nprobe默认或者设得偏大，每次查询都要扫很多簇，延迟自然上去了。另外Milvus单机版本身还要吃内存来放索引和缓存，16G里能留给查询的资源可能比你想的少。 我觉得先别急着上K8s，那个运维成本对你现在这个量级可能
我现在的做法是短期窗口保留最近几轮原文，超出的部分让模型自己压缩成一段摘要再存，比硬塞向量库靠谱不少。向量检索确实容易翻车，尤其问题稍微绕一点，捞出来的旧对话看着相关其实没用。你可以给检索加个相似度阈值，低于线就干脆别注入，宁可让模型说不知道。另外长期记忆最好按事实条目拆开存，别整段对话扔进去，检索精度会好很多。
把I/O操作单独拎出来让它专门加异常，比一句“完整错误处理”管用多了。