工作中使用大模型做text2sql应用,均是选用qwen2.5-72B-instruct模型作为服务提供者,全使用prompt,不微调,基本可以满足需求。 prompt提示词会动态生成,平均长度约为1万字,15000字符左右。
但是最近新增了一个更加复杂的场景,慢慢感觉大模型返回的错误多了很多,因为新增的这个提示词更加复杂,需要假设的场景有点多也有一点乱。
再尝试用了其他模型多次测试:不成功与成功的效果,分别如下:
推理模型QwQ-32B:失败
推理模型DeepSeek-R1-Distill-Qwen-32B:失败
推理模型DeepSeek-R1-Distill-Llama-70B:失败。 甚至原来基础容易的那个功能都失败了。
Qwen2___5-Coder-32B-Instruct:失败
DeepSeek-Coder-V2-Lite-Instruct:失败 (16B A2.4B)
DeepSeek-Coder-V2-Instruct: 成功 8s响应时长 (236B Active21B)
deepseek-v3: 成功 13s响应时长
推理模型deepseek-r1: 成功 39s响应时长
测试结果也有点像猜想的:参数量是更决定性的因素,
后面几个虽然成功了,但参数量过大,本地部署不量化的版本有点困难.. 就在以为只能收集数据做微调时,发现一个最近谷歌刚出来的模型gemma-3-27b-it,说是超过deepseek-v3次于deepseek-r1。要不是看到这句话,估计都不太会去尝试,因为想着27B实在是有点点小。结果试了一下,出人意料的,基本都能正确返回结果! 嗯,时间越往后,发展得都越好吧。都踩在众多巨人的肩膀上。
以上可以做为一个模型间的比较的参考信息吧,在此项功能的验证结果上,与排行版上相对的顺序,一部分也是吻合的。(QwQ-32B与deepseek-r1蒸馏出来的模型在这里好像不突出)