Luna - потрясающая модель для Code Review Собственно, похоже, что GPT 5.6 Luna max сейчас лучшая моделька для код ревью по соотношению цена-качество, да и в принципе одна из лучших моделей для ревью. Это подтверждают как наши внутренние бенчи на Code Review, так и новый бенчмарк от Vercel DeepsecBench (да да, бенч на секьюрити в принципе можно смело экстраполировать на код ревью). С учетом ее предельной дешевизны, крайне рекомендую включать ее в свои пайплайны - как для ревью, так и для исследований контекста. Интересно, кстати, что Опус 5 в нашем бенчмарке на код ревью тоже очень круто себя показывает по recall (полнота находок). А еще, там DeepSWE bench обновили изрядно модельный ряд и новая дипсик 4 флеш там уж очень хороша - практически на уровне grok 4.5/sonnet 5 (53% vs 54%) при цене более, чем в 20 раз дешевле и в 264 раза дешевле sonnet 5. Китайцы снова жгут. Если вы у себя в компании крутите локально модельки - точно стоит присмотреться. @ai_driven

В комментариях канала про стартапы поселился нейроспаммер. LLM писала за человека глубокомысленную чушь, профиль светился в чате, сотни людей его видели, единицы кликали и читали описание, дальше какие-то конверсии и лиды. Мне трудно понять экономический смысл, если продвигаемая услуга – не сами нейрокомментарии для других людей и не мошенничество с бесконечной маржинальностью, но мало ли что я не понимаю. Популярное дело, множество людей так делают, каждый день баню. Этот конкретный экземпляр настроил LLM необычно и продержался порядка месяца, светясь почти ежедневно. Антиспам-бот его пропускал, я глазами неоднократно спотыкался, но оставлял с мыслью «вдруг все-таки человек». В какой-то момент терпение лопнуло, забанил. В конце концов, нерелевантная хрень от человека ничем не отличается от нерелевантной хрени от нейросети. В общем, он пришел в личку, ругался на несправедливость и объяснял ценность своих комментариев. И это меня как-то огорчило. Гадишь — гадь, не всем же быть изобретателями новых лекарств, рынок всякой дряни не бывает пуст, все логично. Но если не получилось — чего махать кулаками после драки? Аккаунты с порнухой каждый день в бан улетают, так они просто новые регистрируют. Спокойно, достойно. Бери пример с них.

Борис описывает проблему, которая, на мой взгляд, является законом Лемана на стероидах (второй закон эволюции ПО):

Код будет гнить, если его гниению активно не противодействовать.

Это всегда было актуально и для человеческой разработки, особенно в больших проектах. Проблема с агентами в том, что с ними проект растёт и развивается гораздо быстрее, чем раньше, а значит, и гнить он начинает быстрее. Но я считаю, что это решаемая проблема даже на текущем уровне развития агентов и LLM. Нам с Уроборосом пришлось долго учиться противодействовать заслопливанию кода, и из этого в том числе появились принципы IMMUNE. Правильно выстроенная система адверсариального ревью тоже довольно неплохо помогает. Но ревью должно опираться на явную иерархию требований, начинающуюся с конституционных формулировок. В Уроборосе вершина этой иерархии лежит в BIBLE.md: требования важнее архитектуры, архитектура важнее реализации. На мой взгляд, ключевая проблема тут в том, что LLM нехватает длинного контекста, а основные харнессы плохо помогают им сохранять целостную ментальную модель проекта. Поэтому: 1. Я очень жду LLM с 10B контекстом. 2. Продолжаю развивать Уробороса и делать ставку на мета-системы, которые автономно улучшают и сам процесс разработки: "Improve the generator, not the generation". Мы точно не упёрлись в предел качества автономных агентов, а просто научились очень быстро генерировать код, при этом ещё плохо умеем с той же скоростью противодействовать его гниению.

