README.md

metadata

title: T5 Fine Tuning
emoji: 🏃
colorFrom: yellow
colorTo: green
sdk: streamlit
sdk_version: 1.51.0
app_file: app.py
pinned: false
license: apache-2.0

Welcome to Streamlit!

Edit /src/streamlit_app.py to customize this app to your heart's desire. :heart:

If you have any questions, checkout our documentation and community forums.

AK:

MzM0MDUzOTItMjRhNy00ZGFmLThjODktZTdjMjM2NGRkMDZkOjI0OTQ2ZjhhLTQ3ZWEtNDkxOC1iZmMzLWJlOTVmOGZkOWI3Mg==

0a559e82-c85c-4e4a-b8a1-251da2dae3f4

Ваша задача — оптимизация расстановки логов (уровней ERROR, WARN, INFO, DEBUG, TRACE) в новых Java-методах, с учётом двух противоположных целей:

• качество кода (минимизация ошибок → логирование должно быть информативным и своевременным),
• ресурсоёмкость (минимизация накладных расходов на логирование → избегать избыточного DEBUG/TRACE в production).

Вы рассматриваете два подхода:

1. Эмбеддинг-модель с поиском ближайшего соседа (по аналогии с content-based recommendation),
2. Классификационная модель прямого предсказания уровня логирования.

Ниже — глубокий сравнительный анализ.

---

🔍 1. Сравнительный анализ подходов

Критерий	Вариант 1 (эмбеддинг + nearest neighbor)	Вариант 2 (классификация)
Цель модели	Восстановить полный профиль логирования (включая какие именно уровни и где они стоят) из контекста метода	Предсказать один класс — уровень логирования (или его отсутствие)
Гранулярность	Может учитывать комбинации уровней (например, INFO + WARN + TRACE), если эмбеддинг обучен на полных профилях	Обычно — мультикласс (5+1 уровней), но может быть мульти-label, если логов несколько. Однако: логи в методе — не независимые события, и мульти-label требует специальной архитектуры
Интерпретируемость	Низкая: «метод похож на X» — но почему? — непонятно. Трудно обосновать рекомендацию	Высокая: можно использовать SHAP/LIME для анализа важности признаков (например, audit_required_by_regulation = true → INFO или WARN)
Требования к данным	Высокие: нужен достаточно большой объём методов с полным профилем логирования, иначе эмбеддинги будут размытыми. Эмбеддинг должен кодировать и показатели, и логи — это неочевидно, как сделать корректно (логи — не числовые признаки).	Умеренные: можно использовать стандартные ML-фреймворки (scikit-learn, XGBoost, LightGBM). Целевая переменная — дискретный класс (или токены уровней).
Обучение эмбеддингов	Требует: • архитектуры (например, Siamese, BERT-like, или автоэнкодер), • определения метрики близости между методами (включая логи), • генерации пар/триплетов для обучения. Это — сложная NLP-задача, где метод — «текст» с синтаксисом Java.	Прямая задача: можно использовать классические ML-модели, даже без глубокого обучения.
Ресурсоёмкость обучения	Высокая: обучение эмбеддинг-модели (особенно на 10k+ методов) требует GPU, длительного времени, тонкой настройки.	Низкая/средняя: обучение XGBoost/LightGBM на 10k+ методов — минуты-часы на CPU.
Ресурсоёмкость инференса	Средняя: поиск ближайшего соседа в большой базе (например, FAISS, Annoy) — O(log N) или близко к этому, но требует хранения эмбеддингов.	Очень низкая: предсказание класса — один forward pass (или даже дерево-поиск).
Гибкость и адаптация	Низкая: если распределение логов в новых методах смещено (например, новая политика логирования), эмбеддинг-модель не «понимает» этого без дообучения.	Высокая: можно легко дообучить или перенастроить пороги, добавить правила (например, if audit_required_by_regulation: WARN).
Семантическая точность	Низкая: эмбеддинг может «смешать» методы с разными бизнес-ролями, но похожим логом — и наоборот. Например, методы chargePayment() и refundPayment() могут иметь похожие эмбеддинги, но разные требования к логированию.	Высокая: признаки напрямую связаны с бизнес-важностью, сложностью, аудитом — всё, что влияет на логирование.
Поддержка мульти-уровневого логирования	Возможна, но требует сложной декомпозиции (например, предсказывать вектор из 5 бинарных флагов), и тогда это уже не nearest neighbor, а multi-output regression/classification.	Прямая поддержка через multi-label classification (например, BinaryRelevance, ClassifierChain в scikit-learn).

---

📌 Критический недостаток Варианта 1:

