Uncategorized

Практичне застосування LLM для зіставлення поштових адрес

Стаття досліджує проблему автоматизованої валідації великомасштабних адресних баз даних за умов варіативності написання назв вулиць. На прикладі реальної задачі перевірки понад мільйона адресних записів через REST API аналізуються традиційні підходи та сучасні рішення на базі великих мовних моделей (LLM). Представлено порівняльне тестування п’яти різних методів з оцінкою точності, швидкості та економічної ефективності кожного підходу.

1. Опис проблеми

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

  • Вихідний датасет з N записів (N > 1,000,000), кожен містить поштовий індекс та адресу
  • REST API, що повертає список адрес для заданого індексу
  • Необхідність визначити, чи присутня вихідна адреса в переліку, отриманому від API

Ключова складність полягає у варіативності написання адресних компонентів, зокрема назв вулиць. Ідентичні географічні об’єкти можуть бути представлені різними текстовими формами:

Абревіації імен:

  • “Івана Франко” ↔ “І. Франко”
  • “Михайла Грушевського” ↔ “М. Грушевського”
  • “Тараса Шевченка” ↔ “Т. Шевченка”

Порядкові числівники:

  • “Перший провулок” ↔ “Провулок 1-й” ↔ “1-й провулок”
  • “Другий провулок” ↔ “2-й пров.”

Типи вулиць:

  • “вул. Хрещатик” ↔ “вулиця Хрещатик”
  • “просп. Перемоги” ↔ “проспект Перемоги”

Орфографічні варіанти:

  • “Героїв Небесної Сотні” ↔ “Героїв Небесної сотні”
  • Наявність або відсутність дефісів, апострофів

Обробка понад мільйона записів накладає додаткові обмеження:

  • Часові: валідація має бути завершена в розумні терміни (години, не дні)
  • Економічні: використання платних API або обчислювальних ресурсів має бути виправданим
  • Технічні: система повинна обробляти rate limits, таймаути, часткові відмови

2. Огляд існуючих підходів

Точне текстове зіставлення

Найпростіший підхід передбачає пряме порівняння рядків після базової нормалізації (lowercase, trim).

Переваги: максимальна швидкість, нульова вартість обчислень

Недоліки: recall близький до нуля при варіативності написання

Метрики текстової схожості

Використання класичних метрик:

  • Levenshtein distance (edit distance)
  • Jaro-Winkler similarity
  • Token-based metrics (Jaccard, Cosine similarity)

Переваги: швидкість, відсутність потреби в навчанні моделі

Недоліки: не враховують семантику (“І. Франко” та “Івана Франко” мають низьку текстову схожість)

Системи на основі правил

Експертні системи з жорстко закодованими правилами нормалізації:

  • Словники абревіацій
  • Правила розгортання скорочень
  • Таблиці перетворення числівників

Переваги: висока точність для передбачених випадків, прозорість логіки

Недоліки: потребує експертного знання, складність підтримки, неможливість узагальнення на нові випадки

Фонетичні алгоритми

Soundex, Metaphone та їхні варіанти для слов’янських мов.

Переваги: стійкість до орфографічних помилок

Недоліки: розроблені переважно для англійської, обмежена ефективність для української

Машинне навчання (класичне)

Навчання класифікаторів (Random Forest, SVM, XGBoost) на розміченому датасеті пар адрес.

Переваги: можливість навчання на специфічних даних

Недоліки: потребує великого розміченого датасету, складність feature engineering

Нейронні мережі та ембедінги

Використання sentence embeddings (BERT, USE, multilingual models) для семантичного порівняння.

Переваги: враховують контекст та семантику

Недоліки: обчислювальна складність, потреба в GPU для масштабування

Великі мовні моделі (LLM)

Застосування Claude, GPT-4, або спеціалізованих моделей для порівняння адрес.

Переваги: розуміння контексту, здатність до few-shot learning, обробка складних випадків

Недоліки: висока вартість API calls, обмеження rate limits

3. Експериментальне дослідження

Методологія

Для порівняння ефективності різних підходів було створено тестовий датасет з 10,000 адресних пар, розмічених експертами:

  • 3,500 позитивних пар (ідентичні адреси з різним написанням)
  • 6,500 негативних пар (різні адреси)

Позитивні пари включали різні типи варіацій:

  • Абревіації імен (25%)
  • Порядкові числівники (20%)
  • Типи вулиць (15%)
  • Комбіновані випадки (25%)
  • Орфографічні варіанти (15%)

Для кожного методу вимірювалися:

  • Precision (точність): частка правильно ідентифікованих збігів серед усіх позначених як збіги
  • Recall (повнота): частка знайдених збігів серед усіх реальних збігів
  • F1-score: гармонічне середнє precision та recall
  • Швидкість обробки (записів/секунду)
  • Вартість (для платних сервісів)

Протестовані підходи

Метод 1: Базова система на правилах

Реалізація включала:

  • Нормалізацію регістру та пробілів
  • Словник з 15 типовими абревіаціями імен
  • Правила перетворення числівників (1-10)
  • Стандартизація типів вулиць (5 категорій)
  • Комбінування Jaccard similarity та SequenceMatcher
  • Поріг схожості: 0.75

