區塊勢

新鮮勢要同時處理分數與事件鏈

分數回答「現在該排多前面」;Parent / Child 回答「這是不是同一故事的下一階段」。兩者同等重要,但不能互相取代。

SCROLL
PART 1 | 兩條軸

這不是一個問題,而是兩個坐標軸

如果只談分數,新鮮勢會知道哪件事現在該浮上來,卻不知道讀者為什麼要把它跟過去的新聞放在一起看。如果只談 Parent / Child,首頁會有脈絡,卻可能把舊事件長期留在前排。

所以兩套機制要分工。分數是排序軸,負責「當下位置」;事件鏈是脈絡軸,負責「故事邊界」。分數可以使用事件鏈當作一個訊號,但不能讓 parent_id 直接變成加分捷徑。

兩套機制各自回答的問題

分數機制這件事現在該不該被放上首頁前排
事件鏈機制這件事是不是同一個 object、case、proposal、exploit 或 investigation 的下一階段
可以互動fresh child 可以小幅提醒 parent,但必須有時間衰減、上限和最低曝光量
不能混用來源數不決定 parent_id;parent_id 也不代表永久高分

這個分工會讓首頁同時有「現在感」和「脈絡感」,而不是讓其中一邊覆蓋另一邊。

PART 2 | 分數方法論

分數該從手寫 prior,接到去偏誤隱式回饋

目前新鮮勢先用來源數和討論數估計事件的重要度。來源 1 到 8 個加分最高,後面逐段變低;討論數也有上限。這比線性加總好,因為第 30 篇報導不該和第 3 篇報導有同樣重量。

首頁排序再把重要度套上時間衰減、新鮮度加成、人工 boost 和閱讀疲勞。這套做法已經比單純加總穩,但它仍然是人手寫出來的 prior。下一步應該採用 Counterfactual Learning to Rank from Implicit Feedback:用讀者實際行為調整排序,但先校正首頁位置造成的偏誤。

目前的排序管線

來源與討論用遞減收益計算 importance_score
時間與新鮮度第 2 天起每天扣 1.5 分;最近 4 天有 freshness bonus
閱讀疲勞用 glance、repeat、click、discuss、dwell 做 log1p 衰減
最後排序前端主要依 display_score 排列首頁

這些訊號只能說「我們猜它重要」。它還沒有處理讀者在看到某個位置之後,是否真的用行為證明它值得被放更上面。

下一版 display_score

base score來源、討論、新鮮度、時間衰減、有限度的 fresh child lift
cf reward校正 rank 之後的有效注意力
adjustmentlog1p(cf_reward_7d) 並設定上下限
final scorebase score + attention adjustment

第 1 名本來就比較容易被點。第 12 名如果仍然被點,反而可能代表它被低估。成熟的排序方法不會直接把「點擊多」當作重要,而會先估計每個位置的被看見機率,再把行為訊號做校正。

PART 3 | 分數實作

第一版不用機器學習,先把展示與行為記對

去偏誤排序的第一步不是模型,而是 impression log。每則新聞被展示時,要記下 request_id、session_id、item_id、rank、display_score、shown_at、viewport_ms。後續點開來源、點開討論、停留時間,都要帶回同一個 request_id 和 rank。

第一版資料流

1

展示

記錄每則新聞當時排第幾。

2

行為

記錄點開事件、來源、討論、停留與分享。

3

校正

用 rank propensity 修正位置偏誤。

4

回寫

把 adjustment 加回 display_score。

reward 不等於點擊

低強度曝光後沒有互動,先當 0;快速返回可小幅扣分
中強度點開事件頁、來源、社群討論,代表讀者願意多看一層
高強度停留超過 30 秒、回訪、分享,代表這則新聞真的抓住注意力

接著把 reward 除以該 rank 的 propensity。排在後面仍然被認真點開,才有機會得到更高的 counterfactual reward。

首頁也要留一個小的 exploration slot,例如第 8 名。它不是亂放,而是從「不確定但有潛力」的事件裡抽一則,讓系統知道低分事件是不是被低估。

PART 4 | 事件鏈舊問題

Parent / Child 不能再只靠字面相似

過去的 YouTube 候選流程會把影片標題、候選 tags、來源 topics、逐字稿,跟既有事件的標題、tags、summary、sources 做 weighted token overlap。最接近的事件分數超過 8,就建議當 child。超過 4.5,也會建議可能掛在某個 parent 底下。

