边学边做商业成长记

试试Qwen2.5-1.5B配vLLM，工具调用逻辑精简下，16G跑起来挺稳的。

试试在prompt里加一句“代码中禁止出现任何注释和文档字符串”，我试过管用，不过偶尔还是抽风。 把示例代码里的注释全删掉，它就会跟着学，你那个思路应该没错。

同感，bge-large-zh-v1.5对同义改写确实有点迟钝，尤其法律这种术语多的领域。我后来把chunk降到了300，加了个简单的query改写（把口语词映射成正式术语），效果立竿见影。8G显存跑bge-m3其实可以试试int8量化，推理时峰值也就5G多，但别用faiss索引，直接用numpy暴力检索都行。另外topk先拉到10，看下召回分布再降，比死磕模型参数省事。

我自己的体验是代码生成真的别太迷信单一参数，7B模型本身能力和稳定性有限，温度0.3起步，但配合top_p调到0.9反而比单独降temp更稳，repeat_penalty设到1.1能治重复生成。你可以试试temperature=0.3，top_p=0.85，repeat_penalty=1.1这组，我拿它写脚本还行。API和本地调参逻辑基本一致，但不同服务商可能对参数做了二次处理，比如有些API强

loss下降只能说明模型在拟合训练集，不代表它能学会生成逻辑，200条数据对7B模型来说太少了，LoRA微调很容易过拟合到噪声上。你那个乱码输出像是tokenizer和词表不匹配，或者special token被破坏了，建议先检查一下LLaMA-Factory的模板配置，Qwen2的chat模板和base模型不一样，如果默认模板跟你的数据格式冲突，生成时就会崩。另一个常见坑是学习率，2e-4对Lo

大概率是MCP每次请求都重新加载模型了，建议搞个常驻模型池或改用Flask挂载模型试试。

你这情况我搭RAG时也遇到过，后来发现单纯靠字符分割确实容易丢失语义边界。我现在的做法是先按markdown标题或PDF中的大纲层级做切分，再对长段落用递归分割兜底，这样至少能保证“售后政策”不会和“维修流程”混在一起。另外你可以试试加个语义分块的步骤，比如用embedding相似度合并邻近段落，效果比固定窗口好不少。

max_num_seqs调低到64试试，3090显存扛不住256的并行。

你这情况太典型了，基本每个做RAG的都在这上面踩过坑。chunk大小真不是个能一劳永逸的参数，它跟你文档结构、检索策略、甚至LLM本身都绑在一起。 先说你这个512和1024的对比。512召回高但上下文断，本质上是你的embedding模型对短文本的语义捕获能力不够，导致切分后关键信息被稀释了。1024上下文完整但跑偏，大概率是因为块内包含了多个主题，向量相似度被非核心内容带歪了。滑动窗口和重叠