Як ми прискорили чистку семантичного ядра в 5 разів і покращили її якість за допомогою LLM

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

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

Чому ручна чистка семантики не масштабується на великих проєктах

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

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

Для якісної SEO-оптимізації всі запити семантичного ядра мають бути релевантні для сайту та конкретної категорії, для якої воно зібране. Перевірка і чистка такого обсягу вручну створюють значне навантаження на команду та є рутинною задачею.

Наш типовий процес чистки виглядав так до введення в нього LLM:

• видалення запитів з нульовою частотністю і неявних дублів;

• чистка по SERP на основі масового парсингу видачі;

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

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

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

Як LLM пришвидшує чистку і покращує якість

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

• інформаційні запити;

• запити конкурентів;

• сміття;

• запити з локаціями окупованих територій;

• інше.

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

Як написати промпт для чистки семантики

Простий запит на кшталт «Прибери нерелевантну семантику для категорії [Назва категорії]» дасть значно гірший результат, ніж детальний з прикладами. Особливо це відчутно на дешевших моделях, бо без чітких інструкцій модель не розуміє межі між релевантними і нерелевантними запитами і помиляється.

З нашого досвіду, хороший промпт для чистки семантики має містити:

1. Роль і контекст — сучасні моделі не потребують складного role prompting, але одне речення про роль і контекст може покращити результат.

2. Патерни з прикладами — для кожного типу нерелевантних запитів описати патерн і дати конкретні приклади. Наприклад: інформаційні запити: «що таке», поради, курси; запити з брендами конкурентів; запити з забороненими локаціями.

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

4. Статус «Під питанням» — дозволяємо моделі позначити невпевненість замість помилкової класифікації.

5. Чіткий формат відповіді — явно вказати, що на виході очікується JSON без пояснень і без обгортки в ```json```.

Як покращити промпт на основі даних

Написати запит ідеально з першого разу дуже складно. Ми використовуємо такий підхід:

1. Готуємо промпт.

2. Пробиваємо вибірку в 1000 фраз і дивимося на результати.

3. Аналізуємо, де модель помилилася, і визначаємо патерни помилок.

4. Покращуємо промпт на основі цих даних.

5. Повторюємо.

Кілька таких ітерацій можуть дати суттєве покращення якості.

Технічна складова: створення скрипту

Для автоматизації чистки ми написали Python-скрипт, який бере список ключових слів з TXT-файлу, відправляє їх до LLM через OpenRouter (сайт-агрегатор доступу до API різних LLM-систем за одним ключем) і зберігає результати у CSV. Для роботи з різними моделями використовуємо OpenRouter: єдиний API-ключ, який дає доступ до тисяч різних LLM-моделей без необхідності підключати кожну окремо.

Кілька важливих налаштувань які безпосередньо впливають на якість і вартість:

• 10 паралельних потоків — скрипт працює асинхронно, що прискорює обробку великих обсягів. За потреби це легко масштабується;

• батчі (партії запитів) по 50–200 штук — якщо відправляти більше, модель починає «галюцинувати» і втрачати якість відповідей;

• temperature = 0 — знижує креативність моделі, що критично для задач класифікації. Чим менше імпровізації, тим стабільніший результат;

• retry з трьома спробами — скрипт автоматично повторює запити при помилках, а також підтримує режими --continue і --retry, тож можна безпечно зупинити обробку і продовжити з того місця де зупинились;

• вбудований підрахунок вартості — після кожного батчу видно, скільки токенів витрачено і скільки це коштує в доларах.

Інсайт про провайдерів

Для деяких моделей вартість токенів може суттєво відрізнятися залежно від провайдера, через якого проходить запит. Наприклад, для DeepSeek V3.2 ціна output токенів у різних провайдерів на момент написання статті відрізняється в 4,5 рази:

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

Повний вивід vs економія на токенах

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

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

Другий — LLM повертає лише нерелевантні ключові слова, а під час постобробки Python-скрипт автоматично присвоює статус «релевантно» всім ключам, яких немає у відповіді моделі. Такий підхід дозволяє заощадити до 30–40% бюджету на токенах. Але є ризик: якщо модель випадково пропустила нерелевантний ключ і не повернула його, він автоматично отримає статус «релевантно» і залишиться в ядрі.

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

Від чого залежить бюджет на LLM-чистку 

Вартість обробки семантики через LLM не фіксована, вона залежить від кількох факторів які варто врахувати ще на етапі планування:

