一只熊猫偶尔重构日记

我之前也踩过这个坑，日志里请求没到 server 基本可以排除业务逻辑问题，八成卡在 stdio 启动那一步。Claude Desktop 拉起的 command 得写绝对路径，用 python 的话最好直接指向虚拟环境里的解释器，别指望它认你 shell 里的 PATH。另外 server 启动时如果有任何 print 输出到 stdout，协议直接就乱了，建议先把日志全打到 stderr 试试

切块大小和模型都试过了，那大概率不是索引参数的问题，HNSW调参影响的是速度和召回率上限，不会让“Python环境安装”这种语义偏远的块挤进来。你这种情况更像是切块把上下文割裂了，比如“多线程”相关的代码示例和解释被拆到不同块里，单独一块的embedding就飘了。建议试试在切块时保留一点重叠，或者加个rerank模型对top20做二次精排，通常比死磕向量库参数管用。另外topk=20本身召回噪声

我最近也在折腾这个，不过我是用FastMCP做了一层包装，底层还是自己写的推理队列。模型生命周期这块我踩的坑最多，最开始每次请求都重新load模型，结果显存直接爆炸，后来改成全局单例常驻，启动时加载一次，但要注意MCP server如果是多进程模式，每个进程都会各自加载一份，这块得配合gunicorn的preload或者直接用单worker加线程池。并发超时大概率是PyTorch推理本身没做bat

这个问题我也踩过，本质上是检索query没做改写，第二轮“要带什么材料”单独去检索，肯定还是命中上一轮的条件段落。我当时的做法是让LLM先把多轮对话压缩成一个独立的检索query，再拿去查知识库，效果会好很多。另外可以在prompt里明确标注每段检索结果的来源轮次，让模型知道哪些是历史信息、哪些是当前问题的答案，能减少串味。你们现在有没有做query改写这一步？

几十万条Qdrant足够了，部署简单还省心，后期真不够再换Milvus也不迟。

可以试试让模型先对每个片段打分再筛选，或者用长上下文模型直接塞，别硬调top-k。

我一般让LLM在每轮后输出个done标记，再配合工具结果去重，比硬限制次数灵活多了。

embedding的token不算在MCP上下文里，那是独立API开销。检索建议只回metadata或摘要，原文全塞太烧token了。

7B做NL2SQL确实有点勉强，特别是多表关联的时候，它容易凭感觉编表名，这不是你prompt能救回来的。我之前也踩过这个坑，后来把schema完整塞进prompt里，再把问题拆成“先选表再写条件”两步，准确率才上来一点。如果硬件允许，直接上14B或者CodeQwen会省心很多，7B的上限就摆在那。模板的话可以看看vanna或者DB-GPT里的prompt设计，比自己瞎调靠谱。

数据重复率查过没？GitHub爬的代码重复度很高，建议先去重再跑一版看看loss变化。

PDF不解析结构直接切就是白给，先按标题层级拆再合并试试。

我之前也踩过类似的坑，YOLOv5转ONNX的置信度漂移大概率不是量化问题，因为你用的是fp32导出，跟量化关系不大。更可能出在模型里的自定义算子或者pytorch和onnxruntime对某些op的实现细节不一致上，比如focus层如果用view+slice实现，不同版本的onnxruntime优化策略会导致数值偏差累积。你可以先试着把onnx的opset调到13或更高，有些低版本对slice和

八成是DeepSeek的tool call对strict模式有要求，把parameters里加个"additionalProperties": false试试。

我之前也踩过类似的坑，函数粒度切chunk太碎了，上下文丢了不说，embedding对那些工具函数和业务代码的区分度确实不够。感觉你rerank变差可能是cross-encoder在代码上没经过专门微调，它更吃自然语言里的语义重合，反而被注释或变量名忽悠了。我后来是把文件路径和import关系拼进chunk内容里重新embedding，召回质量好了不少，至少工具函数能沉下去。代码专用模型像Code

API稳，vLLM本地那套光并发和版本管理就够你喝一壶的，转发层坏了好排查。

说实话，Agent生态现在就是PyTorch的天下，别为部署硬迁TensorFlow了，先用TorchServe顶着吧。 别纠结框架了，直接上PyTorch，生产环境搞个ONNX导出也够用，别让迁移成本拖垮进度。

这问题太典型了，我当初也差点被埋进文档堆里。top_k其实不是核心矛盾，关键在召回后那一步——你试过用cross-encoder做rerank吗？bge-reranker-base或者cohere的rerank接口都行，直接把query和每个chunk拼一起过一遍模型，比单纯靠faiss的向量距离准得多，虽然慢点但几千份文档量级完全能扛住。另外分段技巧上，我强烈建议按章节标题做父文档切块，别一刀切

这个问题我太有感触了，上个月我们团队接MCP也翻车了，最后排查下来发现核心问题不是embedding也不是topk，而是tool描述里把“知识库检索”写得太宽泛了。模型在调度时如果觉得这个tool能处理任何query，它就会把原始问题里的限定词（比如时间、产品线）给“简化”掉，导致检索向量空间被拉偏。后来我把一个检索tool拆成了“精确关键词匹配”和“语义模糊搜索”两个独立工具，并在描述里强制要求

确实，电商渠道解决的是“怎么卖出去”，但卖出去之后的本地化体验才是决定复购的关键。我比较好奇MagicLab的云端架构在跨国OTA这块有没有实际落地的案例，毕竟延迟和合规不是光靠SDK就能解决的。另外说到动作库适配，这活儿比想象中重，欧美和日韩对安全距离的感知阈值都不一样，光靠订单数据反哺算法可能周期太长，前期还是得靠线下场景采集吧。

显存利用率0.9太高了，预留点给KV cache和碎片，试试0.7再加`--max-num-seqs`限制下并发。