Интересное что-то

Когда мы получим realtime видео? Считаю от first principles (Лонгрид) Мне всегда было интересно предсказывать будущее — на знании будущего можно заработать деньги, лучше определить путь своего развития. А как это делать? Ответ у меня начал зарождаться в 2023, во время прослушивания интервью Хинтона о будущем искусственного интеллекта. Он упомянул, что скоро LLM будут инференситься на отдельных устройствах (смотря из 2026 так просто выглядит). Для меня это было непонятно — тогда я не задумывался об устройстве памяти, ограничениях вычислений. Я знал только, что есть A100/H100. А оказывается, создание специализированных чипов для инференса конкретной модели — один из самых эффективных методов ускорения, например Taalas, который с оговорками, но выдаёт 16k токенов в секунду, за счёт отсутствия универсальности CUDA и оптимизированного memory bandwidth И тут я понял: глубинное знание базовых нюансов — скорость вычислений устройства, memory bandwidth — это ключ к пониманию того, где лимиты технологии и какие AI-продукты мы можем получить в ближайшие 5-10 лет (ну если AGI не наступит раньше). Поэтому я решил сделать расчёты для близкой мне технологии — видеогенерации, а именно realtime видеогенерации: какой сейчас статус, что мы можем получить за счёт ускорения GPU и когда это дойдёт до мобильных устройств. Сами расчёты — в лонгриде Интерактивно потыкать и посмотреть как меняться будут предсказания можно — на сайте Лонгрид Демо Enjoy!

#gan

Создаем персонализированный контент: фанфики, аудиокниги, визуальные новеллы Это же видео на яндекс диске: https://disk.yandex.ru/i/BKndy2R19qDEMw Пример на видео - не готовый результат, готовым его сделает нужная вам персонализация (замена персонажей, локаций, привычек, фетишей, голосов и изображений). Читать/смотреть чужие фанфики обычно неинтересно, они слишком плоские и неинтересные. А вот персональный контент это другое дело, за ним будущее. Я себе уже штук 10 адаптаций сделал: по ситкомам, аниме, книгам. 20-40 глав идеально, потом надоедает. До видео стадии дошло пока 2 тайтла, слишком много действий. По фильмам/книгам с серьезным сюжетом пока не рекомендую делать: будет много несостыковок в сюжете, это будет бесить. Ситкомы и аниме - идеально. Или манга, но тут тоже сложно с консистентностью. Важная фишка которая цепляет - добавление ваших фетишей. ТЕКСТ: На вход: субтитры, краткое содержание сюжета Персонализация: замена персонажей (имен, описаний, привычек, пола) Добавление нужных фетишей в сюжет На выход: полноценная глава лайт новеллы или фанфика LLM: qwen3.5-27b, qwen3.5-35b, GLM-4.7-Flash-abliterated, gemma3-27b АУДИОКНИГА: оригинальные голоса + ваши голоса TTS: silero-tts-v5, qwen3-tts, vibevoice(не рекомендую) qwen3 TTS API сервер: https://github.com/andimarafioti/faster-qwen3-tts ВИЗУАЛЬНАЯ НОВЕЛЛА: На вход: Фоны, основные персонажи klein-9b-kv-fp8 в режиме редактирования с одной картинкой на вход Проблемы LLM: 1. LLM не умеют писать длинные главы. Они натренированы на коротких ответах на 1-2 тысячи токенов, что маловато для полноценной главы романа. Если больше - входят в циклы, бредят. Решение - делить главы на части. Потом клеить и просить убрать несостыковки. 2. На русских текстах LLM пишут хуже чем на английском - более шаблонно, чаще входят в лупы. Решение - писать на английском (даже если исходный сериал русский), использовать перевод. Для перевода - gemma3-27b или translategemma-27b. 3. LLM не могут выполнять несколько задач одновременно, например, собрать json с несколькими полями построчно по длинному тексту. Внимание падает, делают ошибки. Решение - делить текст на куски, делить задачу на подзадачи. 4. Расцензуренные LLM хуже выполняют задачи на обработку текста, например, создание промптов для text2image или создание json. А оригинальные LLM иногда могут отказаться от такой задачи, если на вход подается текст с 18+ темами. Решение - жонглировать LLM под задачи. 5. Режим размышлений (reasoning) очень плохо работает с длинными текстами (50-100 строк). Большая вероятность, что LLM войдет в луп. И большая вероятность, что текст на выходе будет в несколько раз короче, чем текст на входе, LLM его сократит, даже если просить не сокращать. Решение - отключаю ризониниг для большинства задач. 6. Режим преобразования манги в художественный текст я пока не победил, есть проблемы с консистентностью сюжета между страницами. Проблемы TTS: 1. silero-v5 xenia нравится за скорость, но есть проблемы с ударениями. Готового решения с омографами пока нет, все решения косячат. Только топовые LLM типа gemini-3-pro могут правильно расставить все ударения. 2. qwen3-tts не очень стабилен при клонировании голосов - иногда голоса совсем не похожи на оригинал, иногда норм. Пока смирился. У faster-qwen3 скорость примерно в 3 раза выше реалтайма - лайк. 3. vibevoice слишком много галлюцинирует, посторонние звуки мешают. отказался от него Проблемы klein: 1. Похожесть: если подавать фон и персонажей отдельными картинками похожесть будет очень низкая, лица очень сильно меняет. Решение: подавать одну картинку с программно приклеенными поверх персонажами, так похожеть намного лучше, но они хуже интегрированы в фон. Ищите компромисс, что важнее - похожесть или действия внутри картинки 2. Лишние руки: чем больше персонажей в кадре, тем больше будет рук. Решение: ограничить число персонажей в кадре до 2-3-х + использовать сэмплер res_2s, он делает чуть меньше косяков, но работает в 2 раза дольше. Этапы создания не влезли, выложу в комментах и на гитхабе. https://github.com/Mozer/personalized_fan_fiction

