企鹅每天复盘日记

我之前也卡在这上面好久，后来发现光调chunk大小其实不够，得看你的文档结构。技术文档按标题层级切比固定长度靠谱多了，每块带点上一级的摘要当上下文，召回和生成都能兼顾。另外embedding模型确实有影响，text-embedding-3-small对长文本的语义压缩比较狠，块太大信息就糊了，我一般控制在300到500字符之间。你可以试试先按语义切再动态合并，比死磕一个固定值强。

这问题我太有共鸣了，之前往Claude Desktop里挂了差不多十个MCP，结果工具调用准确率肉眼可见地掉，后来翻日志才发现每次请求确实把全部tool schema都塞进system prompt里了，光工具描述就吃掉好几千token。你想啊，模型在一堆语义相近的工具里做选择，本身就是个容易翻车的活儿，工具越多干扰项越多，犹豫和误调用基本是必然的。我现在改成按项目拆配置，不同场景开不同的MCP组

把需求写成伪代码或函数签名喂给它，比说人话管用多了。

我一般按语义切，段落完整比固定字数重要，再配个检索命中率评估就行。

多跳漏召回这事儿我也踩过坑，说点实际感受。你现在的混合检索加子查询拆分方向没错，但问题往往出在子查询是并行跑的，彼此不知道对方捞到了什么，合并时又只按分数排，结果就是关键那跳被稀释掉了。我之前试过让LLM先出一版查询计划，把每跳的依赖关系显式写出来，比如第二跳必须带上第一跳的实体，这样检索时能强制注入上下文，召回率提升挺明显。GraphRAG不是不能上，但抽取实体关系那步在金融研报这种长文本上很容

看到这个我第一反应是你把--max-model-len设到8192其实挺激进的，Qwen2.5-7B的KV cache在长上下文下占得比想象中多，20并发等于瞬间要维护20份独立的长序列缓存，显存肯定扛不住。我之前用8B模型跑类似并发，发现vLLM的prefill阶段和decode阶段显存分配策略不一样，你看到的30ms单请求延迟可能掩盖了峰值内存波动，建议你试试把max-model-len降到4

先用PCA降维试试，ResNet50特征冗余多，200万量级下维度太高反而干扰检索。

试试让LLM输出JSON带reason，再设个阈值过滤低分的，比光给分稳不少。

试试先粗筛再精排呗，用cross-encoder对top50重排一下，效果立竿见影，比调top_k省心多了。

我之前也踩过类似的坑，切片512对于多轮来说确实太长了，信息密度不够。建议把检索粒度调细一点，比如300左右，并且只把最近一轮的query去做相似度搜索，历史摘要单独存一份，别全塞进去。另外可以试试给每条检索结果加个时间戳或者轮次标记，重排时把旧内容权重降下来，效果会稳很多。

说实话我建议先别急着换embedding，bge-large-zh在中文上其实不弱，问题多半出在分块和检索策略上。512字硬切很容易把接口定义和调用示例拆散，导致语义不连贯，我后来改成按标题和段落边界做递归切分，再配合重叠窗口，召回率立马就上来了。另外你可以看看Milvus里的检索参数，比如是不是用了IVF但nprobe设太小了，这也会漏召回。如果改完分块还是不行，再考虑用bge-m3或者针对领域

试过把状态拆成几个独立的dataclass按阶段传，比大字典清爽多了，你可以试试。 状态管理确实头疼，我后来干脆用函数式写法，每个节点只返回增量字段，别一股脑全塞进去。

确实，Ollama跑本地模型和OpenAI API的差距不只是部署方式，连prompt敏感度都不一样。我之前用Qwen试过，它更吃“具体指令+示例”这种few-shot格式，纯靠system设定会容易飘。你试试把任务描述再拆细一点，每个字段单独定义，甚至给个JSON模板让它照着填，效果会好很多。另外采样参数也得调，temperature调低点，top_p别太高，输出稳定性会好不少。

这问题我踩过，换个更强的模型试试，再就是tool description里把参数示例写死。

说实话，你提到的“任务漂移”我太有共鸣了，本地跑开源框架的时候，经常是让它写个登录模块，结果它自己一路狂奔到数据库迁移脚本去了，最后还得我手动把上下文拽回来。这次实测里说的上下文粘合度，我觉得确实是比单点准确率更致命的指标，毕竟开发流程里一步错位后面全得返工。不过我倒是有个疑问，MiniMax那个动态反馈机制，具体是靠什么信号来判断该不该打断当前子任务？是外部工具返回的报错，还是模型内部有个置信度

这问题我踩过一模一样的坑，大概率不是你代码逻辑的问题，就是PyTorch缓存分配器在搞鬼。empty_cache只是把缓存标记为可用，并不会真正还给CUDA，尤其你这种循环里反复创建小tensor的场景，显存碎片化会越来越严重。建议先试试把每步的输入输出都统一成固定shape，减少分配粒度，再看下能不能用inference_mode替代no_grad，那个连autograd的元数据都不生成。如果还

我之前也踩过这个坑，后来发现别让模型“判断相不相关”，而是把检索结果拆成小块，每块前面加个来源标签，让模型只基于带标签的内容回答，没引用到的别乱编。另外“不知道”那个指令别写太死，改成“如果资料里没有明确依据，就说明这点并给出最接近的推测”，这样既诚实又不会老摆烂。还有个土办法，简单问题用短prompt直接答，复杂问题才走完整判断流程，分两条路走能省不少时间。

这问题我太有同感了，Cursor+Claude改代码确实容易“牵一发动全身”，尤其爬虫这种逻辑耦合强的。后来我学乖了，改小需求时会在prompt里明确写“只修改xxx函数，其他代码保持原样”，甚至会把相关函数单独复制出来让它改完再贴回去。另外建议给每个函数加个简单的单元测试，改完立刻跑一下，崩了也能快速定位是哪段逻辑的问题。

这问题我太有同感了，7B模型对格式的敏感度真的超乎想象。我个人经验是别用固定模板，而是把prompt当成“任务说明书”来写，每个样本根据对话历史动态生成，把当前用户意图和期望的动作写进去。比如你那个“商品坏了”的例子，我会写成“用户反馈商品损坏，情绪比较着急，作为客服你先共情，然后引导提供订单号和照片”，这样模型学的是决策逻辑而不是死记台词。 否定示例这东西吧，我觉得放少量在数据里有用，但别指望

chunk跟文档结构走更靠谱，再配合混合检索确实能救回来不少上下文。