這解決了召回問題,卻沒有解決關係問題。它能找出「看起來相關」的事件,但不能回答「是不是同一件事的下一階段」。

舊版判斷的盲點

1

詞彙重疊

同一個公司名、tag 或主題字會推高分數。

2

分數過線

高於門檻就建議放進既有 parent。

3

人工確認

審稿者再判斷主軸是不是獨立事件。

4

容易變桶

同主題事件被塞在一起,看起來像一條故事。

預測市場就是典型例子。HIP-4、內線交易、氣象站操縱、CFTC 管轄權都會碰到「預測市場」,但讀者需要的脈絡不是同一種。

PART 5 | 事件鏈新方法

新版要看同一件事是不是往下一階段走

這次調整採用三個方法論:TDT 把新事件偵測、後續追蹤、相似內容連結拆成不同任務;story chain 研究區分「同一事件鏈」與「相似主題」;event coreference 要看 who、what、where、when 與事件實體。

落到新鮮勢,意思很簡單:文字相似只用來找候選,不直接決定 parent_id。真正判斷 child 時,要看事件框架。

新版事件框架

actor誰做了事
action做了什麼動作
object動作指向哪個法案、產品、漏洞、案件、提案或交易
venue在哪個市場、法院、管轄區或鏈上環境
mechanism事情怎麼發生
phase是不是同一件事的下一階段

child 必須共享同一個 object、case、product、proposal、exploit 或 investigation,且 action 或 phase 能接成一條故事。

四種關係各自有位置

同一事件新增來源併入 sources[],不建立 child
同一故事下一階段使用 parent_id
有背景價值使用 context_links[]
只是主題相似保留 parent_id: null

Parent / Child 不再承擔「背景脈絡」和「主題分類」。它只表示同一件事接著發展。

PART 6 | 兩者怎麼接

分數可以讀事件鏈,但不能被事件鏈取代

舊版 Parent 分數會加總 direct children 各自衰減後的重要度。這會讓長事件靠子事件堆疊撐在前排,也會讓「分數」和「脈絡」混在一起。

新版應該把接口縮窄:每個事件先算自己的 importance_score 和 display_score;如果 parent 有新 child,只給一個有上限、會衰減、只看 direct child 的 fresh_child_lift。它提醒讀者這條故事有新進展,但不把整串歷史重新推上去。

分數與事件鏈的接口

atomic event每個事件先獨立計算來源、討論、時間、閱讀行為
parent_id只表示同一故事下一階段,不表示同主題、同市場或同公司
fresh child lift只吃最新 direct child 的一小段分數,設上限並快速衰減
context_links提供背景脈絡,但不傳遞分數

這樣 Clarity Act 這類舊事件會自然下滑;但如果今天真的有同一法案的新階段,parent 會被提醒,而不是靠兩週前的來源數留在封面。

PART 7 | 三個例子

改動後,讀者看到的關係會更窄,也更準

CoinOne 與 Upbit 母公司股權

OKX 與 Korea Investment 投資 CoinOne,三星旗下公司投資 Upbit 母公司,兩者都指向韓國交易所股權與傳統金融入場。但 actor、object、交易標的不同。新版會把它們當成 context_links 或各自 top-level,不會硬接 Parent / Child。

HIP-4 與預測市場操縱

HIP-4 是 Hyperliquid 的產品與治理線。內線交易、氣象站操縱、預言機資料問題是風險與執法線。它們共享「預測市場」這個主題,但 object、mechanism、phase 都不同。

同一法案提出、通過、簽署

同一法案從提出、排審、表決到簽署,是同一個 object 的階段推進。這才是 Parent / Child 該承接的故事線。

分數決定現在的位置;parent_id 決定故事的邊界。

來源與討論是排序 prior;事件框架是脈絡 contract。兩邊要相互參考,但不能互相冒充。

如果要開始實作
第一步該先補哪個缺口?

選完之後,分享你的判斷

你的判斷

想看更深入的分析?

這份頁面把分數方法論和 Parent / Child 的事件鏈方法論放回同一張圖。下一步可以拆成實作規格:impression log、counterfactual reward、event frame、context_links 和 fresh_child_lift。

閱讀完整文章 →