#llm #petproject

Agent Harness — звучит круто, да? И последнее время слышу это определение всё чаще. Но что оно вообще значит?

Коротко: это вся инфраструктура вокруг LLM — оркестрационный цикл, инструменты, память, управление контекстом, обработка ошибок. Всё, что не LLM.

Есть три уровня работы с харнесом (на картинке): 1. Prompt engineering — формирует инструкции, которые модель получает. 2. Context engineering — управляет тем, что модель видит и когда. 3. Harness engineering — включает оба предыдущих плюс всю прикладную инфраструктуру: оркестрацию инструментов, персистентность состояния, восстановление после ошибок, циклы верификации, обеспечение безопасности и управление жизненным циклом. Не стоит умалять заслуги людей, которые обучают LLM — за последнее время они сделали огромный шаг вперёд. Но харнесс тоже имеет вес. Например, LangChain поменяли только его, не трогая модель и веса — и поднялись с 30-го на 5-е место в TerminalBench 2.0. Подробнее про то, как устроены Claude Code, OpenAI, LangChain и где во всём этом харнесс — в новой статье на Хабре. Рекомендую сохранить, если хотите лучше понимать, как работает ваш агент и как его можно улучшить. @ai_for_devs

#agents

Как прокачивать продуктовое мышление? Чтобы улучшить продуктовое мышление нужно думать как продукт Шучу! Или нет. Давайте сразу договоримся о терминологии, что в рамках этого поста продукт – это решение задачи определённого сегмента потребителей в конкретном контексте (определение честно взяла отсюда). Примеры продуктов – маркетплейс, музыкальный стриминг, сервис такси, даже телеграм-канал можно воспринимать как продукт. А еще здесь могли быть ваши шутки про продукты в пятерочке 🤓 Зачем мыслить как продукт? Для продуктового аналитика одним из ключевых скиллов является "продуктовое мышление", наравне с остальными хард скиллами: SQL, A/B тесты, дашборды и так далее, потому что аналитик полноценный партнер бизнесу, а не выгружатель данных по запросу. Поскольку это требуется в работе, то и на собеседованиях очень часто спрашивают на продуктовой/бизнесовой секции. Я сама раньше писала, что невозможно прокачать продуктовое мышление кроме как непосредственно на работе продуктовым аналитиком. Сейчас согласна с этим частично, потому что так развивается лучше всего, но все-таки можно подготовиться и не будучи продуктовым аналитиком. Хотя конечно это чуть сложнее, чем учить SQL и питон, и даже статистику, но возможно. Как мыслить как продукт? Когда я сама переходила в продуктовую аналитику, мне помогло разгонять знакомые мне продукты с точки зрения воронки AARRR, ключевых метрик и моделей монетизации. Глобально идея понять как продукт привлекает пользователей и зарабатывает, какая у него может быть North Start Metric. Можно валидировать свои ответы с помощью нейросети, конечно нейросеть может обмануть, но тут важно скорее мыслить в правильном направлении, детали важны меньше. Такое упражнение очень хорошо помогает повышать насмотренность и не впадать в ступор при вопросах на собеседовании/в работе. Из побочных эффектов – утомила всех рассуждениями про модели монетизации и рекламу 😁 На собеседованиях могут спросить следующее: 🟡прикинуть дерево метрик для конкретного продукта (может быть тот продукт куда собеседуетесь или наоборот НЕ тот куда общаетесь и точно не тот, где работаете). Здесь можно заранее подготовить продукт, которым пользуетесь каждый день и примерно разложить дерево метрик. 🟡описать, на каком этапе развития находится продукт, какие ключевые метрики и вызовы перед ним могут стоять. 🟡упала метрика, что делать 🟡запускаем новую фичу, как оценить эффективность внедрения. Это может быть кейс на A/B, но необязательно Это далеко не все возможные примеры вопросов, но чтобы разобрать детальнее нужен отдельный пост. Ставьте реакции 🔥, в следующий раз могу написать, какие типы вопросов бывают, как к ним готовиться и отвечать 💪 #analytics #собес_PA

