你無法針對「品味」進行單元測試：建立興趣點管線

建立一個需要「品味」的功能——例如判斷哪些地標對使用者來說真正有趣——是無法透過傳統的單元測試來解決的，因為主觀性沒有客觀的基準真相（ground truth）。雖然大型語言模型（LLMs）可以根據其訓練數據提供主觀評分，但它們容易產生幻覺和偏見，因此它們最有效的角色是作為輔助訊號，而非主要的真相來源。

地理空間數據處理的技術棧

為了給 In the Long Run 應用程式建立興趣點（POI）管線，我們結合使用了 Python、Apache Parquet 和 DuckDB 來處理大規模的地理空間數據集。

• 數據源： GeoNames 在 Creative Commons 授權下提供了原始的地點與分類數據。
• 儲存與查詢： 處理後的數據儲存在 Apache Parquet 檔案中以提高效率，並使用 DuckDB 作為基於 SQL 的分析查詢層。
• 地理計算： 管線利用 Shapely 和 Pyproj 來計算邊界框（bounding boxes）以及 POI 相對於特定跑步路線的距離（預設為 50km 半徑）。
• AI 整合： 使用 Claude (Anthropic) 作為編碼代理（coding agent）來協助設計專案計畫並實作管線步驟。

過濾知名度並克服偏見

原始的地理空間數據通常雜訊過多，難以提供精選的用戶體驗。需要透過多階段過濾程序，將數百萬行數據縮減至一組可管理的知名地標集合。

初始過濾與知名度訊號

過濾從排除行政區劃（國家、州）開始，並選擇特定的功能代碼，例如公園、歷史遺跡、城堡和紀念碑。為了識別「知名」的地點，管線使用了 GeoNames alternateNames.txt 數據集中發現的 Wikipedia 連結作為主要的知名度訊號。

「英語圈偏見」

在管線開發初期的一個發現是，依賴 English Wikipedia 連結會造成地理偏見。例如，Route 66 (3,787 km) 產生了 14,181 個 POI，而 Iceland ring road (1,321 km) 僅產生了 511 個。這顯示數據反映的是英語使用者居住與編輯 Wikipedia 的地方，而非實際有趣地標的密度。

LLMs 的角色：主觀品味 vs. 事實準確性

LLMs 被整合進管線中，為 POI 提供「主觀」評分，但事實證明它們在生成事實摘要方面並不可靠。

豐富化過程中的幻覺

嘗試使用 Anthropic 的 Haiku 模型來生成摘要時導致了嚴重的幻覺。該模型偶爾會誤認地點（例如，將 Illinois 的一個 Central Park 歸類為曼哈頓的那個），或捏造有關人口與山脈高度的統計數據。因此，專案回歸到使用原始的 Wikipedia 摘要，以確保正確性高於可讀性。

LLMs 作為評分工具

雖然在事實寫作方面表現不佳，但 LLM 在提供主觀重要性評分方面非常成功。這個評分有助於將「有趣」的興趣點提升到那些僅僅因為在多種語言中擁有許多自動翻譯的 Wikipedia 頁面而脫穎而出的地點之上，否則結果會向一般的居住地傾斜。

驗證「品味」的挑戰

與功能性需求不同，「品味」——即是什麼品質讓一個 POI 對特定路線而言感覺「對味」——是無法透過紅/綠單元測試來驗證的。

路線差異性

數據需求因地理位置而異。如果沒有經過調整，穿過人口稠密地區的路線可能會迅速變成每個小村莊的「人口地圖」。為了這個問題，我們引入了每條路線的參數，包括：

• 自定義人口過濾器。
• 在主觀 LLM 評分與客觀的 Wikipedia 連結數量之間進行權重分配。
• 地理半徑過濾器，以確保點位在城市群與鄉村路徑之間均勻分布。

自動化的極限

因為對於什麼構成「有趣」的景點並沒有基準真相，成功的評估仍然是手動且迭代的。正如社群討論中所提到的，品味通常是「規格書中你忘記寫下的部分，加上你即便嘗試也寫不下來的部分」。

"驗證變得難以推理，因為興趣點沒有基準真相，品味也沒有紅/綠單元測試。"

社群對品味與 AI 的見解

開發者之間的討論顯示，雖然 AI 可以增強過程，但人類的「選擇」元素仍然是關鍵路徑。

• 將品味外部化： 有人認為品味可以被單元測試，除非它能被完全外部化為一份規格書，而這通常是不可能的，因為人類並非「hashmaps」。

• 治理而非生成： AI 代理的價值正在從生成轉向治理——人類的角色是將 AI 生成的 200 行輸出縮減至真正符合所需美學或功能目標的 80 行。

• 替代訊號： 對於尋求更客觀知名度訊號的人來說，工具如 QRank (其聚合了 Wikimedia 專案的頁面瀏覽量) 提供了一個比簡單的連結數量更具數據驅動的替代方案。