こんにちは！株式会社 estie でデータエンジニアを担当している fukushima です。
普段は主に、不動産データの整備・解析プラットフォームを設計・開発し、さまざまな建物情報を結びつけ、顧客に価値を届けられる形に整える仕組みづくりを進めています。
具体的には、dbt を使ったデータパイプラインの構築からメンテナンス、パイプライン周辺の機械学習モデル・ダッシュボード開発などです。データ品質を上げるためにできることに幅広く取り組んでいくことをミッションとして日々働いています。
1. 現在取り組んでいるプロジェクトの課題
estie のデータパイプラインにおける重要なタスクとして、様々なデータソースから来た建物データを
- 同一と見做せるものはまとめる
- 同一と見做せるものがなければ、新規の建物として登録をする
というものがあります。（“名寄せ“ と呼ばれることが多い）
「不動産・地理データの闇と技術的面白さ」イベントレポート - estie inside blog
私は現在、住宅データ領域においてこの 名寄せタスク を解決する仕組みを構築しようとしています。
しかし、住宅領域における名寄せというタスクはなかなかにチャレンジングな部分があります。
以下、その難しさ 3 点を挙げてみました。
ドメインの複雑さ
- 建物の名称や住所表記には微妙な揺れが多く、「同じ建物なのに微妙に名前が違う」「住所は同じでも用途が違う」といったケースが多数。単純なルールベースやキーワードマッチングでは精度が出せない
まったく同じ住所、建物名でも、建物の建て替えがあった場合は異なる建物として扱いたいはずです。一方で、同じ建物を指している場合でも、データ入力者の癖や情報鮮度によっては、異なる名称や階数表記になっていることが頻繁にあります。
求められる精度の高さ
- データ量は多いものの、一件一件の建物データが数千万円単位の意思判断に使われるので、顧客が求めるデータ品質は高い
不動産領域においては、データを使った意思判断一つ一つが金額的に重いため、データの品質は非常に重要です。品質の中でも、正確性はもちろんですが、市場の動向を正確につかむという意味では網羅性も強く求められています。
レコード数の多さ
- 人の目で全件チェックするのは現実的に不可能
- LLM（大規模言語モデル）に丸投げしようとしても、コストと速度の面でハードルが高い
不動産データ、特に住宅データは、日々の建て替え情報・募集などを合わせると数千万件規模にのぼります。ログデータ・センサーデータなどと比較すると小さいオーダーにはなりますが、1 レコードも切り捨てられないため、扱いには工夫が必要です。
これらの背景から、「複雑なドメインをしっかり理解できるモデル」を採用しつつ、人間のフィードバックを効果的に取り込む、つまり Human-in-the-Loop の仕組みを導入することで、精度担保とスピードの両立を目指しています。次節以降では、estie でのアーキテクチャ全体像と、具体的な HITL の回し方をご紹介します。
2. 実際の取り組み
ここからは、先ほどの課題をどのように解決しようとしたか、紹介していきます。
2.1 みんなでアノテーション
プロジェクトのキックオフ時に、まずチーム全員でアノテーション作業を実施しました。
単なるアノテーションデータの拡充以外にもしっかりと副次的効果があったので、全てをアウトソースせずにやってよかったと思っています。
効果① ドメイン理解の共有
- 建物名や住所の微妙な揺れを目で確認しながら議論することで、「これは名前は同じだけど同じ建物として扱っていいのか？」「京都の住所にはどう対処すればいいんだ？」など、ルール感を素早くそろえられる
効果② 課題に対するアプローチについて議論ができる
- そもそも機械学習を使う必要はあるか？など、タスクに対するアプローチの妥当性について早い段階で話し合うことができるようになる
- コミュニケーションの場になり、チーム全員が同じ方向を向くきっかけになる
（この本で紹介されていた手法になります。技術的な側面だけではなく、アノテーターの評価方法やチームビルディングといった組織論にも踏み込んでおり、名著です。）
2.2 Snowflake ML でモデルを継続学習・管理
PoCで “このアプローチが実現可能” と確認できた後は、Snowflake MLを中心に据えた学習管理基盤を構築しました。
Snowflake 上での データ＆モデルの一元管理
学習用データセットも、完成したモデルのバージョンもすべて Snowflake 上で持つことで、データ移動や外部環境依存を排除。dbt からコマンド一発で学習をキックできるようにしたほか、メトリクスやモデルのバージョン履歴も自動で記録しています。
国土交通省主催の機械学習コンペで実績を残した人もおり、Snowflake ML 周りの開発ノウハウは社内に蓄積しています。
品質担保の CI 連携
github にモデル周辺の変更をコミットすると、自動 CI が変更後のモデル精度を算出し、意図しない性能低下（デグレ）がないかをチェックしています。
2.3 Streamlit ダッシュボードで監視
人間による AI の監視
モデルの自動実行結果は、そのままではブラックボックスになりがちです。そこで、Snowflake上で動くStreamlitアプリを作り、判定結果と確信度スコアを可視化。さらに、迷いが大きいペアだけを抽出して人間がその場で更新を行えるインターフェースを SiS （Streamlit in Snowflake）で実装しました。
AI と人間によるプロダクトの監視-出口側のセーフティネット
プロダクト監視用に別途モデルも用意し、プロダクトに出ているデータを定期的にチェック。データドリフトや学習失敗をキャッチしたら、アラートを上げて速やかに対応できる仕組みも整えました。
上記の取り組みによって、「自動化の恩恵」を最大化しつつ、「人の判断」を重要なポイントで必ず挟み、その結果を AI に FeedBack するという Human-in-the-Loop の循環を回せる体制ができあがっています。
3. これから取り組んでいきたいこと
将来的には、従来どおり人間の判断を活かしつつ、大規模言語モデル（LLM）にも同じタスクを並列で実行してもらい、その結果をリアルタイムで比較・評価する仕組みを整えたいと考えています。
人間と LLM を同一の指標で比較検証していく中で、コストパフォーマンスを評価しながら徐々に LLM が代替する領域を増やしていくことが次のマイルストーンになります。（LLM をシステムに組み込んでおけば、LLM の異常な速度の進化に自動的に乗っていけるのでうれしい！）
このアプローチによって、ヒューマンリソースの最適化と、モデルの継続的な品質向上を同時に実現し、よりスケーラブルで柔軟なシステム運用を実現していきたいと思います。
最後に
せひカジュアル面談しましょう！ご応募お待ちしております。
