#gan #petproject

#trading #options #greeks

https://www.youtube.com/watch?v=Qs0jNUtHnVc

#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ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения