上一篇，我們談到實驗課排程時，先把注意力放在一件很重要的事情上：

先找到一個符合所有條件的可行解

例如實驗課表必須滿足：

• 同一間實驗室不能重複借用
• 實驗室安全容量必須足夠
• 共同修課的學生不能撞堂
• 教師、助教與實驗室的時段都必須允許

只要其中一條限制條件被違反，這份實驗課表就不能使用。

但很多現實問題不只是在問：

有沒有可行答案？

而是：

這麼多可行答案裡，哪一個比較好？

問題到了這裡，你發現 慣老闆的思維漏洞 又跑出來了：

「最好」到底是什麼？

推薦系統就是一個很典型的例子。

推薦系統，不就是猜你喜歡什麼嗎？

打開 Netflix，首頁會出現一排一排電影與影集。
打開 YouTube，首頁會推薦你可能想看的影片。
進入購物網站，也可能看到你可能也喜歡的推薦專區。

直覺上，推薦系統好像只需要解一個問題：

找出使用者最可能喜歡的東西

假設系統替每部影片計算一個分數：

Video A → 0.95
Video B → 0.91
Video C → 0.87
Video D → 0.72

那是不是只要按照分數排序 A > B > C > D 就完成了？

如果我們唯一的目標真的是：

預測你最可能喜歡什麼？

那這樣也許合理。

但現實中的推薦系統通常沒這麼簡單，因為平台真正想最佳化的，往往不只一件事情。

如果推薦結果全部長得一樣呢？

假設你最近看了一部料理影片。
系統發現你非常喜歡義大利麵相關內容，於是首頁變成：

• 奶油培根義大利麵
• 番茄海鮮義大利麵
• 青醬雞肉義大利麵
• 白酒蛤蜊義大利麵
• 松露奶油義大利麵
• 懶人義大利麵
• 十分鐘義大利麵

這些影片可能全部都有很高的相關性。

也就是：

它們都很符合你目前的興趣

可是推薦結果如果全部非常相似，使用體驗未必最好。

也許我們還希望首頁同時出現：

• 義大利麵
• 甜點
• 咖啡
• 旅行
• 廚房工具

這時候，系統開始多了一個新的目標：

多樣性

也就是推薦內容不要全部集中在同一種類型。

Relevance：這個東西跟你有多相關？

推薦系統最容易理解的最佳化目標是相關性 Relevance，就是說：

這個內容有多符合目前這位使用者的興趣？

例如你最近：

看了很多 JavaScript
搜尋 React
收藏 TypeScript 影片

那麼推薦 React Server Components 可能就比推薦 判斷大盤低點買入飆股 更相關。

如果我們只考慮相關性，問題可以簡化成：

找出相關性分數最高的內容

甚至直接按照相關性排序。
但實際系統通常還需要考慮更多東西。

Diversity：推薦結果不能全部都一樣

假設平台要推薦五部電影。
根據相關性，最高的五部全部都是科幻電影。
從單部電影來看，它們可能都很適合你。
但把五個推薦一起看時，就可能顯得非常單調。

因此推薦系統可能會考慮：

多樣性 Diversity

希望結果包含：

• 科幻
• 懸疑
• 動畫
• 喜劇
• 紀錄片

就是平台讓你保留一點多元化選擇的考量。

假設：

科幻電影 A
相關性 = 0.95

紀錄片 B
相關性 = 0.82

如果只看相關性：

A > B

當然應該選 A。

但如果目前推薦列表裡已經有四部科幻電影，那加入 B 可能讓整體結果更好。

因此：

單一項目的最高分，不一定會形成最好的整體組合

Novelty：你喜歡，不代表還要一直推薦你已經知道的東西

推薦系統還可能考慮新穎性 Novelty，意思是：

這個推薦對使用者來說有多新鮮？

假設你非常喜歡某個歌手。
推薦系統一直推這位歌手最熱門的歌曲，相關性可能非常高。

可是問題是：

你可能早就聽過了

另一首你從沒聽過、但風格相近的小眾歌曲，相關性也許稍微低一些，卻可能帶來更好的探索體驗。
因此推薦系統可能故意保留一些位置：

