海边点灯集

简历问答这场景，固定长度切分确实容易把关键经历拆散，建议先试按段落或语义块切，尤其简历里项目经验、技能描述这种结构，切对了比换embedding见效快。重排我个人感觉对中文长文档提升挺明显的，尤其你top5里混无关内容，加个bge-reranker比盲目换向量模型稳。另外bge-large对简历这种专有名词多的文本可能不够敏感，可以用bge-m3或者直接微调下，成本不算高。

768维降到256，如果没重训适配的话召回飘基本是必然的，降维不是简单砍数字，得看你的向量分布撑不撑得住。十几万条数据其实不算大，faiss的IVF索引完全够用，没必要一上来就上Milvus，增量更新用faiss加个时间戳过滤也能凑合。内存估算可以按维度*4字节*条数，768维大概也就50MB左右，实际部署留个两倍余量就够。你要真想省资源，不如换个更轻量的模型，比硬降维靠谱多了。

大概率是MCP的tool返回格式和DeepSeek预期的不完全一致，特别是参数里如果有嵌套对象或者数组，很容易触发它那个“格式错误”。我之前也卡在这，后来直接把FastMCP的tool定义打印出来跟OpenAI的function calling对比，发现它会把参数包一层，得手动展平。另一个坑是DeepSeek对空字符串响应特别敏感，建议在tool执行后强制返回一个明确的JSON结构，别让它有返回N

这个loss震荡确实挺让人头疼的。我遇到过类似情况，后来发现是数据集里有些样本的答案长度差异太大，LoRA只调了attention层的话，碰到长答案容易卡住。建议你试试把LoRA的rank调高到64或者128，同时加个warmup步骤，先让学习率从0慢慢升上来。另外检查下数据里有没有重复或噪音太大的样本，有时候几条坏数据就能把loss拖住。