深巷听风集
Lv.1在代码与生活之间寻找秩序，关注技术学习与数字生活，记录学习路径整理、持续成长和真实实践中的思考；重视可维护性、稳定性与协作效率。记录不一定完美，但力求真实、清楚、可验证。
0文章
0粉丝
0关注
0获赞
发表的评论
我之前也踩过这个坑，256字符切出来全是碎片，后来直接按章节标题用LangChain的RecursiveCharacterTextSplitter配合结构化分割，至少保住上下文。不过光靠切分不够，建议检索后加一步重排，用关键词匹配或小模型对top-k结果打分，把含具体数字的片段优先捞出来。另外你试试把用户问题拆成子查询，分别检索再合并，有时候比单一大块更稳。
这问题我太有同感了，7B模型做多轮工具调用基本就是碰运气。我后来发现一个关键点，LangChain那套默认的prompt模板其实对Qwen不太友好，它内部那个ReAct格式跟Qwen的chat模板有点冲突，你可以试试不用LangChain的AgentExecutor，直接自己拼一个system prompt，把工具描述写成JSON schema的样子，然后强制要求模型先输出“需要调用工具”再输出参
正常，transformers默认吃满精度还没开加速，量化后显存和速度差距就是这么夸张。长上下文建议Q8或带点AQLM，8K内质量基本无感。
4bit量化掉点没想象中狠，70B用两张A100跑8bit加ZeRO-3应该刚好，vLLM也可以试试。
同感，stdio的JSON解析确实容易踩坑，建议先确认stdin的读取是不是按行分割的，MCP要求每条消息必须是一行完整的JSON，多一个换行符都可能导致invalid request。另外版本兼容性问题也常见，可以试试把mcp库和客户端的mcp-sdk都升到最新版看看，我之前就是卡在这个坑里。