Candidate 產生邏輯 × Post Snapshot 欄位對照

01目前 Candidate 準備邏輯

所有 candidate 共用一條「生成 → 過濾 → 輸出」的流水線。每個 candidate 以獨立 goroutine 平行跑 Generate()，產生 []*dao.Post，再套共用 filter chain，最後只取 post_id 寫回 response。

service/rpc/get_candidate.go:22 · candidate/main.go:38 · filter/main.go:79

Post Snapshot 是什麼

一份由 postlist.Generator 維護的 in-memory cache（postlist/main.go:24），內容來自 dao.PostDAO.List()，預設實作是 GCSPostDAO——從 GCS 把 JSON 一次讀入記憶體，按 region / forum allow-list 切片，並以 ticker 週期性刷新。絕大多數 candidate（JobTitle、OPHawkeyeV2、Search、Forum 系列…）都呼叫 PostListGenerator.Get(ctx, region) 拿到 []*dao.Post 後做 id 交集。

02Post Snapshot 的欄位結構

dao.Post（dao/post.go:19）與嵌入的 *PostFeature（dao/post_feature.go:12）合計約 20 個欄位。並非全部都被 filter 用到——有些是 ranking 用、有些是完全沒被讀取的殘留欄位。

type Post struct {
    ID                    int64      // 必要：全域識別
    AuthorID              string     // 作者封鎖
    LikeCount             int64      // 品質門檻 + 排序
    ForumAlias            string     // 版規、訂閱、feedback、自殺版
    IsSchool              bool       // 學校版處理
    LayoutType            string     // Layout() 判斷
    CrossPostID, ReplyID  int64      // Layout() 判斷
    Title, Content        string     // 關鍵字封鎖
    Topics                []string   // feedback
    ImageMeta             []struct{} // 品質門檻
    Persona               string     // persona 封鎖
    Gender                string     // 官方文判斷
    CreatedByBrandMember  bool       // 官方文判斷
    CreatedAt             time.Time  // 新鮮度 / 封鎖時間比較
    EnableListLinkPreview bool       // Layout() 判斷
    LinkCount             int        // Layout() 判斷
    PollOptionTitles      []string   // 投票文關鍵字封鎖
    *PostFeature                     // 嵌入
    HawkeyeTaskID         string     // 透傳到 response
    BoostStrength         string     // 透傳到 response
}

type PostFeature struct {
    ID                            int64   // 同 Post.ID
    MemberID                      int64   // 官方文封鎖名單比對
    AverageDuration, MaleETR,
    FemaleETR, ShareRate, LikeRate float64 // 目前僅供 metric/log
    Tags                          []string
    CategoryL1s                   map[int64]string
}

03欄位 → Filter 對照表

以下逐一列出 snapshot 欄位實際被哪些 filter / generator 讀取，以及讀取方式。這張表是判斷「新通道要不要 hydrate 某欄位」的根據。

04反過來：每個 Filter 需要什麼欄位

新通道若想在 experiment_settings.filters 開啟某條 rule，就必須確保 hydrate 了以下欄位；否則零值會導致誤判（例如 AuthorID=="" 會讓 BlockedAuthor 在封鎖清單有空字串的極端情況誤判，或 LikeCount==0 讓 Quality 幾乎全刪）。

05新增 Candidate 通道的影響

情境：召回池是全站 3 天以上舊文，量約 50 萬+（是現行 snapshot ~10K 的 50 倍以上）。問題不在「snapshot 欄位多寡」而在「一次載入 50 萬筆會讓 pod 記憶體與刷新週期崩盤」。底下先看架構影響，再於下一節分析能共用哪些既有資料源。

新通道在 pipeline 中的位置

既有設計邏輯會受影響嗎？

• 介面層：不會。PostGenerator.Generate 回傳 []*dao.Post，沒規定資料來源。同模組已有類似 pattern——JobTitleCandidate、OPHawkeyeV2 都先從自己的 DAO 拿 post_id，再去 hydrate。新通道只是把 hydrate 的來源從 PostListGenerator 改成自己的 DAO。
• Filter 層：不會。filter 吃 *dao.Post，不關心欄位怎麼來；啟用哪些 filter 由新通道的 experiment settings 自行決定。
• Response / FeedSnapshotDAO：不會。兩者都只讀 p.ID。
• 共用 snapshot cache：反而改善。舊文量大，放進共用 cache 會拖累所有 channel 的記憶體；獨立 DAO 讓 hot cache 維持在近期熱文上。

5.5資料來源盤點：共用既有 DAO 的可行性

新通道要解的實際問題，是「召回 clue 源（per-member 幾十到幾百個 post_id）」+「欄位 hydration 源（把這些 id 補回 filter 需要的欄位）」兩件事。下表逐一評估 module 內現有的資料源能否重用。

建議架構：召回與 hydration 分離

這個 pattern 的優點：

• 量級完全解耦：50 萬舊文只存在 offline pipeline 和 Redis key 裡；online 每次 request 只處理 member-specific 的幾百筆，記憶體、CPU、network 全部是可控常數級。
• 既有 pattern 現成可抄：Redis 召回 DAO 參考 evergreen_candidate_redis.go；Mongo by-id hydrate 參考 post_feature_mongo.go。
• 不影響其他通道：pipeline 其它環節完全不變，只新增 1 個召回 DAO + 1 個 hydration DAO（或擴充既有的）+ 1 個 generator。

06與其他 Candidate 的共用程度

下圖把 pipeline 切成「強制共用 / 可選共用 / 新通道自建」三層。

結論：共用比例約 2/3。新通道主要多出來的是「資料來源」本身，pipeline 其餘環節全部是 drop-in。

07自己需要維護的 Post 欄位

取決於這條 channel 要搭配哪些 filter。以下列三種典型強度，從最輕到最完整。

具體 TODO 清單

假設採情境 B（最常見），新通道落地的具體工程項目（按「召回 clue + hydration 分離」架構）：

• 先驗：確認 Mongo dice.posts 有哪些欄位（或問 ETL 維運），決定 hydration 走 Mongo 擴充 projection、ES _mget、還是新 store。
• Offline：寫 pipeline 產 per-member 舊文 id 清單到 Redis；key 結構可比照 member:{id}:evergreen_candidates。
• 召回 clue DAO：dao/old_post_candidate_redis.go，介面只回 []int64。
• Hydration DAO：優先擴充 MongoPostFeatureDAO（加 ListMeta(ctx, ids) map[int64]*Post，projection 納入該情境所需欄位）；或新增 ESPostMetaDAO 實作 _mget。
• Generator：candidate/old_post_recall.go，Generate 先取 clue、再 hydrate、組 []*dao.Post 回傳；不動 filter chain。
• Wiring：application/main.go + cmd/rpc.go 注入並登錄 GeneratorMatcher；外部服務設定放 internal/config/service.go（勿用 envDefault 寫死 addr）。
• 實驗設定護欄：filter 組合限定在你 hydrate 過的欄位範圍（避免零值誤判）。
• Codegen + 測試：task codegen:module:data-dice-candidate；testcontainers pattern（Mongo / PG / Redis 都有現成）。