关于OneBot13的设想：把“百模大战”的各种大语言模型用OneBot统一收编

[2catycm]

背景简介：

以ChatGPT为代表的大语言模型（LLM）的对话能力让人印象深刻，除了OpenAI，一系列大厂都纷纷跟进，用各种方式发布了自己的语言模型；而一系列优秀的开源LLM也不断地进步。
仅仅是国内的闭源语言模型稍有名气的都超过百家，如 awesome-LLMs-In-China 仓库整理；而国内的开源语言模型也有很多，比如Awesome-Chinese-LLM所整理的。而国外大厂的LLM也有很多，比如Awesome-LLM整理的。

然而，不同的闭源模型的调用约定格式protocol不同，比如很多人使用的OpenAI API格式 可以调用 OpenAI开发的“gpt-3.5-turbo”"gpt-4""dalle-3"\embedding等模型；若基于Google API，可以调用gemini、palm等模型；若基于智谱AI API，可以调用chatglm-turbo模型; 而要想调用Claude模型，需要使用slack。开源模型虽然大多数可以使用HuggingFace的Transformers库进行统一，但是其运行配置或各有不同，也比较难有统一的调用格式。

这就造成了很多基于LLM应用的工具，比如QQ聊天机器人、GPT学术优化、ChatGPT Web、川虎GPT个人助理等，难以优雅地切换调用不同的大语言模型，需要重复写很多代码。

现有的其他人的相关工作：

api-for-open-llm 仓库可以把很多开源LLM的调用接口修改为OpenAI格式。litellm支持很多国外的知名模型，包括HuggingFace text generation inference库支持的模型，自己做了一个新的API格式，也可以转换为OpenAI格式。
one-api支持很多国内的闭源模型转为OpenAI格式，还添加了复杂的计费、代理、账户、优先级等管理功能。free-one-api除了支持官方的调用方式，还支持一些通过逆向、爬虫等方式访问的LLM，均可以转为OpenAI格式。

开启了这些工具提供的服务后，只需要修改 OPENAI_BASE_URL 为这些工具运行的地址（比如 http://localhost:8080/v1），就可以像调用OpenAI模型一样调用很多其他模型。

我的想法：

其他相关工作基本都是把某个LLM的API转换为OpenAI接口，这里面的范式是让大家开发基于LLM的程序都基于OpenAI官方库来开发，然后要用到其他LLM的时候把它们假装当做OpenAI来调用。

这当然能解决大部分的问题，但是我认为更好的方法是“any to any”，我们需要一个中间层，把任何的大语言模型的调用接口，转换为中间调用表示，然后转换为任何的另外一个大语言模型的调用接口。

用户故事：有个开发者很喜欢Google，开发自己的LLM助手时，使用Google API。后来他想要对比一下同样的Prompt如果使用OpenAI的模型能不能奏效，但是面对着已经写好的代码，他难以下手修改。如果不改自己的代码，他可以在外部运行转换器，将OpenAI 的API转换为Google API。这样他只需要修改BASE_URL配置就可以了。
用户故事：有一个LLM研究者，自己开发了多个开源LLM，可以使用Hugging Face运行，可以和其他开源模型进行对比，但是他发现要想和GPT进行对比，还需要修改一些代码。

为什么用OneBot来作为中间层统一

OneBot12大胆地解除了OneBot对于QQ的依赖，试图统一所有聊天机器人框架，眼光非常前沿。
而近来随着深度学习的崛起、ChatGPT的问世，OneBot可以跟上时代的发展，再次革新。

LLM其实就是一种聊天机器人，普通的LLM就是text in text out；而多模态的LLM可以输入图片，比如Google Gemini2 模型，输入给模型的消息可以包括图片，图片和文字可以交叉而不是分别输入。而非多模态的LLM，也可以通过toolformer的方式进行Prompt Engineering调用视觉模型，实现处理图片的能力，比如微软的visual chatgpt项目以及HuggingGPT项目。
这其实就类似于QQ聊天机器人所面临的情况，可以输入文字、语音、图片、文件，然后有一个智能群聊机器人可以做出回答。

初步设想

OneBot 实现 是 与机器人平台对接、向上提供符合 OneBot 标准的接口的程序，可简称为实现端。对于LLM来说，我们把我们实现的API服务器当做是OneBot的实现端，而“机器人平台”实际上是用户和API交互的过程。比如，我们可以写出一个叫做“OpenAI OneBot Adapter”的项目作为OneBot 实现端，对下而言，用户把他当做OpenAI API服务器来调用，不断发送推送新的用户消息，希望机器人能做出回答；而“OpenAI OneBot Adapter”将OpenAI格式的request转换为OneBot12格式，向上推送，提供OneBot标准的接口。

OneBot 应用 是 与 OneBot 实现按照 OneBot 标准交互，实现机器人业务逻辑的程序，可简称为应用端。对于LLM来说，我们把我们想要调用的目标LLM当做OneBot的应用端。比如，我们可以写出一个叫做“ChatGLM OneBot Application”的项目，给定下面传送过来的OneBot格式的调用请求，这个项目可以把OneBot格式转换为Zhipu AI API格式，向上去寻找Zhipu AI的官方服务器进行调用，得到回答之后再按照OneBot格式向下推送。

如此一来，我们就很好地利用OneBot作为中间格式，优雅地统一了所有LLM的调用方式。

为了实现这一点，OneBot12标准缺少什么？

我还没有完整阅读和理解OneBot12标准，可能实际上OneBot12可以支持这个功能。我目前看到的情况来说，对比OpenAI API所支持的功能，OneBot12主要是缺少streaming功能，也就是“打字机效果”，就是机器人回答不是整段消息回答过去，而是一点一点打出来（实际上推理也是一点一点往前推），甚至有些模型可以修改前面写好的内容，然后完成整段消息之后再发送过去。但是整个过程用户可以看到这一段消息是如何产生的。
微信、QQ一般来说没有这个效果，不会说看到对方正在怎么样打字，不过OneBot12也想要支持终端，终端也是有不断生成的效果的。

而OneBot12其他的定义都比OpenAI 全面、先进，比如有群聊、mention、reply、notice等概念。

[stdrc]

OneBot12主要是缺少streaming功能，也就是“打字机效果”，就是机器人回答不是整段消息回答过去，而是一点一点打出来（实际上推理也是一点一点往前推），甚至有些模型可以修改前面写好的内容，然后完成整段消息之后再发送过去。

这个确实非常有道理，我曾经在很早的时候畅想过一种流式传送正在聊天框中的消息的聊天软件，似乎跟现在大模型这种流式输出消息不谋而合了。

关于这个你这边有什么正在做的项目已经在尝试把 OB 作为中间层了吗，还是还只是在设想阶段？如果有兴趣可以写 RFC 改进 OB。我个人最近兴趣逐渐不在这方面了，可能回复和讨论不会很及时……

[stdrc]

相关讨论：https://github.com/orgs/botuniverse/discussions/244