最近突然想到一個多人聚餐的問題，每次要約幾個朋友吃飯其實都很麻煩，要先問大家哪一天有空，再來要決定去哪裡吃，還要考慮每個人的飲食習慣、預算、交通方式等。
例如有人吃素、有人不吃牛，有人從桃園搭火車過去，有人開車需要停車位，有人覺得餐廳離捷運站走10分鐘沒問題，有人覺得太遠。好不容易時間喬好了，選了一家餐廳，又可能有人覺得太貴或不想吃那種類型，幹！超煩。
通常這些事情就是在LINE群組裡面大家一句一句問，最後由其中一個倒楣的傢伙（主揪）整理。
我就在想，這件事是不是可以讓AI來做？
一開始想得很簡單，就是讓每個人回答自己的條件，例如可以聚餐的時間、從哪裡出發、搭什麼交通工具、預算多少、有什麼不能吃、比較想吃什麼類型的餐廳等，最後把這些條件整理起來，再推薦大家都可以接受的餐廳。
但後來想到一個問題，如果所有人的條件根本沒有交集怎麼辦？
例如A只有星期六可以，B星期六晚上可以，C星期六晚上也可以，但是D星期六完全不行，那系統不能只是回答「沒有符合條件的方案」，不然跟用Google表單統計完發現大家時間對不上也沒什麼差別。
這時候AI比較有用的地方，可能不是單純幫大家填表格，而是繼續協調。
例如D原本回答星期六不行，AI可以再問D：「星期六是整天都不行，還是晚上某個時間以後可以？」如果D回答晚上8點以後可以，那原本沒有交集的條件可能又出現交集。
或是某個人原本回答預算600元以下，但其他所有條件都已經符合，只剩下找到的餐廳大約要800元，AI就可以只去問這個人：「如果其他條件都符合，預算提高到800元可以接受嗎？」
這樣就不用每次條件改變，又叫所有人重新回答一次。
後來和AI討論才知道，這類問題其實叫做GDSS（Group Decision Support System，群體決策支援系統），以前就已經有這類研究，只是現在有LLM後，可以直接用自然語言跟每個人溝通，這件事變得比較容易做。
┌───┐ ┌────┐
│ A ├─────►┤ AI ├───┐
└───┘ └────┘ │
┌───┐ ┌────┐ │
│ B ├─────►│ AI ├───┤
└───┘ └────┘ │
┌───┐ ┌────┐ │ ┌─────────────┐ ┌────────────────────┐
│ C ├─────►│ AI ├───┼────►│ Group State ├────►│ AI Decision Engine │
└───┘ └────┘ │ └─────────────┘ └────────────────────┘
┌───┐ ┌────┐ │
│ D ├─────►│ AI ├───┤
└───┘ └────┘ │
┌───┐ ┌────┐ │
│ E ├─────►│ AI ├───┘
└───┘ └────┘
我目前想像的使用流程是，首先由其中一個人建立一個新的聚會，例如「11月兄弟聚餐」，系統產生這次聚會專屬的QR Code或連結，建立者再把連結丟到LINE群組給要參加的人。
每個人點進去後，不是在同一個聊天室裡面七嘴八舌，而是各自跟AI回答問題。
例如：
其他人也各自回答自己的條件，系統再把每個人的回答整理到這一次聚會共同的Group State裡面。
不過大家不可能同一時間回答，所以這個流程應該是非同步的。
例如建立聚會時設定第一輪回答期限，星期五晚上以前大家回答完，過程中可以看到目前5個人有3個人已經回答，但先不用急著要求任何人改變條件。
等全部的人回答完，或是回答時間截止後，再開始計算大家的條件是否有共同解。
如果有，就繼續找符合條件的餐廳。
如果沒有，就找出到底是哪幾個條件互相衝突，再開始第二輪詢問，而且只問真的需要調整條件的人。
所以目前想像的流程大概是：
┌─────────────────────────────┐
│ 主揪建立聚會 (Session) │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ 產生 QR Code / 邀請連結 │
└──────────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ 參與者陸續點擊加入 │
└──────────────┬─────────────┘
│
▼
┌──────────────────────────────┐
│ Round 1：AI 分別非同步蒐集 │
│ 每個人的條件 (Hard/Soft) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 建立 Group State │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 所有人回答完成 或 時間截止 │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ GDSS 共識決策引擎計算： │
│ 是否存在共同方案？ │
└──────────────┬───────────────┘
│
┌───────────────┴───────────────┐
│ │
【有共同方案】 【沒有共同方案】
│ │
│ ▼
│ ┌──────────────────────────────┐
│ │ 分析並找出主要衝突條件 │
│ └──────────────┬───────────────┘
│ │
│ ▼
│ ┌──────────────────────────────┐
│ │ Round 2：向特定參與者發起 │
│ │ 針對性追問 (條件放寬) │
│ └──────────────┬───────────────┘
│ │
│ ▼
│ ┌──────────────────────────────┐
│ │ 更新 Group State │
│ └──────────────┬───────────────┘
│ │
│ ▼
│ ┌──────────────────────────────┐
│ │ 重新計算群體可行方案 │
│ └──────────────┬───────────────┘
│ │
└───────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 產生 1 家主要推薦與備選餐廳 │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 大家決定最終聚餐方案 │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 一鍵生成聚餐資訊卡與連結 │
└──────────────────────────────┘
這邊還有一個很重要的區別，就是「不能」跟「不喜歡」不能當成同一件事情。
例如某個人星期六要上班，那星期六不能參加就是不能改的條件；但某個人只是比較不想吃日本料理，如果最後日本料理是最符合其他條件的方案，那就還有協調空間。
所以系統裡面應該要把條件分成Hard Constraint（硬性限制）和Soft Preference（軟性偏好）。
Hard Constraint是不能違反的，例如真的沒空、食物過敏等。
Soft Preference則是比較希望怎樣，但必要時可以調整，例如比較想吃燒肉、希望預算600元以下、希望離捷運站近一點等。
這也是我覺得AI在這個產品裡面比較有價值的地方，因為一般表單很容易把這些東西都變成固定欄位，但人在實際回答問題時常常不是這麼明確。
例如：「遠一點沒差，但不要超過半小時」、「14號最好，但21號也不是不行」、「大概600元，如果真的很好吃800也可以」。
AI可以先理解這些自然語言，再把它整理成系統可以處理的條件，如果不確定就再問一次。
餐廳推薦這邊目前反而想要刻意限縮。
一開始有想到是不是可以直接幫使用者訂位，甚至跟餐廳談導流抽成，但仔細想就發現這件事情麻煩死了。
因為很多餐廳根本沒有線上訂位系統，而且「某一家餐廳星期六晚上6點半還有沒有5個人的位子」是一個即時變動的資訊。如果要自己處理，就會牽涉餐廳合作、訂位、取消、No-show、對帳等一堆問題。
所以目前先不碰。
GroupEats只負責幫大家把條件喬好，然後推薦符合條件的餐廳。至於餐廳有沒有位置，由主揪自己打電話確認。
如果第一順位餐廳客滿，就回來標記這個方案不可行，再看第二順位。
這樣產品的邊界會乾淨很多。
商業模式目前也只是個假設。
因為這種東西如果跟餐廳談CPA導流抽成，還是會碰到餐廳合作與對帳的問題，感覺很麻煩。
另一個比較單純的方式可能是直接讓使用者付費。
例如第一次或前幾次免費使用，之後建立新的聚會需要花15～30元，或是先儲值再扣使用次數。被邀請進來回答問題的人則完全免費，只向建立聚會的主揪收費。
但這邊真正需要驗證的不是到底收15元還是30元，而是「有人願不願意為了少掉這些聚餐協調的麻煩付任何錢？」
因為最強的競爭對手其實就是免費的LINE群組。
所以這個產品目前有沒有辦法賺錢，我也不知道。
另外這個構想目前連MVP都還不急著做，甚至可以先全部手工跑一次。
找4～8個人，讓每個人分別回答聚餐條件，我人工把這些資訊丟給AI整理，看看第一輪會不會出現衝突，再模擬第二輪詢問，最後看看是不是真的可以比大家自己在LINE裡面討論更省事。
如果連全部人工幫忙處理，都沒有比大家自己在LINE裡面喊一句「星期六晚上台北車站吃火鍋有人不行嗎？」來得有效率，那可能根本就不需要做這個產品。
反過來，如果真的會碰到很多「沒有交集，但是稍微問一下其中一兩個人就能解開」的情況，那這個多人協調的流程才可能是這個產品真正有價值的地方。
目前這個構想還很粗糙，尤其實際使用流程還沒有完全理順，我腦中雖然已經會不自覺開始想AI、Group State和決策引擎要怎麼串，但現在先不想實作問題。
先把自己當成使用者，從「我今天想約幾個人吃飯」開始，把整個流程實際走一次再說。
沒有留言:
張貼留言