一份案例研究是怎麼做出來的

前言

一份 hungATC 案例研究的起點是一段 VHF 錄音，終點是一份附腳註、任何人都能核對的文件。中間是大約四十小時的工作，包含接收、轉寫、複核與發布。這篇文章說明錄音如何在系統裡走完一整輪。

訊號接收

我們透過設置在台北 GX10 伺服器上的 Direct Feed 接收器，接收 RCSS 與 RCTP 的標準 ICAO 頻率。串流以三十秒為單位切片，每段都標註頻道、頻率、RSSI，以及來自校時 NTP 來源的 UTC 時間戳記。任何資料都不丟棄 — 即使是靜音段，也會被記錄下來，做為接收器仍在線上的正向證明。

兩段式轉寫

第一段使用 hungASR，一個基於 Whisper Large V3 的微調模型，產生帶有詞級時間戳記的初稿。第二段把同一段音訊送進 Gemini，並把 hungASR 的初稿當作提示輸入，主要用來修正數字、呼號，以及單純使用 Whisper 容易誤判的塔台術語。兩段結果不一致時，該片段會被標記進人工複核佇列。

人工複核

複核員對照原始音訊聽過完整轉寫，並從三個維度評分：發音準確度、呼號正確性、以及指示意圖。任何低於發布門檻的分數都會把片段退回隊列。每一次複核操作都會留下紀錄，讓整條複核鏈日後仍可被稽核。

發布

通過複核的轉寫會渲染成 MDX，跟網站其他頁面共用同一條靜態輸出管線發布。音訊檔、轉寫 JSON、與渲染後的文章共用同一個 case ID，方便外部研究者端到端重建。

限制

VHF 接收屬於視線傳播且會有遺漏，距離較遠的航機訊號會時有時無。每一份案例都會附上覆蓋率地圖，讓讀者知道哪些東西沒收到。轉寫做得不錯但並非完美 — 每一份發布的案例都附有信心區間，以及公開的修正政策。