「RFC」- AIStoreProvider 数据流&配置Provider

[ONLY-yours]

Summary

新增名为 AIStoreProvider - 数据流&配置Provider 的新组件。目的为了让用户快速搭建一个 AI 对话场景下的内容获取和组装。
包含以下几个部分：

• messages：对话上下文数组及配套 hook
• model config：模型配置的参数层及配套 hook

不包含的部分：

• 网络请求

Motivation

Detailed Design

组件名称

• 英文名称: AIStoreProvider
• 中文名称: 数据流&配置Provider

API 设计

interface AIStoreProviderContentType {
  /**
   * 唯一标识符
   */
  id: string;

  /**
   * 对话上下文存储内容区域
   */
  message: MessagesStoreType;

  /**
   * 快捷指令的图标，可以是任意 ReactNode
   */
  model?: ModelConfigStoreType;
}

interface LLMMessage {
  content: string;
  role: 'user' | 'system' | 'assistant' | 'function' | string;
  id?: string; 
}

interface MessagesStoreType {
  /**
   * 对话内容区域
   */
  messages: <LLMMessage & Object>[];
  onMessagesChange?: (list: <message>[])=>void; //callback
  onMessageChange?: (item : message)=>void; //callback
}

interface ModelBaseConfig  {
    model?: string; // model name
    frequency_penalty?: number;// 控制生成文本中的惩罚系数，用于减少重复性
    max_tokens?: number; // 生成文本的最大长度
    presence_penalty?: number; //控制生成文本中的惩罚系数，用于减少主题的变化
    temperature?: number; // 生成文本的随机度量，用于控制文本的创造性和多样性
    top_p?: number; // 控制生成文本中最高概率的单个 token
}

interface ModelConfigType {
  config: ModelBaseConfig & Object
  onChange?: (config)=>void;
}

Hooks 设计

interface LLMMessage {
  content: string;
  role: 'user' | 'system' | 'assistant' | 'function' | string;
  id?: string;
}

type UseMessageType = {
  message: LLMMessage[],
  addMessage: (msg: LLMMessage) => void,
  clearAllMessage: () => void,
  pushMessage: (index: number, msg: LLMMessage) => void,
  setMessage: (id: string, msg: LLMMessage) => void,
  deleteMessage: (id: string) => void,
  getMessage: () => LLMMessage[],
}

declare function useMessages(id: string): UseMessageType;

Example Usage

Basic Use Message

import React, { useState } from 'react';
import {AIStoreProvider, Bubble } from '@ant-design/x';

const Chats = [
    {
      content: '昨天的当天是明天的什么？',
      id: 'ZGxiX2p4',
      role: 'user',
    },
    {
      content: '昨天的当天是明天的昨天。',
      id: 'Sb5pAzLL',
      role: 'assistant',
    },
  ]


const App: React.FC = () => {
  const [messageList, setMessageList] = useState(Chats）;

  return (
    <AIStoreProvider 
      id="save-query-database"
      message={{
        messages: messageList,
        onChange:(list)=> setMessageList(list)  
      }}
      >
      <Bubble.List item={messageList}/>
    </Shortcuts>
  );
};

export default App;

Use Hook

import React, { useState } from 'react';
import {AIStoreProvider, Bubble } from '@ant-design/x';

const Chats = [
    {
      content: '昨天的当天是明天的什么？',
      id: 'ZGxiX2p4',
      role: 'user',
    },
    {
      content: '昨天的当天是明天的昨天。',
      id: 'Sb5pAzLL',
      role: 'assistant',
    },
  ]


const BubbleList = ()=>{
const BubbleList = () => {
  const {
    messages,
    addMessage,
  } = useMessages('save-query-database');
  return (
    <div>
      <Bubble.List item={[]} />
      <Sender
        onSubmit={(messages) =>
          addMessage({
            id: nanoid(),
            role: 'user',
            content: messages,
          })
        }
      />
    </div>
  );
};
}

const App: React.FC = () => {
  const [messageList, setMessageList] = useState(Chats];

  return (
    <AIStoreProvider 
      id="save-query-database"
      message={{
        messages: messageList,
        onChange:(list)=> setMessageList(list)  
      }}
      >
      <BubbleList/>
    </Shortcuts>
  );
};

export default App;

Hints

• 不涉及网络处理的原因在于，流式和非流式处理起来逻辑不一样，要做多种逻辑兼容非常复杂，要考虑的问题应该单独开一个东西来处理。（最好基于 useRequest 单独封装一个 hooks 叫做 useAIRequest 会好很多）

[ONLY-yours]

我说一下我这边的看法，为什么不应该包含 runtime 和 AI 的请求部分：

• 有了 Runtime 会有一些东西很难处理：是否要加入 Peding 一些状态，例如网络请求过程中，流式的话还有 progress 中，奇奇怪怪的
• 不带 AI 模型请求的一个主要原因是，虽然大部分LLM 参数都差不多，但是在细微逻辑上是无法统一的，如果 LLM 架构升级，参数就变得很快，不建议直接把请求带进去。（我甚至觉得 Model 的 Config 都可以去掉，只留下 messages 和 对应的 hook）

还有很重要的一点：可能业务背后说不定没有模型，🤣 他们只是想看起来是大模型

[zombieJ]

我说一下我这边的看法，为什么不应该包含 runtime 和 AI 的请求部分

没有数据部分，这个功能用户自己 useState 管理其实也不难……

[ONLY-yours]

确实有点尴尬

[ONLY-yours]

感觉还是需要的，至少 hook 需要

• 删除某个对话、编辑某个对话

[YumoImer]

我们两个的方向不太相同，我认为可以有 Runtime 和 fetch，我梳理了下核心的点：

1. 异步问题：可以把 fetch 交由用户传入，内部只认标准的 fetch API，应该不存在难以处理的问题
2. 协议问题：协议是指模型的返回，我认为我们是可以内部把主流的闭源（openai）、开源（llama、ollama）内部做兼容然后转换为我们原子组件的数据版本（这其实对我们的开发者用户来说通常是必经之路）
3. 太重的问题：X 不需要把对应的模型供应商 SDK 包含进来，只需要写一些 Adapter 和 TS 类型定义
4. 协议变化的问题：这个点确实没法避免，但是可以适当防御。

还有一个点，Ant Design X 生态的多样性：原子组件 + Runtime = Chat ，这可以给我们的开发者用户提供多样的选择：

• 需要深度使用：原子组件 + Runtime
• 需要开箱即用：Chat
• 仅需要 UI：原子组件
• 仅需要运行时，UI自己写：Runtime

另外，对于「只是想看起来是大模型」这类我始终觉得：交给时代，X 应该是面向未来。