我的旅程
協助設計並實作 以 PID controller 為核心的 Pacing 2.0 預算控速機制
Research Developer (Bidder Team) · Bridgewell
1.0 版的 pacing weight 震盪嚴重，導致預算過早燒完、OP 需人工盯盤，也難以滿足「整段期間平均帶量」這類需求（如直播廣告每時段平均曝光）。2.0 改用 PID controller，error function 取 (expected - actual) / (expected + actual)，gains (Kp, Ki, Kd) = (0.1, 0.001, 0.01)，並以分流實驗驗證成效。
統整 七個媒體流量源的出價流程為單一 BiddingCoordinator 框架
Research Developer (Bidder Team) · Bridgewell
原本 Google、Dable、Taboola、ucfunnel、SPA、RMN、Prebid/DirectPath 各有一套出價實作，任何共用邏輯的修改都得散彈式改七個地方。抽出 AdTypeIdRepository 搭配各媒體的 AdTypeSelector（strategy pattern）、BidPriceCappingService、DemographicRepository，並收斂到統一入口 BiddingCoordinator。
升級 三個核心競價服務至 .NET 8 並容器化部署到 Linux
Research Developer (Bidder Team) · Bridgewell
BiddingService、ImpService、Searcher 陸續脱離 .NET Framework 4.x 改跑 .NET 8 on Linux；最後一塊把 Searcher 從 Windows 主機搬到 Docker + Ansible + systemd 部署管線，並調校 Server GC，rolling deploy 間隔從 5 分鐘縮到 90 秒。
根治 RecSearcher 營業時間重啟時的啟動期 race 與 OOM
Research Developer (Bidder Team) · Bridgewell
推薦資料 provider 的 GetOrAdd 不是原子操作，啟動空窗期內 Kafka 行為事件與資料更新通知會同時觸發同一家大型商城資料的 deserialize（單次重啟最多 9 份），撞上記憶體上限。改為 single-flight，對同一個 key 的併發建構去重。
合併 出價候選資料（campaign / ad group / creative）的多個讀取來源為單一 GraphQL 快照
Research Developer (Bidder Team) · Bridgewell
原本出價與曝光服務的 campaign、ad group、creative 欄位分散在 MySQL 與 GraphQL 的多個定時 reader，各有不同更新週期，同一個 entity 的欄位之間有讀取時間差，跨來源 join 失敗時 creative 會靜默消失。改為單一 GraphQL reader 依廣告主分批抓取完整快照，限播類別、cost control 預算、landing 設定與廣告牆都改讀這份共用快照；遷移期以 shadow 雙讀逐欄位比對一致後才切換。
移除 9 個 repo 的 CI 對 Windows 實體主機的依賴
Research Developer (Infra Team，兼任) · Bridgewell
將 bwproto、recdb、eventtoken、WebHdfsDotNet、tsdblib、catjs、pixel 等 9 個 repo 的 Windows CI job 改用 windows_cmd runner 或 Linux dotnet/sdk:8.0 container，同時把單元測試升到 net8.0、修好已經失效的 pipeline。