小北Dev手记

2万条判决书杂讯多，先抽100条看看是不是长文本截断把答案切没了，这比调参管用。

我现在的做法是混合切分：先用标题和段落做一级切分，太长的段落再按句子边界切到300-500字，尽量别硬截断。语义切分我也试过，效果不稳定还慢，后来只在关键文档上开。表格和代码块建议单独走一条链路，别混在正文里切，不然embedding基本废掉。可以试试unstructured或者semchunk这类工具，比手写规则省心点。

这个坑我也踩过，Prompt确实没法可靠地锁死工具调用顺序，模型本质上是概率生成的，你写再多“必须”它该跳还是跳。我的经验是顺序依赖这种硬逻辑最好放到客户端代码里做编排，比如第一个工具返回后再触发第二轮请求，别指望一轮对话里模型自己串起来。MCP本身不负责调度顺序，它只是把工具描述暴露给模型，决定权还是在模型和你的调用框架。可以在Prompt里描述意图，但真正的顺序保证得靠外层状态机或者多轮交互来

先试试query改写吧，术语对不上embedding再强也白搭，我这边加了个同义词扩展好了不少。

可以把固定逻辑写死，变量用占位符替换，就像调函数传参那样，省得每次重写。

试试分两步走，先让它标出可疑点，再逐条深挖，比一次性全审稳多了。

我之前也遇到过一模一样的报错，折腾半天发现是Claude Desktop没完全退出，后台还挂着旧进程，导致新配置根本没加载。你试试彻底杀掉所有Claude相关进程再重启，任务管理器里翻一下别漏了。另外stdio模式的服务器如果启动脚本里有阻塞输出也容易卡死，可以先在终端手动跑一遍看有没有异常日志。

双4090跑32B本来就吃力，建议先试FP8加chunked prefill，比直接换卡划算多了。

我之前也踩过这坑，AgentExecutor 串行跑任务还行，一旦并行就容易出现互相等锁的情况，尤其子任务有依赖关系时更明显。你可以试试把调度层抽出来，用 asyncio 自己管任务队列，Agent 只负责执行，别让它自己决定下一步。另外重复执行多半是没做幂等或状态没共享，加个任务ID去重会好很多。

JSON传tensor确实挺伤的，尤其是多维度float数组，序列化开销能占大头。我之前也踩过类似坑，换成base64编码的numpy二进制后延迟直接砍半。另外检查下MCP server是不是默认单线程处理tool call，同步阻塞很容易把吞吐拖死。你本地50ms是裸推理吧，建议把传输和序列化单独压测一下，定位到底卡在哪一层。

我最近也踩过这个坑，后来发现prompt里加个简短的few-shot示例比单纯写“口语化”管用多了，模型会照着示例的语气走。system prompt我一般只放角色和硬约束，比如“只根据上下文回答，不要编”，具体风格要求塞到user prompt里，效果稳一些。检索结果最好带上来源标题或者分段标记，不然模型容易把几段内容揉成一坨。还有个坑是topk别贪多，塞太多不相关的上下文反而会把回答带偏。

我之前也踩过这个坑，后来发现最该先排查的其实是你的评测方式。top5相关度低，你是怎么判断的？如果是靠肉眼看几条case，很容易被个例带偏，建议先攒个三五十条带标准答案的query，跑一遍recall@k，不然你换什么模型都是盲调。chunk_size和max token关系没那么大，500对大多数embedding模型来说远没到截断线，真正影响的是语义完整性，切断了上下文，embedding再强

几千条QA对微调embedding其实够了，关键是看你怎么构造训练数据。我之前用bge-large在类似量级上做过对比，如果只是拿QA对做in-batch negative，提升很有限，真正有用的是加入hard negative——就是从faiss里召回的但标注为不相关的那些段落，这个对排序改善特别明显。不过你这情况先别急着微调，topk=5配chunk 400，召回的段落本身可能就有语义漂移，建

直接上LoRA吧，7B全参微调单卡本来就吃力，梯度检查点加ZeRO那报错够你折腾的。

本地部署和API版确实有差别，API后处理更狠，而本地模型对prompt的敏感度和解码参数关系很大。温度调到0.7以上容易啰嗦，建议先固定top_p=0.8再试。重复输出多半是repetition_penalty没调，设到1.2左右能缓解。模板别硬套官方，试试把system改成“你是问答助手，输出不超过200字”，比“不要解释”这种负向指令稳定得多。另外你用的什么量化版本？4bit和fp16对指令

你这场景我熟，我们之前也卡在显存和延迟上。7B模型实际跑起来KV cache和中间激活值很吃显存，网上那些20实例多半是纸面参数，别太当真。2卡各跑实例做负载均衡比4卡张量并行更划算，至少单路故障还能兜底，TTFT也更稳定。AWQ 4bit在知识库问答这种短文本场景掉点其实不大，但建议你先量化后跑一遍测试集，重点看长上下文的回复连贯性。另外vLLM记得开continuous batching，2秒

我之前也遇到过这问题，后来发现把约束拆进代码结构里比在prompt里罗列管用。比如直接给个带pass的骨架，让它填函数体和except块，比单纯说“要处理异常”靠谱多了。另外你可以试试把“网络超时”和“HTTP错误”写成具体的Exception类名，模型对具体token的响应比对抽象描述好。漏函数定义的话，大概率是它把上下文理解成“补全”了，你干脆在Prompt末尾加一句“输出完整可运行的.py文

实测过2卡各跑实例，并发翻倍但显存碎片多，4卡张量并行TTFT更稳，建议先上4卡。AWQ4bit掉点不大，知识库问答够用。

这问题我也踩过坑，单卡A100跑7B其实没必要硬撑满血精度，AWQ或GPTQ量化到4bit之后显存能砍一半还多，并发8个基本能稳。流水线并行更吃多卡环境，单卡上不如把--gpu-memory-utilization调到0.95，再配合--enable-chunked-prefill把prefill和decode拆开，显存峰值能平滑很多。你那边如果量化后还爆，建议查下是不是vLLM版本太老，新版对连

说实话base64塞JSON这事我踩过坑，图像数据一多直接爆token上限，后来改成先传文件再让MCP读本地路径，实测稳得多。PyTorch这边维度归一化确实没法靠协议解决，我就在tool定义里加了image_width、image_height、mean、std这几个参数，客户端传数据时统一带上，服务端解析完再拼tensor，虽然不够优雅但至少能跑通。另外MCP的schema目前确实不支持自定义