LangChain4j中Qwen2.5模型工具调用JSON参数格式异常问题解析

问题背景

在LangChain4j框架与通义千问大模型(Qwen)的集成实践中，开发者发现不同版本的Qwen模型对工具调用时的JSON参数处理存在显著差异。具体表现为：Qwen2.5-72B模型生成的JSON参数会被额外包裹一层双引号，导致后续JSON解析失败；而qwen-max模型则能生成符合预期的标准JSON格式。

技术现象分析

当开发者使用@Tool注解定义工具方法时（如获取产品价格的getProductPriceByCode方法），模型需要生成符合方法参数要求的JSON结构。异常情况表现为：

• 异常格式：""{\"productCode\": \"K1111002-001\"}""（多套一层双引号）
• 正常格式："{\"productCode\": \"K1111002-001\"}"

这种差异会导致Gson等JSON解析器抛出IllegalStateException，提示"Expected BEGIN_OBJECT but was STRING"错误，因为解析器期望直接遇到JSON对象起始符{，但实际获取的是被当作字符串处理的JSON文本。

根本原因推测

1. 字符串转义处理差异：Qwen2.5-72B可能过度执行了字符串安全处理，将本应作为JSON对象传递的参数强制转换为字符串类型
2. 模型训练数据偏差：不同版本模型在工具调用场景的训练数据可能存在处理范式差异
3. 参数序列化策略：模型内部对复杂参数的序列化策略可能存在版本间不一致

解决方案建议

临时解决方案

1. 参数预处理：在工具方法中添加字符串净化逻辑，自动去除多余引号

@Tool("根据车型编号获取车型价格")
public String getProductPrice(@P("车型编号") String productCode){
    // 净化参数：去除首尾多余引号
    String sanitizedCode = productCode.replaceAll("^\"|\"$", "");
    // 后续处理逻辑...
}

2. 自定义参数解析器：实现自定义的JSON解析策略，兼容异常格式

长期解决方案

1. 模型微调：针对工具调用场景对Qwen2.5进行针对性微调
2. 框架层适配：在LangChain4j的Qwen适配器中增加参数格式标准化处理
3. Prompt工程优化：在系统提示中明确要求JSON参数的生成格式

最佳实践建议

1. 版本兼容性测试：混合使用不同模型版本时，应进行全面的工具调用测试
2. 防御性编程：工具方法应对参数进行格式校验和自动修正
3. 日志监控：对工具调用的原始参数和净化后参数进行对比日志记录

扩展思考

该问题揭示了LLM在复杂参数处理中的一个共性挑战：当模型需要生成结构化数据作为另一个系统的输入时，输出的一致性和可靠性至关重要。开发者在设计工具调用体系时应当：

• 明确约定结构化数据的生成规范
• 建立参数验证机制
• 考虑不同模型版本的行为差异
• 在框架层面提供标准化处理

通过系统化的解决方案，可以确保大模型在工具调用场景下的稳定性和可靠性，为构建复杂的AI应用奠定坚实基础。