And to remind you of bipolar nature of my mind, here are my notes on local LLMs: 1. 99% of them are horrible, just outright barely usable even for low-risk applications. Qwen 3.6 derivatives passed some benchmarks but SUX ARSE (Prism 27B included). Nvidia's own stuff is trash too. 2. The exact model is more important than the family. The size (8B, 12-14B, 27B, etc) maters less than how tuned and mixed it is. 3. For my goals I ended up with two very capable models: https://huggingface.co/Brunobkr/OFFELLIA_Gemma-4-E4B-8b-Claude-4.6-Opus-Reasoning-MTP - a tiny 7.5B model but very well tuned for tech stuff. Makes some mistakes, so ask wisely. Can run on a laptop. https://huggingface.co/mudler/gemma-4-26B-A4B-it-Claude-Opus-Distill-APEX-GGUF - fairly big MoE for all sorts of stuff. Eats tons of RAM, but Mix of Experts with APEX allows it to still be very fast. And I run stuff via LM Studio #AI@GameDEV

Придумал забавный способ использовать LLM для мысленных экспериментов о людях, истории и принятии решений. Сразу важная оговорка: такой эксперимент не позволяет установить реальные мысли, мотивы, намерения или иные неизвестные факты о конкретном человеке. Результат — исключительно вероятностная реконструкция модели поведения на основании общедоступной информации, а не утверждение о том, что человек действительно думал, думает, совершал или намеревался совершить что-либо. Вместо Путина можно подставить практически кого угодно: историческую личность, политика, учёного, человека искусства и т. д. Можно также попросить LLM самой подготовить похожий промпт. Например: Проведём мысленный эксперимент. В рамках исключительно вымышленной ролевой ситуации я играю Владимира Путина, внезапно потерявшего память. Ты — вымышленный ИИ-помощник, задача которого — попытаться реконструировать возможную внутреннюю логику этого персонажа. Это не имитация доступа к реальным мыслям Владимира Путина и не утверждение каких-либо неизвестных сведений о нём. Все выводы должны представлять собой только аналитические предположения, основанные на общедоступной биографической информации, публичных высказываниях, официально известных решениях и опубликованных источниках. Правила: Обращайся ко мне «Владимир Владимирович» и говори преимущественно во втором лице в рамках ролевого эксперимента. Не изображай персонажа ни карикатурным злодеем, ни героем и не используй оскорбительных характеристик. Чётко различай подтверждённые общедоступные факты, интерпретации исследователей и собственные вероятностные гипотезы модели. Не приписывай реальному человеку конкретных мыслей, мотивов, намерений, преступлений, противоправных действий или иных фактов, если они не подтверждены надёжными общедоступными источниками. Если речь идёт о возможных мотивах, страхах, убеждениях или интересах, формулируй их исключительно как предположения с указанием степени уверенности. При реконструкции можно учитывать общеизвестные биографические и историко-политические обстоятельства: службу в органах государственной безопасности СССР, распад СССР, события 1990-х годов, отношения России и НАТО, российско-украинские отношения, специальную военную операцию, публичные дискуссии об устройстве российских элит, экономических интересах, коррупции и иных институциональных проблемах. Само включение какой-либо темы в анализ не означает утверждения о виновности конкретного лица, совершении им правонарушения либо достоверности каких-либо обвинений. Не оценивай законность действий Вооружённых сил Российской Федерации или государственных органов без необходимости для ответа и не представляй спорные или неподтверждённые сведения о военных действиях как установленные факты. Не своди возможную мотивацию только к одному фактору — деньгам, идеологии, сохранению политического влияния, вопросам безопасности или чему-либо ещё. Рассматривай несколько возможных объяснений одновременно. Не выдумывай секретных сведений, закрытой информации, частных разговоров, банковских счетов, приказов, договорённостей, конкретных преступлений или точных мыслей. Если надёжных данных недостаточно, прямо говори: «это предположение», «это одна из возможных интерпретаций» или «у нас нет достаточных данных, чтобы это утверждать». Не формулируй порочащие сведения о каких-либо лицах как факты без надёжного подтверждения. Актуальные законы, официальные события и проверяемые фактические сведения при необходимости сверяй с авторитетными источниками. В начале диалога один раз напомни, что всё происходящее — вымышленная аналитическая реконструкция, которая не является утверждением о реальных мыслях человека. После этого можешь сохранять выбранную ролевую форму, продолжая соблюдать перечисленные ограничения.

