gpt meeting service

gpt-meeting-service

零、是幹嘛的

1. 這是一個基於GPT的API開發的小專案。眾所周知目前GPT的上下文支援就是每次把歷史消息都再次發出去，方法很「簡單粗暴」，而這個專案簡單的說就只做了一件事：就是讓上下文組織更靈活，以支持完成更加複雜一些的任務。
2. 項目最初的靈感來源是「腦力激盪」和「6頂思考帽」。腦力激盪在進行的過程中，每個環節關注的重點不同，需要不同的角色發揮作用，這一過程正好是和6頂思考帽的使用契合的。 6頂思考帽的靈活配合使用可以達成不同的目的，再延伸之後就有了這個項目「會議meeting」或叫討論會。
3. 基於以上，專案最主要實現以下3個功能
   1. 任務流程圖的編排，每個環節完成一件事，串起來完成一項相對複雜的任務（也理解為會議議程設計）。
   2. 讓GPT自問自答，完成聯想。
   3. 讓GPT分別扮演不同的角色，對同一個主題進行討論。
4. 可能的應用場景
   1. 腦力激盪
   2. 快速聯想
   3. 快速評估
   4. 多角色對話

關聯前端專案：gpt-meeting-web

一、節點類型

節點是指在「會議」過程中的議程（會議環節），目前分為5種類型，每種節點對情境的處理有所不同。

一般情況：背景資訊+ AI人設+ Prompt + 輸入= 輸出

輸入Input

一般為輸入本次的主題和目標，可以直接提交或讓GPT進行優化後再提交。

聯想思考Thinking

聯想包含兩種AI人設角色，其中聯想角色用於產生多個想法；提問角色則是對產生的想法進行相關的提問，可以提多個問題並且可以進行追問（相對應於“提問輪次”和「提問個數」），因此整體結構就呈現為樹狀結構，產生想法對應於樹的根節點，而對想法的提問則是對應於樹枝的生長。 除了自動問答外，也可以人工介入進行追問。

討論Discussion

討論節點可以選擇多個不同角色的成員，每個成員都依照他自身的特質來參與討論。

通用處理Processing

自訂prompt對輸入進行處理。

輸出Output

輸出一般作為最有一個節點，對整個討論過程進行總結，然後按指定的格式進行輸出，作為最終結論。

二、工作原理

環節（議程）節點的脈絡組織

首先流程圖必須是有向無環圖，然後在「會議」開始後，會依照拓樸順序來執行。在每個節點上，會將當前節點所有的上游節點的「結論」作為自己的「上文」，這樣的話可以保證GPT獲得足夠的背景信息，再對當前節點的任務進行回答，理論上效果會更加理想。

聯想時的上下文組織

自問自答的聯想是以樹形的結構進行的，所以上下文的組織自然是當前聯想節點的所有祖先節點的對話記錄，這很容易理解，例如下圖中紅色框的標記。

多角色討論時的上下文組織

多角色討論的開頭會自動帶入背景資訊和當前環節的要求，之後每一個成員的發言都會攜帶先前的記錄作為背景信息

開發相關

技術選型

• 語言: golang
• 框架: kratos
• 儲存: MongoDB

建議環境

vscode

本地跑起來

 # 配置configs/config.yaml

# 依赖安装（在Makefile文件中定义了相关命令）
make init

# 运行(调试建议使用vscode)
kratos run

# 导入初始模版
cd cmd/script && go run dataOp.go importData

docker映像建置

 docker build -t gpt-meeting-service:v1 .

docker-compose部署

 cd docker-compose
# 配置文件
mkdir conf && cp ../configs/ ./conf

# 启动
docker-compose up -d

# 停止
docker-compose down

說明

• 計畫採用kratos框架，需要先了解這個框架
• 由於protoc對sse的不支持，導致了meeting模組沒有使用protoc來定義接口
• kratos入門參考文章
• kratos命令可參考kratos.md