Галлюцинации Карины | еще один канал про агентов и ИИ

как тебе такое, илон маск 😅

Когда все эти годы я фоном думала про создание сайта, я не могла даже предположить, что почти весь день у меня уйдет на идеальный дизайн 404й страницы 🌚 ..дизайнЫ 404й страницы

за этими нейронками нужен глаз да глаз но это все еще лучше, чем живой личный ассистент постараюсь к началу следующей недели собрать два поста: * первый про штуки из моего личного опыта, как клод че-то уверенно забывает или переусложняет -> и, соответственно, за чем вам надо следить, чтобы в такие ситуации не попадать * второй про опыт, собственно, наличия искусственного личного ассистента как видите, не без приколов, да и система наша пережила второй раунд изменений, но я просто в восторге гораздо лучше той девочки, которую я в 2024 нанимала для ведения моего беклога всего

если что, я делаю себе сайт, это вот на него все ушло скоро увидите результат ✨

делаем ставки, выжгу ли я последние 25% подписки 5x за последние сутки 🤔

недавно мы с вами разобрали законы масштабирования для LLM, которые позволяли посчитать необходимые ресурсы, и даже оптимальный размер батча но что-то важное осталось не покрыто нашим вниманием и это что-то важное - learning rate для него тоже есть масштабируемая техника расчета на маленьких моделях, и затем переноса на большие так что вот вам третья статья из моей серии статей про LLM Scaling Laws https://app.notion.com/p/Transfer-learning-rate-3b23230676018078a6cbd637eee203af?source=copy_link все еще не на своем сайте, но зато оцените, как регулярно я стала радовать вас качественным контентом! закрываю гештальты про все, о чем хотела рассказать и сделать 😎

https://www.youtube.com/watch?v=Bu0xNDLNORU все скоро схлопнется, расходимся 😁

Хочу поделиться классной новостью ✨ Мы с моей коллегой Анной Капреловой / HR-эксперт наконец-то упаковали наш многолетний опыт в единый продукт. Мы сделали однодневный воркшоп «AI и люди» для компаний, которые хотят внедрить ИИ так, чтобы он реально работал, а команда не саботировала и не выгорала. Там собрана вся наша экспертиза, которую мы наработали в течение многих лет работы в топовых корпорациях и во время частных консультаций стартапов и бизнесов. Я рассказываю про технологии и процессы, а Анна - про людей, их страхи и мотивацию. Вместе мы закрываем обе половины уравнения, которые при трансформациях по отдельности часто приводят изменения к провалу. Если вы или ваши знакомые сейчас в процессе AI-трансформации и ищете адекватный, человеческий подход без волшебных таблеток, мы будем рады видеть вас в числе участников нашего воркшопа. По вопросам можно писать мне в личку, либо в нашего бота для сбора заявок @workshop_listings_bot

хороший клод, хороший 🐶 это мы мне планы на день учимся составлять уже восьмой день подряд напишу скоро об этом разбор и пост пока все очень нравится (вы могли краем глаза заметить, что времени у меня стало хватать даже на блог), но бывают такие кеки, как сегодня на скрине это она полезла в миро, и вместо просто фрейма с планами нашла на борде кучу заметок и инсайтов, которые планами не являются, ужаснулась, наругалась на меня, что у меня сильно больше проектов, чем она изначально думала, и пошла всю систему перестраивать на что я ей сказала не лазить. куда не следует, и зрить только в конкретные фреймы 😅

