模型 function call 的一些问题

[nomagick]

首先需要肯定 ChatGLM3-6B 的 Function call 和 Interpreter 都非常新颖，填补了开源模型的一些空白。
但经过一段时间的试用，我发现当前模型有以下问题，这种问题是模型层次的，只能通过训练解决，希望在下个版本能够考虑。

• Function 的参数不能是字典或JSON，而只能是Python Primitive
• 工具，或者说function的名称不能为 interpreter
• 处理 markdown 前缀和 tool_call() 调用形式过于复杂

如果进行一些分析思考，不难推测，Function call 功能是建立在 Interpreter 基础上微调得到的，本质上还是 Python Interpreter

https://replicate.com/p/qudth7dbwpljdbgmw5p2glk2qq

这一点尤其限制了模型理解和生成JSON树状结构的能力。

同时当前模型的输出形式，可以推测只是为了在Python中实现起来方便。

我想说的是eval任意Python代码的实现方式是非常危险的, 在工程上也是不可接受的。

所以Function call的能力不应该建立在Interpreter基础上, 最好也不要和Python扯上任何关系，做成语言中立的。
建议对模型进行JSON树状结构的微调，这一点才是应用开发者最期盼的。

[wengyuan722]

使用容器跑，要一定门槛

[Lihengwannafly]

我在前几个月测试openai的interpreter时，它认为自己是一个叫'python'的function，以及在测试openai的function_call接口时，也有一个默认的'python' function。所以我的猜测是，应该是interpreter的能力建立在function_call的基础上，智谱也借鉴了openai function_call的能力。

[positive666]

补充下应用角度，fuction call 并不新颖，抛开SFT训练它的过程，使用这个逻辑本质是一种prompt的工程 ，大部分都是参考OPENAI的逻辑调用思路，demo返回dict是命中了tools中的一个， string则是没有命中，是一种前后端交互逻辑，针对每个人的使用场景所产生的效果也相差很多，最终在垂直领域还是需要SFT，不过很感谢提供这么一个10B以内的强力底座