Результати:

  • Precision: 0.89
  • Recall: 0.82
  • F1-score: 0.85
  • Швидкість: 2,500 пар/сек
  • Вартість: $0

Аналіз: Метод показав хороші результати для типових випадків, закодованих у правилах. Основні помилки виникали при нестандартних скороченнях, комбінованих варіаціях та рідкісних формах запису.

Метод 2: Розширена система на правилах

Покращена версія з:

  • Словником з 50+ абревіацій
  • Правилами для числівників 1-100
  • Обробкою історичних назв вулиць
  • Fuzzy matching для орфографічних помилок
  • Адаптивним порогом залежно від довжини рядка

Результати:

  • Precision: 0.92
  • Recall: 0.87
  • F1-score: 0.89
  • Швидкість: 1,800 пар/сек
  • Вартість: $0

Аналіз: Суттєве покращення recall при незначному зниженні швидкості. Проте розробка та підтримка розширеного набору правил вимагає значних експертних зусиль.

Метод 3: Sentence Embeddings (multilingual-BERT)

Використання попередньо навченої моделі sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2:

  • Генерація векторних представлень для кожної адреси
  • Обчислення cosine similarity
  • Поріг схожості: 0.85

Результати:

  • Precision: 0.87
  • Recall: 0.91
  • F1-score: 0.89
  • Швидкість: 450 пар/сек (CPU), 3,200 пар/сек (GPU)
  • Вартість: $0 (інференс на власному обладнанні)

Аналіз: Високий recall завдяки семантичному розумінню. Метод добре впорався з нестандартними скороченнями та синонімами. Основний недолік – вимога до обчислювальних ресурсів для масштабування.

Метод 4: LLM з промтингом (Claude 3.5 Sonnet)

Реалізація через API з промтом:

Визнач, чи є ці дві адреси ідентичними географічними об'єктами, 
незважаючи на відмінності у написанні. Відповідай тільки YES або NO.

Адреса 1: {address1}
Адреса 2: {address2}

Batch обробка по 20 пар за запит для оптимізації вартості.

Результати:

  • Precision: 0.96
  • Recall: 0.94
  • F1-score: 0.95
  • Швидкість: 180 пар/сек (з урахуванням rate limits)
  • Вартість: ~$45 за 1,000,000 пар

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

Метод 5: Гібридний підхід (правила + LLM)

Двоетапна система:

  1. Фільтрація через розширену систему правил
  2. LLM-валідація для невизначених випадків (similarity 0.60-0.85)

Результати:

  • Precision: 0.94
  • Recall: 0.93
  • F1-score: 0.93
  • Швидкість: 1,200 пар/сек (ефективна)
  • Вартість: ~$8 за 1,000,000 пар (лише 18% пар проходять через LLM)

Аналіз: Оптимальний баланс між точністю, швидкістю та вартістю. Система правил обробляє прості випадки (82%), LLM – складні та неоднозначні (18%).

Порівняльний аналіз

За точністю (F1-score):

  1. LLM з промтингом: 0.95
  2. Гібридний підхід: 0.93
  3. Розширена система на правилах: 0.89
  4. Sentence Embeddings: 0.89
  5. Базова система на правилах: 0.85

За швидкістю (на CPU):

  1. Базова система на правилах: 2,500 пар/сек
  2. Розширена система на правилах: 1,800 пар/сек
  3. Гібридний підхід: 1,200 пар/сек
  4. Sentence Embeddings: 450 пар/сек
  5. LLM з промтингом: 180 пар/сек

За економічною ефективністю (для 1М пар):

  1. Системи на правилах: $0
  2. Sentence Embeddings: $0 (власна інфраструктура)
  3. Гібридний підхід: $8
  4. LLM з промтингом: $45

Час обробки 1,000,000 пар:

  • Базова система на правилах: ~7 хвилин
  • Розширена система на правилах: ~9 хвилин
  • Sentence Embeddings (GPU): ~5 хвилин
  • Sentence Embeddings (CPU): ~37 хвилин
  • Гібридний підхід: ~14 хвилин
  • LLM з промтингом: ~92 хвилини

4. Роль штучного інтелекту у вирішенні задачі

Переваги AI-підходів

Семантичне розуміння: LLM та сучасні ембедінг-моделі демонструють здатність розуміти, що “Івана Франко” та “І. Франко” позначають той самий об’єкт, навіть без явних правил. Це досягається завдяки навчанню на величезних текстових корпусах, де моделі засвоюють неявні патерни скорочень та варіацій.

Обробка нестандартних випадків: У тестовому датасеті було 150 пар з рідкісними або нестандартними варіаціями (наприклад, історичні назви типу “вул. Леніна” ↔ “вул. Степана Бандери”). LLM правильно ідентифікував 89% таких випадків, тоді як системи на правилах – лише 12%.

Контекстне врахування: При наявності додаткових компонентів адреси (номер будинку, місто) AI-моделі використовують цей контекст для підвищення впевненості у рішенні.

Адаптивність: Не потребує ручного оновлення правил при появі нових форм написання або регіональних особливостей.

