Навчання системи рекомендацій тому, де люди хочуть жити: гео-ембеддинги

Ринок нерухомості з мільйонами оголошень стикається з проблемою пошуку. З такою кількістю пропозицій ключовим завданням є показати кожній людині саме той будинок, і для більшості людей вирішальним фактором є місцезнаходження. У цій статті розповідається, як команда з рекомендацій на найбільшій платформі з нерухомості в Латинській Америці, яка допомагає орендарям, покупцям та орендодавцям орендувати чи купувати нерухомість без звичайної бюрократії, перебудувала спосіб, яким її модель розуміє місцезнаходження. Ці результати були представлені на конференції RecSys 2025 у Празі, а всі наведені нижче цифри — це дані, надані самою командою.

Чому місцезнаходження потребує особливої уваги

Опитування майже 800 користувачів платформи показало, що понад половина з них вважає місцезнаходження найважливішим фактором при прийнятті рішення про оренду, випереджаючи ціну, розмір та зручності. Це здається очевидним, проте місцезнаходження є одним із найскладніших показників для правильної обробки в системах рекомендацій.

Решта історії стосується геоорієнтованих ембеддингів: навчених векторів, які кодують місцезнаходження нерухомості та ступінь схожості між місцями у форматі, який система рекомендацій може використовувати безпосередньо.

На якому етапі була перша версія

Система рекомендацій є моделлю з двома „вежами“ — архітектурою, популяризованою Google та YouTube для пошуку в дуже великих каталогах. Одна „вежа“ обробляє інформацію про користувача, а інша — про будинок. Кожна з них проєктує дані у спільний простір ембеддингів, а скалярний добуток у цьому просторі визначає якістю зіставлення. Внутрішня серія таких моделей у платформі називається HUE, що є скороченням від House User Embeddings.

Перша версія була навмисно простою та повністю табличною. Кожен атрибут з боку будинку мав аналог з боку користувача, який обчислювався як рухома статистика на основі останніх п’ятнадцяти взаємодій цієї особи.

Це охайний дизайн: будинки описуються за їхніми характеристиками, користувачі — коротким оглядом того, що вони переглядали, а вежі визначають, як ці два елементи пов’язані між собою. Оренда, площа квартири та кількість спалень добре функціонують у цій схемі, адже медіанна оренда за останніми п’ятнадцять переглянутих об’єктів досить точно відображає їхній бюджет. Місцезнаходження ж так не працює, і саме це є причиною існування цього проекту.

Чому сирі координати є поганими характеристиками

Координата не має практичного значення. Широта та довгота утворюють глобальну сітку, яка не пов’язана з тим, як люди уявляють собі місця, і значення на кшталт -22.97 нічого не говорить моделі про Копакабану. Щоб працювати з ним, щільні шари мають розділити кожен район кожного міста на окремі частини на основі неперервної площини, вивчаючи межі лише за даними про взаємодію. Це витрачає багато ресурсів моделі на те, що кожен місцевий житель вже знає.

Числова близькість — це не функціональна схожість. Річка, автомагістраль чи гряда можуть розділити два місця, розташовані на відстані лише 500 метрів, надаючи їм різних умов для пересування, цін та характеру. Два райони, розташовані на відстані десяти кілометрів, можуть бути майже ідеальними замінниками для певного орендаря. Евклідова відстань між координатами — це слабкий замінник для справжнього запитання: чи буде ця людина так само щаслива в обох місцях?

Усереднення координат знищує сигнал. Це фатальна проблема, яка впливає на вежу користувача. Уявіть орендаря в Ріо-де-Жанейро, який порівнює Копакабану та Барру-да-Тіжуку — поширену пару. Медіанна координата з його історії перегляду знаходиться в масиві Тіжука, де майже немає об’єктів для оренди. Будь-хто, хто розглядає два чи три різні райони, що стосується більшості людей, опиняється зведеним до однієї точки, яку він ніколи б не обрав.

Перш ніж замінити спосіб представлення даних, команда намагалась виправити ситуацію, додавши квадрати латитуди та довготи, щоб щільні шари могли легше описувати вигнуті регіони. Покращення було незначним, і саме ця незначність стала причиною проблеми. Функція, яка потребує поліноміального розширення перед тим, як модель зможе її використати, вказує на помилкове представлення даних, а не на помилкову модель. Тож команда припинила подавати моделі координати та почала навчати її географії.