#analytics #interview

Я продолжаю экспериментировать с разными штуками, которые позволяют запускать автономную работу агента и выполнять поставленные задачи "под ключ". А то начитаешься всякого на реддите, что "если у вас агент ничем не занят, то вы делаете что-то не так" 🙂 Сейчас пробую Ralphex. Очень любопытная штуковина – под капотом используется Claude Code, но поверх накручена полноценная система управления процессом работы агента. Начинается всё по классике – нужно любым удобным способом составить план выполнения задачи. Можно использовать встроенную команду plan. Качественный план для агента – это важно, а здесь особенно важно, потому что когда процесс запущен – вклиниться и что-то подправить уже не получится. Далее просто запускаю ralphex и машина начинает шуршать – выполнять план по шагам, отмечать прогресс, писать тесты. Последний этап – код-ревью. Если у вас в наличии Codex – то он призывается для ревью. Вообще забавно наблюдать, когда один агент чехвостит другого. На самом деле – там много интересного происходит под капотом – рекомендую поэкспериментировать. #ai #agents

#agents #petproject

Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада. Первая часть была посвящена тому, как мы разрабатываем агента в среде разработки. Когда мы начинали, было много скепсиса к агентам, поэтому главной ставкой были фичи, связанные с бесшовным входом в разработку с агентом. Но настоящим вызовом стал адопшен – нужно было сделать так, чтобы агентом начали реально пользоваться. Писали доку, гайдлайны, проводили воркшопы – в общем было очень потно, но в то же время приятно было видеть, как в результате растёт аудиторная метрика. Ещё один важный момент, влияющий на адопшен, который подтверждается как нашими внутренними исследованиями, так и исследованиями DORA – важно, чтобы были прозрачные политики безопасности, чтобы люди понимали, что можно отправлять в агентов, а что нет. Вообще агентов сейчас разрабатывают кажется все кому не лень, и при этом по ощущениям не так часто говорят о качестве. Об этом была вторая часть доклада – как подходить к качеству через офлайн и онлайн-метрики на примере еще одного агента для написания запросов к данным. Для офлайн-метрик мы используем валидационный датасет – прогоняем на нём агента, чтобы не выкатить изменения, которые ухудшают пользовательский опыт. Но одних офлайн-метрик недостаточно, потому что реальных сценариев сильно больше, чем мы можем собрать в датасете. И говоря уже об онлайн-метриках, важно их строить от сценариев использования. Первое на что смотрим – CJM, так появляются метрики, основанные на пользовательских сценариев. А чтобы сформировать более точечные метрики, мы регулярно разбираем весь фидбек по работе нашего агента – это дорого, но позволяет понимать, что реально происходит в продукте. По результатам таких разборов тоже появляются метрики – например, мы заметили фейковый тул-колинг, пошли разбираться из-за чего такое происходит, а заодно появилась метрика, насколько эта проблема актуальна для наших пользователей. И ещё заканчивая о метриках – важно не забывать их валидировать, действительно ли метрика измеряет то, что нужно. Иногда об этом забывают, а потом удивляются :) А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах. #devfm #ai

#agents #metrics

В прошлом году делал пост с подборкой ресурсов для желающих разобраться в деталях RLHF. Одним из ключевых ресурсов была книга довольно уважаемого рисерчера и преподавателя Nathan Lambert. Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом. Получилось 4 лекции по часу, от введения до математики и реализации. Лекции на ютубе смотреть тут

#rl #courses

