Нас стало в 3 раза больше!

... ну и что, что с 9 до 31, а не со 100 до 300 подписчиков, в три же раза :)

Спасибо всем, кто подписался за 3 дня моей мини-рекламы канала 🥰

Постараюсь подкидывать вам интересности 🙂

Сегодня вечером выложу саммари статейки про ИИ и долгосрочную поддерживаемость его кода.

Со всех сторон очень много новостей, какой ИИ прекрасный, а мой аналитический мозг не может не исследовать вторую сторону медали. Поэтому, если мне будут попадаться новости о том, где ИИ не такой прекрасный буду делиться с вами :)

ИИ и поддержание кода в долгосрочной перспективе

Исследователи из Университета Сунь Ятсена и Alibaba Group представили SWE-CI - бенчмарк*, позволяющий оценить, насколько модель способна писать код, поддерживаемый в долгосрочной перспективе.

*Бенчмарк - стандартизированный тест или набор задач (датасет), используемый для объективной оценки и сравнения производительности, точности, скорости и возможностей моделей ИИ.

Для ленивых - кратко :)

Китайцы заставили ИИ поиграть в долгосрочное развитие кода - сделав ИИ-Архитектора, который выдает требования на естественном языке, и ИИ-программиста, который их исполняет. Ну что бы прям как вживую! 😏

А затем начали измерять, сколько работающих юнитов упадет после очередной итерации доработок.

15 из 18 моделей смогли не ухудшить код в 37% случаев и менее.

А если интересны подробности, читай дальше :)

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

Исходные данные
Исследователи прошлись по Python-репозиториям на Github, выбирая по критериям: активно поддерживается не менее трех лет, набрал более 500 звезд, содержит конфиги, зависимости и наборы юнит-тестов, распространяется под разрешительной лицензией (такие как MIT или Apache-2.0).

Затем, оставив только основную ветку, выделили такие кусочки истории, в которых зависимости кода неизменны. Начальная точка такого кусочка - "база" с которой стартовал ИИ, конечная - "эталон" к которому он должен был прийти.

После проверили корректность отработки тестов и выбрали топ-100 кусочков истории из 68 репозиториев, в которых присутствует более длинная история, большее число коммитов и у которых было значительное число изменений (сравнивали по запуску тестов). В среднем, кусочек истории состоял из 233 дней и 71 последовательного коммита + в каждом кусочке не менее 500 строк измененного кода (без учета тестов).

Как?
ИИ должен был превратить "базовую" кодовую базу в "эталонную", путем итераций разработки.

Для итераций использовалось 2 ИИ агента - Архитектор и Программист.

Тесты, релевантные эталонной базе, запускались на базовой версии. Архитектор должен был проанализировать ошибки упавших тестов и сформировать список требований Программисту, причем этот список требований формировался на естественном языке. Также допустимо было формулировать не более 5 требований за раз, поэтому Архитектор должен был выбирать наиболее критичные.

Программист реализовывал требования Архитектора.

Оценка "поддерживаемости" кода
Для оценки "поддерживаемости", т.е. корректности работы кода в будущем, сравнивалось, сколько юнит-тестов из исходного их количества выполнилось успешно после очередной итерации доработки кода.

При этом более поздним итерациям доработок давался больший "вес", чтобы как раз и выделить модели, чей код в будущем работал менее корректно.

Итог
См. график выше. По оси Y - модель, которую тестировали, по оси X - доля нулевых регрессий от всех итераций доработки (нулевая регрессия - ни один старый тест не сломался после доработки кода).

15 из 18 моделей показали результат ниже 37% - т.е. доля таких доработок, при котором тесты, что должны были работать, не сломаны, ниже 37%.

Однако 2 модели Claude показали очень неплохие результаты в 51 и 76 процентов.

Также попробовали варьировать метрику, дающую больший вес итерациям, и выяснили, что модели MiniMax, DeepSeek и GPT склонны к долгосрочным улучшениям, Kimi и GLM - к более быстрым, но менее поддерживаемым результатам. Qwen, Doubao и Claude оставались стабильными при разных значениях метрики.

