你无法针对“品味”进行单元测试：构建兴趣点流水线

构建一个需要“品味”的功能——例如确定哪些地标对用户真正有趣——无法通过传统的单元测试来解决，因为主观性没有客观的真值（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 链接作为主要的显著性信号。

“英语圈偏见”

流水线早期的一个发现是，依赖英语 Wikipedia 链接会产生地理偏见。例如，Route 66 (3,787 km) 产生了 14,181 个 POI，而冰岛环岛公路 (1,321 km) 仅产生了 511 个。这表明数据反映的是英语使用者居住并编辑 Wikipedia 的地方，而不是有趣地点的实际密度。

LLMs 的角色：主观品味 vs. 事实准确性

LLMs 被集成到流水线中，为 POI 提供“主观”评分，但事实证明它们在生成事实性摘要方面并不可靠。 \n### 丰富化过程中的幻觉 尝试使用 Anthropic 的 Haiku 模型生成摘要导致了严重的幻觉。该模型偶尔会误认位置（例如，将伊利诺伊州的 Central Park 归类为曼哈顿的那个），或者捏造有关人口和山脉高度的统计数据。因此，项目回归到使用原始的 Wikipedia 摘要以确保准确性而非可读性。

LLMs 作为评分工具

虽然在事实性写作方面表现不佳，但 LLM 在提供主观重要性评分方面是成功了。这一评分有助于将“有趣”的兴趣点从那些仅仅因为在多种语言中拥有大量自动翻译的 Wikipedia 页面而显得突出的地点中区分出来，否则结果会向普通的居住地倾斜。

验证“品味”的挑战

与功能性需求不同，“品味”——即一个 POI 如何让特定路线感觉“对味”的质量——无法通过红/绿单元测试来验证。

路线差异性

数据需求因地理位置而异。如果不进行调整，穿过人口密集区域的路线可能会迅速变成每个小村庄的“人口地图”。为了解决这个问题，引入了每条路线的参数，包括：

• 自定义人口过滤。
• 在主观 LLM 评分与客观的 Wikipedia 链接计数之间进行加权。
• 地理半径过滤，以确保点在城市集群和乡村路径之间均匀分布。

自动化的局限性

由于对于什么构成“有趣”的景观没有真值，成功的评估仍然是手动且迭代的。正如社区讨论中所提到的，品味通常是“规范中你忘记写下的部分，加上你试图写下却写不下的部分”。

"验证变得难以推理，因为兴趣点没有真值，品味也没有红/绿单元测试。"

社区对品味与 AI 的见解

开发者之间的讨论表明，虽然 AI 可以增强这一过程，但“选择”的人类因素仍然是关键路径。

• 将品味外部化： 有人认为，品味只有在能够完全外部化为规范时才能进行单元测试，但这通常是不可能的，因为人类不是“hashmaps”。

• 治理而非生成： AI 代理的价值正在从生成转向治理——即人类的角色是将 AI 生成的 200 行输出削减到真正符合预期审美或功能目标的 80 行。

• 替代信号： 对于寻求更客观的显著性信号的人，像 QRank（它聚合了 Wikimedia 项目中的页面浏览量）这样的工具提供了比简单的链接计数更更具数据驱动的替代方案。