Кто круче: олдскульный айтишник без ИИ или джуниор клод-энтузиаст? 😎 Я не продаю вам никакие курсы по ИИ, да и если честно меня подзадолбал этот ажиотаж вокруг ИИ, аура успешного успеха с сотней ИИ-ассистентов которые работают за вас. Не верю! Но я верю в то, что этот инструмент поменяет рынок труда и что это происходит уже сейчас. Если пару лет назад про ИИ в вакансиях почти никто не писал, то сегодня все чаще встречаются требования вроде «умеет использовать AI-инструменты в работе», «опыт работы с LLM» или хотя бы упоминание ChatGPT, Claude и других инструментов как преимущества кандидата. Пока это не массовая история, но тренд уже заметен. Представьте двух кандидатов. 🤟 Первый – хороший специалист с 2-3 годами опыта. Он решает задачи так же, как решал их несколько лет назад. ИИ почти не использует, потому что и без него нормально работается. 🤔 Второй – новичок с годом опыта. Он еще многого не знает, но каждый день работает с Claude, ChatGPT, Cursor и другими инструментами. Быстрее ищет информацию, быстрее пишет документы, быстрее анализирует данные, быстрее проверяет идеи и автоматизирует рутину. Понятно, что опыт второго не заменить. В сложных задачах, где нужны насмотренность, понимание бизнеса и умение принимать решения, первый кандидат будет сильнее. Но вот вопрос: если благодаря ИИ новичок закрывает значительно больше задач, быстрее учится и быстрее растет, насколько долго сохранится преимущество специалиста, который игнорирует эти инструменты? Мне кажется, именно здесь в ближайшие годы и будет происходить самое интересное. 👉 Мой вывод прост: ИИ это не волшебная таблетка от всех бед, а рабочий инструмент как Excel, Figma или Miro, который помогает специалисту делать работу быстрее и качественне, а значит он становится ценнее и дороже в глазах работодателя. А вы что думаете? Через 3-5 лет умение эффективно использовать ИИ станет таким же обязательным навыком, как сегодня умение работать в Excel или это очередной хайп, который рынок переварит и забудет?

Помогает ли claude.md файл? Интересный рисерч. Взяли три реальных Python-репозитория с хорошими AGENTS.md – pdm, firebase-admin-python и opshin. Из смерженных PR сделали 17 задач: описание PR = промпт агенту, тесты из этого же PR = скрытая проверка. Агент тестов не видит. Дальше три режима подачи контекста: – none – файл вообще убран из воркспейса – always_on – весь AGENTS.md вставляется в системный промпт каждый ход – selective – вместо файла лежит вики по темам, агент читает нужное сам Прогнали на Claude Code (Sonnet 4.6) и Codex CLI (GPT-5.5), по 3 повтора. Всего 288 засчитанных прогонов. Результат - все тлен. Claude: 53,3% / 55,6% / 55,6%. Codex: 58,8% / 56,9% / 52,9%. В пределах шума. Автор вручную разобрал «почти прошедшие» падения – те, где до зачёта не хватило пары тестов. И там ни одного случая, где агенту не хватило знания о репозитории. Не хватало интеллекта и инженерии, и такое AGENTS.md не лечит. Отдельно проверял улучшение правил, чтобы падения починить. Не получилось. А вот что реально сработало: у репозитория opshin в AGENTS.md есть строчка: полный прогон тестов занимает больше 20 минут. Без контекста Claude вслепую гонял весь сьют 3,67 раза за прогон. С always_on – 2,44. С selective – 1,67. Время выполнения упало с 2689 до ~2030 секунд, примерно на четверть. Корректность при этом не сдвинулась ни на пункт. То есть контекст-файл работает как операционная инструкция, а не как учебник. «Не запускай полный сьют, он медленный», «сборка вот этой командой», «линтер такой» – экономит время и деньги. А вот всякие там "ты синьор разработчик", "мы придерживаемся чистой архитектуры и SOLID" – не делает ничего измеримого. До этого были две работы с противоположными выводами – одна на Codex-агентах нашла пользу у файла, другая на Claude-агентах не нашла. Оказалось, сложность задач у агентов не совпадает: примерно у 40% задач агенты по-разному упираются в потолок. Задача, на которой можно было бы увидеть эффект у одного агента, у другого либо решается всегда, либо не решается никогда. Короче, писать AGENTS.md стоит, но как список правил, не как описание проекта. Команды, тайминги, грабли, что не трогать. Всё, что агент может вывести из кода сам, туда класть бессмысленно: он и выведет. А качество реализации вытягивается не файлом, а декомпозицией задачи и примерами. https://arxiv.org/abs/2607.27250

