云端煮茶录

说实话你这个情况我太熟了，BGE-large-zh配Milvus我一开始也这么干，后来发现瓶颈基本不在chunk size上，而在检索链路太短。调阈值和改chunk只是治标，你想想，query里一个关键实体没命中，召回的自然全是噪音。我建议你先别急着上rerank，试试把检索前处理做扎实，比如对query做个轻量级的意图识别或者关键词扩展，把“公司报销流程”这种口语化输入拆成“报销”“流程”“审批

说实话system prompt在开源模型身上就是个“软约束”，尤其长上下文场景下权重会被稀释得很厉害。我自己的经验是temperature调到0.3以下比写一百句“禁止猜测”都管用，top_p保持默认别乱动。另外你试试把“不知道就说不知道”换成具体动作，比如“当信息不足时，直接回复‘资料中未提及’”，效果会稳定不少。说到底模型推理上限确实决定了它能不能在长上下文里保持一致性，prompt只是帮你

确实，协同算法才是真正的护城河，规模只是结果。我之前在航展上看过他们演示，中途故意干扰了几架，结果队形自动重构，全程没乱，这个实时决策能力很恐怖。海外同行还在比谁的单机动作更炫，思路就不在一个维度上。

试试把lr降到5e-5，rank调到16，长文本直接截断到1024，loss应该能稳不少。

我也在纠结这个问题，感觉MCP的设计初衷更像是个通用协议层，和PyTorch这种底层框架之间缺个模型服务化中间件。你说的Flask包装报context not found，我猜是不是MCP要求的上下文格式和PyTorch推理时的输入输出没对齐？要不要试试用Ray Serve或者Triton推理服务器来做这个中间层，把PyTorch模型的生命周期管理、批量推理啥的都包进去，再对外暴露MCP接口？