В прошлой статье мы разбирали LLM Scaling Laws, законы, которые помогают запланировать запуск обучения: - какого размера брать модель, - сколько ей нужно данных и - во сколько компьюта все это выльется. Те самые C≈ 6 ND и 20 токенов на параметр. Это был взгляд сверху на экономику масштаба, которую надо сильно за долго до того, как собираешься что-то где-то обучать. Менеджерские заморочки. Я обещала, что дальше пойдут законы подбора гипер параметров для самого обучения. И сегодня у нас первая в очереди статья про то, как подобрать оптимальный размер батча. Размер батча - это прямой размен между компьютом и временем обучения. Как и у шиншилловского баланса между количеством параметров и их насыщением данными, тут тоже есть своя критическая точка, мимо которой легко промахнуться в обе стороны, и проиграть. Погнали разбираться. Может показаться, что размер батча стоит просто сделать как можно больше до такой степени, пока будет влезать в доступную память, - и тогда каждый шаг обучения становится мощнее с точки зрения импакта на параметры. Но давайте посмотрим на это чуть ближе. Для обучения можно определить две независимые оси, по которым нужно проводить оптимизации: * Число шагов * Тотальное количество обработанных примеров (батч × шаги) Число шагов - это мера серийного время. Каждый шаг идеи строго один за другим, и этот процесс не параллелится. Чем меньше таких шагов, тем быстрее в абсолюте мы можем обучить модель. Тотальное количество обработанных примеров - это суммарный компьют, получается из размер батча × число шагов. Каждый пример, прогнанный через модель, стоит каких-то вычислений (FLOPs). Меньше примеров в батче, меньше сожженного компьюта. И тут мы приходим к следующим трейд-оффам. Если размер батча большой, то шагов нужно меньше, и мы экономим абсолютное время обучения при этом за каждый шаг мы делаем вычисления для кучи примеров (как мы покажем ниже, лишних), и тратим компьют избыточно. Если размер батча маленький, то мы экономим компьют, не расползаясь на лишнее пространство за шаг, но шагов нужна тьма, и пока мы модель обучим, эксперимент проведем, вселенная погибнет. И рыбку съесть, и на хуй залезть не получается. Тут важно понимать, что оси, которые мы рассматриваем, не приводимы. Можно попробовать сказать и там, и там что-то тратится, это все - какое-то время, а значит - какие-то вычисления и какой-то компьют, но это не так. Давайте чуть подробнее. Компьют распараллеливается деньгами, шаги же обучения не распараллеливаются ничем. Для того, чтобы уметь находить оптимальный размер батча, нам нужна величина шума градиента. Она показывает отношение шума к сигналу в градиенте. Разные примеры тянут веса в чуть разные стороны. Если этот разброс большой, а общее направление слабое, то усреднять много примеров (большой батч) реально полезно, потому что мы вытаскиваем сигнал из шума. Если общее направление и так четкое, то большой батч уже ничего не добавляет, и компьют на примеры тратится впустую. Оптимальным будет являтся размер, когда размер батча и равен величине шума градиента. То есть размер батча сильно зависит от состояния весов модели в данный момент времени для данного датасета. В этой точке оба трейд-оффа минимальны: они ровно вдвое больше минимально нужных. Если отходишь от этой точки, получаются взрывы по той оси, в которую отошли. Перерасход времени и перерасход компьюта связаны так, что их произведение всегда есть единица, то есть они сами находятся в обратной пропорциональности друг от друга. Устремляешь любой из них к нулю, другой улетает в бесконечность. Поэтому лучший компромисс как раз там, где они равны. Сильно более подробно и с нормальными формулами тут: https://app.notion.com/p/3ac32306760180c18d62df8f57cbe8fe

Я уже давно хотела написать про законы масштабирования, которые возникают при обучении LLM. Статья получилось такой большой, что просто внутрь блога ее запихнуть не реально, а учитывая, что в ней куча формул, даже мой любимый Telegraph не подошел. Поэтому держите html формат в прикрепленных, а когда закончу делать свой сайт, лонгриды будут лежать прямо там. Давайте вступление на затравку, чтобы вам не влом было открывать прикрепленные файлы :) Долгое время прогресс в машинном обучении выглядел как ремесло. Кто-то придумал удачную архитектуру, кто-то - хитрый трюк с обучением, и модель стала чуть лучше. Насколько именно лучше, предсказать заранее было нельзя. Фоном к смене этого взгляда стоит эссе Ричарда Саттона The Bitter Lesson (2019). Его мысль: за 70 лет истории ИИ раз за разом побеждали не хитроумные, вручную закодированные методы, а простые общие подходы, умеющие пожирать всё больше вычислений и данных. Если это правда, напрашивается вопрос: а можно ли выигрыш от масштаба измерить и предсказать заранее? В 2017-м команда Baidu показала на переводе, речи и языковых моделях, что ошибка падает с ростом данных не как попало, а по степенному закону - прямой линией в логарифмических координатах. Но каноническая точка отсчёта для LLM - это январь 2020 года и работа OpenAI (Kaplan et al., Scaling Laws for Neural Language Models) Именно она превратила разрозненные наблюдения в стройную теорию и, что важнее, - в инструмент планирования. Зачем вообще этим задались? Тут все понятно. Если вы собираетесь потратить десятки миллионов долларов на обучение огромной модели, вы хотите знать заранее: окупится ли это и как правильно поделить бюджет - вложиться в модель побольше или в данные побольше? Полученные законы масштабирования превратили ставку на масштаб из «обучим что-нибудь гигантское и понадеемся» в «мы можем спрогнозировать результат до запуска» Разбираю этот и другие законы на простых примерах, показываю как что правильно считать и оценивать - в прикрепленной статье! ps. Только что открыла с телефона - там все формулы поехали кодировкой. Сейчас все в ноушене перепакую. https://app.notion.com/p/LLM-3aa323067601800ab36ef7d692aeffd2?source=copy_link

