В популярных ML-библиотеках часто бывают проблемы с качеством кода. В Transformers не прописаны тайпинги, Sklearn падает при большом количестве ядер, а в сурсы vLLM вообще страшно смотреть. Иногда это приправлено ещё и весьма специфичным синтаксисом, например, как у torch.einsum().
Поэтому в большинстве случаев не получается использовать линтеры. Или их нужно кастомизировать, чтобы они нормально работали с ML-проектами.
В классической разработке можно сделать MVP и затем постепенно улучшать его, не переписывая весь код. В ML всё работает немного иначе: часть экспериментов требуют лишь поиграться с гиперпараметрами или конфигурациями.
Но иногда подход к обучению модели не оправдывает себя целиком. Тогда приходится, например, задачу seq2seq переформулировать как NER — это тянет за собой всю архитектуру проекта, практически снося предыдущие наработки.
Так нужно ли качественно оформлять короткоживущий код?
Обычно проблему решают ведением двух репозиториев:
👾 Для экспериментов.
👾 Для продакшена, который потом интегрируется с бэкендом.
В репозитории с экспериментами качество кода может быть ниже, но важно, чтобы он оставался понятным для всех членов команды.
Как упростить работу с кодом?
Есть конструкторы для LLM (LangChain, LlamaIndex), которые упрощают работу с языковыми моделями, позволяя из готовых «кубиков» собрать работающую RAG-систему, и не только. Однако за простотой использования кроются проблемы, которые обязательно вылезут при масштабировании.
В чём минусы таких конструкторов, а также какой стек технологий должен знать современный ML-инженер, обсудили в подкасте «PiterPy и IML» с нашей Data-scientist Лизой Афанасьевой.
Смотрите полный выпуск на YouTube или в VK Видео.