Вы спрашиваете у Claude 3.7 Opus: «Почему мой Spark job работает 4 часа? Даю тебе метрики из Spark UI». И получаете в ответ универсальный список из десяти пунктов: проверьте spark.sql.shuffle.partitions, увеличьте память executor'ов, используйте broadcast join. Знакомо?
Это не ошибка конкретной модели. Это системная проблема всех LLM на февраль 2026 года – от GPT-4.5 Turbo до локальных Mixtral 8x22B. Они блестяще генерируют общие советы, но пасуют перед конкретными метриками вашего кластера. Почему? И что с этим делать?
Почему ваш ИИ-инженер не читает Spark UI
Представьте, что вы просите врача поставить диагноз по общему описанию «болит живот». Он даст общие рекомендации. Но если вы дадите ему результаты конкретных анализов – картина изменится. LLM находятся на этапе «общего описания».
Ключевая проблема: LLM тренировались на документации, статьях, обсуждениях на Stack Overflow. Но не на реальных логах Spark UI, не на специфичных метриках вашего продакшена. У них нет контекста вашей конкретной боли.
Когда вы говорите «высокий spill на диске», модель знает, что это плохо. Но она не знает, что в вашем случае это 2 ТБ при 10 ТБ памяти, а не 50 ГБ при 512 ГБ. Разница принципиальная.
Три уровня бесполезности LLM-советов по Spark
Проведите эксперимент. Задайте любой современной LLM (DeepSeek-R1, Command R+, даже специализированным моделям для кода) вопрос про настройку Spark. Ответы будут на трёх уровнях:
- Уровень 1: Документационный мусор. Пересказ официальной документации Spark 3.5 (последняя стабильная на февраль 2026). Без адаптации к вашей версии, без учёта вашего кластера.
- Уровень 2: Статистически вероятные советы. «Увеличьте
spark.executor.memory». Потому что в 70% вопросов на Stack Overflow этот совет помог. А в вашем случае память и так простаивает. - Уровень 3: Красивые, но бесполезные обобщения. «Проанализируйте skew в данных». Спасибо, Кэп. А как именно – непонятно.
Парадокс: чем умнее модель (взгляните на LLM-судью для оценки моделей), тем увереннее она даёт общие советы. GPT-4.5 звучит убедительнее, чем GPT-4. Но суть та же.
Метрики, которые LLM игнорирует (и как их подать)
Вот конкретные метрики из Spark UI, которые вы показываете модели, а она делает вид, что не видит:
| Метрика | Что видит LLM | Что нужно видеть |
|---|---|---|
| GC time 45% | «Много GC» | Конкретный паттерн: частые young GC при малом heap, или редкие full GC при переполнении |
| Skew factor 15.7 | «Есть skew» | Конкретные ключи, вызывающие skew, и их распределение |
| Spill (Memory) 1.2 TB | «Много spill» | Какие операции spill вызывают, соотношение spill к shuffle |
Проблема не в том, что модели глупые. Проблема в формате подачи информации. Вы даёте сырые цифры. А нужно давать структурированный контекст.
RAG для кода: не для документации, а для метрик
Стандартный Retrieval-Augmented Generation (RAG) обычно настраивают на документацию. Вы ищете похожие проблемы в мануалах. Но для Spark это не работает.
Нужен RAG для метрик и логов. Вот как это выглядит на практике:
1 Собираем историю инцидентов
Не статьи, не документацию. А реальные инциденты из вашего продакшена: логи Spark UI, конфигурации, фиксы. Как это делает Zalando для анализа постмортемов (читайте их опыт).
2 Структурируем метрики в семантический пайплайн
Превращаем сырые метрики в векторы, которые модель сможет сравнивать. Здесь поможет семантический пайплайн для LLM.
3 Учим модель читать контекст
Даём не просто «GC time 45%», а: «Воркер на i3en.6xlarge, 192 ГБ RAM, heap 120 ГБ, young GC каждые 2 секунды, full GC раз в час». Это уже диагностическая картина.
Что не сработает (чтобы вы не теряли время)
Популярные, но бесполезные подходы:
- Тонкая настройка промптов. Можно потратить неделю на коллекцию промптов для тестирования LLM. Но если в контексте нет специфичных данных по Spark – результат будет общим.
- Смена модели. Переход с GPT-4.5 на Claude 3.7 или на локальную модель через кластеризацию LLM не решит проблему. Все модели страдают от одного: отсутствия вашего контекста.
- Добавление документации в контекст. 100К токенов документации Spark – и модель будет пересказывать её, а не анализировать ваши метрики.
Будущее: LLM как инженер по данным, а не как справочник
К концу 2026 года мы увидим специализированные модели, обученные не на общих текстах, а на:
- Логах Spark UI с десятков тысяч продакшен-кластеров
- Историях инцидентов и их фиксах
- Корреляциях между метриками и перфомансом
Такая модель не скажет «увеличьте память». Она скажет: «В вашем случае на аналогичных кластерах при skew factor >10 помогал salted join с 256 партициями. Вот статистика успешных фиксов».
Пока таких моделей нет. Но вы можете начать строить их контекст уже сегодня. Собирайте метрики. Записывайте, что помогло. Стройте свою базу знаний. Потому что даже самая умная LLM в 2026 году – всего лишь инструмент. А контекст – это ваше конкурентное преимущество.
И да, если ваш ИИ советует увеличить spark.sql.shuffle.partitions без анализа skew – отправьте его читать эту статью сначала.
