自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

聽說你會架構設計?來,弄一個約會系統

開發(fā) 架構
客戶端在 Moment 發(fā)布合成視頻時,將原視頻分片上傳至視頻處理中心(VHS),并通過開啟 QUIC 的方式,讓用戶在弱網環(huán)境下也有著不錯的性能。

引言

大家好,我是小?。

不知道大家有沒有經歷過,比家人逼著相親的苦惱,被七大姑八大姨天天問有沒有對象的無奈。當然,希望你永遠不要經歷 (>-<

不過,在今天這個快節(jié)奏的世界里,相信有很多人都有找對象或者說約會的需求。這時候,誰不想要一個聰明的紅娘呢?

“Dating” 應用正是為此而生,它將傳統約會方式和 AI 技術完美結合,讓你和潛在對象的距離瞬間拉近。本文將帶你一探這款應用的神奇之處,看看它如何讓約會變得既高效又有趣。

1. 整體架構

Dating 是一款社交類 App,在傳統單一社交上新增了 虛擬 AI,采用 Moment+ AI 對話等動態(tài)方式,讓交友對象可以更快速地熟悉彼此,從而快速實現精準 Match 的目的。

架構圖:

圖片圖片

涉及前后端關鍵組件如下:

客戶端:頁面展示,接口調用,渲染好看或者有趣的用戶信息

網關:數據接收,根據用戶不同的位置就近接入代理服務,比如:你在硅谷和在深圳,網關側識別后分別將請求發(fā)到不同的代理服務上

代理服務:公共鑒權,業(yè)務請求轉發(fā),灰度部署等,在不同地區(qū)部署多個服務器(如硅谷、深圳)

用戶服務:管理用戶基本信息,用戶權益等數據

動態(tài)服務:存儲用戶Moment動態(tài)信息,以及和推薦、Agent交互,是Dating業(yè)務的核心后臺模塊

會話服務:管理用戶關系(好友、粉絲)和用戶對話,和 IM 后臺之間交互

涉及算法模塊如下:

Agent模塊:接收后臺傳入的用戶對話信息,根據一定的Prompt規(guī)則,請求大模型(LLM)進行AI回復

用戶畫像:處理用戶所有基礎數據和記憶,加工、過濾、篩選,并存入ES(大數據處理組件)

推薦模塊:暴露接口給后臺服務,當用戶獲取推薦時,在ES里取出對應的用戶列表展示在客戶端頁面上

涉及基礎組件包括:

ASR(語音轉文字),TTS(文本轉語音),DB(結構化數據存儲),COS文件存儲及 Kafka 數據傳輸等

主要功能包括:用戶登錄、Moment 發(fā)布、獲取推薦用戶、IM 對話,下面基于這些核心功能,我們依次來介紹一下。

2. 用戶登錄

用戶在使用 App 的過程中,創(chuàng)建賬號可以方便用戶對自己創(chuàng)建的資料和信息進行管理。

圖片圖片

Dating 支持用戶采用谷歌、蘋果賬號或者手機號登錄,登錄模塊是公共模塊,主要和 Firebase/Apple 后臺進行交互,做數據鑒權和驗證。

業(yè)務時序圖如下:

圖片圖片

用戶的業(yè)務信息主要是用戶服務進行管理,結構化數據存儲在 MySQL 里面,圖片、視頻類數據存在 Cos 對象存儲服務中。

同時,用戶的個人信息:包括昵稱、年齡、性別、喜好、標簽等數據上報到用戶畫像進行離線處理,每當有用戶注冊完成后,推薦模塊會根據用戶畫像的數據用一定的公式計算用戶之間的匹配度,進行推薦。

3. Moment 發(fā)布

在快節(jié)奏的現代社會中,人們越來越傾向于通過在線約會應用程序尋找伴侶。然而,虛擬世界中的信任建立和真實性驗證是一個挑戰(zhàn)。

Dating 通過引入"Moment"功能,旨在提供一個創(chuàng)新的平臺,利用人工智能技術引導用戶全面展示自己,并與潛在的伴侶建立真誠的聯系。

以下是創(chuàng)建 Moment 的步驟:

圖片圖片

moment創(chuàng)建中AI共提問兩輪:

第一輪,AI 根據用戶相冊上傳/主攝像頭拍攝的圖片/live 動圖+用戶基礎信息進行提問,問題實時展示在視頻上。提問結束后調用前置攝像頭,并出現語音交互提示,用戶通過語音回答 AI 的問題。

第二輪,AI 根據用戶上一輪回答深挖提問,問題實時展示在視頻上。提問結束后調用前置攝像頭,用戶繼續(xù)通過語音回答問題。

兩輪回答結束后,進入 moment 制作環(huán)節(jié)(loading 狀態(tài)),moment 制作完成后向用戶展示。

用戶點擊“post”按鈕進行發(fā)布,若不滿意拍攝效果,可點擊返回按鈕選擇是否刪除當前 moment 重新創(chuàng)建。

以下是交互流程(時序圖):

圖片圖片

用戶選擇圖片進行上傳到 dating,后臺根據圖片內容、用戶信息生成 AI 提問,比如用戶上傳了一張貓咪的照片,AI 可能會用溫柔的語音詢問:“Hi 小?,這只布偶貓咪真可愛,是之前你說的那只奶昔吧,看它在床上睡得真閑適啊!你今天還要繼續(xù)在家擼貓嗎,還是出門和大學同學去逛街???”

這時我會回答:“是的,奶昔很可愛呢,今天要背著它先打疫苗,然后和鄢哥去約飯”,然后 dating 再根據我的回答調整問題,經過兩次問答之后,客戶端會上傳這部分的視頻和圖片,以及我和 AI 的問答信息,并將它們經過后臺處理后記錄成我的標簽,最終放到我的個人畫像里面。

下次我們再上傳 Moment 時,AI 就可能會問:“Hi 上周你和鄢哥去約飯吃了些什么呀?味道如何...”。

由于都是通過語音進行交流,所以這個部分涉及的組件主要有 DB 存儲語言文件路徑,Cos 存儲語音文件,ASR 將用戶語音轉為文本輸入,TTS 將大模型的回復文本轉成語音播放給用戶聽。

4. 獲取推薦用戶

當用戶創(chuàng)建 Moment 之后,就可以在首頁刷到別的用戶了。

推薦時我們會根據:用戶距離、相似度(比如年齡、身高、興趣愛好)、活躍度、Moment 豐富程度等來進行推薦,傾向于推薦那些有著優(yōu)質 Moment 及內容完善度高,還有比較活躍的用戶。

同時,會根據用戶的受歡迎程度來影響被推薦的概率因子。

圖片圖片

用戶刷到別的用戶時,可以在主頁點贊或者對別人的 Moment 進行評論,這時:客戶端會調用 ASR SDK 方法,將用戶的語音評論轉換成文本傳入后臺動態(tài)服務。

每次點贊或評論都默認喜歡對方。當對方用戶回復了點贊或評論后,就會自動成為好友,此時會話服務會把好友關注寫入到 IM 系統中(比如騰訊云的 IM 系統,參考 QQ),進行實時會話管理、好友關系維護等。

5. IM 對話

當兩個用戶成為好友以后,就可以在 CHAT 頁進行對話。

圖片圖片

此時,用戶拉取好友列表、發(fā)消息都是直接調用 IM 管理服務,如果是真實用戶對話,IM 管理服務會將會話發(fā)到長連接管理中心,進行消息推送。比如:你在 VX 上給好友發(fā)了一條消息,好友手機 APP 上就會出現通知圖標。當好友拉取對話列表時,IM 管理服務會在接口返回兩個用戶的聊天記錄。

同時,當 IM 管理服務監(jiān)測到有消息發(fā)送時,會將所有對話通過回調的方式傳入會話服務。會話服務會通過用戶 ID 判斷是與真人對話還是和虛擬人對話,如果是和虛擬人對話則調用 Agent,通過一系列 Prompt 處理后由 LLM(大模型,如 DeepSeek)生成智能回復。

6. 一些難點和要點

1)好友關系存儲復雜

