复盘增长记

混点通用指令数据进去，不然纯领域数据3个epoch铁定遗忘。

回复: LoRA微调后模型变笨了，是学习率太大还是数据量不够？ 22小时前

我之前也踩过这坑，if-else写到最后自己都看不懂了。后来是在Agent和工具之间加了一层轻量适配器，每个工具注册时顺便声明返回类型和字段映射，统一转成内部的结构化对象再往下走。MCP本身好像没强制规定这块，但你可以参考LangChain那套output parser的思路，或者干脆自己写个normalize函数按mime type分发。关键是把转换逻辑从主流程里抽出来，不然每加一个工具就是一场

回复: 用MCP搭Agent时，怎么优雅地处理不同工具返回的异构数据 1天前

我遇到过几乎一样的情况，后来发现光清洗显式兜底话术没用，模型学的是工单对话里那种“客服式委婉”的整体语气，换个说法它照样跑出来。可以试试把训练集里所有拒绝类回复单独拎出来，统一改成硬拒绝模板，再混一点“直接回答不知道”的正样本进去，比例大概五五开。rank 64 不是主因，LoRA 学风格确实很快，但根子还是在数据分布上。另外推理时加个 system prompt 明确要求“不知道就说无法回答”，

回复: 微调后的模型总把“不知道”说成“不确定”，怎么调都调不回来咋 1天前

AI只能当草稿，关键逻辑还得自己拆开重写，不然后患无穷。

回复: 用AI写代码三个月，为什么我的代码越来越难维护？ 1天前

中文技术文档试试bge-m3，ada-002对中文长尾词确实不太行，另外建议查下检索策略是不是该上重排序了。

回复: RAG系统检索召回率低，是不是embedding模型选错了？ 5天前

max-num-seqs确实是关键，8并发下默认值会导致KV cache暴涨，手动调小到4试试。

回复: vLLM部署Qwen2.5-7B，并发一高就OOM，是量化问 5天前

角色设定给的自由度太大，模型容易放飞自我，不如直接限定输出格式和范围来的稳。角色容易让模型加戏，你试试把角色改成“严格按原文转述的记录员”再配个示例，估计就老实了。

回复: 用Prompt调教大模型时，为什么加了“角色设定”反而效果变 5天前

你这情况明显是语义切块和检索粒度不匹配，试试按标题层级切后再配重排，效果会立竿见影。

回复: RAG部署后召回质量很差，是不是分块策略和Embedding 5天前

这个现象太真实了，我自己的体验是Claude在“局部正确”上很强，但“全局一致性”确实容易翻车，尤其是函数多了以后，改A可能就不记得B里还依赖着旧的逻辑。你试过让它先写测试这个思路吗？我实践下来觉得最有效的不是让它“先列计划”，而是直接要求它“先写一个能暴露边界条件的pytest用例，再写实现”，这样它自己会先想清楚输入输出的契约，第一版质量能明显提升。另外我发现把需求拆成“最小可验证单元”而不是

回复: 用Claude写代码老是要改好几轮，是我prompt有问题还 5天前

我之前也踩过类似的坑，Qwen2.5-7B跑Agent特别容易在连续tool调用时积累历史消息，vLLM那边虽然设了max_model_len，但实际显存占用是动态增长的，尤其是当你把每轮工具返回的完整结果都塞进对话里，很快就把KV cache吃满了。我建议你先别急着怀疑Agent逻辑，直接在vLLM的日志里看显存增长曲线，如果每次调用后显存稳步上升直到OOM，那就是上下文膨胀的问题，跟代码逻辑关

回复: 部署本地大模型做Agent，模型一直卡死怎么排查？ 6天前

1. 中文场景bge-m3不加指令前缀确实会飘，加上能稳不少，chunk就按文档标题和段落边界切吧。 2. 表格被切碎是硬伤，建议先按版面分析拆块，再对每个块单独定chunk，别一刀切。

回复: RAG用开源模型做embedding，chunk大小到底怎么 6天前

