味覚はユニットテストできない: ポイント・オブ・インタレストパイプラインの構築

味覚をユニットテストできない: ポイント・オブ・インタレスト(POI)パイプラインの構築

機能が「味覚」を必要とする場合—たとえば、どのランドマークが実際にユーザーにとって面白いかを判断すること—は、主観性に客観的な真実が存在しないため、従来のユニットテストでは解決できません。大規模言語モデル(LLM)は訓練データに基づく主観的評価を提供できますが、幻覚やバイアスが発生しやすく、主要な真実の情報源というよりは補助的なシグナルとして活用する方が効果的です。

地理空間データ処理の技術スタック

In the Long Run アプリ向けのポイント・オブ・インタレスト(POI)パイプラインを構築するために、Python、Apache Parquet、DuckDB の組み合わせで大規模な地理空間データセットを扱いました。

  • データソース: GeoNames が Creative Commons ライセンスの下で提供する生の位置情報とカテゴリデータ。
  • 保存とクエリ: 処理済みデータは効率性のために Apache Parquet ファイルに保存し、DuckDB が SQL ベースの分析用クエリ層として機能。
  • ジオ計算: パイプラインは Shapely と Pyproj を使用して、バウンディングボックスや特定のランニングルート(デフォルトは半径 50km)に対する POI の距離を計算。
  • AI 統合: Claude(Anthropic)をコーディングエージェントとして利用し、プロジェクト計画の設計とパイプラインステップの実装を支援。

注目度でのフィルタリングとバイアス克服

生の地理空間データはユーザー体験をキュレーションするにはノイズが多すぎます。何百万行ものデータから管理可能な注目すべきランドマークの集合へと絞り込むために、複数段階のフィルタリングプロセスが必要です。

初期フィルタリングと注目度シグナル

管理区分(国、州)を除外し、パーク、史跡、城、モニュメントなどの特定のフィーチャーコードを選択することからフィルタリングを開始しました。"注目すべき" サイトを特定するために、パイプラインは GeoNames の alternateNames.txt データセット内に見つかる Wikipedia リンクを主要な注目度シグナルとして利用しました。

"英語圏バイアス"

パイプラインの初期段階で、英語版 Wikipedia のリンクに依存すると地理的バイアスが生じることに気付きました。たとえば、ルート66(3,787 km)は 14,181 件の POI を生成したのに対し、アイスランドのリングロード(1,321 km)はわずか 511 件しか生成しませんでした。これはデータが実際の興味深い地点の密度ではなく、英語話者が住んで Wikipedia を編集している場所を反映していることを示しています。

LLM の役割: 主観的味覚 vs. 事実的正確性

LLM は POI に対して「主観的」な評価を提供するためにパイプラインに組み込まれましたが、事実的な要約を生成するには信頼性が低いことが判明しました。

エンリッチメントにおける幻覚

Anthropic の Haiku モデルを使って要約を生成しようとしたところ、重大な幻覚が発生しました。モデルは時折場所を誤認識(例: イリノイ州のセントラルパークをマンハッタンのものと分類)したり、人口や山の高さに関する統計を捏造したりしました。そのため、可読性よりも正確性を優先し、元の Wikipedia 要約に戻すことにしました。

評価ツールとしての LLM

事実記述が苦手な一方で、LLM は主観的な重要度スコアの提供に成功しました。このスコアは、多言語に自動翻訳された Wikipedia ページが多数存在するだけの一般的な人口密集地ではなく、真に "面白い" ポイント・オブ・インタレストを上位に押し上げるのに役立ちました。

"味覚" の検証課題

機能要件とは異なり、"味覚"—特定のルートに対して POI が適切かどうかという感覚—は赤/緑のユニットテストで検証できません。

ルート別のばらつき

データ要件は地理によって大きく異なります。人口が密集したエリアを通るルートでは、調整しなければ小さな村すべてが "人口マップ" になってしまいます。これを解決するために、ルート別パラメータを導入しました:

  • カスタム人口フィルタ。
  • 主観的 LLM スコアを客観的な Wikipedia リンク数に対して重み付け。
  • 都市クラスターと農村パス間で均等にポイントが分布するようにする半径フィルタ。

自動化の限界

"面白い" 視点が何かという根拠が存在しないため、成功の評価は手動かつ反復的です。コミュニティの議論でも指摘されているように、味覚はしばしば "書き忘れた仕様の部分、そして書こうとしても書けない部分" です。

"検証は難しくなる。ポイント・オブ・インタレストに対する真実が存在せず、味覚に対する赤/緑のユニットテストがないからだ。"

コミュニティの洞察: 味覚と AI

開発者間の議論では、AI がプロセスを補強できる一方で、"選択" の人間要素が依然として重要な道筋であることが示唆されています。

  • 味覚の外部化: 味覚は完全に仕様化できる場合に限りユニットテスト可能だと主張する声もありますが、人間は "ハッシュマップ" ではないため実現は困難です。
  • 生成からガバナンスへ: AI エージェントの価値は生成からガバナンスへシフトしています。人間の役割は、AI が生成した 200 行のコードを、目的とする美学や機能に合致する 80 行に絞り込むことです。
  • 代替シグナル: より客観的な注目度シグナルを求める場合、QRank(Wikimedia プロジェクト全体のページビューを集計)などのツールが単純なリンク数よりもデータ駆動的な代替手段を提供します。

Sources