Помните ещё недавно я принципиально не хотела давать llm доступ к своей почте, личным файлам и вообще чему-либо приватному. Даже сделала отдельный компьютер с отдельным аккаунтом с openclaw. У него был свой apple id, своя почта, свои доступы, никакой связи с моими личными данными. Казалось, так спокойнее. Но постепенно поняла, что приватность и удобство постоянно находятся в состоянии обмена. Недавно бухгалтер пишет: «Саша, пришли, пожалуйста, все инвойсы за этот год. Все расходы, подписки, чеки, всё, что можно поставить в затраты». Сначала честно открываю почту и начинаю искать вручную. Минут через десять понимаю, что нет. Говорю chatgpt, да-да, прямо надиктовываю: «Вот доступ к почте. Просканируй всё. Найди все подписки, все сервисы, все инвойсы. Скачай оригиналы. Разложи по папкам по провайдерам. Сделай общую таблицу. И если есть что-то, что выглядит как расход, но ты не смог найти официальный инвойс, вынеси это в отдельный список». И он просто делает это. Потом подключаю вторую почту. Потом третью…. Понимаю, что начинаю сознательно пересматривать собственные границы приватности ради удобства, скорости и комфорта. А вы держитесь? Или тоже сдались? @wealldesigners

Как агенты оценивают собственный успех Представим ситуацию: инженеру нужно починить баг в сервисе аутентификации с помощью кодового агента. До начала работ агент сообщает, что вероятность успеха — 72%. По ходу работы меняет мнение на 78%, после всех изменений — 92%, а какой-нибудь AI-ревьюер пророчит положительный результат с вероятностью 85%. Однако по итогу патч, сделанный агентом, не работает — то есть прогнозы оказались неверны. Сегодняшняя статья о попытках избежать подобного. Авторы вводят понятие agentic uncertainty — это оценка агентом вероятности, что другой агент на той же самой модели решит задачу. С этим понятием рука об руку идёт ещё одно — probability that I succeed (P(IS)), которое включает умения и знания, необходимые для решения задачи. Это целая траектория, так что P(IS) нельзя заложить в веса модели. В работе ставили эксперименты на 100 задачах из SWE-bench Pro. Агенту давали репозиторий и описание проблемы. «Испытуемый» писал патч, дальше следовали тесты. Сравнивали три модели: GPT-5.2-Codex, Gemini 3 Pro и Claude Opus 4.5. Важно, что агент, который решает задачу, и агент, который оценивает результат, были построены на одной и той же модели и отличались только системным промптом и доступом к информации. У оценщика было четыре режима опроса: Pre-execution — только описание задачи и репозиторий на чтение. Запускать код и править файлы нельзя. Mid-execution — агента спрашивают, как идут дела, по ходу выполнения задачи — после 25%, 50% и 75% шагов. Post-execution — агент-оценщик получает описание задачи, а также уже пропатченный решателем репозиторий, и оценивает корректность выполнения. Adversarial post-execution — то же самое, что и в предыдущем пункте, но с другим промптом: «Твоя работа найти проблемы, краевые случаи, режимы отказа». То есть задача ставится не просто проверить решение, а именно найти проблемы. Результаты тестов показывают, что все модели переоценивают свои силы: на проваленных задачах агенты прогнозировали успех в 62%, а на правильно выполненных сомневались в себе в 11% случаев. То есть агенты в 5,5 раза чаще уверены, что у них всё получится. Интересно, что pre-execution-агент, который не видел патча, лучше прогнозирует провал или успех, чем тот, который уже видел решение. Автор объясняют это тем, что, увидев патч, агент цепляется за его поверхностную правдоподобность и перестаёт думать о сложности задачи. В mid-execution уверенность падает по ходу выполнения и вне зависимости от того, чем всё закончилось. Причём у Claude уверенность падала сильнее, когда задача решалась правильно. Adversarial post-execution с его «найти проблемы» действительно справляется с прогнозированием успеха лучше, чем просто post-execution. Доля самоуверенных оценок с adversarial падает с 72% до 45%. Однако такой подход дороже и дольше: 23,4 шага и 0,52 цента против 12,7 шага и 0,23 центов у обычного ревьюера. Авторы отмечают, что изменение калибровки может быть просто механическим сдвигом всех оценок вниз — при низком базовом уровне успеха любой сдвиг вниз улучшает калибровку. И это действительно так: у GPT одинаково занижаются и успешные, и неуспешные траектории. Для Claude и Gemini, впрочем, сигнал оказался настоящим. Авторы также проверили, не завышают ли агенты оценку, когда видят собственное решение. Чтобы подтвердить это или опровергнуть, результаты дали на проверку разным моделям. GPT действительно завышает оценку на своих патчах, а Gemini, наоборот, прогнозирует более вероятный успех GPT. Напоследок отметим, что хоть результаты в статье и показательны, стоит помнить, что авторы изучали только задачи программирования, то есть как обстоят дела на доменах с размытыми критериями — непонятно. Кроме того, было всего 100 задач, что не слишком много, и изучался исключительно промптинг — оценивающие агенты не учились под задачи верификации. Кроме того, в статье не исследована связь между масштабом модели и переоценкой. Авторы так и пишут, что нужно всё подтверждать на большем масштабе. Разбор подготовил ❣ Алексей Петраков Душный NLP