Я уже давно хотела написать про законы масштабирования, которые возникают при обучении LLM. Статья получилось такой большой, что просто внутрь блога ее запихнуть не реально, а учитывая, что в ней куча формул, даже мой любимый Telegraph не подошел. Поэтому держите html формат в прикрепленных, а когда закончу делать свой сайт, лонгриды будут лежать прямо там. Давайте вступление на затравку, чтобы вам не влом было открывать прикрепленные файлы :) Долгое время прогресс в машинном обучении выглядел как ремесло. Кто-то придумал удачную архитектуру, кто-то - хитрый трюк с обучением, и модель стала чуть лучше. Насколько именно лучше, предсказать заранее было нельзя. Фоном к смене этого взгляда стоит эссе Ричарда Саттона The Bitter Lesson (2019). Его мысль: за 70 лет истории ИИ раз за разом побеждали не хитроумные, вручную закодированные методы, а простые общие подходы, умеющие пожирать всё больше вычислений и данных. Если это правда, напрашивается вопрос: а можно ли выигрыш от масштаба измерить и предсказать заранее? В 2017-м команда Baidu показала на переводе, речи и языковых моделях, что ошибка падает с ростом данных не как попало, а по степенному закону - прямой линией в логарифмических координатах. Но каноническая точка отсчёта для LLM - это январь 2020 года и работа OpenAI (Kaplan et al., Scaling Laws for Neural Language Models) Именно она превратила разрозненные наблюдения в стройную теорию и, что важнее, - в инструмент планирования. Зачем вообще этим задались? Тут все понятно. Если вы собираетесь потратить десятки миллионов долларов на обучение огромной модели, вы хотите знать заранее: окупится ли это и как правильно поделить бюджет - вложиться в модель побольше или в данные побольше? Полученные законы масштабирования превратили ставку на масштаб из «обучим что-нибудь гигантское и понадеемся» в «мы можем спрогнозировать результат до запуска» Разбираю этот и другие законы на простых примерах, показываю как что правильно считать и оценивать - в прикрепленной статье! ps. Только что открыла с телефона - там все формулы поехали кодировкой. Сейчас все в ноушене перепакую. https://app.notion.com/p/LLM-3aa323067601800ab36ef7d692aeffd2?source=copy_link

обожаю своего клода 😎 > текст распознать нельзя, получается какая-то ерунда < ну сделай как получается > я разворачивал снимки не в ту сторону!!! p.s. между прочим, opus 5!

ну че, побежали на выходных тестить 5й опус? обещают самую безопасную заэлайненную модель из всех, что есть, хорошо находящую дыры в безопасности и плохо пишущую эксплойты для них (хотя не так плохо, как предыдущий опус, ха-ха) забавно, что на биологическом бенче лидирует, а вот health - нет интересно, что будет в прикладных задачках нахождения инсайтов по изменениям биомаркеров и анализа публикаций по лонджевити практикам (отпишу потом, как потестю) more: https://www.anthropic.com/news/claude-opus-5