Дорогие и дешевые сигналы лидера Недавно прочел исследование, в котором говорится, что люди оценивают чужие лидерские компетенции довольно субъективно. Они замечают ряд «сигналов», из которых делают выводы. А сигналы эти исследователи делят на «дешевые» – не требуют затрат и легко имитируются. И «дорогие» – требующие затрат и несущие риски. Дешевые - Харизматичная риторика (метафоры, сторителлинг, обещания); - Публичные заявления о ценностях и этике; - Дружелюбные сообщения и благодарности в коммуникациях; - Статусный или «технобро»-стиль одежды; - Демонстративная «открытость». Дорогие - Последовательность действий на протяжении длительного времени; - Личное выполнение сложной задачи; - Публичная защита смелой позиции; - Сопротивление давлению сверху; - Признание своих ошибок; - Снижение собственной зарплаты в кризис. В чем тут ирония? Я читал и грудь колесом делал: «Я же выбил полный страйк из дорогих сигналов, ух я лидер!». А потом до конца дочитал, а там говорится, что дешевые сильнее бросаются в глаза, их субъективно проще и чаще замечают, следовательно, нередко компания может больше ценить тех, у кого прокачаны дешевые сигналы. Думал, что я крутой, а оказалось, что наоборот 🙂 НО На днях один из сообщников по Менеджмент Хабу, с которым мы долго работали вместе, написал: «Я вот Жене что угодно доверю, потому что если мы договорились, он прям точно сделает». Так что можно не спешить расстраиваться, ибо дешевые сигналы действуют быстро и громко, но потом так же быстро и выдыхаются, если за ними реальных дел не окажется. А долгая, надежная, консистентная и порядочная работа может быть со стороны не так маркетингово видна, но зато она ведет к долгосрочному сотрудничеству и сарафанному радио из довольных твоей работой. Итог Не принижаю ни одни, ни другие виды «сигналов», но призываю вас повнимательнее всматриваться в результаты. Уверенные речи, обещания светлого будущего, давление авторитетом и т. д. впечатляют. Но вы потом спросите: «А результат-то какой?». Кстати, вот здесь перформанс ревью работает, на мой взгляд, хорошо (оставляю за скобками другие его аспекты). Там так просто не отбрехаться, там надо результаты предъявить.

#softskills #career

# ULTRAPACK Я стал настолько много клод-кодить, что захотелось поработать напильником. TL;DR: мой минималистичный пак скиллов для Claude Code, построенный вокруг коротких планов и работы над одной фичой в одном диалоге: https://github.com/btseytlin/ultrapack или просто /up:. Установка:

/plugin marketplace add btseytlin/ultrapack
/plugin install up@ultrapack
/reload-plugins

Запускаем:

/up:make <описание вашей фичи>

Что произойдет: 1. Агент создаст файл docs/tasks/<ваша-фича>.md который будет пополняться по ходу планирования и исполнения. Всегда можно возобновить работу с этого файла или закинуть его в контекст другому агенту. 2. Проведет через стадии: дизайн, планирование, исполнение, верификация, ревью, обновление документации. 3. Если написать /up:make handsoff <описание вашей фичи> будет стараться минимально вас о чем-то спрашивать и при этом делать самые безопасные выборы (например, ничего не удалять без бекапа). Явно документирует какие решения он принял без вас, см. пример. Дизайн и планы получаются достаточно короткие, потому что делается упор на инварианты (условия которые должны выполняться) и принципы. В исполнении и проверке делается фокус на мануальное тестирование. Как же меня достало, что агент делает фичу, покрывает всё тысячью юнит-тестов, но потом всё падает при первой попытке это запустить. В up агент всегда сам "протыкивает" свои изменения. Подобные паки уже есть и ultrapack это компиляция из всего, что мне в них нравится, но короче и проще: - Официальный feature-dev: в целом хорош, но мне лично много чего в нём не хватает, например мануальных тестов и обновления документации. Основной воркфлоу в up оттуда. - Superpowers: ещё больше хорош, но перегружен и уничтожает лимиты. Потому что пишет в планы буквально какой код планирует писать и какие команды будет вызывать дублируя всю работу. Пихает TDD туда, где он не нужен. Ещё авторы зачем-то меняют всё каждые 15 минут, я устал. - Personal AI Infrastructure: перегружен какой-то шизофренией. Вот здесь пример task файла по созданию этого же пака: https://github.com/btseytlin/ultrapack/blob/main/docs/tasks/ultrapack-v1.md Пример task.md для поиска нетривиального бага в hr-breaker: https://github.com/btseytlin/hr-breaker/blob/main/docs/tasks/fix-non-ascii-resume-upload.md Пользуйтесь, делитесь фидбеком 👀 Пет проекты в 2026 би лайк: 5 маркдаун файлов. @boris_again

#llm #code

5 git-команд, которые стоит запустить перед чтением чужого кода. Это рекомендация консультанта по аудиту кодовых баз — 20 самых часто изменяемых файлов за последний год. Файл на первом месте -- тот, которого все боятся:

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

— Все авторы, отсортированные по числу коммитов, чтобы понять, кто «главный». Если один делает ≥60% -- высокий bus factor:

git shortlog -sn --no-merges

— Где скапливаются баги. Пересечение с первым списком -- самый рискованный код:

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

— Проект растет или умирает. Коммиты по месяцам за всю историю. Резкое падение, например, уход сотрудника:

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

— Как часто команда тушит пожары. Несколько раз в год - норма. Раз в две недели -- проблемы с деплоем:

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

#code