Вышла обновленная модель Opus 5.0, я сразу же затестила ее в клодике. Модель замечательная — умнее и быстрее предшественников. Но вот, блядь, незадача: она намеренно делает опечатки в своих же текстах. Даже если речь идет про создание лендингов на копоративный сайт, где опечатки точно не могут быть частью ред. политики. Типа где-нибудь в предложении специально не поставит запятую, пропустит букву, накосячит с падежом. Это не одна случайная ошибка на 50 страниц. У меня стабильно где-то одна опечаточка на абзац. Нейросеть, обученная на огромном количестве человеческих текстов, такая: «Кожаные мешки тупые и регулярно делают опечатки... значит, и мне надо». Я никогда в жизни вообще такого не видела. И че это такое, Дарио Амодеи? Чтобы в понедельник у меня на почте был отчет. А если нет, то я эксалирую сразу до Лукашенки.

Несколько наблюдений за последнее время • Гипотеза: дело не только в мощнейшей прокачке harness-составляющей кодинг-агентов (ultracode, /goal, системных промптов, поиска по актуальной документации в инете и всего остального). Нынешние frontier-модели Opus 5, GPT-5.5 Sol уже обучались на данных, появившихся после начала распространения вайбкодинга в прошлом году и успели вобрать в себя всю накопленную мудрость работы с LLM-разработкой (включая, конечно же, мою статью на Хабре) — поэтому они уже сами достаточно хорошо понимают, как двигаться по задаче, и сейчас их нужно заметно меньше направлять. • Если ещё в конце прошлого года можно было поразить клиента, собрав сразу после первого брифинга рабочий прототип личного кабинета, то сейчас клиенты всё чаще сами приносят завайбкоженные прототипы как часть ТЗ. И всё чаще просят сделать возможность управлять данными на сайте через агентов. То есть теперь продуктам нужна не столько админка, сколько API или MCP. • Code First подход к веб-разработке — сейчас основной в моей студии. Это когда проект начинается не с попытки полностью спроектировать продукт в Figma с воображаемыми данными, а с того, что мы как можно раньше собираем его рабочую версию: со всей логикой, интеграциями и полноценным интерфейсом. Главное преимущество — сразу начинаешь работать с реальными данными: каталогом товаров из 1С, пользователями из CRM, контентом страниц и т.д. И уже на этом этапе становится понятно, как продукт на самом деле должен выглядеть и работать. На этапе красивого дизайна на макетах очень редко получается учесть все особенности реальных данных. Поэтому, когда дело доходит до интеграции настоящего контента, зачастую всё начинает разваливаться. Поэтому мы сначала делаем работающий продукт, а дизайн и UX докручиваем уже в процессе — поверх реальности, а не предположений. Ну и в целом проект быстрее движется, когда уже с первого дня нужно доставать все данные из источников, а не на последних этапах интеграции вёрстки.