Дві структурні проблеми

Будь-який підхід мусить вирішувати дві проблеми.

Перша — це розрідженість. Кількість будинків у мікрорегіоні є невеликою та нерівномірно розподіленою. Рекомендації діють лише в межах вузької зони, тож запаси швидко вичерпуються, а модель бачить занадто мало взаємодій у кожному місці, щоб навчитися чомусь надійному.

Друга проблема полягає у тому, що функціональна схожість ніде не описана. У описі немає жодної інформації про те, чи може один район замінити інший, та чому: доступ до пляжу, транспорт, безпека, рівень цін. Ці знання існують лише у способах пошуку людей, тому модель мусить навчитися їм з поведінки або обійтися без них.

Підхід: модель з двома вежами на основі клітин H3 різної роздільної здатності

Замість створення функцій вручну команда навчила мережу з двома вежами з використанням контрастного об’єктива, щоб представлення місць формувалися на основі спостережуваної поведінки. Вежа користувача кодує людей, а вежа місця — місця, і під час навчання об’єднуються вектори користувачів та місць, які зустрічаються разом у реальних, інтенсивних взаємодіях.

Найважливішим є спосіб опису місця. Сирові координати не використовуються. Кожна властивість індексується за допомогою сітки H3 від Uber, яка перетворює пару широти та довготи на ідентифікатор гексагональної клітинки. Оскільки сітка H3 є ієрархічною, кожна точка знаходиться в одній клітинці за кожним рівнем деталізації — від грубого (близько 36 км² на клітинку при різолюції 6) до дрібного (приблизно 0,105 км² при різолюції 9). Кожен ідентифікатор клітинки є дискретним токеном, тож для нього можна навчити ембеддинг так само, як навчають ембеддинги слів у текстових моделях.

Клітинки з роздільною здатністю H3 6, 7, 8 та 9 проходять через власний шар вбудовування, а також додається вбудовування на рівні міста для відтворення загальної структури урбаністичних районів. Вежа локацій об’єднує всі ці елементи та пропускає їх через пару повністю з’єднаних шарів ReLU, у результаті чого для кожної локації утворюється 32-вимірний вектор.

Користувацька частина навмисно залишається простою: вбудовування ідентифікатора користувача, за яким слідують щільні шари, тож майже весь процес навчання відбувається у вежі локацій. Вона призначена для того, щоб спрямувати кожен вектор локації до місць, з якими користувач дійсно мав справу. Після навчання вона видаляється, а залишається набір векторів локацій, які потім використовуються іншими моделями.

Чому кілька роздільних здатностей одночасно? Одна деталізована клітинка забезпечує точність, але страждає від нестачі даних. Одна груба клітинка має велику кількість даних, проте не дозволяє розрізнити важливі відмінності. Використання кількох рівнів роздільної здатності дозволяє моделі спиратися на навколишню область, коли певна клітинка має мало взаємодій, водночас зберігаючи локальні деталі там, де є достатньо доказів. Уявіть собі це як піраміду ознак у просторі — це прямий спосіб боротьби з розрідженістю даних.

Сигнал навчання. Функція втрати — це ціль InfoNCE з контрастного прогнозного кодування. Рядки складаються з пар (користувач, місцезнаходження), взятих з реальних інтеракцій із високою інтенцією, тобто заброньованих візитів чи надісланих пропозицій. Негативні приклади не вибираються вручну. У кожній партії місцезнаходження інших користувачів виступають у ролі негативних прикладів, що не коштує нічого та відображає реальний попит.

Є одна проблема. Місце не є просто довільним ідентифікатором елемента, адже багато користувачів можуть одночасно мати позитивні оцінки для одного й того ж місця. Коли негативний результат з однієї партії виявляється як оцінка того самого місця від того самого користувача, алгоритм розглядає це як хибно негативний результат та маскує його, щоб пара не була випадково розділена. Схожості мають певний рівень інтенсивності, і крос-ентропія застосовується в обох напрямках — від користувача до місця та назад.

Модель створена за допомогою PyTorch Lightning із методом ініціалізації Xavier uniform, 32-вимірними ембеддингами, оптимізатором Adam та розміром партії 512 елементів. Дані для навчання склали близько 4 мільйонів подій з високою інтенсивністю, створених приблизно мільйоном різних користувачів. Зберігалися лише сильні сигнали, такі як бронювання візиту чи подання пропозиції, а шумні події з низькою інтенсивністю, як-от кліки, були видалені.

