Как мы ускорили очистку семантического ядра в 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-очистки. Младший специалист просматривает запросы, которые модель обозначила как нерелевантные, обращает особое внимание на статус «под вопросом» и проверяет, нет ли среди нерелевантных запросов тех, которые модель классифицировала ошибочно. Это значительно менее изнурительная работа, чем ручная очистка с нуля. Концентрация не падает, а качество проверки выше.

Важно понимать, что результат работы LLM напрямую зависит от промпта, а промпт формирует и улучшает именно специалист. Если логика классификации заложена неправильно, LLM лишь масштабирует эту ошибку на весь объем семантики.

Выводы

1. Очистка семантики на крупных проектах является серьезным вызовом для команды.

2. Python-скрипт через OpenRouter позволяет автоматизировать очистку и ускорить обработку больших объемов.

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

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

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

6. Младший специалист в новом процессе фокусируется на проверке результатов LLM вместо ручной очистки. Это менее утомительная работа и более высокое качество проверки.