旅人經驗爆炸：數據堆積與論壇被忽略的小角落
Tripadvisor 這個名字，可能大家都聽過。說它是全球規模數一數二的旅遊指引平台，好像也不為過——用戶提交的評論加起來據說有上億條，年年還會增加不少，每年大約就有好幾千萬則新評論進來，圖片更是累積到一個驚人的數字。這些資訊雖然繁雜，但對計畫行程的人來說，有時候真能派上用場。
其實除了寫評論，很多人也喜歡在 Tripadvisor 上參與討論區交流。論壇不像一般評價那麼單向，它比較像閒聊，每天新話題、留言多到讓人難以統計——算下來，一整年下來有超過兩百萬則發言吧。不過到底是不是這麼多，應該沒人真的去細算。論壇裡的內容五花八門，有時當地熟門熟路的人會推薦一些鮮為人知的小店，也常有人在紐約找最棒三明治之類的問題發問，總之比純粹的景點評價細膩得多。
之前 Tripadvisor 團隊分享過，他們嘗試用生成式 AI 技術，把龐大的評論資料濃縮成摘要，同時盡量保留原始用戶那種帶點主觀又誠懇的語氣，不偏頗、不做裁判，而是呈現各方觀點。但具體效果怎樣，好像還需要更多時間觀察。不過既然旅客對網站有一定信任度，用同樣方式從論壇這些互動內容提煉出旅行建議，看起來也合情合理。
最近他們推出了「Travel Advice」這項功能，在城市或熱門地標網頁底部新增了一塊專區。裡面主要精選英語論壇裡那些常被問到的大哉問，再從眾多回覆中挑出較受歡迎或實用的答案，再做簡短整理，希望能讓資訊變得更親切易懂。有一點值得注意：內容來源都會公開標註，所以如果有人想要了解更多細節，也能自己去追溯原文。不過目前看起來只針對英文內容處理，其它語言版本未必同步開放。
至於這整套流程是不是真的全面準確，也許每個用戶感受不太一樣。但從外部觀察，「Travel Advice」似乎讓那些經驗豐富、愛分享的小眾聲音更容易被看見。如果你剛好在規劃下一趟旅程，大概可以考慮看看——至少省下一部分搜尋討論串的時間吧。
其實除了寫評論，很多人也喜歡在 Tripadvisor 上參與討論區交流。論壇不像一般評價那麼單向，它比較像閒聊，每天新話題、留言多到讓人難以統計——算下來，一整年下來有超過兩百萬則發言吧。不過到底是不是這麼多，應該沒人真的去細算。論壇裡的內容五花八門，有時當地熟門熟路的人會推薦一些鮮為人知的小店，也常有人在紐約找最棒三明治之類的問題發問，總之比純粹的景點評價細膩得多。
之前 Tripadvisor 團隊分享過，他們嘗試用生成式 AI 技術，把龐大的評論資料濃縮成摘要，同時盡量保留原始用戶那種帶點主觀又誠懇的語氣，不偏頗、不做裁判，而是呈現各方觀點。但具體效果怎樣，好像還需要更多時間觀察。不過既然旅客對網站有一定信任度，用同樣方式從論壇這些互動內容提煉出旅行建議，看起來也合情合理。
最近他們推出了「Travel Advice」這項功能，在城市或熱門地標網頁底部新增了一塊專區。裡面主要精選英語論壇裡那些常被問到的大哉問，再從眾多回覆中挑出較受歡迎或實用的答案，再做簡短整理，希望能讓資訊變得更親切易懂。有一點值得注意：內容來源都會公開標註，所以如果有人想要了解更多細節，也能自己去追溯原文。不過目前看起來只針對英文內容處理，其它語言版本未必同步開放。
至於這整套流程是不是真的全面準確，也許每個用戶感受不太一樣。但從外部觀察，「Travel Advice」似乎讓那些經驗豐富、愛分享的小眾聲音更容易被看見。如果你剛好在規劃下一趟旅程，大概可以考慮看看——至少省下一部分搜尋討論串的時間吧。
FAQ升級術，地標頁新欄位怎麼冒出來的？
每個問題都被放在獨立的小選單裡，想查什麼，旅客點一下小箭頭就能展開看到完整的回應。有些內容用多段落分開，還加上明顯的標題，看起來比較不費力。其實他們好像也特別注意過語氣簡單易懂，不會有太複雜的句子。你如果仔細看下去，差不多整體調性都是偏向整理摘要那種感覺，每一大段最後還會特地標註這是AI自動產生的說明。
為了讓那些熱心分享經驗的人被記得，每則旅遊建議文底下都附有「看相關討論」連結。點進去會彈出個小視窗，有幾張類似卡片的小預覽，把其他人的論壇貼文挑出來給你參考，也會標明原始作者。每張卡片可以直接跳到那篇完整文章，比較容易找到更細節的資料，同時也算是一種小小肯定吧。
其實這套做法主要是想讓資訊來源透明一點，好像希望大家知道AI整理出來的答案，其實內容跟論壇用戶原話差不多，只是換了一種方式呈現而已。
講到為什麼要用論壇內容——Tripadvisor.com/Forums有分地區專屬版塊，比如某個城市或鄉鎮，用戶可以在那邊發問、回應，也有人習慣順手交流各地旅遊消息。不只是按地理分類，他們還設計了一些主題式板塊，例如公路旅行、蜜月這類專門興趣群組，所以其實蠻靈活的。
另外，為了讓論壇資訊不要過時，他們還找了不少所謂目的地專家協助維護，那些人本身不屬於Tripadvisor公司，但平常滿常給建議。有點像是社群和外部達人一起幫忙把關，大致上能保證內容新鮮又帶有一點深度。
前陣子內部調查結果，有將近一半使用者覺得論壇資訊對旅遊頁面很受用，只比「興趣探索」這個分類稍微遜色一些。不久前測試好像也指出，如果FAQ整理得妥當，搜尋引擎流量可能會提升許多。不過這部分數據比較模糊，也不是絕對。
為了讓那些熱心分享經驗的人被記得，每則旅遊建議文底下都附有「看相關討論」連結。點進去會彈出個小視窗，有幾張類似卡片的小預覽，把其他人的論壇貼文挑出來給你參考，也會標明原始作者。每張卡片可以直接跳到那篇完整文章，比較容易找到更細節的資料，同時也算是一種小小肯定吧。
其實這套做法主要是想讓資訊來源透明一點，好像希望大家知道AI整理出來的答案，其實內容跟論壇用戶原話差不多，只是換了一種方式呈現而已。
講到為什麼要用論壇內容——Tripadvisor.com/Forums有分地區專屬版塊，比如某個城市或鄉鎮，用戶可以在那邊發問、回應，也有人習慣順手交流各地旅遊消息。不只是按地理分類，他們還設計了一些主題式板塊，例如公路旅行、蜜月這類專門興趣群組，所以其實蠻靈活的。
另外，為了讓論壇資訊不要過時，他們還找了不少所謂目的地專家協助維護，那些人本身不屬於Tripadvisor公司，但平常滿常給建議。有點像是社群和外部達人一起幫忙把關，大致上能保證內容新鮮又帶有一點深度。
前陣子內部調查結果，有將近一半使用者覺得論壇資訊對旅遊頁面很受用，只比「興趣探索」這個分類稍微遜色一些。不久前測試好像也指出，如果FAQ整理得妥當，搜尋引擎流量可能會提升許多。不過這部分數據比較模糊，也不是絕對。
Comparison Table:
| 主題 | 關鍵點 |
|---|---|
| PR行銷與SEO整合 | 透過論壇資料來提升搜尋引擎可見性和用戶互動 |
| 問題設計原則 | 問題應具體明確，避免模糊和過度細節 |
| 內容分類策略 | 將問題拆分成獨立類別以減少混淆，保持結構清晰 |
| 模型選擇與測試 | 使用bge-base-en-v1.5模型優於all-mpnet-base-v2，並進行內部評估 |
| 資料處理方法 | 採用語意斷句及上下文抓取方式，以提高回答的準確性 |
一團亂線索裡，怎挖出真正熱門的提問？
在開始之前，或許應該先講一下，有些人會發現Tripadvisor早就針對幾個熱門地區設有FAQ，那些內容蠻多人會去看。這些常見問題集是由站方自己整理的，大致上涵蓋了旅人常問的事情，像住宿、餐廳等等。不過說真的，它們比較像條列式筆記，比較少那種細膩討論或深度經驗分享。長期下來，要靠人工更新維護這些資料好像變得愈來愈吃力。反倒是在論壇裡頭，大家交流出現的那些細節和觀察，有時候還挺受用。於是就產生了個想法——是不是可以靠AI，把社群裡面用戶貢獻的內容梳理清楚、呈現出來？
其實機器學習確實有它厲害的地方，但也不是一蹴可及。有不少環節要克服，比如：怎麼篩選出真正值得回答的問題？答案要去哪找？再者，AI如果總結失真、不貼合原始討論，也難免讓人擔心。
在分析了一陣子論壇資料之後，好像逐漸浮現某種規律。例如不管哪個城市，只要旅客熱度高，大家在版上問的都蠻類似。拿紐約市舉例吧——關於博物館什麼時候去、路線怎麼走，好幾串主題都繞著這類事打轉。巴黎、柏林也差不多。
我們那時注意到，一條討論串最有價值資訊常藏在標題和第一則貼文裡頭。標題通常下得簡明扼要；首篇留言多半交代得很詳細，不外乎把疑問講清楚，有時連背景都帶進去了。這樣的小發現，其實就給接下來的工作帶來啟發——至少知道從哪開始下手比較妥當。但當然，接下來還是可能碰上一堆其他小狀況需要慢慢摸索解決…
其實機器學習確實有它厲害的地方，但也不是一蹴可及。有不少環節要克服，比如：怎麼篩選出真正值得回答的問題？答案要去哪找？再者，AI如果總結失真、不貼合原始討論，也難免讓人擔心。
在分析了一陣子論壇資料之後，好像逐漸浮現某種規律。例如不管哪個城市，只要旅客熱度高，大家在版上問的都蠻類似。拿紐約市舉例吧——關於博物館什麼時候去、路線怎麼走，好幾串主題都繞著這類事打轉。巴黎、柏林也差不多。
我們那時注意到，一條討論串最有價值資訊常藏在標題和第一則貼文裡頭。標題通常下得簡明扼要；首篇留言多半交代得很詳細，不外乎把疑問講清楚，有時連背景都帶進去了。這樣的小發現，其實就給接下來的工作帶來啟發——至少知道從哪開始下手比較妥當。但當然，接下來還是可能碰上一堆其他小狀況需要慢慢摸索解決…
AI聚類誰說必須照規則走，自幹演算法奇遇
在整理內容的過程裡，碰到一個蠻有趣但也挺棘手的狀況，就是怎麼把那些看起來差不多的問題分成一群一群。說真的，找出哪些問題最常被問，有時候比想像中還花時間。我們用了一種叫 bge-base-en-v1.5 的嵌入模型，把論壇標題跟第一篇文章大致算成某種向量。這些資料轉完以後，再試著靠聚類方法湊成幾堆。
其實每個城市論壇規模落差很明顯，像巴黎那邊的討論串多到快數不清，如果硬要用傳統演算法去切，大概會產生好幾千群（可能還更多），而威斯康辛州麥迪遜這類地方，討論區相對小很多，能分出的主題就沒那麼多，也許十多組或再多一點。這樣一來，我們需要的是能夠隨著資料大小變動、彈性伸縮的聚類方式。
當初我們先拿幾個城市做測試，用不同演算法跑看看結果。K-means 這玩意兒要求事先設定好分幾群才行，但是對於資料量變動很大的情境，好像不太適合。有嘗試過 HDBScan，那時發現它在我們手上的資料集下，很難湊出足夠細緻、有意義的小群組。這兩條路都卡住後，只好自己設計了一套比較客製化的方法，讓它可以根據不同論壇自動調整。
舉例來說，其中有三個群組，一個圍繞紐約市新手旅遊建議，有另一個關心 JFK 機場到市中心交通，再來就是冬季和聖誕節活動主題。基本流程其實也沒什麼複雜，就是先算所有帖子間的相似度，把分數高低排排站，用一種有點貪婪的方式把最像的一批貼文拉在一起。
說穿了，這方法只是希望能抓住那些大家老是在問、容易搞混或合併的問題。不過嘛，不同地區論壇活躍程度天差地遠，所以每次跑完聚類結果，都要稍微檢查一下，看是不是哪邊怪怪的。有時候感覺上演算法處理得還行，但偶爾也會漏掉一些冷門但重要的小話題——大體來講，目前只能說「部分情境下」這方法還算受用吧。
其實每個城市論壇規模落差很明顯，像巴黎那邊的討論串多到快數不清，如果硬要用傳統演算法去切，大概會產生好幾千群（可能還更多），而威斯康辛州麥迪遜這類地方，討論區相對小很多，能分出的主題就沒那麼多，也許十多組或再多一點。這樣一來，我們需要的是能夠隨著資料大小變動、彈性伸縮的聚類方式。
當初我們先拿幾個城市做測試，用不同演算法跑看看結果。K-means 這玩意兒要求事先設定好分幾群才行，但是對於資料量變動很大的情境，好像不太適合。有嘗試過 HDBScan，那時發現它在我們手上的資料集下，很難湊出足夠細緻、有意義的小群組。這兩條路都卡住後，只好自己設計了一套比較客製化的方法，讓它可以根據不同論壇自動調整。
舉例來說，其中有三個群組，一個圍繞紐約市新手旅遊建議，有另一個關心 JFK 機場到市中心交通，再來就是冬季和聖誕節活動主題。基本流程其實也沒什麼複雜，就是先算所有帖子間的相似度，把分數高低排排站，用一種有點貪婪的方式把最像的一批貼文拉在一起。
說穿了，這方法只是希望能抓住那些大家老是在問、容易搞混或合併的問題。不過嘛，不同地區論壇活躍程度天差地遠，所以每次跑完聚類結果，都要稍微檢查一下，看是不是哪邊怪怪的。有時候感覺上演算法處理得還行，但偶爾也會漏掉一些冷門但重要的小話題——大體來講，目前只能說「部分情境下」這方法還算受用吧。
題目寫法卡關：抽象還是細膩？五大守則才有救
假設有兩個討論串——A跟B，彼此之間的內容其實差不多，照理來說應該算是同一組。然後如果再冒出一個C，它不太像前面那兩個，那通常就自己單飛成一團，有點像先卡位，看以後會不會有新朋友靠過來一起湊成類似的小圈圈。每當碰到新的一堆問題，它這邊都會臨時決定到底要讓新話題融入現有的群體，還是乾脆另闢新天地。
那個演算法的偽代碼嘛，大致長這樣：
說真的，一開始要自己寫這種比較貪婪式的分群法也有點冒險，不過很快發現其實滿適合我們需求，而且擴展起來好像也沒遇到什麼大瓶頸。
等大家常問的問題粗略歸在不同主題以後，接下來還得幫每組挑一句最能代表大家意思、而且讀起來順口又清楚的新問題。這步驟我們會丟給GPT-4 Turbo去生成一條合適的標準句子，再請它順便配個更寬泛的大分類，好讓未來搬去不同地區時通用性高一些。舉例說，如果哪群都跟博物館差不多意思，我們就把它們往「文化或休閒體驗」那種大傘底下收編。一邊檢查AI生出來的問題和分類，我們慢慢摸索出幾條判斷標準——到底什麼叫做「夠好」的新問題？講太籠統就變得沒啥參考價值，但細節又不能多到只剩小眾才看得懂；怎麼拿捏中間點，其實光靠生成模型還蠻難解決。有些地方最後還是靠人工一步步微調，把語意導回最合適的位置。
繞了一圈，我們手上就累積了大約五項重點原則，用來判別哪些問題能進下一輪…
那個演算法的偽代碼嘛，大致長這樣：
def embedding_clustering(
unclustered_embeddings,
sim_threshold,
min_samples,
):
sim = cosine_similarity(unclustered_embeddings, unclustered_embeddings)
descending_indices = np.argsort(-sim, axis=1)
n_above_threshold = np.sum(sim >= sim_threshold, axis=1)
ordered_indices = np.argsort(-n_above_threshold)
clusters = []
for i in ordered_indices:
if not_clustered(i):
indices_ranked = [j for j in descending_indices[i] if sim[i, j] >= sim_threshold and not_clustered(j)]
if len(indices_ranked) >= min_samples:
mark_clustered(indices_ranked)
clusters.append(indices_ranked)
return clusters說真的，一開始要自己寫這種比較貪婪式的分群法也有點冒險，不過很快發現其實滿適合我們需求，而且擴展起來好像也沒遇到什麼大瓶頸。
等大家常問的問題粗略歸在不同主題以後，接下來還得幫每組挑一句最能代表大家意思、而且讀起來順口又清楚的新問題。這步驟我們會丟給GPT-4 Turbo去生成一條合適的標準句子，再請它順便配個更寬泛的大分類，好讓未來搬去不同地區時通用性高一些。舉例說，如果哪群都跟博物館差不多意思，我們就把它們往「文化或休閒體驗」那種大傘底下收編。一邊檢查AI生出來的問題和分類，我們慢慢摸索出幾條判斷標準——到底什麼叫做「夠好」的新問題？講太籠統就變得沒啥參考價值，但細節又不能多到只剩小眾才看得懂；怎麼拿捏中間點，其實光靠生成模型還蠻難解決。有些地方最後還是靠人工一步步微調，把語意導回最合適的位置。
繞了一圈，我們手上就累積了大約五項重點原則，用來判別哪些問題能進下一輪…
論壇回覆找答案，語意切片跟傳統拆句你選哪個？
有些問題看起來總是需要拿捏一個分寸——既不能太模糊，也別鉅細靡遺。像是在設計問題時，通常會希望它們多少能貼合某地的特質，但也不至於落入過度細節裡。然後嘛，時間性也是個考量點。例如那種「某位歌手七月要去哪場演唱會」這樣的提問，好像就容易失去長遠價值，畢竟瞬息萬變。
其實，把焦點集中在單一主題上，多數時候效果還不錯。類似「倫敦有哪些住宿和美食推薦？」這類雙重題目，如果拆成兩道來問，反倒清楚許多。有些人可能會覺得問題都差不多，但事實上，每一道題目的內容最好還是各自獨立，比較不容易混淆視聽。至於字數嘛，大致維持在五、六到十幾個字左右，好像最容易讓人明白想問什麼。
在整理分類時，一開始我們其實分了不少層級，後來慢慢調整合併，最後留下三十多個比較大的主分類。這樣看下來，也許每一類都能套用到不同國家城市，不見得只適用某一區域。從草案到成品，中間大概經歷了三輪左右的修正流程吧，有些步驟現在回想起來也不是絕對不可變動，只是目前看起來還算管用。
其實，把焦點集中在單一主題上，多數時候效果還不錯。類似「倫敦有哪些住宿和美食推薦？」這類雙重題目，如果拆成兩道來問，反倒清楚許多。有些人可能會覺得問題都差不多，但事實上，每一道題目的內容最好還是各自獨立，比較不容易混淆視聽。至於字數嘛，大致維持在五、六到十幾個字左右，好像最容易讓人明白想問什麼。
在整理分類時，一開始我們其實分了不少層級，後來慢慢調整合併，最後留下三十多個比較大的主分類。這樣看下來，也許每一類都能套用到不同國家城市，不見得只適用某一區域。從草案到成品，中間大概經歷了三輪左右的修正流程吧，有些步驟現在回想起來也不是絕對不可變動，只是目前看起來還算管用。
原帖語氣能保留嗎？GPT同時摘要又取證挑戰多多
有時候，論壇的討論串裡主題挺雜亂，當初他們是怎麼挑出重點問題的，好像是先用模型把每一堆話題抓個大概，再憑這個寫出一些初步問題。只是這步驟也不是一蹴可幾，每次還得透過另一種模型再修修補補，把那些題目弄得比較一致，也比較穩定。有些內容明顯很像嘛，他們就用嵌入比對的方法，差不多的直接刪掉。
等到問題整理得差不多後，其實最費工夫的是找答案。他們好像把所有論壇留言都丟進向量資料庫裡，用Qdrant存著——這樣要找相關內容就省事不少。其實這些嵌入，不只拿來產FAQ，據說在Tripadvisor那邊，也成為了AI助理、或是其他類似智能流程的小工具底層技術之一。
說到提升檢索品質，其實分兩塊：第一個重點是選嵌入模型。他們測試過將近兩種主流模型，一個叫all-mpnet-base-v2，一個則是bge-base-en-v1.5。最後好像做了內部問卷調查，請同事針對生成答案給點意見。印象中，大致上覺得bge-base-en-v1.5表現稍微優一點，所以後來就以這款為主。
另外還有資料切割方式，他們好像嘗試過語意斷句，也有傳統直接以貼文分段法。不過細節怎麼選的，好像沒特別提。有些小地方記不太清楚，但總體流程大約如此。
等到問題整理得差不多後，其實最費工夫的是找答案。他們好像把所有論壇留言都丟進向量資料庫裡，用Qdrant存著——這樣要找相關內容就省事不少。其實這些嵌入，不只拿來產FAQ，據說在Tripadvisor那邊，也成為了AI助理、或是其他類似智能流程的小工具底層技術之一。
說到提升檢索品質，其實分兩塊：第一個重點是選嵌入模型。他們測試過將近兩種主流模型，一個叫all-mpnet-base-v2，一個則是bge-base-en-v1.5。最後好像做了內部問卷調查，請同事針對生成答案給點意見。印象中，大致上覺得bge-base-en-v1.5表現稍微優一點，所以後來就以這款為主。
另外還有資料切割方式，他們好像嘗試過語意斷句，也有傳統直接以貼文分段法。不過細節怎麼選的，好像沒特別提。有些小地方記不太清楚，但總體流程大約如此。
真實例句對比：相似度計算背後的小聰明
其實一開始，討論的時候大家本來想要把每個貼文整篇分開處理，不過後來還是覺得，直接切成一句一句比較有意思。這種做法，好像讓同類型、相關聯的句子可以湊在一起，結果整體下來，產生出來的向量資料量比原本少了大約一半，也就差不多省了一半左右成本吧。然後在Qdrant找資料時，感覺也順暢不少。
下面有個圖解，大概就是講這樣分段的方法啦。說真的，論壇上的討論總是七零八落，而且前後文蠻重要。有些旅人會突然回應上一則留言，有的又好像是在補充或反駁別人的看法。如果只抓一小段出來給AI，其實容易誤會，那個人在講什麼。所以每次我們抓到符合問題的段落，也都會再帶上附近幾則貼文當參考，希望這樣上下文能更完整點，不然回答常常會怪怪的。
等到都整理完這些內容，其實處理問題時，就是拿之前用過的那些問題，一條一條去Qdrant找適合的貼文。然後把搜到的一堆答案通通丟給GPT去做彙整。不過重點還是在於「摘要」，不是照抄，所以最後生成出來的東西，都會明確地告訴旅人：嘿，這些資訊都是大家論壇上討論來的喔。
我們覺得，把原本旅人的語氣保留下來其實挺重要——只要模型能做到，就盡量維持那種分享經驗、聊天式的小細節和語感。
至於正確性跟透明度嘛... 怎麼講，比方說，我們希望AI彙整內容時不要亂編，而是盡可能讓它標示出哪些句子是真正在原文裡面找到、有根據的。這樣讀者也比較知道推薦從哪裡來。一開始測試時，是讓GPT一次產生摘要，同時列舉它到底用到了哪些支持片段，但目前具體效果好像還在摸索中吧。
下面有個圖解，大概就是講這樣分段的方法啦。說真的，論壇上的討論總是七零八落，而且前後文蠻重要。有些旅人會突然回應上一則留言，有的又好像是在補充或反駁別人的看法。如果只抓一小段出來給AI，其實容易誤會，那個人在講什麼。所以每次我們抓到符合問題的段落，也都會再帶上附近幾則貼文當參考，希望這樣上下文能更完整點，不然回答常常會怪怪的。
等到都整理完這些內容，其實處理問題時，就是拿之前用過的那些問題，一條一條去Qdrant找適合的貼文。然後把搜到的一堆答案通通丟給GPT去做彙整。不過重點還是在於「摘要」，不是照抄，所以最後生成出來的東西，都會明確地告訴旅人：嘿，這些資訊都是大家論壇上討論來的喔。
我們覺得，把原本旅人的語氣保留下來其實挺重要——只要模型能做到，就盡量維持那種分享經驗、聊天式的小細節和語感。
至於正確性跟透明度嘛... 怎麼講，比方說，我們希望AI彙整內容時不要亂編，而是盡可能讓它標示出哪些句子是真正在原文裡面找到、有根據的。這樣讀者也比較知道推薦從哪裡來。一開始測試時，是讓GPT一次產生摘要，同時列舉它到底用到了哪些支持片段，但目前具體效果好像還在摸索中吧。
從小測試到SEO飆升，70%旅客買單但限制還在
最初嘗試讓模型一次處理多件事，好像還蠻有想法，不過很快就冒出不少狀況。舉個例子，當它同時被要求產生摘要又要列出支撐句時，生成的答案品質一下就掉下來了；感覺兩頭都顧不好。另外，GPT挑出來的那些所謂重點句，有時候跟實際需要的內容落差不小，地區換了、問題不同，選句子的準確度也忽高忽低，有點看運氣。
後來摸索一陣子，才慢慢搞出一套比較穩定、省力的方法。基本上是這樣：先從論壇裡找一些看起來最貼近問題脈絡的討論片段（用Qdrant之類工具）。然後再請GPT根據這些資料去回答問題。接著把答案和原始貼文拆成一句一句單位，比較每對句子的語意相似程度——大致就是算那種餘弦相似分數啦。不會精確到什麼百分比，大約抓個前幾名分數高的論壇句子，把它們連同AI回覆一起存起來。
你可能會發現，有些字詞或關鍵片段在答案和原文裡都會重複出現，但也有幾次好像不是每個案例都能精準對應。不過整體感覺這流程在不同國家或語境下表現算平穩吧，也沒有遇到太明顯的大滑坡。現在旅客看到的不僅是AI整理過的答覆，同時還能參考那些原汁原味、比較真實的網友留言。
說到底，其實這做法多少讓人想起之前秋天弄評價摘要那次——雖然兩者細節不盡相同，但都是一路跌跌撞撞調整到目前這樣。有些地方解決得比較順利，有些還留點遺憾。
後來摸索一陣子，才慢慢搞出一套比較穩定、省力的方法。基本上是這樣：先從論壇裡找一些看起來最貼近問題脈絡的討論片段（用Qdrant之類工具）。然後再請GPT根據這些資料去回答問題。接著把答案和原始貼文拆成一句一句單位，比較每對句子的語意相似程度——大致就是算那種餘弦相似分數啦。不會精確到什麼百分比，大約抓個前幾名分數高的論壇句子，把它們連同AI回覆一起存起來。
你可能會發現，有些字詞或關鍵片段在答案和原文裡都會重複出現，但也有幾次好像不是每個案例都能精準對應。不過整體感覺這流程在不同國家或語境下表現算平穩吧，也沒有遇到太明顯的大滑坡。現在旅客看到的不僅是AI整理過的答覆，同時還能參考那些原汁原味、比較真實的網友留言。
說到底，其實這做法多少讓人想起之前秋天弄評價摘要那次——雖然兩者細節不盡相同，但都是一路跌跌撞撞調整到目前這樣。有些地方解決得比較順利，有些還留點遺憾。
全站向外擴散、合作與未來展望沒個底
一開始，從那麼大一堆論壇討論裡頭要把合適的內容找出來，坦白說真的挺費工夫。試過主流的開源分群法後，團隊最後還是冒了點風險，決定自己寫一套聚類工具。這中間有利用自動化的反饋調整手段，好像讓AI整理出來的重點能更清晰地分門別類，問題也變得比較貼近日常、而且放到哪個國家都通用。
頁面上那些熱門的聊天式問答資訊，其實就是這麼浮現出來的。不過，也不是所有細節都那麼乾脆，比如我們選擇GPT-4 Turbo，大致是因為測下來它在聽指令這件事比較拿手，但未來如果有模型又便宜又強，也可能會再考慮換新。
其實系統上線後，在旅遊建議專區跑的一些測試，有發現網站曝光率和旅客互動都有提升。大概七成多給意見的人覺得這部分蠻有幫助，所以看起來應該還算值得信賴。但目前能展示給大家看的問題還只是其中一小塊，我們內部正在想辦法讓它們能跟論壇本身整合得更深入一些。
這套方法可以擴展到很多地方，而且應該已經慢慢滲透到別的功能裡了。像現在Tripadvisor AI旅遊助手，就是靠論壇內容做向量化檢索，因此針對旅客詢問時，答案通常會有一定關聯性跟上下文判斷。
往前看，我們也規劃把這類內容提供給合作夥伴，希望不管是在傳統搜尋，還是在新型態對話體驗裡，只要有需要都找得到Tripadvisor相關見解。最近其實才剛跟Perplexity合作了一波，把旅客分享結合進他們家的聊天式搜尋，用起來感覺更貼近需求——不過未必每種情境都適合啦，就是早期嘗試而已。
然後呢，要把東西做出來，其實各種角色少不了。雖然這次文章講的是機器學習那邊，但產品設計、SEO、人因研究、分析、QA、MLOps、網頁工程等等，全都一起參與才搞得起來。有些決策或許要特別感謝Nadeem Almoayyed，他帶領方向滿明確。不然光靠資料科學應該很難讓最初那些雜亂無章的小細節最後變成旅客看起來舒服順手的一個經驗吧。
頁面上那些熱門的聊天式問答資訊，其實就是這麼浮現出來的。不過，也不是所有細節都那麼乾脆，比如我們選擇GPT-4 Turbo，大致是因為測下來它在聽指令這件事比較拿手，但未來如果有模型又便宜又強，也可能會再考慮換新。
其實系統上線後，在旅遊建議專區跑的一些測試，有發現網站曝光率和旅客互動都有提升。大概七成多給意見的人覺得這部分蠻有幫助，所以看起來應該還算值得信賴。但目前能展示給大家看的問題還只是其中一小塊，我們內部正在想辦法讓它們能跟論壇本身整合得更深入一些。
這套方法可以擴展到很多地方，而且應該已經慢慢滲透到別的功能裡了。像現在Tripadvisor AI旅遊助手，就是靠論壇內容做向量化檢索，因此針對旅客詢問時，答案通常會有一定關聯性跟上下文判斷。
往前看，我們也規劃把這類內容提供給合作夥伴，希望不管是在傳統搜尋，還是在新型態對話體驗裡，只要有需要都找得到Tripadvisor相關見解。最近其實才剛跟Perplexity合作了一波，把旅客分享結合進他們家的聊天式搜尋，用起來感覺更貼近需求——不過未必每種情境都適合啦，就是早期嘗試而已。
然後呢，要把東西做出來，其實各種角色少不了。雖然這次文章講的是機器學習那邊，但產品設計、SEO、人因研究、分析、QA、MLOps、網頁工程等等，全都一起參與才搞得起來。有些決策或許要特別感謝Nadeem Almoayyed，他帶領方向滿明確。不然光靠資料科學應該很難讓最初那些雜亂無章的小細節最後變成旅客看起來舒服順手的一個經驗吧。