Также внутри одного "семейства" более новые версии модели давали лучшие результаты.

- - - - - - -

Такие вот дела. Всё еще осторожнее с генерацией кода с ИИ - в долгосрок они пока умеют не очень :) Но совершенствуются!

Оригинал статьи можно скачать тут + переведенная от меня в первом комментарии. Осторожно, там немного математики :)

ИИ-сериальчик на вечер

Всем пятничное 🙂

Рабочая неделя закончилась, значит, можно и сериальчики посмотреть.

Очень давно стали модными вертикальные сериальчики формата reels, но в них снимались люди. Теперь их генерируют в ИИ! (и продают за сто тыщ мильенов уроки по их созданию)

Один такой меня зацепил, на злобу дня, так сказать. Рекомендасьон сериальчика про мессенджеры! Тут все: Инста, Телеграм, Ватсапп, Макс... и даже Роскомнадзор с Аськой :)

Юмор неплохой, картинка приятная, ностальгию вызывает. Кидаю вам вторую серию, как самую затравочную, остальное в первом комментарии)

Объявляю у себя на канале неделю техподдержечных кейсов! 🙃

Да, не самое смешное, что могло бы быть, но надо же тут полезный какой-то для аналитиков контент выкладывать, чтобы они подписывались 🙂

хотя ставлю на то, что именно аналитики на этой неделе не совсем поймут, зачем им что-то такое

Техподдержечное #1
Или как решать проблемы методом обезьянки

Задача: протестировать поиск по топику Kafka с использованием kcat.

Вообще, пока что, самый прекрасный инструмент, что мне попадался. Все самое прекрасное почему-то всегда линуксовое и консольное 🫥

Да-да, аналитик и тестировать. Просто без этого инструмента я буду через три недели как без рук, т.к. не смогу доказывать, кто не прав.

И есть у нас 2 кафки. Своя и чужая. И чужая с поиском по ней нужна больше, т.к. часто она - единственный источник правды на тему, чья подсистема виновата в проблемах обработки.

Запускаем команду на поиск, смысл которой:

Найди мне сообщение в промежутке с 14:30 до 14:40 с вхождением строки "ромашка"

На своей кафке все прекрасно.
На чужой...

ERROR: offsets_for_times failed: Local: Timed out

Ага. На вход скормили время 14:30 и 14:40, но по этому времени кафка не смогла найти оффсеты сообщений. Казалось бы, ну нет там сообщений за это время, отстань, противная. Но нюанс в том, что я сначала убедилась, что сообщение есть, а потом пошла его искать.

Как я развлекалась в течение следующего часа:

1️⃣ Решила все же проверить таймстемпы на адекватность.
Для этого запустила такой же поиск, но с другой машины, с которой проблем никогда не было. И оно... работает!

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

2️⃣Нашла, как включать дебаг на kcat.
Включила. Ничего особо не поняла 🥲

3️⃣Решила оставить запрос как есть, но поменять топик, по которому идет поиск.
И... оно начало работать и... зависло.
Сменила топик еще раз. Не работает.
И еще раз... заработало 🥲

4️⃣ Теперь включаем дебаг на работающем топике, а потом на неработающем!
И вот он, метод обезьянки - я ничего не понимаю в логе, но могу глазками сравнить позитивный и негативный случаи, буквально посимвольно, чтобы обнаружить, где всё пошло не по плану.

5️⃣ Нашла. Понятнее не стало.

6️⃣Отчаялась и начала писать ИИ, чтобы скормить ему обезличенный лог.

7️⃣ Получила, что команда в целом нерабочая, т.к. kcat, оказывается, может принять на вход только один таймстемп. Вздохнула.

8️⃣ Уверила ИИ, что команда рабочая. Попросила посмотреть на лог, а не бежать впереди паровоза.

9️⃣ ИИ решил, что проблема в недоступности брокера. Предложил попинговать тот, что указан в логе.

Брокер из лога пинговался. Да и до этого я пинговала несколько брокеров. Но дело в том, что на этой кафке брокеров было под 60 штук.

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

Какие выводы из этой увлекательной (увлекательной же?..) истории можно сделать:

