文章目录

一、接口概念1、接口类型 - 人机交互接口 / 应用程序编程接口2、人机交互口的发展 - 命令行 -> 图形界面 -> 语言界面 -> 脑机3、应用程序编程接口的发展 - 本地 -> 远程 -> 自然语言接口

二、AI 大模型缺陷与补救措施 - 函数调用 Function Calling 引入1、AI 大模型原理2、AI 大模型缺陷3、函数调用 Function Calling 引入4、" 真逻辑 " 要求5、函数调用 Function Calling 为 大模型 赋能 " 真逻辑 "

一、接口概念

1、接口类型 - 人机交互接口 / 应用程序编程接口

接口类型 : " 接口 " 的 关键 就是 , 使用接口的 双方 要遵守 " 事先约定 " ;

人之间的交互接口 : 通过 语言、表情、动作 进行交流 ;人机交互接口 : Human-Computer Interaction Interface , 简称 " HCI Interface " , 是 人 与 计算机系统 之间建立联系 , 交换信息的 输入 / 输出 设备的接口 , 输入 / 输出 设备主要有键盘、显示器、打印机、鼠标等 ;

核心是 " 人 " 要遵守 接口 的规定 , 来操作 计算机系统 ;计算机系统 不懂 人的语言 , 需要 事先定义 计算机 可以理解的 与人交互的 " 接口 " , 人要学习 计算机 可理解的 接口 ; 应用程序编程接口 : Application Programming Interface , 简称 " API " , 是一组 预定义 的 函数、协议和工具 , 用于 实现 软件应用程序 之间的通信和交互 , API 允许 开发人员 在不访问源代码或理解内部工作机制的情况下 , 调用和使用特定的软件功能或服务 ;

核心是 " 应用程序 " 要遵守 接口 的规定 , 来调用 计算机系统 中的另外一个应用程序 提供的服务 ;应用程序 之间 是不知道另外一个 应用程序 的实现机制的 , 需要 事先约定 如何提供服务 , 如何进行调用服务 ;

2、人机交互口的发展 - 命令行 -> 图形界面 -> 语言界面 -> 脑机

人机交互口的发展 :

命令行接口 : Command Line Interface , 简称 " CLI " , 这是最早的人机交互方式 , 用户通过文本命令操作计算机系统 , 程序员需要受到严格训练 , 才能流畅使用该接口 ; 常见的 命令行接口 有

DOSLinux shellWindows Power Shell

图形界面接口 : Graphical User Interface , 简称 " GUI " , 应用程序靠 图标、窗口、菜单等图形元素来与用户交互 , 极大地降低了使用难度 , 用户需要简单学习 , 可以使用该接口 ;

语言界面接口 : Conversational User Interface , 简称 " CUI " , 或 Natural-Language User Interface , 简称 " LUI " , 通过 自然语言 对话的方式 与 计算机系统 进行交互 , 如 : 汉语、俄语、英语 ; 这种交互方式更加直观、自然 , 用户无需记忆复杂的命令或操作图形元素 , 不需要学习 只要会说话 就可以操作该接口 ; 常见的 语言界面接口 :

智能音箱 : 小米 / 华为 智能音箱 ;手机助手 : Siri ;GPT 大模型 : 文心一言 / ChatGPT ;

语言界面在智能家居、智能客服、语音助手等领域得到了广泛应用 ;

脑机接口 : Brain–Computer Interface , 简称 " BCI " , 允许用户 通过 大脑活动 来与计算机进行交互 , 涉及 脑电图 EEG 等 神经科学技术 , 以捕捉和解析大脑信号 ; 不需要会说话 , 只要不是傻子就可以使用该接口 ;

3、应用程序编程接口的发展 - 本地 -> 远程 -> 自然语言接口

应用程序编程接口的发展 :

本地 -> 远程 API : 早期 API 只应用于 本地或局域网内的程序间通信 , 随着互联网发展 , 远程 API 使得不同地理位置的 进程 能够相互交互 ;同步 -> 异步 API : 同步 API 要求 客户端 在请求后等待服务器响应 , 异步 API 允许 客户端 在等待响应的同时继续执行其他任务 , 提高了程序的效率和响应性 ;传统 API 本质不变 : 传统的 API 本质都是 程序员 互相约定好 , 服务方给出文档接口 , 使用方按照文档接口进行开发 , 使用服务方功能 ;自然语言接口 : Natural-Language Interface , 简称 " NLI " , 所有的软件都可以提供 NLI 接口 , 软件进程之间传递 自然语言 , 互相之间不再使用 API , 而是使用 自然语言 进行协同交互 , 无需 编写代码 或 遵循特定的语法规则 , 使得 非技术人员 也能轻松地与软件系统进行交互和定制 ;