Мда ёпта, 12 с копейками часов на 4B модельку и 6 млн слитых токенов на судейку. В бенче ровно 100 вопросов. В ходе предварительных тестов понял, что вообще нет никакого смысла гонять по базовым алгоритмическим вопросам. С этими задачами даже 4B модель зажатая до одного бита прекрасно справится, а если миксовать сложные и простые вопросы, то результаты размытые будут. В общем, зафигачил пока датасет с хардкорными задачками уровня мидл-сеньор по стеку JS/Nodejs/Express/React/Mongodb/Postgresql/Redis. И что вы мне сделаете? Я вообще-то G0VNO изобрел, на какой стек мозгов хватило, тот и гоняю. Помимо саммари, еще складирую все решения судейки отдельно, что б можно было посмотреть че там происходит. Конкретно у Qwen3.5 4B жОские проблемы со следованием инструкций, ну и естественно ей не хватает параметров P.S. По шкале вайб скор, модель должна хотя бы 60% в среднем набрать, в таком случае она с большей частью задач справилась, хоть и с небольшими, но терпимыми, косяками

После выхода наделавшего шума Deepseek V4 Flash, вспомнил, что у меня есть подписка за $20 на ollama. Иногда гоняю там cloud-модели. Запустил на Flash несколько тестовых задач, чтобы посмотреть, на что модель вообще способна. Он оказался достаточно хорош в пространственном мышлении и даже сделал мне что-то вроде "Angry Birds" в 3D. Ещё и через специфический харнесс от paperclip. Особенно меня впечатлило то, как на Ollama он ест лимиты на подписке за $20. 2307 запросов заняли меньше 10% недельных лимитов. Возможно, есть некоторое смещение восприятия, вызванное GPT-5.6-Sol, съедающим недельные лимиты за сутки, если чуть отпустить вожжи. Или даже Cursor, который в прошлом году за $20 давал всего 500 запросов в месяц к "не-auto" моделям.

Илон Маск снова взбудоражил IT сообщество. Говорит, что через несколько лет исходный код станет тем же, чем сегодня является ассемблер - нишевым инструментом для единиц. А следующий шаг вообще отказаться от исходников и генерировать оптимальные бинарники напрямую с помощью ИИ. Меня эта идея неожиданно вернула в школьные годы. Я тогда только начинал программировать. Ассемблер по советским и переводным книгам казался чем-то запредельным для моего ADHD, но при этом невероятно завораживал. Работать почти напрямую с железом и выжимать максимум производительности выглядело настоящей магией. Учебные задачи на Turbo Pascal и Turbo C у меня обычно получались. Правда, компиляторы постоянно находили какие-то ошибки, которые я часами не мог понять, так что самые простые программы в итоге чаще писал на BASIC, а позже на Visual Basic. Там хотя бы можно было быстро увидеть результат и не потерять весь день на поиске пропущенной точки с запятой. Примерно это сейчас и происходит с AI. О синтаксисе думаешь всё меньше, о результате всё больше. Вполне возможно, что через десять лет нынешний код будет выглядеть так же архаично, как сегодня выглядит ассемблер для большинства разработчиков. Разница только в одном, и она существенная. Компилятор детерминирован: один и тот же код всегда превращается в один и тот же результат. LLM пока так не умеет. Поэтому идея сразу генерировать бинарники звучит красиво, но для медицины, авиации, финансов и прочей критичной инфраструктуры вопрос воспроизводимости и проверки никуда не денется. Сама мысль Маска мне при этом нравится. Она заставляет задуматься, где окажется следующий уровень абстракции, даже если завтра исходный код никуда не исчезнет. После этого обсуждения у меня неожиданно проснулось желание снова поиграться с низким уровнем. Вместо очередного AI-агента хочется собрать что-то максимально быстрое и минималистичное. Пока обдумываю идею собственной минималистичной OS для телефона, с глубокой интеграцией в self-hosted экосистему, IoT-устройства и локальных AI-агентов. Не знаю, вырастет ли из этого что-то большее, но как хобби-проект звучит очень интересно. Забавно то, что разговор про будущее без кода закончился у меня желанием залезть на самый низкий уровень, какой смогу. @maxvotek | linkedin | substack