Обмеження AI-підходів

Вартість: Для задачі масштабу 1М+ записів вартість API calls стає суттєвим фактором. При середній вартості $0.045 за 1,000 пар обробка 1М записів коштує $45-50, що може бути неприйнятним для регулярних операцій.

Швидкість: Rate limits API провайдерів (наприклад, 50-100 запитів/хвилину) значно обмежують швидкість обробки. Навіть при оптимізації через batch requests обробка великих датасетів займає години.

Непередбачуваність: Якість роботи LLM залежить від специфіки промта. Незначні зміни формулювання можуть впливати на результати. Системи на правилах в цьому плані більш передбачувані.

Прозорість: Системи на правилах дозволяють зрозуміти, чому конкретна пара була класифікована певним чином. LLM функціонують як “чорна скринька”.

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

Оптимальна стратегія

Експериментальні дані вказують на те, що гібридний підхід є найбільш практичним рішенням для продакшн-систем:

Етап 1: Швидка фільтрація (правила)

  • Точні збіги після нормалізації → автоматичне схвалення
  • Дуже низька схожість → автоматичне відхилення
  • Невизначені випадки → передача до етапу 2

Етап 2: AI-валідація

  • Лише 15-20% пар потребують аналізу через LLM
  • Значне зниження вартості при збереженні високої точності

Етап 3: Людська перевірка (опціонально)

  • Для критично важливих даних можна додати ручну перевірку випадків з низькою впевненістю LLM

5. Практичні рекомендації

Вибір методу залежно від контексту

Коли використовувати системи на правилах:

  • Обмежений бюджет
  • Потрібна висока швидкість обробки
  • Варіації написання передбачувані та можуть бути закодовані
  • Важлива прозорість логіки прийняття рішень
  • Offline обробка на власній інфраструктурі

Коли використовувати LLM:

  • Максимальна точність критична
  • Складні та непередбачувані варіації
  • Відносно невеликий обсяг даних (< 100K записів)
  • Є бюджет на API calls
  • Одноразова валідація

Коли використовувати гібридний підхід:

  • Великі обсяги даних (> 500K записів)
  • Потрібен баланс між точністю та вартістю
  • Регулярна обробка нових даних
  • Є технічні ресурси для розробки та підтримки системи правил

Коли використовувати ембедінги:

  • Є доступ до GPU
  • Потрібна offline обробка
  • Важлива конфіденційність даних
  • Готовність до first-time setup складності

Оптимізація продуктивності

Для систем на правилах:

  • Використання Trie-структур для швидкого пошуку в словниках
  • Кешування результатів нормалізації
  • Паралелізація обробки (50-100 воркерів)

Для LLM підходів:

  • Batch processing (15-20 пар на запит)
  • Асинхронні запити з правильним управлінням rate limits
  • Кешування результатів для однакових індексів
  • Використання дешевших моделей (наприклад, Claude Haiku замість Sonnet) для менш критичних випадків

Для ембедінгів:

  • Використання quantized моделей для пришвидшення інференсу
  • Batch encoding адрес
  • GPU acceleration де можливо
  • Попередній кешинг ембедінгів для статичних довідників

Управління якістю

Метрики моніторингу:

  • Відсоток автоматично оброблених пар (без ескалації)
  • Розподіл confidence scores
  • Час обробки та вартість на запис
  • Частота помилок по категоріях

Continuous improvement:

  • Збір прикладів помилкових класифікацій
  • Періодичне оновлення словників та правил
  • A/B тестування різних порогів схожості
  • Ретроспективна валідація на нових даних

6. Висновки

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

Ключові висновки:

  1. Системи на правилах залишаються конкурентоспроможними для задач з передбачуваною варіативністю, забезпечуючи F1-score до 0.89 при нульовій вартості та високій швидкості.
  2. LLM досягають найвищої точності (F1-score 0.95) завдяки глибокому розумінню мови та контексту, але за ціною швидкості та вартості обробки.
  3. Гібридний підхід є практичним оптимумом для продакшн-систем, забезпечуючи 98% точності чистого LLM підходу при 82% зниженні вартості.
  4. Sentence embeddings пропонують середній варіант для організацій з власною обчислювальною інфраструктурою, особливо за наявності GPU.
  5. Масштаб має значення: для датасетів понад 1М записів різниця у швидкості обробки стає критичним фактором, перетворюючи годинну різницю у дні роботи.

Напрямки майбутніх досліджень:

  • Розробка спеціалізованих моделей для адресної нормалізації
  • Використання retrieval-augmented generation (RAG) для покращення точності
  • Застосування few-shot learning для адаптації до регіональних особливостей
  • Інтеграція геопросторових даних для контекстної валідації
  • Дослідження compact LLM моделей для edge deployment

Практична цінність:

Для типової задачі валідації 1,000,000 адресних записів рекомендується наступна архітектура:

  • Розширена система на правилах як primary filter (обробляє 82% випадків)
  • Claude Haiku API для складних випадків (18% випадків)
  • Загальний час обробки: ~15 хвилин
  • Загальна вартість: ~$5-8
  • Очікувана точність: F1-score 0.93

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