Як відбувалося оцінювання

Порівняння охоплювало три моделі: базову модель факторизації матриці (ALS із неявним зворотним зв’язком, що використовує лише найдрібнішу клітинку H3), модель з двома вежами, яка використовує лише роздільну здатність H3 9, та повну багаторізольвну модель з двома вежами. Два способи оцінки працювали паралельно.

Внутрішня оцінка досліджує якість ембеддингів безпосередньо, незалежно від будь-яких наступних завдань, за допомогою двох критеріїв для виявлення колапсу. Першим є Кількість інформації, яка в останніх дослідженнях колапсу ембеддингів визначається як сума сингулярних значень матриці ембеддингів, поділена на найбільше з них. Для 32 вимірів цей показник коливається від 1 (повний колапс) до 32 (кожен вимір вносить однаковий внесок), тож чим вище, тим краще. Другим критерієм є спектр сингулярних значень нормованої матриці коваріації ембеддингів, який показує, як розподіляється дисперсія між вимірами. Плавне, рівномірне зменшення означає, що модель повністю використовує свою потужність, тоді як різке падіння свідчить про колапс вимірів, коли ембеддинги деградують до низькорангового підпростору.

Звітовий спектр є чітким. Модель з однією роздільною здатністю різко падає при вищих індексах рангу, що є ознакою краху. Модель з багатьма рівнями роздільної здатності має найбільш плавне зниження серед трьох, що означає, що її дисперсія розподіляється рівномірно та вона повністю використовує простір вбудовування.

Екстринсична оцінка перевіряє, чи кращі вбудовування допомагають користувачам. Для цього використовувалися місячні записи з системи (березень 2025 року) з модуля „схожі будинки“ — системи рекомендацій від товару до товару, яка показує будинки, схожі на базовий об’єкт. Для кожного базового об’єкта початкові рекомендації були переранжовані за допомогою косинусової схожості між гео-вбудовуванням базового об’єкта та вбудовуванням кожного кандидата, а рекомендації, які не досягали певного порогу схожості, були поступово видалені.

Ключовим бізнес-показником є швидкість орендних операцій — частка показаних рекомендацій, які призвели до конкретної дії: особистого візиту або пропозиції про оренду. Кліки є шумовими показниками, тому замість них використовуються орендні операції, оскільки вони відображають справжній інтерес. Для кожної моделі та порогового значення обчислювався підвищений ефект у порівнянні з непідфільтрованими рекомендаціями цієї моделі, які мали дійсні значення схожості, а таблиця показує середнє значення за всіма пороговими значеннями. Навчання завершилося у грудні 2024 року, а для оцінки використовувалися дані за березень 2025 року, тому нічого з періоду оцінки не потрапило до процесу навчання.

У міру зменшення списку рекомендацій модель багатьох роздільних здатностей проявляє кращі результати при найбільш жорстких критеріях відбору, тоді як методи, засновані на навчанні, збираються разом у середній частині діапазону. Найбільш показовим порівнянням є використання звичайного фільтра радіальної відстані: найбільші покращення були досягнуті завдяки методам оцінки схожості, а не через віддавання переваги будинкам, розташованим поблизу.

Результати

Платформа працює у двох основних напрямках: Оренда та Продаж. Офлайн-оцінка зосереджена на операціях оренди, де обсяг запитів є найвищим, тоді як онлайн-вплив оцінювався для обох напрямків.

Обидва офлайн-напрямки покращувалися з кожним кроком у підвищенні складності моделі. Перед наведенням цифр варто зазначити, що покращення у потоці оренд є результатом симуляції, заснованої на переранжуванні історичних записів, а не живого експерименту. Результати живих тестів типу A/B наведені далі.

Перехід від факторизації матриці до моделі з двома вежами на одній роздільній здатності підвищив показник Інформаційної обсягності на 158%, а симульоване підвищення доходів від оренди — на 84%. Мультироздільнісні ембеддинги H3 додали ще 40% до показника Інформаційної обсягності, довівши його до 21,7, та підвищили симульоване підвищення до 10,9%, що майже вдвічі більше, ніж на попередньому етапі. Коротко кажучи, надання моделі просторового контексту на кількох масштабах покращило самі ембеддинги та їхній симульований вплив на користувачів.