1️⃣ Если что-то не работает - накидай любых гипотез, почему. Желательно таких, которые ты можешь проверить.

2️⃣ Найди инструмент, с помощью которого можно понять, что не работает внутри исследуемого компонента. В моем случае - как включить дебаг.

3️⃣ Если что-то, что ты изучаешь, ругается на переменную Х (у меня - таймстемп) - проверь адекватность этой переменной. Если с ней все в порядке - меняй соседние переменные. Но только по одной. Если найдешь рабочий кейс - иди к п.4

4️⃣ Даже если ты ничего не понимаешь, но можешь хоть что-то сравнить глазами (как логи для позитивного и негативного кейса) - сравни. Даже если там написана абракадабра - шанс найти идею не нулевой.

Последний вывод - в такие моменты я понимаю важность насмотренности, о которой часто говорят на собесах. Ну где, как не в реальных проектах мотать на ус нюансы инженерных решений! Или почему 8 брокеров из 60 в другой подсети НУ ПОЧЕМУ 💯

Тут снова только вздохнуть. Админь.

Техподдержечное #2
Или как выгодно себя показать благодаря лени соседа

Приходит ко мне фронтендер и говорит - на меня тут багу повесили, а я что-то хз, что с ней делать, я не понимаю, при чем тут фронт.

Так-то я сама вообще в другой компании работаю, и тем более хз, но... как не поковыряться-то 😏

Задача: с тестового стенда уходит форма, в которой один из параметров - строка, в ней по смыслу должны быть ссылка. Там всё ок.

С предпродового стенда форма падает в ошибку после отправки (возвращается неуспешный http-код), если указать ссылку ссылкой, а если вместо ссылки ввести строку, то всё ок.

Бэкендеры уже всё посмотрели. Проблема не на их стороне. До них даже запрос не доходит! И не на стороне тех, кто инфраструктуру настраивал.

Кто у нас остался? Фронт? А, он ничего не делает с этой ссылкой, только в метод передает? Не суть. Все же остальные не виноваты 🙂

Эта задача чуть более простая с точки зрения исследования, чем вчерашняя. Очевидно, что есть какая-то проверка на "ссылочность" строкового содержимого. Только вот интересно, она - просто какая-то регулярка или там что похитрее?

1️⃣ Если строка уходит без ошибок, а строка со ссылкой падает в ошибку - надо понять, в какой момент то, что находится в строке, становится ссылкой.

Для этого начинаем постепенно вводить в форму что-то, что будет "приближаться" к ссылке, например:
⏩"https"
⏩"https:"
⏩"https://"
⏩"https://www"
... и так далее.

У нас ссылкой стало такое:
<протокол>://www.<домен>.<а тут уже что угодно>

2️⃣ Как только обнаружили - проверяем, а можно ли как-то изменить "ссылку" так, чтобы она стала перестала вызывать ошибку.

Т.е. менять ее компоненты - протокол или домен.

В нашем случае оказалось, что отвергаются все ссылки, с доменом != домену стенда.
Ссылки с доменом стенда спокойно проходят, несмотря на то, что они тоже ссылки 🤡

Чувствуете, как запахло настройками от безопасников? 🙂🙂🙂

Выводы тут достаточно простые:

1️⃣ Если у вас на одном стенде "все работает", а на соседнем - "нет", то проблема почти наверняка в разности стендов. Начиная от того, что просто нечаянно разные ветки кода на них оказались, заканчивая проблемами с железом.

Что-то легче находится, что-то проще, но подумать надо в первую очередь об этом.

2️⃣ Если у вас строка, и "просто строка" работает, а "сложно строка" - нет, значит, надо, шаг за шагом, буква за буквой понять, в какой момент одно превращается в другое.

3️⃣ Выявив точный вид того, что вызывает проблему, можно попробовать этот вид всяко поизменять. Но тоже по одной части за раз! Так можно сделать проблему более узкой.

А фронтендер на следующий день выглядел очень умным в глазах менеджеров.

Иногда стремление разобрать даже то, что напрямую к тебе не относится, может принести интересные результаты.