不是最確定你會喜歡
但值得讓你試試看的內容

這也是推薦系統裡很重要的一種 trade-off：

已知興趣 vs. 探索新內容

Engagement：平台還在意你會不會繼續使用

推薦平台通常也不只是想知道：

你喜不喜歡這一部影片？

它可能更在意：

• 你會不會點進去？
• 你會看多久？
• 你看完會不會繼續看下一部？
• 你明天還會不會回來？

這些都可以被視為不同形式的：

使用者投入程度 Engagement

例如兩部影片：

A：
你很喜歡
看完 5 分鐘就離開平台

B：
你也滿喜歡
看完後繼續看了三部相關影片

如果平台的最佳化目標是：延長單次使用時間。

那 B 可能比 A 更有價值。

但如果最佳化目標改成：提高使用者滿意度。

結果又可能不同。

這也是推薦系統困難的地方：

「使用者喜歡」和「使用者停留更久」並不一定完全相同

購物推薦還要考慮營收（Revenue）

如果場景換成電商，問題還可能再多一層。

假設兩個商品：

商品 A
使用者購買機率：20%
平台利潤：10 元

商品 B
使用者購買機率：15%
平台利潤：100 元

如果只看 購買機率 會推薦 A。
但如果看 預期營收，我們可以粗略算：

A：
0.20 × 10 = 2

B：
0.15 × 100 = 15

那麼從營收的角度，B 反而更有吸引力。
這時推薦系統就不再只是：

猜你最喜歡什麼

它還可能同時考慮：

• 相關性
• 多樣性
• 新穎性
• 使用者投入程度
• 營收

而且這些目標彼此不一定一致。

問題真正困難的地方，是這些目標會互相打架

例如我們可能希望提高相關性。
但提高多樣性時，有時必須放棄一些相關性。

我們可能希望：提高新穎性。
但越新的內容，系統通常越不確定使用者會不會喜歡。

我們可能希望：提高使用者投入程度。
可是最容易讓人一直點擊的內容，不一定最符合使用者長期利益。

我們也可能希望：提高營收。
但如果推薦大量高利潤、卻不相關的商品，使用者可能很快失去信任。

所以這些最佳化目標之間常常存在：

取捨 trade-off

例如：

相關性 ↑
多樣性 ↓

或：

新穎性 ↑
預測信心 ↓

甚至：

短期投入程度 ↑
長期滿意度 ↓

這表示推薦系統真正要回答的問題，不只是：

哪個 item 分數最高？

還要考量：

我們願意用多少 A，換多少 B？

所以我們需要目標函數

前面幾篇其實已經出現過最佳化目標。

• Day 19 找零時，我們的目標是：最少數量的零錢。
• Day 21 Knapsack 裡，我們想：最大化總價值。
• Day 23 Scheduling 可能想：最大化完成任務。

到了推薦系統，我們仍然需要一個方法描述：

到底什麼叫做比較好的結果？

這就是：

目標函數 Objective Function

假設先用非常簡化的形式表示：score = 相關性。
那麼演算法只需要讓相關性越高越好。

但如果我們同時考慮多個目標，也許會變成：

score =
  相關性
  + 多樣性
  + 新穎性
  + 使用者投入程度

當然，現實不會這麼簡單。
因為這些數值的尺度可能完全不同。

因此更常見的概念會像：

score =
  0.5 × 相關性
  + 0.2 × 多樣性
  + 0.1 × 新穎性
  + 0.2 × 使用者投入程度

這些係數代表：

我們認為每一個目標有多重要

這時演算法做的事情，其實只是在我們定義好的最佳化目標下，尋找分數更高的答案。

演算法沒有自己決定什麼叫「好」

這是一個很容易被忽略的地方。

我們常常會說：

演算法推薦了這個影片

聽起來好像演算法自己做出了價值判斷。

但更精確地說：

演算法只是按照我們提供的最佳化目標，尋找比較符合這個目標的結果

如果最佳化目標是：

maximize click-through rate

系統可能變得很擅長讓人點擊。

如果最佳化目標是：

maximize watch time

系統可能變得很擅長讓人一直看下去。

如果最佳化目標改成：

maximize long-term satisfaction

