Всем привет! Меня зовут Шубин Вадим, я Data Scientist в компании Raft. В этой статье я хотел бы рассказать о нашем опыте с фейл-сабмитом в существующий Open Source проект Axolotl и о том, какие уроки из него мы извлекли. Но обо всём по порядку. Давайте начнем!
Завязка
В компании мы занимаемся различной интеграцией ИИ в бизнес процессы, а один из векторов R’n’D направления - это исследование локальных LLM:
В какой-то момент времени исследуя локальные модели, мы поняли, что из коробки они часто показывают плохое качество и решили эти самые модели дообучать (файтюнить) на кастомных клиентских данных.
Поскольку структура LLM сложная, то и дообучать ее нужно с умом (иначе после дообучения будет хуже, чем было до). На старте деятельности с поиском фреймворка у нас уже было несколько своих нароботок по файнтьюнингу, но до воссоединения их в красивый фреймворк требовалась качественная доработка. Поэтому мы с командой решили посмотреть, что есть из готовых (опенсорсных) решений для файнтьюнинга.
Развитие
Почти сразу я обнаружил Axolotl, популярный Open Source фреймворк для дообучения LLM, который привлек моё внимание благодаря своей гибкости и возможностям масштабирования (еще у них очень убедительный гит и проект выглядит достаточно живым). Я решил провести с ним серию экспериментов и сравнить его с нашим собственным фреймворком, чтобы определить какое решение более качественное по метрикам, быстрое по скорости дообучения и удобное для пользователя.
Всю методологию сравнения раскрывать не буду, но метрики замерялись на внутренних бенчмарках компании, которые снимались с “ванильной” модели из коробки и с моделью после файнтьюнинга.
Ниже пример метрики качества ванильной ламы из коробки, ламы после нашего дообучения, и ламы после дообучения на Axolotl.
В этом конкретном примере, лучше себя показал наш фреймворк, но результаты не всегда были такие хорошие. Поскольку есть ряд факторов, влияющих на итог. Большую роль играют данные для дообучения и их тип.
Кульминация
Как раз формат данных и стал местом преткновения. Данные для экспериментов по умолчанию хранились в формате CSV, что было удобным для нас.
Однако, чтобы интегрировать их с Axolot и запустить дообучениe, потребовалось преобразовать их в специфический формат JSONL. Для меня это создало новые неудобства, так как потребовалась написать дополнительную обработку данных перед их загрузкой в фреймворк.
В документации и примерах использования проекта упоминался только формат JSONL, из чего я пришел к выводу, что фреймворк работает исключительно с ним.
Реализовав функционал обработки данных из CSV в JSONL для наших пайплайнов, я решил поделиться этим с миром и засабмитить поддержку для CSV в Axolotl.
Развязка
После того как я отправил pull request в репозиторий Axolotl, я ожидал, что работа будет принята и добавит полезную фичу для всех пользователей фреймворка.
Вскоре я получил ответ от разработчиков, в котором мне сообщили, что функциональность для работы с CSV и другими форматами данных уже была реализована. Мне указали на файл, в котором была указана информация о поддержке реализованного мной формата, но описывалась она в одном единственном комментарии. И мой pull request не приняли.
Для меня это было разочарованием: было потрачено время на разработку и тестирование функционала, который оказался попросту ненужным.
НО!
После общения с одним из разработчиков Axolotl, мне пообещали, что они с командой вскоре улучшат документирование своего проекта. Возможно, что страдания старания не оказались полностью напрасны)
Выводы
Мой опыт с проектом Axolotl стал для меня важным уроком о том, как правильно организовывать документацию в своих проектах и какие последствия может иметь ее отсутствие или нестандартная структура. Так же я пересмотрел и дополнил документацию нашего фреймворка, возможно урок судьбы вел нас именно к этому.
Общие выводы напоследок:
Документация должна быть четкой и легко доступной. Важно, чтобы вся критически важная информация, такая как поддерживаемые форматы данных, настройки и примеры, была структурирована и представлена в удобном виде.
Наличие полноценных примеров и инструкций. В идеале документация должна содержать не только технические детали, но и примеры использования, которые помогут пользователям быстрее освоиться с проектом и избежать типичных ошибок.
Не делайте предположений без полного изучения документации. Даже если информация кажется очевидной, важно внимательно изучить весь доступный материал, чтобы избежать лишних усилий на разработку функционала, который уже существует.
А у вас был подобный опыт? Делитесь в комментариях!