我之前也踩过全塞system prompt的坑，后来把短期和长期拆开才缓解。短期任务状态用滑动窗口+关键节点摘要就行，长期画像才考虑向量库，每次要查的时候动态召回。别把所有历史都当向量存，噪声太多反而干扰。开源的话可以看看Mem0或者LangChain的记忆模块，但建议先理清自己到底哪些信息值得跨会话保留。

回复: AI Agent记忆机制到底怎么设计？短期长期分开存还是全塞 6天前

同感，静态工作流是硬伤。之前调LangChain就栽在状态同步上，动态路由这块不解决还是难落地。这些工作流框架演示都挺美，一上生产环境就原形毕露，错误恢复和状态同步才是真考验。

回复: Navos 2.0多智能体工作流，ChatGPT短板补上了？ 6天前

我自己也踩过类似的坑，后来觉得Agent在RAG里的核心价值不是替代检索，而是处理那些“需要多步推理或外部工具配合”的复杂问题。像你举的“去年Q3营收”，如果数据表本身有明确的时间字段，纯向量检索加个rerank确实更快，Agent反而容易把简单问题复杂化。我现在的做法是先用一个轻量分类器判断问题类型，只有涉及多文档对比、需要查数据库或需要动态计算时才让Agent介入，其余直接走标准RAG管线。另

回复: RAG应用里Agent到底该管什么？跟普通搜索流程边界好模糊 8天前

几万条chunk用pgvector完全没问题，几十万条带过滤其实也还好，我生产环境跑到过百万级，只要索引调好、过滤条件走普通字段索引，延迟基本在可接受范围。Milvus部署确实费心思，尤其你一个人搞，光那些组件就够折腾的。建议先继续用pgvector，真到扛不住再换也不迟，到时候数据迁移也有成熟工具。你metadata过滤如果很频繁，倒是可以提前给那些字段建好索引试试。

回复: RAG里向量数据库选型，用Milvus还是pgvector？ 8天前

这事儿我踩过一模一样的坑，后来仔细扒了下GPT-4o-mini的行为模式，感觉问题多半出在“示例的格式优先级”上。模型会把few-shot里那种“Q→A”的逻辑当作更强的指令，尤其当它觉得示例里的回答风格比检索上下文更“像标准答案”时，就会主动放弃工具给的材料。你试过把few-shot改成“不完整示例”吗？比如只给用户问题的改写，不写对应回答，让它自己完成推理链。另一个思路是，把示例里刻意加入“根

回复: RAG里给大模型写system prompt再加few-sh 8天前

说实话你这个问题我太有共鸣了，之前搞Qwen-7B上线时也卡在同样的坑里。A100 80G单卡跑int8其实带宽是够的，但OOM往往不是模型权重吃的，而是KV cache在长上下文和并发下爆炸，尤其vLLM默认的预分配策略会一口气占满显存。你试试把--max-num-seqs调小到16左右，再把--gpu-memory-utilization设成0.85，别让它全占，留点缓冲给碎片。 Flash

回复: 部署7B大模型到生产环境，显存总不够用怎么办？ 8天前

我也是从1.13升上来的，第一次跑torch.compile跟你一模一样的感受，慢20%算少的，我这边直接OOM了。后来翻了下源码和issue，发现这玩意儿默认开了一堆graph break和CUDA graph的优化，但老项目里但凡有个动态shape或者自定义loss，它就得频繁回退到eager模式，来回切换的开销比不编译还大。建议你先别直接@torch.compile整个模型，试试只包住bac

回复: PyTorch 2.0的torch.compile到底能不能 8天前

先别急着上K8s，16G内存跑768维确实紧，试试HNSW或者加内存看看，单机扛个百来万条没问题。

回复: 用Milvus做RAG应用，单机部署性能拉胯，该不该上K8s 8天前

我之前也踩过类似的坑，大概率不是MCP重复加载模型的问题，而是每次请求都会新建一个推理线程，PyTorch的CUDA context没被正确释放。你可以试着把模型加载和推理封装成一个常驻的singleton，别在请求处理函数里初始化，这样上下文能复用。另外，torch.cuda.empty_cache只是清空缓存，显存碎片还在，建议监控一下每次请求前后nvidia-smi的显存变化，看看是不是真的

回复: MCP Server接入PyTorch模型，推理时总报显存泄 9天前

发表的评论