上述发展仅仅是 从 AI 大模型角度出发考虑的 应用程序编程接口 发展问题 , 短时间内实现的可能性不大 ;

二、AI 大模型缺陷与补救措施 - 函数调用 Function Calling 引入

1、AI 大模型原理

GPT 大模型 ( Generative Pre-trained Transformer ) 是一种 基于Transformer架构的生成式预训练语言模型 , 在大规模无监督文本数据上进行预训练 , 学习语言的普遍规律 , 从而具备生成高质量文本的能力 ;

通过 预测单词序列中下一个单词的方式 , 模型能够学习到文本中的语法、语义和上下文信息 , 从而捕捉到丰富的语言知识 ;

根据概率 生成文本 的 机制 , 如下图所示 :

提示词是 The cat ;根据现有提示词 , 后面生成每个词的概率中 , sat 的概率是 0.5 , 概率最大 , 则生成 sat 单词 ;

2、AI 大模型缺陷

AI 大模型有如下 缺陷 :

并非全知全能 : AI 大模型 并非 全知全能 , 知晓一切 , 其本身的知识仅限于 训练的数据 包含的内容 , 一些非公开的知识 它 是不知道的 , 也不会生成出来 ;时效性差 : AI 大模型 训练一次 消耗很多时间 和 资源 , 不可能随时保持更新 , GPT 3.5 的知识截止到 2022 年 1 月 , GPT 4.0 截止到 2023 年 4 月 , 每次训练都需要花费 1 年的时间 ;

GPT 4.0 的 训练数据 , 截止到 2023 年 4 月 , 整理完数据 , 训练一年到 2024 年才能推出 ;AI 大模型在训练的时候 , 属于炼丹 , 一次性投入一些文本知识库 , 不知道训练结果 , 有可能变聪明了 , 有可能变傻了 ; 每次训练都要检查是否变好还是变坏 , 如果变坏就回滚 , 如果变好继续迭代 ; 没有逻辑推理能力 : AI 大模型 的 思维链 是 基于文本的 统计规律 生成的 , 并不具备真正的逻辑推理能力 , 其本质就是根据概率生成文本 ;

一些简单问题 , 根据概率生成的文本 , 看似具备逻辑推理能力 ;复杂问题 , 基本上就是胡说八道 ;

3、函数调用 Function Calling 引入

AI 大模型有 上述 三种缺陷 , 因此 需要 有一种机制 , 使得 AI 大模型 需要 与 外部进行交互 , 为 AI 大模型 对接 各种接口 ;

特定领域的知识或消息 , 如 : 非公开信息等 ;专业领域的接口 , 如 获取当前的时间 , 天气 , 特定领域知识请求 , 特定功能对接具有时效性的信息 , 如 : 最新的新闻 , 最新统计数据等 ;特定领域的逻辑推理能力

上述对接 , 可以通过 函数调用 Function Calling 实现 ;

函数调用 Function Calling 是 大模型 与 真实世界的实际业务 进行联系交互的纽带 , 使用 函数调用 可以将 大模型 与 实际业务 进行关联 ;

4、" 真逻辑 " 要求

" 真逻辑 " 必须是 符合逻辑规律、能够正确反映事物本质和规律的逻辑推理 , 有如下特点 :

正确性 : 得到的结果必须是正确的 , 不能出错 ;一致性 : 多次推理 , 推理的步骤和结果必须一致 , 大模型根据概率生成内容 , 肯定无法达到这个要求 ;可读性 : 不能像神经元网络一样 , 数据输入进去 , 跟炼丹一样 , 得到一个结果 , 不知道具体的推理步骤和过程 ;

GPT 大模型 并没有 逻辑推理能力 ;

5、函数调用 Function Calling 为 大模型 赋能 " 真逻辑 "

AI 大模型 没有 " 真逻辑 " , 只是一个基于 概率 生成文本的 工具 ;

代码编程 , 使用 顺序 / 选择 / 循环 解决的各种问题的方式 , 是 " 真逻辑 " , 可以 确定性的 解决各种具体的问题 ;

函数调用 Function Calling 就是 使用代码 实现的 " 真逻辑 " , 嵌入到 AI 大模型中 , 在 大模型 的 概率生成文本的 基础上 增加 确定性的 " 真逻辑 " 功能 , 可以解决所有的问题 ;