Логи — не признак, а целевая переменная.
Вы хотите предсказать, какие уровни логирования должны быть, а не восстановить их по аналогии.
Эмбеддинг-подход подразумевает, что похожие методы имеют похожие логи — но это не всегда верно:

• Два метода могут быть технически похожи (cyclomatic_complexity=5, num_external_calls=2), но один — chargePayment() (требует INFO + WARN), другой — logDebugMetrics() (требует DEBUG + TRACE).
• Логи определяются бизнес-контекстом, а не только техническими метриками.

Таким образом, эмбеддинг-модель будет обучаться на шуме, а не на истинной зависимости.

---

✅ Вывод:

Вариант 2 (классификация) — значительно более эффективный и практичный подход для вашей задачи.

Он:

• проще в реализации и обучении,
• требует меньше ресурсов (CPU, время, экспертиза),
• даёт интерпретируемые рекомендации,
• лучше учитывает бизнес-правила (например, audit_required_by_regulation = true → INFO или WARN),
• легко адаптируется под политику вашей организации (например, запрет DEBUG в production).

---

🛠 Рекомендуемая реализация Варианта 2

1. Формулировка задачи:

• Целевая переменная:
  • либо один класс (например, log_level = "INFO"),
  • либо множество классов (например, {"INFO", "WARN"}), если в методе может быть несколько уровней.
    → Рекомендуем multi-label classification (например, BinaryRelevance с XGBoost в качестве базового классификатора).

2. Признаки:

Используйте все 4 группы показателей, кроме, возможно,:

• количество ошибок в методе и срок разработки — они постфактум, и недоступны при разработке нового метода.
• количество коммитов по исправлению ошибок — тоже постфактум.
  → Оставьте только предиктивные признаки, доступные до написания кода:
• бизнес-важность (все 11 булевых/float-признаков),
• техническая сложность (все 15 признаков),
• изменчивость (все 11 признаков),
• логирование (все 6 уровней — как целевую переменную).

3. Модели:

• Базовая модель: LightGBM или XGBoost (быстро, точно, интерпретируемо).
• Мульти-лабель: BinaryRelevance, ClassifierChain, или MultiOutputClassifier.
• Альтернатива: RandomForest — для простоты и интерпретируемости (важность признаков через feature_importances_).
• Глубокая модель (если данных много): TabTransformer (из AutoGluon) или DeepFM — но это избыточно для <100k методов.

4. Открытые и свободные модели/библиотеки:

Название	Тип	Ссылка	Примечание
scikit-learn	ML-библиотека	https://scikit-learn.org	MultiOutputClassifier, BinaryRelevance, XGBClassifier (через xgboost), SHAP для интерпретации
XGBoost / LightGBM	Градиентный бустинг	https://xgboost.ai / https://lightgbm.readthedocs.io	Лучший выбор для табличных данных
AutoGluon	AutoML	https://github.com/autogluon/autogluon	Поддерживает multi-label classification, работает с pandas.DataFrame
H2O.ai Driverless AI (open source)	AutoML	https://github.com/h2oai/h2o-3	Можно использовать для baseline
SHAP	Интерпретация	https://github.com/shap/shap	Для анализа решений модели (важно для экспертов)

5. Дополнительные рекомендации:

• Создайте rules-based baseline (например, если audit_required_by_regulation = true → INFO, если error_log_mentions > 3 → WARN, и т.д.). Это даст вам нижнюю границу качества.
• Проведите A/B-тест: внедрите рекомендации модели в одном модуле, сравните количество багов и объём логов с контрольным модулем.
• Добавьте фильтрацию по окружению: DEBUG/TRACE — только в dev/test, INFO/WARN — в prod. Это можно закодировать в постпроцессинге рекомендаций.

---

📊 Пример метрики качества:

• Primary: F1-macro (если классы несбалансированы — INFO встречается чаще, чем TRACE).
• Secondary:
  • log_volume_reduction % (сравнение объёма логов до/после внедрения),
  • error_detection_rate (сколько ошибок было бы обнаружено при текущем логировании vs. рекомендованном).

---

✅ Итоговая рекомендация:

Выберите Вариант 2 (классификация).
Используйте LightGBM + MultiOutputClassifier (BinaryRelevance) на всех предиктивных признаках из вашей базы.
Это — быстро, точно, дешево и интерпретируемо, и вы получите реализуемый в production инструмент для рекомендаций логирования.

Если нужно — могу помочь с:

• проектированием pipeline обучения (Python + pandas + LightGBM),
• кодом для генерации признаков из AST Java-методов (например, через javaparser),
• примером multi-label classification с SHAP.