向内求解商业修炼册
Lv.1记录从不会到会、从能用到做好。当前重点关注商业分析，通过业务流程拆解、数字化方案落地持续提升能力；更关注能够真正落地的方法，并把过程整理成可复用的学习记录。
发表的评论
你这数据量用pgvector真别硬扛，几百万条加过滤条件后延迟和召回率都容易崩。我生产环境两个都跑过，Milvus在内存占用上确实比Qdrant高不少，但Qdrant的payload索引做复杂过滤时容易踩坑，召回率调起来更费劲。K8s迁移的话其实都差不多，反而Qdrant单机部署更省心，Milvus分布式组件多，运维日志能看哭你。建议先拿Qdrant试点，等真扛不住了再上Milvus也不迟。
我一开始也被这问题烦得不行，后来发现主要是Cursor的自动补全延迟阈值太低，你试试在设置里把“触发延迟”拉到300ms以上，或者关掉“跨文件补全”，只保留当前文件内的建议。MCP本身没有直接调权重的参数，但你可以给Server端加个中间层，过滤掉置信度低于某个值的补全请求。另外我习惯用Tab手动接受，把Enter改成换行，这样即使它提前补了，我也可以不理会继续打我的。
建议带上，但别原样照搬，可以精简成更短的角色设定，效果会比一模一样更稳。
这问题我也踩过坑，no_grad确实干净但后续RLHF就得全拆开，建议直接用现成的Agent框架比如LangChain或Tianshou，别自己硬撸。 多步推理计算图用trl库的PPO trainer封装挺省心的，手写循环调参时哭都来不及。
按语义切分加滑动窗口试试，我用sentence-transformers做边界检测比固定tokens靠谱不少。
我也遇到过这个问题，后来试了把历史对话先压缩成一句话的“当前状态摘要”再拼到query里，效果比直接塞整段历史好不少。可以参考LangChain那个ConversationSummaryMemory的思路，让LLM每轮结束后自动生成精简版背景。另外，检索时把历史对话里的高频实体词单独拎出来做权重加成，也能减少“跑偏”的概率，你可以试试看。
这问题我上周刚踩过坑。LangChain的Agent对工具描述的敏感度比你想象的高得多，特别是工具名称和参数描述里的歧义词，模型很容易选错。建议你把每个工具的description写得像给实习生看的操作手册，明确说清“什么时候用这个工具”和“绝对不要用这个工具的场景”。另外temperature降到0.1以下试试，太高会让模型在工具选择上更“发散”。