实战派推理加速研究笔记

我之前也是被tool calling折磨得不行，后来发现很多时候不是prompt写得不够好，而是模型对结构化指令的敏感度差异极大。Qwen2.5对JSON格式的要求特别死板，少一个换行符都可能触发幻觉，Llama3.1相对宽容但容易把工具结果混进对话历史里。我自己试下来，与其死磕一条万能prompt，不如在LangChain里给工具返回值加一层强制的schema校验，比如让模型先输出一个固定的“意

老哥试试加--gpu-memory-utilization 0.85，vLLM默认会预留显存给KV cache，爆了很正常。

我之前也踩过这个坑，光调chunk_size和overlap真的帮助有限，尤其你这种带PDF表格和多级标题的文档，纯按字符切会把语义块切得稀碎。后来我改成先做结构解析，把标题层级和表格区域单独提取出来，再按每个二级标题下的完整段落作为一个chunk，表格单独存成带表头说明的块，这样检索命中率明显上来了。你试过用unstructured或者marker这类库做文档预处理吗？它们能保留标题层级，比直接

说实话你这情况我太熟了，bge-large-zh对长文档的语义聚焦确实不太行，512字符切分容易把关键信息切碎，尤其财务公告那种带日期和条件的句子，一拆开向量就飘了。我建议先别急着上GraphRAG，那玩意儿工程量大，调起来更玄学，先把切分改成按标题或段落结构走，overlap提到128试试，另外做个简单的关键词权重加权，比如命中“报销”“截止”这类词时提升候选分数。重排序确实该加，但别指望它逆天

说实话chunk size这东西真没有银弹，我之前也卡了很久。后来发现与其死磕固定值，不如先看看你的文档结构，比如有没有标题、段落或者代码块，用这些自然边界来切往往比硬切效果好很多。 另外embedding模型本身对长度也敏感，你可以试试先跑一个检索质量的快速评估，看看是召回的问题还是排序的问题，再针对性调。overlap我觉得不用加太多，50就差不多了，主要用来补上下文，不是用来救命的。 还

loss降这么低但acc卡在65%，大概率是过拟合小样本了，LoRA rank是不是设太高了？我之前做类似任务，把rank降到8甚至4，再加点weight decay，验证集反而涨了5个点。另外你分类头是怎么接的？直接取last token还是用了pooling？Llama3的CLS位置不一定适合分类，换个平均池化试试可能更稳。还有个坑，10类200条/类对模型来说还是太少了，试试加些数据增强或回

这loss卡在2.3下不去，大概率不是lr的问题，我怀疑你的数据分布和预训练阶段没对齐。LLaMA-2的tokenizer对代码里的缩进、特殊符号编码效率很低，如果原始函数里空行和注释太多，有效信息密度不够，loss自然降不动。建议你先跑个100条数据的小实验，看看loss在过拟合时能到多少，如果还卡在2.x就说明数据本身有问题。另外别上来就用LoRA，先全量微调几百步找到合理的loss基线，再切