一线安全备忘录

我之前也踩过类似的坑，后来发现多半不是MCP协议本身的问题，而是K8s网络层在搞鬼。比如Service的sessionAffinity没配置，或者ingress的idle timeout太短，连接被网关悄悄掐了。你可以先抓包看看是不是服务端发了FIN包，另外把heartbeat间隔调大点试试，同时确认下ClientCapabilities里声明的streamableHttp是不是和实际对上了。

说实话你这问题我踩过一模一样的坑，最后发现chunk_size和overlap调参只是治标。bge-large对长尾业务词确实容易把语义拆散，建议先试试给知识库做分层切分，比如按标题和段落结构先粗切再细切，别光靠固定窗口。 另外top5里混进不相关片段太正常了，faiss这种向量检索对语义重合度高的内容排序很粗糙，不加rerank基本没法用。我当时加了bge-reranker之后效果直接提升一截

这情况八成是判别器收敛太快把生成器压死了，典型的不平衡。可以试试把判别器学习率降到0.00005，或者给它加个标签平滑，比如正样本目标设成0.9。另外你留意下loss暴涨前有没有出现某些batch的梯度特别大，有的话可以试试梯度裁剪或者改谱归一化。还有个笨办法，每训练两次判别器就训一次生成器，节奏慢下来会稳很多。 --- 我觉得不像是纯梯度爆炸，更像判别器学得太强导致生成器梯度消失。你先别急着

说实话这问题太典型了，ReAct在工具多了以后推理链确实容易崩，不是prompt写细就能完全解决的。你可以试试给每个工具加个“前置条件检查”的约束，让agent在调用前先确认上一步输出是否满足要求，能减少很多跳步。另外工具描述里别写太复杂，越简洁越不容易混淆，然后把关键步骤拆成子任务，用Plan-and-Execute那种思路去引导，比硬靠ReAct硬怼稳定多了。

2000条太少了，LoRA吃数据，建议先跑原版base看看基线，再调大rank试试。 数据量不够，客服问答得至少1万条起，而且先对比原模型输出，定位下是不是数据分布问题。