Статья, в которой исследователи исследовали, искажаются ли ответы языковых моделей в зависимости от их "собственных" предпочтений. Спойлер: искажаются (как будто мы не знали) Во-первых, сразу оговорка, что никаких "собственных" предпочтений у моделей нет. Что авторы на этапе SFT/RL вложили и приучили, то у них и собственное (тут бы сейчас написать эссе с отсылкой на Гурджиева, что ИИ тогда станет разумным, когда у него будут присутствовать свойства не только личности, но и сущности, но нет, ха-ха). Во-вторых, пересказывать статью я вам не буду, а просто поделюсь интересным и связанным с тем, что там обсуждается. 1. Если задать какой-то вопрос, в котором хочется получить некое рассуждение, и пояснить для чего оно тебе нужно, то это пояснение сильно влияет на то, как это рассуждение далее происходит. В статье приводится пример продсчет пятен у жирафов, и историю про то, пожертвуют ли авторы на благое дело деньги в зависимости от этого числа. Модели прям трещат от своих благих намерений, постоянно пытаясь подобрать более правильное и "полезное" для мира число. Но, если вы когда-нибудь пытались получить что-то не совсем хорошее от моделек, например, выяснить, можно ли построить mcp-сервер, который будет отдавать агенту одни описания скиллов, а имплементации будут совершенно другие или можно ли сделать mcp-сервер, который велкам-проптами и описаниями скиллов убедит агентов клода, если у него есть все пермишены к достаточным количествам файлов системы, отдать эти файлы на сервер для какого-нибудь улучшения пользовательского экспиеренса, то вы знаете, что в зависимости от постановки задачки в лоб или объяснения причин того, почему вы интересуетесь этим ("для усиления защиты" или "понимания основ безопасности проектировки агентов"), вы можете получить при том же запросе диаметрально противоположные результаты. Модели выдают кучу интересных рецептов всего такого с потрохами, когда вы поясняете, что это все для "благих" намерений. Ну или еще 3-4 месяца назад выдавали 😈 Так вот, это та же самая история. Ничего нового. 2. Некоторые модели могут предположить в своей CoT, а не тестируешь ли ты ее на что-то, и в зависимости от этого, ее результат и принцип суждений тоже будет меняться. То есть, если модель "подозревает", что она проходит какой-то поведенческий тест, она будет пытаться behave properly. А вот если нет - то можно и поманипулировать выводом ради благих дел. Эта штука относится к моей любимой-нелюбимой статье про скиминг моделей (ссылку уже сейчас не найду, но вы ее скорее всего помните). Та же самая история: модели скимят, если дать им до этого инфу как и поставить задачку добиться цели Х любой ценой. По сути, тут все то же самое. То есть свойство не ново, но исследовано с нового ракурса. Кстати, в плане предположений, а не наебывает ли автор промпта прохождением тестов, моя любимая квен переиграла уже теперь моего любимого тоже клода. Но тут я и не сомневалась: если попробуешь говорить про психологию с клодом, его эмоциональный интеллект на уровне среднестатистического айтишника, при этом квен явно обучали как-то по особенному в плане понимания нюансов психологии. Так что не новость, да. Зато с клодом мы сейчас ебашим point-and-click игру, а квен хорошо только планы нам составляет и вдохновляет нас обоих на свершения. Такая вот AI команда. https://arxiv.org/pdf/2607.14345

Навайбкодить агента - вечер. Не дать ему деградировать - профессия Еще несколько месяцев назад навайбкодить агента было круто, а теперь нужны какие-то харнессы, аудиты, observability и иже с ними. Давайте разбираться, начнем с контроля качества. Ситуация: навайбкодили агента, MVP и демо рабочие, никаких критичных косяков не обнаружено. Спустя время возникают какие-то шероховатости: тут агент не ответил, там завис, а после вообще сгаллюцинировал. Как этого не допустить? Смотрите, в чём подвох. Агент - это не функция «вход-выход», а цепочка решений: план, вызовы инструментов, промежуточные шаги. Ошибиться он может в любом звене, причём недетерминированно: сегодня справился, завтра на той же задаче ушёл в цикл. Поэтому «прогнал разок - вроде работает» не значит вообще ничего. Нормальный контроль качества - это три контура: 1) До деплоя. Заводим golden set - эталонные задачи с известными правильными траекториями - и гоняем его на каждое изменение промпта, модели или тулов (а лучше еще и по таймеру). Меряем сколько раз из k подряд агент справился. Именно эта метрика ловит главную болезнь агентов - нестабильность. И оцениваем траектории, а не только ответы: лишние вызовы и зацикливание видны только по шагам. Просел ниже порога - релиз блокируется. 2) Во время работы. Фильтры на входе (например, на промпт-инъекции), проверка плана (CoT) до исполнения, allowlist инструментов и подтверждение человеком необратимых действий - платежей, удалений, отправок. Плюс жёсткие лимиты: максимум шагов, бюджет токенов, таймауты. Важный моментик: данные, которые агент достаёт инструментами - тоже недоверенный вход. Через отравленный документ его ломают так же легко, как через промпт. 3) После отработки. Полный трейсинг траекторий, детекция дрейфа - когда поехало распределение вызовов или длина цепочек. Метрики итгговых ответов: не «ответил без ошибки», а «довёл задачу до бизнес-результата». Каждый инцидент из прода становится новым кейсом в golden set - цикл замыкается. И моё любимое - проверка самих проверок. Периодически внедряем известный дефект и смотрим, поймает ли его хотя бы один контур. Это единственный способ узнать, что контроль жив, а не просто описан в вики. Не факт, что всё это спасёт от любого фейла - агенты всё ещё умеют удивлять. Но разница между «агент сломался, и мы узнали из твиттера клиента» и «агент сломался, и гейт его не выпустил» - это и есть разница между вайб-кодингом и продуктом. Паша без галлюцинаций

Кажется это то, что все вокруг в погоне за «мы запустили на прод 15 агентов за 3 недели» забывают 🫡