Я поставил личный рекорд: еще никогда так долго не прокрастинировал написание двух параграфов текста 👀

Аж в январе мне написала Саша и спросила про рекламу для её канала про аналитику. Меня настолько зацепила ламповость её канала, что я пообещал поделиться им бесплатно, потому что такой контент нужно продвигать.

Саша работает аналитиком в Авито и пишет про собеседования, карьеру и самозванство, работу, а так же много личного. Меня особенно зацепило, что она написала про переговоры о зарплате через призму теории игр, как и я в своей методике. Но в отличие от меня она действительно что-то понимает в теории игр, потому что работала в лаборатории ВШЭ и может похвастаться статьей 👀.

А ещё Саша рисует научпоп комиксы

Словом очень ламповый канал, поглядите. 👀

Разбавим набившее оскомину AI-думерство. Вот неплохой, достаточно короткий и не слишком душный тейк о том, почему из текущих LLM не получится никакого AGI.

https://www.lesswrong.com/posts/oKAFFvaouKKEhbBPm/a-bear-case-my-predictions-regarding-ai-progress

Правда автор все равно дает нам примерно до 2030 👍

Как по мне весь аргумент не очень сильный сам по себе, но автор может оказаться прав.

Борис опять у микрофона 🎤

💬 Путь от программиста до ML-инженера в eBay

💬 Про модели мира и ML простым языком

💬 И, конечно, — вопросы от зрителей

▶️ Open Talks c Борисом Цейтлиным — Смотреть на YouTube

Обучи алгоритмы YouTube: ставь лайк и комментируй видео 🦾

Новый выпуск #OpenTalks совсем скоро, оставайся с нами 😎

#AITalentHub #ITMO #NapoleonIT

🎉 Тем временем, мы с коллегами выложили на arXiv новый 4-страничный препринт про применение Sparse AutoEncoders (SAE, разреженные автоэнкодеры) для детекции искусственно сгенерированных текстов 🎉 (чтобы подробно разобраться, как работают SAE, можно начать, например, отсюда: https://transformer-circuits.pub/2022/toy_model/index.html ; если же говорить вкратце, SAE - это один из способов извлечь более "распутанные" и интерпретируемые фичи из эмбеддингов LLM-ки). В процессе работы над исследованием к моим постоянным соавторам присоединились два новых: Антон ( https://www.tgoop.com/abstractDL ) и его коллега Полина, которые очень помогли с экспериментами и текстом на финальных стадиях!

Сама же работа называется "Feature-Level Insights into Artificial Text Detection with Sparse Autoencoders" ( https://arxiv.org/abs/2503.03601 ) 🤓 и заключается в следующем:

Мы взяли модель Gemma-2-2B, навесили на нее предобученный SAE (gemmascope-res-16k) и начали подавать на вход различные LLM-сгенерированные тексты. Далее мы:

а) Детектировали LLM-генерацию по фичам SAE (интересно, что качество такой детекции оказалось лучше, чем детекции по оригинальным эмбеддингам Gemma!);
б) Отобрали 20 наиболее важных для детекции фичей с помощью бустинга и проанализировали их смысл, чтобы разобраться, какие именно отличия человеческих текстов и LLM-сгенерированных были "пойманы" этими фичами.

