#dl #llm #papers

#llm #audio

Как LLM научились слышать?

В одной из предыдущих статей мы разобрали, какие подходы научили LLM понимать изображения и 3D-сцены.

В новой статье мы поговорим о добавлении в LLM новой модальности — аудио. От идеи представления звука мел-спектрограммой до генерации музыки по текстовому описанию.

А бонусом станет краткий разбор анализа видео с помощью LLM — задачи, где нужно синхронизировать визуальные и аудиодорожки.

Читайте новую статью по ссылке!

RAG — от первой версии к рабочему решению

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

В новой статье пошагово разбираем каждый компонент RAG-системы, объясняем типичные ошибки и даём план действий по улучшению ванильной версии:
— как разбивать данные на чанки
— что влияет на качество эмбеддингов и как выбрать модель
— зачем нужен реранкер и можно ли без него обойтись
— когда достаточно модели «из коробки» и как понять, нужно ли её дообучать

Статья будет особенно полезна новичкам, кто только начинает работать с RAG. Читайте по ссылке!

#llm #code #petproject

Страх и ненависть в Cursor

Тренды идут, а я не в трендах. Да и кодинг навыки в бытность мою лидом начали практиковаться значительно меньше 4-6 часов в день, необходимых для поддержания формы.
Потому, вдохновлённый опытом Валеры, моего любимого соратника-затейника, я самоорганизовался в недельный хак-интенсив безудержного AI кодинга.

Центральная идея
Глобально - Возможно ли за счёт скорости и экспертизы AI написать качественный код в сроки демки?
Если так, AI кодинг при должных навыках способен открыть прямой и быстрый прыжок от демо-прототипа к MVP.
Почему это важно:
Сейчас демки собираются либо на коленке, либо на морально волевых. И потом, как правило, переписывается под 0, часто уже другой командой, ибо говнокод, противно и нерасширябельно.
MVP - уже достаточно развитая система с проработанным и зафиксированным наборов бизнес-фичей, пригодная для стабильного запуска на малой аудитории, достаточно качественная и корректно организованная технически для комфортной итерационной разработки/развития в будущем.

С чем стартовал:
Ящик энергетосов и репо мне на растерзание. Как здесь, только страшнее, с повышенным содержанием сенситивных данных, хардкода ссылок и невменяемого .env. Это результат ~30 часов ИИ кодинга специалиста, не занимающегося промышленным программированием. Буду далее называть его легаси кодбазой.

Здравый смысл и начавший подёргиваться глаз подсказывали не ввязываться с этим кодом.
Тем не менее, это был вполне рабочий(!) проект, демонстрирующий все основные интересные мне сценарии. Некоторая исследовательская жилка ИИ артефактов всё-таки взыграла.
Да и потом, откуда ещё получить и поделиться бесценным опытом. Насколько бесценным? БД проекта выглядела вот так.

class DatabaseService:
    """Сервис для работы с JSON базой данных"""
    
    def __init__(self):
        self.lock = threading.Lock()
    
    def load_database(self) -> Dict:
        """Загрузка базы данных из JSON файла"""
        with self.lock:
            if DATABASE_FILE.exists():
                try:
                    with open(DATABASE_FILE, 'r', encoding='utf-8') as f:
                        data = json.load(f)
                        # Обеспечиваем структуру базы данных
                        if 'transcriptions' not in data:
                            data['transcriptions'] = {}
                        if 'users' not in data:
                            data['users'] = {}
                        if 'sessions' not in data:
                            data['sessions'] = {}
                        return data

Не знаю как у вас, а у меня сразу вызывает желание жить замерить, насколько сложнее/дольше будет отстроиться от этого чем писать нуля.


Задачи интенсива
- Разработать систему транскрибации, как можно ближе сходящуюся к уровню MVP по зрелости и качеству кода и технической архитектуры.
Небходимые целевые фичи:
* Гугл авторизация
* Получение транскрипта файла (в базу взяли WhisperX)
* Получение разбиения по спикерам (pyannote)
* Аналитический отчёт по содержанию файла ( LLM + proдуманный prompt)
* Запись встреч (ввиду сжатых сроков пришли к идее google extension - запись вкладка+микро, что мне кажется гениальным в своей универсальности)
* Развёртывание на сервере, Docker базовая инфра

- Посчитать выигрыш в своей скорости относительно плана реализации вручную.
- Выявить для себя правила оптимального использования ИИ
- Разобрать кейс доработки "легаси" кодбазы.

Как оно было
С чем столкнулся, к чему пришёл, что посчитал и как оно в итоге - будет дальше.

#llm #code #petproject #prompt

Начало

Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены


пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным

Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет

Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы


Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку

- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.

- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач

- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб

ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.

Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля

- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты

- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы

- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.

Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву

- Курсору можно относительно доверять в аспекте консистентности изменений, в большинстве случаев он ничего не забудет поменять. Впечатляет, что я забываю менять какие-то импорты или куски логики в соседних файлах чаще чем ИИ

- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения

How to avoid machine learning pitfalls by Michael A. Lones

Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.

This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.

Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.

It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results

Link: arXiv

Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign

@data_science_weekly

#systemdesign #courses

Пишем Микросервисы на Python + Брокер RabbitMQ

Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.

🗝 Урок живет здесь

Кодим на Коленке | #RabbitMQ

#parsing #courses

ПОЛНЫЙ КУРС ПО SELENIUM

Добро пожаловать на бесплатный курс по Selenium, в данном видеокурсе/плейлисте будут рассмотрены практически все аспекты Selenium, включая фишки, лайфаки и прочее!

🗝 Курс живет здесь

Кодим на Коленке | #Python