1. Обрана модель і тарифи провайдерів, через яких вона роутиться — як ми показали вище на прикладі DeepSeek V3.2, різниця між провайдерами може бути в 4,5 раза.

2. Обсяг промпту — чим детальніший і чим більше містить прикладів, тим більше вхідних токенів ви витрачаєте на кожен батч.

3. Обсяг і формат вихідних даних — якщо ви просите модель повертати всі ключові слова з мітками, вихідних токенів буде значно більше, ніж при поверненні лише нерелевантних. А вихідні токени, як правило, дорожчі за вхідні.

4. Розмір батчів — менші батчі дають кращу якість, але збільшують кількість запитів і, відповідно, загальну вартість через повторення системного промпту в кожному запиті.

5. Використання кешу — деякі моделі підтримують кешування вхідних токенів, що дозволяє знизити вартість повторних запитів з однаковим промптом.

Яку модель обрати і на що звертати увагу

Ми протестували 7 варіантів на вибірці з 5000 ключових слів для однієї ніші з одним промптом. Серед них 1400 нерелевантних, від очевидних випадків до складних edge cases. Всі результати перевірили вручну SEO-спеціалісти. Для оцінки використовували два показники якості:

1. Якість загальна — скільки фраз з 5000 модель класифікувала правильно;

2. Якість по нерелевантних — скільки нерелевантних фраз з 1400 модель виявила.

Також фіксували два типи помилок: коли LLM позначає релевантну фразу як нерелевантну і коли пропускає нерелевантну фразу.

Якщо пріоритет — максимальна якість і ціна не критична, Gemma-4-26b показала найкращі результати за обома показниками. Єдиний мінус: швидкість, 779 секунд проти 90 у найшвидшої моделі. При великих обсягах це суттєво.

Коли потрібен баланс між якістю, швидкістю і вартістю, Gemini-2.0-Flash виглядає оптимальним вибором. Найшвидша модель в тесті, найменше хибних відхилень (9), і при цьому найдешевша разом з Gemma.

DeepSeek-V3.2, попри гарний загальний показник, пропустила найбільше нерелевантних фраз (161), і це при тому, що є однією з найповільніших.

GPT-5.4-Mini і GPT-5.4-Nano при вищій вартості — $0,49 і $0,14 відповідно — не показали кращого результату, ніж Gemini-2.0-Flash за $0,05.

Claude Haiku 4.5 — найдорожча модель в тесті ($0,73) з середніми показниками якості.

Qwen3.5-Flash — найдешевше рішення ($0,03), але має найбільше хибних відхилень (208 релевантних фраз позначила як нерелевантні).

Окремо варто зазначити, що використання топових моделей для масової класифікації семантики економічно невиправдане. Claude Sonnet 4.6 і GPT-5.4 коштуватимуть $2,40 і $2,33 відповідно за обробку 5000 фраз, це в 35 разів дорожче, ніж Gemini-2.0-Flash за $0,067.

Результати та яка роль junior-спеціаліста в новому процесі

До введення LLM процес чистки семантичного ядра займав від 5 до 10 годин. Після — 1–2 години. 

Основне завдання — перевірка якості LLM-чистки. Junior-спеціаліст переглядає запити, які модель позначила як нерелевантні, звертає особливу увагу на статус «під питанням» і перевіряє, чи немає серед нерелевантних запитів тих, що модель класифікувала помилково. Це значно менш виснажлива робота ніж ручна чистка з нуля. Концентрація не падає, а якість перевірки вища.

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

Висновки

1. Чистка семантики на великих проєктах є значним викликом для команди.

2. Python-скрипт через OpenRouter дозволяє автоматизувати чистку і прискорити обробку великих обсягів.

3. Для роботи зі скриптом найважливіше обрати модель, а також правильно налаштувати розмір батчів, температуру і провайдерів: різниця у вартості між провайдерами для однієї моделі може досягати 4,5 раза.

4. Якість LLM-чистки напряму залежить від якості промпту: детальні патерни з прикладами і блок неочевидних випадків дають значно кращий результат, ніж простий запит.

5. З протестованих моделей Gemini-2.0-Flash показала найкращий баланс між якістю, швидкістю і вартістю. Gemma-4-26b — найкращий результат, але повільніша.

6. Junior-фахівець в новому процесі фокусується на перевірці результатів LLM замість ручної чистки. Це менш виснажлива робота і вища якість перевірки.