Анализ фичей проводился тремя основными способами: ручной интерпретацией (вручную смотрели, чем отличаются те тексты, на которых значение фичи низкое, от тех, на которых оно высокое), авто-интерпретацией (то же самое делала LLMка) и steering-ом. В последнем способе, в отличие от предыдущих, мы подавали на вход Gemma-2-2B не весь пример из датасета, а только промпт. Продолжение же мы генерировали с помощью самой Gemma-2-2B и при этом вектор, соответствующий выбранной фиче в эмбеддинге модели искусственно увеличивали или уменьшали, чтобы посмотреть, как это влияет на результат генерации. Далее GPT-4o автоматически интерпретировала, чем тексты, сгенерированные при уменьшенном значении нужного вектора, отличаются от текстов, сгенерированных при увеличенном значении (также про steering см. посты https://www.tgoop.com/tech_priestess/1966 и https://www.tgoop.com/tech_priestess/1967 ).

Результаты интерпретации в целом вполне соответствуют тем интуитивным представлением о сгенерированных текстах, которое обычно формируется у людей, которые часто пользуются LLMками (см. https://www.tgoop.com/abstractDL/320 ): согласно нашему анализу, сгенерированные тексты чаще оказывались водянистыми, заумными, чрезмерно формальными, чрезмерно самоуверенными, а также чаще содержали повторения, чем человеческие тексты. Также мы описали несколько легко интерпретируемых признаков сгенерированности для отдельных доменов и моделей и другие наблюдения (о которых подробнее можно почитать в тексте самого препринта).

#объяснения_статей

# Нечего добавить? Не усложняй

Не знаю отчего, но очень популярен такой паттерн:


try:
do_thing()
except Exception as e:
logging.error("Doing thing failed")
return None

То есть обработка ошибки, которая уничтожает информацию и не добавляет никакой пользы.

Прямо сегодня я столкнулся с этим в langchain (конечно же 👀). Он имеет привычку прятать все внутренние ошибки и заменять их на свои, абсолютно бесполезные.

Причем это не только про Python. Думаю у всех такое было, что на каком-нибудь сайте вылетает: "Что-то пошло не так!" Давай, детектив, разгадай в чем проблема.

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

Возможно есть какое-то суеверие, что у пользователя будет разрыв мозга если он увидит "exception KeyError(...)" вместо "Произошла ошибочка 😳🥰." Однако второй вариант ни капли не понятнее первого!

Есть редкие продукты которые просто показывают ошибку. Примерно в половине случаев я могу догадаться в чем проблема и обойти её. Во второй половине случаев я могу хотя бы скопировать ошибку когда обращусь в тех поддержку.

Существуют очень редкие случаи когда нельзя показывать ошибки из соображений безопасности. Это исключения.

🔹🔹🔹

Просто верни ошибку как есть. Не усложняй.

Перезапись ошибки другой информацией имеет смысл только если это лучше помогает решить проблему. 🤪

В целом опыт на три с плюсом, почти четыре.

Сначала про плюсы. Очень приятный интерфейс. Cursor конечно монстр UI/UX. Очень простое погружение и онбординг. Самое главное: это работало. Если claude code agent за два часа работы не приблизил меня к желаемому результату, то здесь наблюдается прогресс. То, что осталось после часа работы, гораздо лучше, чем ничего. Cursor гораздо лучше понимал целевой вайб. В целом прикольно.

Однако мне кажется, что без курсора я бы продвинулся примерно так же. Было слишком много случаев когда агент шел не в нужную сторону, но это не было сразу очевидно, чтобы просто откатиться. Поэтому позже приходилось разбираться. В итоге процесс работы прерывается и приходится выходить из режиме решения задачи и переходить в режим "разбираемся в коде незнакомого интерна."

Самый неприятный момент (начинается около 57 минуты) был когда ассистент написал вызов трех методов:
1. Распарсить категории.
2. Распарсить изображения.
3. Распарсить аннотации.

Странность там была уже в том, что первые два метода, как и ожидается, парсили дикты и возвращали питон объекты. А третий почему-то ничего не возвращал, а делал что-то внутри себя. Это очень нечеловеческий и неинтуитивный способ написать кусок кода: две вещи работают так, а третья, функционально такая же, в другой парадигме. Закопавшись внутрь я понял, что ассистент написал третью функцию с сайд эффектом. То есть она не возвращала то, что распарсила, а сразу куда-то записывала. Это снова проблема непослушания: я прописал в правилах, что ожидаю функции и методы которые делают одну вещь без сайд эффектов, но модель решила подзабить на это.

Ничего, поправили. После шага парсинга аннотаций добавился шаг связи аннотаций и изображений (в COCO формате их надо сопоставить друг-другу). Потом ассистент пошел прогонять тесты, начал их править, внес множество изменений. И удалил шаг связи, который только что добавлял. Но вдруг тесты проходят!

Я смотрю в код и не понимаю как так может быть. То есть аннотации парсятся, результат записывается в переменную, а потом она нигде не используется. Её даже VSCode подсвечивает: смотри, этот кусок кода не нужен.

Получается мы распарсили аннотации, потом просто выбросили их, а тесты всё равно проходят. Не должно работать, но работает – очень плохая ситуация. Значит или тесты неправильные, или код работает не так, как мне кажется. Оказалось второе. На самом деле вторая функция, которая парсила изображения, уже записывала всё куда нужно. То есть она выглядела будто там нет сторонних эффектов, будто это правильная "делаю одну вещь" функция, а на самом деле это была подстава 👀.

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

Дело так же в качестве. Я поймал эту проблему только потому, что у меня очень четкое представление о том, что я хочу получить. И то она вскрылась случайно. Как много программистов заботятся о том, чтобы каждая функция делала одну вещь? Может процентов десять. Как много не-программистов/вайбкодеров? Ноль. Значит 90% программистам и 100% вайбкодерам Cursor поможет написать код со скрытым приколом 🙄. В общем готовьтесь через пару лет поддерживать чье-то курсорное легаси где возможно всё и в любом куске кода может обнаружиться пасхалка.

В общем смешанные ощущения. Но скорее положительные. Однако точно не идет речи ни о каком "В 100Х РАЗ ЛУЧШЕ ПРОГРАММИСТЫ НЕ НУЖНЫ!1!11" Я напоминаю, что мы тут всё ещё пытаемся прочитать JSON с диска.

Вот это пожалуй лучший перл LLM кода сегодня 👀

Работало кстати