[RFC] 028 - 插件四期 #1310
arvinxx
started this conversation in
RFC | 特性开发
[RFC] 028 - 插件四期
#1310
Replies: 7 comments 15 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.
5 replies
-
Groq 的 Tool Calling 暂不支持流式输出
解决方案： 将 response 转换为 Stream，然后复用 sse 协议 |
Beta Was this translation helpful? Give feedback.
-
OpenRouter API Key 余额没钱时会有报错待排查 |
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
-
背景
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 是
ai@3.0.20做了流式传输协议变更导致的( vercel/ai#1316 )。他们的初心是希望做更强大的流式能力支持，但造成了 Breaking Change。但他们在尝试做的新的流式协议可以区分出是 普通 text 还是 fc。如果基于这个新的协议，我们有机会实现体验更好的 fc 执行交互与可维护性更加的 fc 实现，这样之前尝试的 #1810 应该就可以比较顺畅的实现了。
Tool Calling 流式协议
自行实现兼容 Text 、 Tool Calling 的流式协议
Beta Was this translation helpful? Give feedback.
All reactions