推薦策略又可能完全不同。

演算法沒有突然變聰明或變笨。

真正改變的是：

我們怎麼定義問題

多目標最佳化

當一個問題同時存在多個最佳化目標時，我們可以把它理解成：

多目標最佳化 Multi-objective Optimization

也就是：

最大化相關性
最大化多樣性
最大化新穎性
最大化使用者投入程度
最大化營收

問題在於：

這些目標很可能無法同時全部最大化

例如推薦五部電影。

方案 A：

相關性：非常高
多樣性：很低

方案 B：

相關性：稍低
多樣性：很高

方案 C：

相關性：中等
多樣性：中等
新穎性：很高

我們不能單純說：

A 一定最好

也不能說：

C 一定最好

因為答案取決於：

我們更在意哪一個最佳化目標

「最佳解」其實依賴於你站在哪個角度

想像一個購物推薦。
對使用者來說 相關、便宜、品質好，可能比較重要。
對商家來說 庫存、毛利、新品曝光，可能也很重要。
對平台來說 轉換率、留存率、廣告收入，又可能是另一組最佳化目標。

因此同一組商品，在不同目標函數下，最佳排序可能完全不同。

例如：

目標 A：
最大化使用者購買機率

A → B → C

但換成：

目標 B：
最大化預期營收

C → A → B

又或者：

目標 C：
提高新品曝光，同時維持基本相關性

B → C → A

資料沒有改、商品沒有改、使用者也沒有改。

改變的只是：

「什麼叫好」的定義

這件事其實不只發生在推薦系統

回頭看前面的問題就會發現，幾乎每個最佳化問題都有同樣的情況。

導航可以問：

• 最短距離
• 最快時間
• 最低過路費

排班可以問：

• 最少需要多少員工
• 讓每個人的工作量更平均

外送系統可以問：

• 最快送達
• 降低整體等待時間
• 外送員工作量
• 配送距離
• 平台成本

因此，真正開始最佳化之前，第一個問題往往不是：

要用什麼演算法？

而是：

我們到底想最佳化什麼？

限制條件和最佳化目標不是同一件事

這裡也可以回頭和上一篇做一個重要區分。

限制條件是：

不能違反的條件

例如：

• 未滿 18 歲不能推薦特定內容
• 缺貨商品不能購買
• 某地區無法配送

只要違反其中一項，這個答案就是不可行解。

最佳化目標則是：

在合法答案之間，我們希望越多越好的東西

例如：

• 相關性越高越好
• 多樣性越高越好
• 營收越高越好

所以整個問題可以整理成：

先滿足限制條件，再依最佳化目標比較答案

也就是：

可行解
        ↓
最佳化
        ↓
較佳解

上一篇我們關心的是第一步，今天則開始處理第二步。

「最好」不是天然存在的

這也是最佳化問題很重要的一個觀念。

現實世界通常不會自己附帶一個：

best = ...

是我們必須先決定：

• 我要最小化什麼？
• 我要最大化什麼？
• 哪些東西不能違反？
• 不同目標之間要怎麼取捨？

定義完成之後，演算法才有可能開始尋找答案。

所以：

「最好」不是演算法決定的，而是我們如何定義目標

這也是為什麼同一份資料、同一組候選答案，換一個目標函數，就可能得到完全不同的結果。

但定義完目標，事情就結束了嗎？

假設現在我們已經非常清楚地定義：

score =
  0.5 × 相關性
  + 0.2 × 多樣性
  + 0.1 × 新穎性
  + 0.2 × 使用者投入程度

而且所有限制條件也都確認好了。

看起來問題終於完整了：

找出 score 最高的推薦組合

但接下來還有一個新的麻煩。
假設只有 10 個候選影片，要選 3 個。
我們也許還能把很多組合試過一次。
可是如果候選內容變成：

100 個
1,000 個
1,000,000 個

而且我們不是選一個，而是要決定：

• 選哪些
• 怎麼排序
• 如何搭配

可能答案的數量就會快速增加。
這時問題考量開始變成：

就算目標已經定義清楚，當可能組合隨資料量快速增加時，我們真的有足夠時間把每個答案都算過一次嗎？