在所有社交軟件中,IM 關系都是我們需要考慮的重點。Dating 業(yè)務中,我們不僅要考慮單向關注、粉絲,好友,以及成為好友后單向取關、好友拉黑等情況。

關系模型轉換圖如下:

圖片圖片

為了減少轉換的狀態(tài),我們將拉黑和刪除好友后,直接將關系置成單向關注,并在 IM 開始對話前校驗好友關系,如果發(fā)現對方已經拉黑或者刪除,就彈出一個提示(類似 VX 里面的紅色感嘆號),無法進行對話。

同時,為了快速返回好友的關系,我們在會話服務存儲關系狀態(tài)時,不僅需要持久化到 DB 里面,還需要給每個用戶創(chuàng)建三個 Set(分別存儲好友、粉絲和已關注),這樣拉取好友列表時可以快速返回,減輕數據庫負擔。

關于 Redis 和 DB 如何保持一致性,可以看我之前寫的這篇文章:Redis IO多路復用

2)用戶對話耗時較高

在創(chuàng)建 Moment 時,由于每次需要通過用戶上傳的圖片,其基本信息,用戶記憶等數據請求大模型,再生成 Q1 提問,這個串行化的過程比較長且涉及 VQA 流程(即給機器一張圖片和一個開放式的的自然語言問題,要求機器輸出自然語言答案),同時,由于圖片的鏈接放在對象存儲服務中,每次從 LLM 拉取圖片鏈接時由于網絡不穩(wěn)定,可能會導致用戶上傳圖片后等待回復需要很久,大概 7~9s。