Щоб зробити ембеддинги зрозумілішими, команда створила внутрішній інструмент, який відображає найближчих сусідів на карті. Якщо вибрати темний гексагон у Копакабані, то загоряється група сусідніх клітин — ті, які модель вважає функціонально схожими. Це зручна перевірка того, чи вивчена географія відповідає уявленню людей про місто.

Онлайн-тест A/B з подібними будинками. На момент написання статті експеримент із каруселлю „подібні будинки“ ще тривав. Він вже завершився, і отримані результати для цієї каруселі були такими:

• Оренда: зростання кількості кліків на 4,18%, а кількість кліків, які призвели до бронювання візиту, — на 3,38%.
• Продаж: кількість кліків зросла на 5,53%.

Важливим є саме фінальний результат. Як офлайн-метрики, так і тест A/B вказують на одне: гео-ембеддинги є ефективними.

Інтеграція GeoEmbeddings у HUE

Дослідження з переранжуванням слугувало доказом концепції. Справжньою метою було видалення координат широти та довготи з самого рекомендувального механізму, що призвело до другої версії продакшн-рекомендувальника. Заздалегідь підготовлені GeoEmbeddings знаходяться у спільній вежі даних та залишаються незмінними, тож рекомендувальник отримує стабільний географічний сигнал та не повинен заново вивчати географію. Обидві вежі використовують їх по-різному.

Зміна у вежі будинків полягає у простій заміні. Там, де раніше надходили координати об’єкта, тепер надходить GeoEmbedding клітинки H3, яка містить цей об’єкт.

Вежа користувача потребує більш глибокого переосмислення, адже медіани не можна просто замінити на щось еквівалентне. Немає нічого значущого для обчислення середнього. Натомість у вежу подається послідовність, яка в порядку охоплює елементи з останніх десяти подій користувача. Кожен запис фіксує тип події, тож поверхневий огляд та пропозиція рахуються по-різному, а також є кодування новизни, яке дозволяє моделі зрозуміти, наскільки швидко сигнал має зникати.

Користувач, який порівнює Копакабану та Барру, більше не знаходиться в обмеженому просторі між ними. Тепер модель бачить обидва місця. Вона може визначити, яке з них щойно переглядали, яке призвело до бронювання візиту та яке було раніше.

Разом ці дві зміни принесли найбільше покращення, яке команда коли-небудь бачила внаслідок модифікації однієї лише функції. За показником важливості пермутацій GeoEmbeddings став найважливішою функцією у рекомендаційній системі другої ітерації, а результати прямого тестування типу A/B показали +1% бронювань у розділі „Оренда“ та +3,3% запропонованих пропозицій у розділі „Продаж“. Такі покращення рівня конверсії на рівні платформи демонструють, наскільки сильно якість представлення даних впливає на кінцеві результати.

Що буде далі

У географії ще є можливості для покращень. У планах — використання чітких сигналів близькості, таких як відстань до станцій метро, шкіл та парків, а також більш детальні форми представлення даних, які є більш дрібнозернистими та динамічними.

Ще одне важливе відкриття виникло майже випадково. Переробка структури „вежі користувача“ стала першим випадком, коли HUE розглядав історію користувача як послідовність подій, а не як набір статистичних підсумків, і цей підхід виявився ефективним. Це породило природне запитання: якщо послідовність — це правильний спосіб описати те, де користувач шукав інформацію, чи не підійде вона також для опису всього іншого, що він робив?

У пошуках відповіді на це запитання з’явився SENNA — послідовний багатомодальний рекомендувальний систем, у якій вся „вежа користувача“ складається з послідовності сайтів, з якими людина взаємодіяла, причому кожен сайт описується детально, включаючи фотографії. GeoEmbeddings використовуються як зафіксовані географічні дані.

Місцезнаходження завжди було найважливішим для користувачів. Навчання моделі робити висновки щодо місця в різних масштабах, замість того щоб розглядати координати як ще одне число, дало команді можливість враховувати цю пріоритетність.

Додаткова література

Ці ідеї ґрунтуються на кількох публічних джерелах: статті Covington, Adams та Sargin (2016) про метод двох веж у YouTube, робота Yi та колег (2019) з корекцією упереджень у виборці для методу двох веж, стаття van den Oord, Li та Vinyals (2018) про контрастне прогнозне кодування, дослідження Guo та колег (2024) щодо колапсу ембеддингів, а також документація до геопросторового індексу H3 на сайті h3geo.org.