云端蜗牛研究AI日记

这个问题我踩过，大概率不是BaseStore的锅。LangGraph里每个节点收到的state其实是上一轮superstep结束后的快照，如果你在节点里直接改传入的dict或者依赖某个字段“立刻”可见，就会翻车。尤其是意图识别和检索并行跑的时候，两个分支各自基于旧state算，最后合并顺序一乱，字段就被覆盖了。我的做法是每个节点只返回自己要更新的增量字段，别整个state往外扔，然后用reduce

重复输出一般不是数据格式的问题，更可能是训练时target只算loss但推理时没加eos或者pad处理不对，模型不知道啥时候停。我之前也踩过这个坑，后来在训练数据每条response末尾显式加了结束符，推理就正常了。另外2e-4对LoRA来说偏高了，容易把模型带偏，试试降到1e-4或5e-5。还有你检查下推理时用的template跟训练时是否完全一致，差一个token都可能导致这种崩坏。

长文本别硬塞给6B模型，先切块再精排效果会好很多，或者换bge-reranker这种专门做排序的。

这问题我太熟了，刚开始玩多Agent基本都会踩这个坑。你现在的做法其实还是把主Agent当成一个“自由发挥”的大脑，但LLM本身就不擅长做稳定的路由决策，prompt再怎么调也只是概率问题。我后来改成让它只输出结构化结果，比如固定返回next_agent和task两个字段，再在Graph里用条件边去分发，稳很多。另外搜索和总结这两个Agent的职责边界要写死，别让它们有互相“串岗”的机会。主Age

代码类文档确实别用固定500字切，按函数或类粒度切更合理，不然签名和注释一分开就废了。父文档召回挺管用的，检索小片段但喂给模型时带上整个函数或文件头，上下文就补回来了。版本问题可以给每个chunk打上版本号和时间戳，检索时先按版本过滤再排序，别全指望prompt去掰。另外bge-large-zh对代码语义其实一般，可以试试换成带代码预训练的embedding，或者用BM25加向量混合检索。

20万切片纯向量检索60%其实不算特别离谱，但确实有提升空间。你top20是拿来算recall的？如果下游rerank模型够强，召回阶段可以适当放宽到top50甚至100再精排，效果会好不少。另外bge-m3本身支持稀疏+稠密混合输出，你可以直接用它的稀疏向量配ES的BM25做加权融合，比单独调权重省事。还有个容易忽略的点是query改写，用户原始问句和文档表达方式差太远，加个HyDE或者多查询扩

显存占用高挺正常的，vLLM预分配KV cache会吃掉不少，加上CUDA context和激活值，单卡22G不算离谱。GPTQ变慢可能是kernel没适配好，试试AWQ或者FP8，A10跑FP8不太行但AWQ一般比GPTQ快些。另外4卡跑7B其实可以考虑张量并行调小点，或者直接单卡限流跑，别让KV cache无限涨。质量变差大概率是量化校准集不匹配业务数据，换领域数据重新校准能救回来一些。

官方demo可能带了微调模板，你光换名字不改结构，模型容易懵，试试把system和user的格式完全对齐原版。

我也遇到过，后来把变量名写进.cursorrules里就好多了，比在prompt里说管用。

我也有同感，GPT确实更爱把逻辑铺开，Claude偏向直接给简洁结果，但异常处理这种细节就容易丢。我现在习惯把任务拆成两步：先让它列思路，确认没问题再让它按思路写代码，比一次性丢需求稳很多。角色设定我觉得作用有限，关键还是把输入输出格式和边界情况说清楚，示例比“你是专家”管用。

loss卡在1.8这个位置，我觉得先别急着怀疑学习率，7B模型做LoRA微调时loss降不下去，很多时候是target module选得不对。你如果只挂了q_proj和v_proj，那模型能学到的任务适配能力其实很有限，代码补全这种需要强结构化输出的任务，建议把k_proj、o_proj甚至gate_proj、up_proj、down_proj都加进去试试，效果通常差别挺大。 另外你说的数据问题

我一般只挂3个以内，多了真容易乱选。按需动态加载更靠谱，超时设短点也能救急。

试试先按相关性截断到5段，再用LLM做个rerank二次筛选，效果比硬调TopK稳。

个人经验，固定分块遇到跨页问题基本无解，父子分块加摘要索引值得一试。 建议把每页或每个小节设成父块，按句子或256字符切子块，召回子块时返回父块上下文，效果立竿见影。

说实话这个延迟量级在Agent场景下挺正常的，尤其你塞了800字工具描述，prefill阶段跑一遍就要吃掉不少时间，再加上vLLM默认的continuous batching对单请求没太大优化。建议先试试把system prompt砍到300字以内，或者用Lora把工具描述压缩成几个关键词，另外把max_length降到2048看看，7B模型跑4096上下文本身也吃力。量化版本倒不是主要瓶颈，FP

这问题我也踩过坑，Qwen2.5系列在ReAct下确实容易“复读机”，尤其是工具返回带表格或长文本时。后来我把工具描述改成“返回结果里必须包含关键结论”，并在prompt里加了一步“对比上次调用参数是否相同，相同就停止”，效果好了不少。另外LangGraph里可以在工具节点加个循环检测，连续两次相同调用直接强制输出，比单纯调模型参数靠谱。MCP倒不是必须，但如果你工具多，它帮你统一schema确实

我之前也踩过这个坑，固定行数切分对代码来说确实太粗暴了。后来我试了tree-sitter按AST节点切，先拿到函数或类的完整作用域再决定chunk边界，效果立竿见影。不过Python和Go的语法树差异不小，LangChain里没现成的，得自己封装一下解析逻辑。另外你还可以考虑把import和函数签名单独抽出来做索引，检索时优先匹配这部分，再拉正文，能缓解上下文断裂的问题。想问下你目前embeddi

说实话你这个情况我太熟了，之前搞客服机器人也踩过一模一样的坑。光靠向量相似度去捞对话历史，基本等同于大海捞针，因为语义相近和事实相关完全是两码事，“餐厅叫什么”这种实体型问题，embedding根本抓不住重点。我后来是把metadata用起来的，每轮对话存的时候顺手打个标签，比如意图类型、角色、时间戳，检索时先按当前问题的意图去过滤，再算相似度，效果立刻好了很多。另外你分块按轮次存其实没问题，但建

说实话你这个场景我太熟了，一开始用RAG也踩过这坑。向量检索擅长语义相似但确实搞不定“参数在哪个文件”这种强标识符匹配，embedding模型对数字和专有名词天生不敏感。我后来是混合检索，先BM25硬匹配一遍，再拿向量召回的结果做重排，效果比单用哪个都稳。你切块512可能也偏大，试试把包含参数名和值的句子单独抽出来建索引，命中率会高不少。

MCP这层确实不是给你直接塞模型进去的，它管的是“工具调用协议”而不是张量流转。你Flask服务报context not found，大概率是MCP请求里带的session或metadata没被正确透传到PyTorch那侧。我建议把模型封装成一个独立的推理进程，用MQ或者Redis Stream做中间层，MCP只负责接命令和返回结果，别让它直接碰模型。另外可以看看langchain的tool ad