所以我們通過以下方式來優(yōu)化:

  • 圖片直接通過 Base64 從客戶端傳入 LLM,節(jié)省圖片上傳下載耗時;
  • Agent 通過記憶、圖片信息提問時合并成一步,減少多次調用耗時,總結用戶記憶可以異步進行;
  • 流式傳輸,每次 AI 流式返回時,動態(tài)服務通過標點符號判斷一整句話就送入 TTS 生成語音返回給用戶,把整段耗時減少為首句耗時;

圖片圖片

通過以上優(yōu)化,客戶端等待時間從 7~9s 減少到 1~2s 就可以收到 AI 提問。

3)用戶Moment播放卡頓

獲取推薦列表時,由于用戶都是從對象存儲拉取視頻文件進行播放,所以對用戶的網絡要求比較高。而對于海外 25~30Mbps 網速的用戶來說,拉取一個 15MB 的視頻就得花 5s(15/3MB/s),這是項目上是難以接受的,用戶體驗也很差。

所以我們嘗試加入視頻壓縮、預加載和自適應碼流播放等功能。

圖片圖片

具體流程為:客戶端在 Moment 發(fā)布合成視頻時,將原視頻分片上傳至視頻處理中心(VHS),并通過開啟 QUIC 的方式,讓用戶在弱網環(huán)境下也有著不錯的性能。

然后 VHS 根據配置的規(guī)則開始轉碼,通過異步轉碼的方式處理視頻,將用戶的視頻轉成 480P、720P、1080P 等格式。

動態(tài)服務將視頻的鏈接存儲,每次客戶端拉取時,返回視頻鏈接,這時 VHS 可根據用戶網速的變化自動選擇最適合的碼流,在保證視頻播放盡可能流暢的前提下,選擇最佳清晰度的視頻播放,以此來優(yōu)化用戶體驗。

7. 小結

由于篇幅有限,很多技術點和細節(jié)都是淺嘗輒止,如果讀者感興趣,后面我們可以再出一篇細節(jié)的技術或者代碼實現來講解介紹。

感謝大家一路看到這里!還記得我們開頭聊的那些相親煩惱嗎?在這個快節(jié)奏的世界里,Dating 應用正是為了解決這些問題而誕生的。

它不僅結合了傳統約會方式和 AI 技術,還讓整個過程變得更有趣和高效。無論是智能推薦、自然流暢的對話,還是輕松的互動體驗,這款應用都讓你在尋找對象的路上更加從容。

在大模型應用化的過程中,Dating 算是一款為現代約會帶來了新思路的 App。希望它能為大家提供一些啟發(fā),讓你在愛情的路上少些波折,多些樂趣;同時讓我們在 AI+ 的過程中,探索更多可能性,體驗技術如何在社交關系中發(fā)揮積極作用。


責任編輯:武曉燕 來源: xin猿意碼
相關推薦

2023-11-08 07:05:07

架構設計群聊系統

2023-12-29 11:32:27

2023-12-14 17:27:28

架構設計數據表

2023-10-08 22:38:52

2023-11-01 18:10:45

架構設計技術

2022-12-25 18:58:53

架構RabbitMQ

2024-03-01 18:55:54

內存調試Go 語言

2024-08-28 08:38:51

2021-04-28 08:52:22

高并發(fā)架構設高并發(fā)系統

2019-08-22 10:54:05

分布式系統架構

2022-05-17 20:37:41

MyPick泛型對象類型

2019-01-28 11:46:53

架構運維技術

2024-04-24 10:38:22

2023-07-05 08:00:52

MetrAuto系統架構

2025-01-22 08:00:00

架構秒殺系統Java

2024-06-21 08:15:25

2023-09-02 21:22:36

Airbnb系統

2013-07-15 13:36:29

架構設計

2013-07-24 10:49:04

架構設計師商業(yè)價值

2022-02-17 08:57:18

內存設計進程
點贊
收藏

51CTO技術棧公眾號