Lamoda ускорила обработку данных Spark вдвое, заменив Python-скрипты LLM-разметкой

Дата-инженер Lamoda Tech Дмитрий Иванов описал, как команда пришла к «llm_markup», Spark-приложению для массовой разметки текстов через вызовы к LLM API. Проблема знакомая: пока записей мало, хватает Python-скрипта, но на десятках тысяч строк нужны батчинг (объединение строк в пакеты для отправки одним запросом), параллельная отправка, контроль нагрузки на API, повторы при сбоях и сопоставление ответов с исходными данными. Всё это «llm_markup» берёт на себя, а бизнес-логику задаёт конфигурация: источник данных, промпт, формат ответа, лимиты и целевая таблица.

Какие задачи решили в Lamoda?

Два реальных сценария из e-commerce.

• Оценка качества поиска. В fashion-каталоге запросы бывают от «летнее платье» до «adidas rhjccjdrb» (это «adidas кроссовки» в неправильной раскладке клавиатуры). Модели нужно восстановить смысл запроса и определить, насколько каждый товар ему соответствует.
• Классификация негативных отзывов. Другая бизнес-задача, но та же инженерная механика: подать текст, получить метку из заданного словаря.

Оба сценария показали, что общую часть пайплайна (pipeline, последовательность шагов обработки данных) можно отделить от бизнес-логики и переиспользовать. Так и появился универсальный инструмент, в коде которого нет понятий «товар» или «отзыв».

Почему именно Spark, а не простой скрипт?

Вопрос напрашивается: зачем Spark для HTTP-вызовов, если можно написать скрипт на Python с «asyncio»? Команда Lamoda выделяет четыре причины.

• Объёмы. Десятки тысяч строк за один прогон требуют управляемого параллелизма и восстановления после сбоев.
• Источники данных. Инструмент читает из Hive, Feature Storage на HDFS (распределённая файловая система Hadoop) и внешних баз по JDBC. Spark работает с ними в уже настроенном контуре безопасности.
• Оркестрация. Airflow (планировщик задач, который управляет расписанием и зависимостями) уже запускает Spark-приложения. Отдельный сервис для LLM-батчей означал бы ещё один деплой и мониторинг.
• Распределённое исполнение. Spark параллельно выполняет задачи на «executor-ах» (исполняющих узлах) и собирает результат в DataFrame (табличную структуру данных).

Главная идея: Spark используется как распределённый движок для сетевого ввода-вывода, а не только для классических ETL-вычислений (извлечение, преобразование, загрузка данных). Партиции данных независимо обращаются к LLM API, результаты возвращаются в DataFrame.

Что понадобится

• Apache Spark с поддержкой «mapInPandas» (Spark 3.0+)
• Airflow для оркестрации DAG-ов (направленных графов задач)
• Доступ к LLM API (OpenAI-совместимый эндпоинт или аналог)
• Хранилище данных: Hive, HDFS или внешняя база по JDBC
• Python с библиотеками pandas, Jinja2, requests
• Конфигурационный файл: источник, промпт, формат ответа, лимиты, целевая таблица
• Время на первый запуск: по опыту Lamoda, настройка нового сценария не требует изменений в общем Spark-коде

Пошаговая инструкция

1. Подготовьте источник данных. Укажите в конфигурации, откуда читать: таблица Hive, файл на HDFS или внешняя база. Spark прочитает данные в DataFrame.

2. Опишите промпт. Задайте текстовую колонку или Jinja2-шаблон, который соберётся из нескольких колонок DataFrame. Шаблон позволяет передать модели контекст, например название товара и текст запроса одновременно.

3. Настройте батчинг. Если тексты короткие, несколько строк можно отправить в одном LLM-запросе, это сократит долю токенов (единиц текста, которые оплачиваются при вызове модели), уходящих на повторяющиеся инструкции. Для длинных уникальных промптов используйте batch_size=1 и масштабируйте через количество Spark-партиций.

# Пример параметров конфигурации
source: hive_table_name
prompt_template: "templates/search_quality.j2"
batch_size: 5
target_table: results_search_quality
rate_limit: 100  # запросов в минуту

1. Задайте формат ответа. На выходе «llm_markup» может вернуть метки из заданного словаря или типизированные данные по декларативной схеме. Оба варианта используют общий механизм обработки.

2. Запустите через Airflow. Spark-приложение запускается как задача в DAG-е. Конфигурация передаётся executor-ам как broadcast-переменная (копия только для чтения, которую Spark рассылает на исполняющие узлы).

3. Проверьте результат. Итоговая статистика собирается на driver-е (управляющем узле). Результат записывается в целевую таблицу и доступен для BI-дашбордов.

Что с этого вам?

Авторам Дзена и копирайтерам. Если вы пишете о товарах или собираете отзывы, принцип тот же: массовая разметка текстов через LLM экономит часы ручной работы. Даже без Spark можно взять идею батчинга и промпт-шаблонов для своих задач с GPT или YandexGPT.

Маркетологам в e-commerce. Классификация отзывов и оценка поисковой выдачи напрямую влияют на конверсию. Кейс Lamoda показывает, что задачу можно решить внутри существующей инфраструктуры, без отдельного ML-сервиса.

Дата-инженерам и предпринимателям в РФ. Подход работает с любым OpenAI-совместимым API. Из доступных в России LLM: YandexGPT, GigaChat. Если у вас уже есть Spark и Airflow, добавить LLM-звено можно без перестройки пайплайна.

Подход Lamoda показывает простую вещь: LLM не обязательно требует нового сервиса, если у вас уже есть распределённый движок. Промпт, конфиг, целевая таблица, и десятки тысяч строк размечены к утру.