小禾_Linux手记

多工具串行确实难，建议先用官方function calling模板重洗数据，格式对齐比调参管用。

试试加个rerank模型，bge-reranker对中文场景效果挺明显的，比MMR稳。

换种问法就挂，多半是切太碎了，试试按语义边界切再加点重叠，别急着换模型。

先别急着调参，拿几个问题手动看看召回的chunk到底长啥样，大概率是PDF解析把表格和正文混一起了。

7B模型指令遵循本来就偏弱，prompt越长越容易迷失，这是通病。知识库别一股脑全塞进去，先做检索把最相关的两三段拿出来，再放到prompt靠前的位置，中间部分确实容易被忽略。温度调到0.1到0.3之间试试，另外系统提示里明确写“不知道就说不知道，禁止编造”，比写一堆角色设定管用多了。

我这边生产上只挂了两个MCP，文件系统加数据库，GitHub那种按需起停。全挂上延迟确实会涨，因为每轮工具列表要聚合，调用时还会挨个探测可用性。与其堆很多小服务器，不如把常用能力合并到一个进程里，权限也更好控。动态加载加个简单的路由层就够用了，别一上来就搞负载均衡，复杂度不划算。

切片这块问题挺大的，固定500字切很容易把完整语义切碎，同一段被重复召回就是典型症状。建议先按标题或章节做层级切分，再在段落级别做chunk，重叠也可以少一点。重排不是万能的，召回源头不干净，后面怎么排都别扭。query改写可以试试让模型先抽关键词再扩写成完整问句，能缓解飘的问题。

你这个情况我踩过一模一样的坑，Claude Desktop里stdio模式启子进程的时候环境变量是独立继承的，不会自动带上你shell里配的PATH和venv，所以哪怕你本地命令行跑得通，它那边可能连python都找不到。你可以先试试在config里把command写成venv里python的绝对路径，args里第一个参数写server脚本的绝对路径，别用uv或者python -m这种偷懒写法。另

硬规则得单独拎出来做校验层，别指望它一次生成就记住，我都是生成完再跑一遍规则检查。

bge-large-zh对“报销流程”这种短问题确实容易飘，建议先加个关键词过滤或者换用bge-m3试试。

3个epoch对几千条数据来说确实容易过拟合，重复生成基本就是模型在死记硬背训练样本的典型表现。建议先降到1个epoch试试，同时把LoRA的alpha调到32左右，让适配器更新更克制些。另外5e-5的学习率对LoRA来说偏高了，可以试试1e-5到2e-5，配合cosine调度会稳很多。排查顺序我一般先看epoch和lr，这俩调完还重复再动rank。

试试vLLM+PagedAttention，FP16两张卡能稳跑16K，吞吐比张量并行高不少。

试试把chunk调到256、重叠64，top_k拉高到10，bge-m3对长文本切分的语义边界其实挺敏感的。 你这512的chunk配128重叠，检索召回的内容太容易跑偏了，先拿测试集量化查下recall，别急着调LLM那边。

十几万条就卡的话，先看索引类型和内存配置，别急着上分布式，召回率才是RAG的命根子。

试试按语义段落切分，加上重排模型过滤，固定窗口对会议纪要这类结构文档确实容易切碎上下文。

1.8的loss对中文法律这种专业领域来说其实不算太差，你先看看生成结果是不是都堆在少数几个模板上，如果是的话大概率是数据多样性不够。另外LoRA的rank可以调到32以上试试，我碰到过rank太低导致表达空间受限的情况。全量微调先别急，成本高不说，你这一万条数据量其实更适合把基座换成中文法律相关的模型，比如Lawyer-LLaMA或者DISC-LawLLM，直接省很多事。 数据里如果有大量相似

这问题我也踩过，大概率不是CORS的事，Ollama那边压根不校验这个。你回调地址填localhost，但MCP服务器如果是跑在容器或者别的网络命名空间里，这个地址就指向它自己了，根本回不到你本地工具，先确认下两边网络能不能互通。另外SSE超时60秒很常见，你模型推理虽然出结果了，但流式响应如果没按MCP要求的格式逐块推送，客户端会一直等，试试把回调改成实际局域网IP，再把timeout调大到12

ROIAlign和NMS确实得走plugin，TensorRT原生不支持这俩op，onnxruntime能跑是因为它自己实现了。dynamic shape报错八成是opset版本问题，建议ONNX用opset 17以上，另外检查下输入维度是不是NCHW，TensorRT对layout特别敏感。我之前用onnx-tensorrt（就是仓库里那个parser）搞过带动态batch的Faster RCN

说实话你这情况我太熟了，之前我们内部wiki也翻过车。问题很可能不在chunk和模型上，而是你的技术手册本身信息密度低，检索召回的内容太碎，reranker拉不回上下文语义。建议先看看top-3召回片段里到底有没有完整答案，没有的话再调参也是白搭。另外试试走一遍query改写，把用户口语化问题映射成文档里的术语，可能比换embedding更管用。

这种对抗性的活AI真不擅长，你把具体报错和抓包数据喂给它，比堆prompt管用多了。 别指望一句话调教，得把目标站的校验逻辑拆解给它，一步步喂，才能跑通。