[RFC] 028 - 插件四期 · 流式 Tools Calling #1310
arvinxx
started this conversation in
RFC | 特性开发
Replies: 7 comments 14 replies
-
|
目前是不是会把插件信息放到请求的系统提示里？ |
Beta Was this translation helpful? Give feedback.
10 replies
-
|
@BrandonStudio 可以看下这个： https://github.com/steven-tey/weathergpt/blob/main/public/.well-known/ai-plugin.json#L6 我说的注入是指的 |
Beta Was this translation helpful? Give feedback.
-
|
这个东西不就是tools[0].function.description吗？传给模型的啊。另一个description_for_human不是显示给人的么？ 我觉得要让模型正确地使用工具，应该是优化tools[0].function.description的内容，比如明确可以做什么、输出是什么等 如果一定说系统提示很大程度上提升模型的能力，那我希望这个系统提示也是设成可选的参考的，而不是强制的 |
Beta Was this translation helpful? Give feedback.
-
功效上是一样的，但是工程上不太可能放在 tools[0].function.description，原因是 ChatGPT 的 plugin 使用的是 openapi (Swagger) 的 Schema 规范。 这样所有的后端服务只要有 openapi 的 shcema ，就能做成 ChatGPT 的插件。但正常来说一般 openapi 的 schema 不会是手写的，而是通过工具自动生成的。那这里就会存在一个问题：如果优化描述是写在 我估计 OpenAI 之前探索的是有就有发现这个问题，所以才会单独给出一个 |
Beta Was this translation helpful? Give feedback.
-
|
也就是说，对于 ChatGPT 的插件，开发商会设计两个提示，一个是专门放在 system 里的，一个是传给 tool_use 的？ |
Beta Was this translation helpful? Give feedback.
-
OpenAI 在 介绍 ChatGPT 插件的开发时，只建议了将提示写到 所以这就导致 ChatGPT的所有插件，关键的说明都是写在 在我们实际测试下来情况也是这样。如果没有了 |
Beta Was this translation helpful? Give feedback.
-
|
Tool Calls 标准示例： 平行调用示例； |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
流式tool calls 核心要解决的问题： 1. 如何选择后端发给前端的协议？ai/sdk 的协议不可用，缺少服务端方案和客户端方案。 最终采用 SSE 标准规范 （Server-Sent Events 教程 - 阮一峰）： 
Dev tools 很方便查看，并且 2 也好做 2. 如果直接输出，那么会导致一次读取的 token 量是全的 （如何标准化解析 SSE 结果？）
使用 import { fetchEventSource } from '@microsoft/fetch-event-source';
await fetchEventSource(url, {
// ...
onmessage: (ev) => {
const data = JSON.parse(ev.data);
switch (ev.event) {
case 'text': {
output += data;
options.onMessageHandle?.({ text: data, type: 'text' });
break;
}
case 'tool_calls': {
if (!toolCalls) {
toolCalls = [];
}
options.onMessageHandle?.({
tool_calls: parseToolCalls(toolCalls, data),
type: 'tool_calls',
});
}
}
},
});3. Tool Calls 如何应该如何流式解析？ |
Beta Was this translation helpful? Give feedback.
0 replies
-
新流式协议 Provider CheckListOpenAI 兼容 Provider
Claude 类
其他
|
Beta Was this translation helpful? Give feedback.
0 replies
-
一些问题记录各个 Provider 存在的千奇百怪的 Tool Calling 问题 |
Beta Was this translation helpful? Give feedback.
4 replies
-
Groq 的 Tool Calling 暂不支持流式输出
解决方案： 将 response 转换为 Stream，然后复用 sse 协议 |
Beta Was this translation helpful? Give feedback.
-
Minimax 的 tool calling 流式处理问题Minimax abab 系列的 tool calling 流式处理有细节问题。 OpenAI标准的 tool calling 流式的第一次输出 tool calling 时，一定会完整输出function 的name字段，然后在后续的输出中再流式输出arguments 的内容。但 minimax 的 tool calling 第一次输出，name字段是不全的 这就导致没法真正产生有意义的流式效果（流式需要清楚用哪个 API name） |
Beta Was this translation helpful? Give feedback.
-
TogetherAI 的 function calling很奇怪，有点问题，暂时不开启。得排查下原因 |
Beta Was this translation helpful? Give feedback.
-
Mistral 的 Tool Calling 也有问题原因：丢失了 |
Beta Was this translation helpful? Give feedback.
-
Anthropic 的 Stream 参考Tool Calling 非流式数据： |
Beta Was this translation helpful? Give feedback.
0 replies
-
Bedrock 流式ClaudeBedrock 的 Claude 的接口最终返回的 json 和 Anthropic 的一致 Llama |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
背景
Provider Function Calling ( Tool Calling ) 支持
最近 Claude3 支持了 fc，大量用户希望为Claude3 系列模型支持上插件能力。
Google Gemini 1.5 pro最近也正式发布了，号称也完整支持了 function calling
用户对其他 Provider 的 Function Calling 需求：
未来 FC 会成为顶级模型的必备高级能力，因此需要为其可扩展性做好准备
message 数据结构升级
OpenAI 在 1106 时废弃了 role=function,改为 role=tool, 这针对一些场景做了很好的修正(比如重复调用)，我们需要改造成新方式。
集成aiSDK 的新流式协议Warning
经调研，该方案不可行
最近出的一个 bug 是
[email protected]做了流式传输协议变更导致的( vercel/ai#1316 )。他们的初心是希望做更强大的流式能力支持，但造成了 Breaking Change。但他们在尝试做的新的流式协议可以区分出是 普通 text 还是 fc。如果基于这个新的协议，我们有机会实现体验更好的 fc 执行交互与可维护性更加的 fc 实现，这样之前尝试的 #1810 应该就可以比较顺畅的实现了。
Tool Calling 流式协议
自行实现兼容 Text 、 Tool Calling 的流式协议
Beta Was this translation helpful? Give feedback.
All reactions