Незважаючи на складні умови в Україні поступово розвивається ринок земельних ділянок сільськогосподарського призначення, збільшується обсяг транзакцій, розширюється його географія, зростають ціни на землю. У зв’язку з цим є необхідність аналізувати ринкові тенденції та вплив ринку на зміни у землекористуванні. Проте обсяг, склад і якість даних про земельний ринок, що представлені в офіційних джерелах, виявляються недостатніми для глибокого розуміння ринкових процесів.
Одним з додаткових джерел інформації про фактичний ринок земель можуть стати оголошення про продаж чи оренду земельних ділянок на онлайн ресурсах. Збір даних щодо пропозицій на ринку земельних ділянок в оголошеннях на торгівельних площадках на кшталт OLX.ua ускладнюється або взагалі втрачає сенс через низьку структурованість інформації та помилки ручного введення в цих оголошеннях. Так, серед основних проблем якості даних в таких оголошеннях можна відмітити:
- Одиниця вимірювання площі ділянки може бути зазначена користувачем у гектарах, сотках, квадратних метрах, акрах тощо. При цьому часто користувачі плутають ці одиниці вимірювання в різних частинах оголошення – в заголовку і тексті оголошення прямо зазначають площу ділянки, наприклад 4.2 гектари, а в атрибуті оголошення “Площа, соток” пишуть 4.2, що відповідно означає 4.2 сотки. Також в тексті оголошення може бути зазначено одиницю вимірювання з відмінками та скороченнями: га, гектар, гектари, гектара, гектарів, гектаров, ha, сот, соток, сотки, сотків тощо. Тому пропонується виявляти площу ділянки одночасно і в гектарах, і в сотках.
- Одиниця валюти оголошення може бути також заплутаною: у гривнях, доларах або євро. Причому в різних місцях оголошення може бути одночасно зазначено ціну за 1 гектар, за повну ділянку, за декілька ділянок (тобто за весь лот). Наприклад в атрибуті оголошення “Ціна” може бути зазначено 10 000 грн., а тексті оголошення вказано, що це ціна за 1 гектар. Тому, якщо під атрибутом “Ціна” при аналізі розуміти ціну за всю ділянку, а ділянка матиме площу відмінну від 1 га, то аналіз буде викривлено. І таких оголошень, де ціна зазначена в розрахунку на 1 га або 1 сотку досить багато. Тому пропонується виявляти ціну одночасно і в UAH, і в USD.
- В тексті оголошення може бути представлено на продаж кілька земельних ділянок, які продаються разом. В деяких випадках таких ділянок може бути багато з різними кадастровими номерами, різними видами цільового призначення, різними площами. В такому випадку, як правило, атрибут “Ціна” оголошення часто не має багато сенсу, та її треба за можливості визначити виходячи з тексту оголошення. Тому пропонується виявляти кількість ділянок в оголошенні, загальну площу оголошення, повну ціну оголошення, ціну за 1 гектар. Це дозволить створити додаткові перевірки і точніше розуміти усі параметри оголошення.
- В атрибуті оголошення “Кадастровий номер” іноді користувачі не пишуть нічого, але зазначають кадастрові номери ділянок в самому тексті оголошення. Тому пропонується виявляти кадастрові номери списком з усього оголошення.
- В тексті оголошення може бути описано оренду ділянки, але саме оголошення може бути подано в розділі продажу нерухомості. Тобто доцільно розрізняти оголошення про продаж чи оренду.
- В тексті або заголовку оголошення про продаж ділянки користувачі часто зазначають, що це земельний пай. Це може бути корисно для виявлення ділянок, які є земельними частками (паями) із цільовим призначенням для сільського господарства. Хоча, звісно, більшість оголошень присвячені продажу земельних ділянок під забудову.
- Текст оголошення може бути написаний різними мовами: українською, англійською, російською. В тексті можуть бути присутні помилки граматичного або синтаксичного характеру, що ускладнює формалізацію змісту оголошення.
Аналіз оголошень, який ми робили раніше, передбачав використання складних запитів для врахування, усунення чи мінімізації наведених вище помилок і неточностей. З появою великих мовних моделей (LLM) такий аналіз стало можливим проводити на якісно новому рівні. Особливо враховуючи можливість безкоштовного і необмеженого використання локальних моделей. Останні можна запускати як сервіси на локальному комп’ютері чи власному сервері за допомогою LM Studio або Ollama. Парсинг тексту оголошень та їх подальший запис до бази даних разом з структурованими відповідями LLM ми виконували за допомогою мови програмування python.
Так, до промпта моделі надається текст зі сторінки оголошення, в якому міститься заголовок оголошення, текст оголошення, а також усі атрибути оголошення, включаючи ціну, площу, кадастрові номери. Також доцільно підказати мовній моделі в системному промпті, що 100 соток = 1 га, 1 USD = 42 UAH, 1 EUR = 1.05 USD (або інші важливі актуальні співвідношення значень). Також слід запросити модель надати відповідь у структурованому вигляді, наприклад в форматі JSON. Як приклад, до моделі LLM по кожному оголошенню нами надсилається такий запит:
url = "http://localhost:1234/v1/chat/completions"
headers = {"Content-Type": "application/json"}
data = {
"messages": [
{"role": "system",
"content": "You are a helpful assistant analyst. 100 соток = 1 га. 1 USD = 42 UAH. 1 EUR = 1.05 USD"},
{"role": "user",
"content": "I want You to give formatted and calculated data without explanation, without notes, without comments. Please provide the responce always in the single plain JSON object. The JSON responce must include: {Продаж чи оренда, Кадастрові номери, Кількість ділянок, Чи це пай, Призначення, Загальна площа (га), Загальна площа (соток), Повна ціна USD, Ціна USD/га, Повна ціна UAH, Ціна UAH/га}. " + formatted_text}
],
"temperature": 0.0,
"max_tokens": 2000,
"stream": False
}
response = requests.post(url, headers=headers, data=json.dumps(data))
Тут: url – адреса, на якій піднято модель, data – запит до моделі, response – відповідь моделі. В цьому запиті доцільно також встановити параметр моделі “температура” = 0.0 (можливі значення від 0 до 1), аби модель поменше імпровізувала чи “вигадувала”.
Звертаємо увагу на те, що є різні методи “примусити” модель надавати структуровану відповідь. Ми зупинились на такому запиті: “Please provide the responce always in the single plain JSON object. The JSON responce must include: {Продаж чи оренда, Кадастрові номери, Кількість ділянок, Чи це пай, Призначення, Загальна площа (га), Загальна площа (соток), Повна ціна USD, Ціна USD/га, Повна ціна UAH, Ціна UAH/га}”. З часом можливо вдасться покращити цей підхід.
Часто на виході модель намагається надати нотатки, пояснення чи коментарі до згенерованої нею JSON-відповіді, що варто врахувати при парсингу відповіді моделі. В результаті роботи запиту модель може надати наступну відповідь, як приклад:
{
"Продаж чи оренда": "Продаж",
"Кадастрові номери": ['XXXXX', 'XXXXX'],
"Кількість ділянок": 2,
"Чи це пай": False,
"Призначення": "Житлова і суспільна забудова",
"Загальна площа (га)": 0.16,
"Загальна площа (соток)": 16,
"Повна ціна USD": 27000,
"Ціна USD/га": 168750,
"Повна ціна UAH": 1134000,
"Ціна UAH/га": 7087500
}
На даний момент зібрано і проаналізовано понад 20 тисяч оголошень. Попередній аналіз показав, що в результаті застосування локальної LLM вдалось досягти радикального покращення якості даних про ціни та площі виставлених на продаж земельних ділянок. Частка помилок самої LLM є незначною та іноді може бути виправлена додатковими sql-запитами. В основному LLM помиляється в математичних розрахунках, але це як правило легко виявити шляхом додаткових перевірок і співставлень. Проте, якщо в оголошенні містяться критичні неспівпадіння, що й людині їх важко буде зрозуміти, то LLM тут безсильна.
В цій задачі ми експериментували із різними моделями з набором параметрів 7B-14B (gemma2 9B, qwen2.5 14B, phi4 14B та інші). Найбільш послідовною та надійною в цій задачі, на наш погляд, виявилась мовна модель phi-4 14B, зокрема її квантована версія Q4_K_M. Вибір моделей в нашому випадку обмежувався наявною відеокартою RTX3060 із відеопам’яттю 12GB. Тому всі апробовані моделі мали розмір менше 12GB аби їх можна було завантажити в цю відеокарту. Одне оголошення обробляється моделлю phi-4 14B на цій відеокарті близько 6 секунд, що на нашу думку є прийнятними втратами часу для отримання якісних результатів.
Останнім часом можливості локальних невеликих LLM стрімко покращується, що відкриває нові якісні можливості для автоматизованого збору та аналізу даних. При цьому вони можуть бути корисними також і для подальшого аналізу отриманих даних, зокрема виявлення неочевидних тенденцій та закономірностей, опису одержаних результатів аналізу.
Залишити відповідь