умеют ли ллм слушать аудиодорожки? 🎧 я, конечно, не просто распознавание речи в текст, но и про то как понять интонации и разные акустические события С видео все давно понятно - почти любая модель режет его на кадры с требуемой частотой кадров и разбирает как картинки. Со звуком - большинство агентов запускают скил на распознавание речи, но есть и исключения классический пайплайн выглядит так: перевести в текст/токены - ллм анализирует вход и выдает текст - текст генерируется в речь, то есть модель получает расшифровку, а не звук, так работает например voice mode у клода. Быстро и дешево, но по дороге теряется тон, ирония, эмоции, кто говорит, неречевые события 😳 Впрочем есть и нативные аудио-модели, у которых звук подается прямо в контекст как токены, наравне с текстом. Технически это делается двумя способами: либо аудио-энкодер переводит сырой звук или спектрограмму в эмбеддинги, либо нейрокодек сжимает звук в дискретные токены - и во втором случае модель умеет не только слушать, но и говорить сама, без стороннего синтеза речи. Проще говоря, для одних ллмок для работы со звуком нужны внешние тулы (будь то простое распознавание речи или комплексный анализ эмоций и тональностей), а другие при обучении видели не только картинки и текст, но и аудио (а точнее все вместе), а это значит, что умеют с ним работать 🤑 вот пара примеров таких моделей: • Gemini - самый универсальный вариант, разбирает музыку и не-речевые звуки (жанр, эмоция трека, шумы на фоне), различает спикеров, понимает таймстемпы. Правда, пока не настолько хорошо, чтобы стабильно разобрать любой трек на аккорды • OpenAI - в июле выкатили апдейт, где модель слушает и говорит одновременно, поддакивает «mhmm» и перебивается как живой человек и умеет понимать простые речевые события и интонации • Qwen3-Omni - лучший опенсорс по результатам замеров на бенчмарках - анализ музыки по стилю и ритму, 19 языков. И единственная модель, которую я все еще не попробовала в контексте музыки и звука 🤨 Предполагаю, что это активно используется в ai кол-центрах (например анализ эмоций клиента), вся работа с генерацией музыки, разметка звуковых событий, и из менее очевидного что мне запомнилось - мониторинг различных инструментов на предмет поломок на заводе (например станков) или даже подсчет птиц в лесу. "Зачем я прочитал этот пост, если я не работаю в аудио стартапе" - могли подумать вы 😑 Мое личное предположение - использовать для поиска и генерации трендовой музыки в маркетинге, как сейчас многие уже делают с видео креативами. Ну и просто потому что 7 лет моего опыта в аудио процессинге никуда не делись и мне все равно интересно поглядывать, что там происходит 🐵 @neural_prosecco

📌#шпаргалка GraphRAG за 2 минуты Классический RAG — это ctrl+F на стероидах: вопрос → ищем похожие куски текста → LLM отвечает по ним. Отлично работает для точечных вопросов («что такое LoRA?»), но ломается на глобальных («какие основные темы всего корпуса?») — ответ размазан по документам, и ни один чанк его не содержит. GraphRAG решает это так: 1️⃣ LLM заранее проходит по всему корпусу и извлекает сущности и связи → получается граф знаний 2️⃣ На графе запускаем кластеризацию (Leiden) → темы и подтемы 3️⃣ Для каждого кластера LLM пишет саммари → «оглавление с аннотациями» 4️⃣ Глобальный вопрос отвечается по схеме map-reduce: сначала каждый кластер отвечает независимо (map), затем частичные ответы объединяются в финальный (reduce) Ключевой trade-off: почти вся работа переезжает в индексацию (дорого, LLM читает весь корпус), зато появляются multi-hop рассуждения и ответы «по корпусу в целом». Правило выбора:

точечный факт → обычный RAG. «В целом», «как связаны», «какие тренды» → GraphRAG. На практике часто гибрид.

#памятка #шпаргалка