Forwarded from Запрети мне псевдолейблить
4 место в #BirdClef2025
Коротко, но ценно: иногда простота выигрывает.
Поскольку на BirdCLEF нас оценивают именно по AUC, логично оптимизировать его напрямую.
AUC-лосс устойчив к переобучению, но не поддерживает soft labels, как, например, кросс-энтропия.
Что еще работало и не работало:
Semi-supervised learning на неразмеченном датасете:
Сначала обучил 10 моделей EfficientNet на размеченной части.
Сгенерировал «псевдо-лейблы» для неразмеченных данных.
Обучил следующий раунд моделей уже на объединённом наборе.
Отказался от самодистилляции и сложных схем — не заводилось.
Лотерея или мастерство? Автор поднялся с 11 места на 4-е на прайвете! Возможно, дело не только в удаче.
Коротко, но ценно: иногда простота выигрывает.
Поскольку на BirdCLEF нас оценивают именно по AUC, логично оптимизировать его напрямую.
AUC-лосс устойчив к переобучению, но не поддерживает soft labels, как, например, кросс-энтропия.
class SoftAUCLoss(nn.Module):
def __init__(self, margin=1.0, pos_weight=1.0, neg_weight=1.0):
super().__init__()
self.margin = margin
self.pos_weight = pos_weight
self.neg_weight = neg_weight
def forward(self, preds, labels, sample_weights=None):
# Разделяем положительные и отрицательные предсказания
pos_mask = labels > 0.5
neg_mask = labels < 0.5
pos_preds, pos_labels = preds[pos_mask], labels[pos_mask]
neg_preds, neg_labels = preds[neg_mask], labels[neg_mask]
if pos_preds.numel() == 0 or neg_preds.numel() == 0:
return torch.tensor(0., device=preds.device)
# Веса отражают уверенность soft-label
pos_w = self.pos_weight * (pos_labels - 0.5)
neg_w = self.neg_weight * (0.5 - neg_labels)
if sample_weights is not None:
sw = sample_weights.unsqueeze(1).expand_as(labels)
pos_w *= sw[pos_mask]
neg_w *= sw[neg_mask]
# Считаем pairwise-разности и лог-лосс
diff = pos_preds.unsqueeze(1) - neg_preds.unsqueeze(0)
loss_matrix = torch.log1p(torch.exp(-self.margin * diff))
# Усредняем по всем парам с учётом весов
return (loss_matrix * pos_w.unsqueeze(1) * neg_w.unsqueeze(0)).mean()
Что еще работало и не работало:
Semi-supervised learning на неразмеченном датасете:
Сначала обучил 10 моделей EfficientNet на размеченной части.
Сгенерировал «псевдо-лейблы» для неразмеченных данных.
Обучил следующий раунд моделей уже на объединённом наборе.
Отказался от самодистилляции и сложных схем — не заводилось.
Лотерея или мастерство? Автор поднялся с 11 места на 4-е на прайвете! Возможно, дело не только в удаче.
Kaggle
4th place solution | Kaggle
Kaggle is the world’s largest data science community with powerful tools and resources to help you achieve your data science goals.
Forwarded from Запрети мне псевдолейблить
3 место в #BirdClef2025
Данные:
1. Выкорчевали человеческий голос с помощью паблик кернела с каггла.
2. Взяли весь датасет 2025 года и к нему доложили 80% датасета 2023 года, добавив 112 новы классов. Оставшиеся 20% данных 2023 использовали для валидации. Локальная валидация не билась с ЛБ, но такая схема давала лучшую оценку сходимости модели.
3. Дополнительно вытянули еще данных из обоих открытых источнико, Xeno-Canto и INaturalist.
4. Запсевдолейбили всю неразмеченную часть, чтобы еще немного улучшить итоговые модели
Модели:
Обучили зоопарк моделей на двух видах спектрограмм. Вообще почти всегда есть смысл покрутить параметы построения спектрограмм для того, чтобы увеличить разнообразие и не потерять в качестве. Главное одну модель не учить на двух видах.
Список моделей
tf_efficientnet_b0_ns
tf_efficientnetv2_b3
tf_efficientnetv2_s.in21k_ft_in1k
mnasnet_100
spnasnet_100
Интересные приемы для обучения:
1. Семплировали случайные отрезки, а не честную нарезку по 5 сек. Говорят, так лучше училось
2. Добавляли человеческий голос для аугментации. На мой взгляд не сильно вяжется с удалением голоса из изначального датасета, но видимо использовали этот прием чтобы голос 'равномерно' размазать по всему датасету
3. FocalLoss
4. Использовали Model Soup. Это способ 'ужать' в одну модель несколько чекпоинтов. Усредняем веса например 20 resnet c одинаковой архитектурой и обученных на одних данных. Получаем почти ту же стабильность, что и усреднение 20 отдельных предикшнов этих моделей, но со скоростью инференса и весом одного resnet.
Кстати, тут можно обычно докрутить и делать только GreedySoup: пробовать в ансамбль добавлять только те модели, которые делают предикты лучше. Но опять же, тут надо верить в свой CV, а в этом соревновании наверно никто не верил в свой CV.
Для сабмита использовали Post-processing with power adjustment. Идея проста, работает для очень классификации с очень большим числом классов. Берем предикты, из них выбираем n самых 'уверенных' и усиливаем их, занижая скоры для прочих классов.
Данные:
1. Выкорчевали человеческий голос с помощью паблик кернела с каггла.
2. Взяли весь датасет 2025 года и к нему доложили 80% датасета 2023 года, добавив 112 новы классов. Оставшиеся 20% данных 2023 использовали для валидации. Локальная валидация не билась с ЛБ, но такая схема давала лучшую оценку сходимости модели.
3. Дополнительно вытянули еще данных из обоих открытых источнико, Xeno-Canto и INaturalist.
4. Запсевдолейбили всю неразмеченную часть, чтобы еще немного улучшить итоговые модели
Модели:
Обучили зоопарк моделей на двух видах спектрограмм. Вообще почти всегда есть смысл покрутить параметы построения спектрограмм для того, чтобы увеличить разнообразие и не потерять в качестве. Главное одну модель не учить на двух видах.
Список моделей
tf_efficientnet_b0_ns
tf_efficientnetv2_b3
tf_efficientnetv2_s.in21k_ft_in1k
mnasnet_100
spnasnet_100
Интересные приемы для обучения:
1. Семплировали случайные отрезки, а не честную нарезку по 5 сек. Говорят, так лучше училось
2. Добавляли человеческий голос для аугментации. На мой взгляд не сильно вяжется с удалением голоса из изначального датасета, но видимо использовали этот прием чтобы голос 'равномерно' размазать по всему датасету
3. FocalLoss
4. Использовали Model Soup. Это способ 'ужать' в одну модель несколько чекпоинтов. Усредняем веса например 20 resnet c одинаковой архитектурой и обученных на одних данных. Получаем почти ту же стабильность, что и усреднение 20 отдельных предикшнов этих моделей, но со скоростью инференса и весом одного resnet.
Кстати, тут можно обычно докрутить и делать только GreedySoup: пробовать в ансамбль добавлять только те модели, которые делают предикты лучше. Но опять же, тут надо верить в свой CV, а в этом соревновании наверно никто не верил в свой CV.
Для сабмита использовали Post-processing with power adjustment. Идея проста, работает для очень классификации с очень большим числом классов. Берем предикты, из них выбираем n самых 'уверенных' и усиливаем их, занижая скоры для прочих классов.
Kaggle
3rd Place Solution | Kaggle
Kaggle is the world’s largest data science community with powerful tools and resources to help you achieve your data science goals.
Forwarded from Запрети мне псевдолейблить
Топ-2 в #BirdClef2025
В этот раз опытне птичники, у которых в команде чел с первым местом в 2022 и 2023 годах!
📊 Данные
Использовали данные из прошлых соревнований, что собственно и помогала в прошлые года +
Подтянули дополнительно записи из Xeno Archive.
Тут помог баг, который был обнаружен еще в 2023: API Xeno Archive выдаёт максимум 500 семплов на вид — большинство команд этого не учли. Багу два года, и его никто не чинит. Кто знает- тот знает
🎛️ Предобработка
Для обучения берём первые 7 секунд каждого файла и рандомно вырезаем 5 секунд.
Баланс между разнообразием данных и интуицией: голос птицы чаще слышен в начале записи.
🛠️ Архитектура и оптимизация
tf_efficientnetv2_s + RAdam
eca_nfnet_l0 + AdamW
Обе модели тренировали 50 эпох
Loss: Focal + BCE
Scheduller: Cosine LR
⚖️ Веса семплов
Учли с весами, чтобы компенсировать дисбаланс классов:
🚀 Ключевые бусты
1. Предтренинг на всём Xeno Archive
Вычистили низкочастотные классы и текущее тесто-трейн
Предобучили на задаче классификации и получили бекбон с глубоким пониманием спектрограмм записей животных
Результат: 0.84 → 0.87
2. Псевдолейблинг(запрещенная техника)
Предсказываем на неразмеченных данных → pseudo1
Оставляем только скоры > 0.5 → pseudo2
Зануляем слабые метки (< 0.1): pseudo2[pseudo2 < 0.1] = 0
Обучаем модель на таргет pseudo2 и повторяем цикл
После двух итераций: 0.87 → 0.89 → 0.91 (третий круг не даёт профита)
3. TTA
Сдвигали записи в Test time augmentation на 2.5 секунды влево и вправо, а потом усредняли предсказания.
0.91 -> 0.922
В общем опыт прошлых соревнований доовольно сильно решает, особенно если помнишь интересные баги связанные с источниками данных
В этот раз опытне птичники, у которых в команде чел с первым местом в 2022 и 2023 годах!
📊 Данные
Использовали данные из прошлых соревнований, что собственно и помогала в прошлые года +
Подтянули дополнительно записи из Xeno Archive.
Тут помог баг, который был обнаружен еще в 2023: API Xeno Archive выдаёт максимум 500 семплов на вид — большинство команд этого не учли. Багу два года, и его никто не чинит. Кто знает- тот знает
🎛️ Предобработка
Для обучения берём первые 7 секунд каждого файла и рандомно вырезаем 5 секунд.
Баланс между разнообразием данных и интуицией: голос птицы чаще слышен в начале записи.
🛠️ Архитектура и оптимизация
tf_efficientnetv2_s + RAdam
eca_nfnet_l0 + AdamW
Обе модели тренировали 50 эпох
Loss: Focal + BCE
Scheduller: Cosine LR
⚖️ Веса семплов
Учли с весами, чтобы компенсировать дисбаланс классов:
python
sample_weights = (
all_primary_labels.value_counts() /
all_primary_labels.value_counts().sum()
) ** (-0.5)
🚀 Ключевые бусты
1. Предтренинг на всём Xeno Archive
Вычистили низкочастотные классы и текущее тесто-трейн
Предобучили на задаче классификации и получили бекбон с глубоким пониманием спектрограмм записей животных
Результат: 0.84 → 0.87
2. Псевдолейблинг
Предсказываем на неразмеченных данных → pseudo1
Оставляем только скоры > 0.5 → pseudo2
Зануляем слабые метки (< 0.1): pseudo2[pseudo2 < 0.1] = 0
Обучаем модель на таргет pseudo2 и повторяем цикл
После двух итераций: 0.87 → 0.89 → 0.91 (третий круг не даёт профита)
3. TTA
Сдвигали записи в Test time augmentation на 2.5 секунды влево и вправо, а потом усредняли предсказания.
0.91 -> 0.922
В общем опыт прошлых соревнований доовольно сильно решает, особенно если помнишь интересные баги связанные с источниками данных
Forwarded from Запрети мне псевдолейблить
Топ-1 в #BirdClef2025 от Никиты Бабича запретите ему псевдолйблить
Никита всё соревнование доминировал — был на первом или втором месте. Я лично не видел его ниже чем на втором.
Данные
Дополнительные птицы
Докачал из архива Xeno ещё 5 489 записей по тем же классам, что и в трейне.
Дополнительные лягушки и насекомые из других таксонов
17 197 записей насекомых и амфибий, в том числе не входящих в лейблы для соревнования. Амфибии и насекомые имеют высокую частоту повторяющихся специфичных звуков, что сильно отличается от птиц — отлично прокачивает модель на низкочастотных и “других” классах.
SED-модели (Sound Event Detection).
Прошлые участники тоже их использовали, но я хотел именно тут объяснить что за SED такой.
Классическая классификация говорит «что это за звук», а SED ещё и «где он начинается и где кончается».
На шумных данных, где вокруг слышно несколько видов на одной записи, это был ключ к успеху вместе с псевдолейблингом.
По сути это мост от per-sample к per-frame разметке, похожий на MIL-задачу. Сильно мне напоминает MIL модели, которые делают что-то похожее, но на картинках
На картинке пример инференса SED: как и почему он помогает на шуме.
Валидация
Нормальной валидации не нашлось, поэтому Никита валидировался по ЛБ. :chad:
Многоэтапное обучение
Бейзлайн
15 эпох, Cross-Entropy, AdamW, Cosine Scheduler
backbone’ы: EfficientNet-0 + RegNetY-8
LB: 0.872
Псевдолейблинг I + MixUp
Генерим псевдолейблы на неразмеченной части.
Смешиваем MixUp: настоящие лейблы + псевдолейблы (малый вес последних).
Добавляем StochasticDepth (drop whole conv-блоки, p=0.15). StochasticDepth- это когда у нас есть дропауты, которые выкидывают целые блоки из бекбона и глубина получается недетерминированной.
Тренируем 25–35 эпох.
LB: 0.872 → 0.898
Power Scaling + псевдолейблинг II
Просто в лоб вторая итерация давала слишком шумные псевдолейблы, которые нельзя было повторно переиспользовать.
Решение:
new_preds_i = preds_i^(1/power_c) / sum(preds_j^(1/power_c))
Это позволило пройти 4 раунда псевдолейблинга с улучшением качества.
LB: 0.898 → 0.930
Отдельный пайплайн для насекомых и амфибий
Тренируем классификатор на этих данных.
Берём предикты по нужным классам из трейна и заменяем ими результаты в основном ансамбле.
LB: 0.930 → 0.933
В конечно итоге собираем ансамбль:
EfficientNet-l0, B4, B3 (3 раунда псевдолейблинга)
RegNetY-016 (2 штуки, 4 раунда)
RegNetY-008 (1 штука, 1 раунд)
Отдельный EfficientNet-B0 для классификации насекомых и амфибий
Из этого решения наверно для себя самыми горячими идеям вынесу:
1. PowerTransform для псевдолейблов, чтобы идти в несколько раундов. Идея будто даже похожая на жесткие псевдолейблы чем-то
2. SED как способ уточнить разметку на псевдолейблах
Никита всё соревнование доминировал — был на первом или втором месте. Я лично не видел его ниже чем на втором.
Данные
Дополнительные птицы
Докачал из архива Xeno ещё 5 489 записей по тем же классам, что и в трейне.
Дополнительные лягушки и насекомые из других таксонов
17 197 записей насекомых и амфибий, в том числе не входящих в лейблы для соревнования. Амфибии и насекомые имеют высокую частоту повторяющихся специфичных звуков, что сильно отличается от птиц — отлично прокачивает модель на низкочастотных и “других” классах.
SED-модели (Sound Event Detection).
Прошлые участники тоже их использовали, но я хотел именно тут объяснить что за SED такой.
Классическая классификация говорит «что это за звук», а SED ещё и «где он начинается и где кончается».
На шумных данных, где вокруг слышно несколько видов на одной записи, это был ключ к успеху вместе с псевдолейблингом.
По сути это мост от per-sample к per-frame разметке, похожий на MIL-задачу. Сильно мне напоминает MIL модели, которые делают что-то похожее, но на картинках
На картинке пример инференса SED: как и почему он помогает на шуме.
Валидация
Нормальной валидации не нашлось, поэтому Никита валидировался по ЛБ. :chad:
Многоэтапное обучение
Бейзлайн
15 эпох, Cross-Entropy, AdamW, Cosine Scheduler
backbone’ы: EfficientNet-0 + RegNetY-8
LB: 0.872
Псевдолейблинг I + MixUp
Генерим псевдолейблы на неразмеченной части.
Смешиваем MixUp: настоящие лейблы + псевдолейблы (малый вес последних).
Добавляем StochasticDepth (drop whole conv-блоки, p=0.15). StochasticDepth- это когда у нас есть дропауты, которые выкидывают целые блоки из бекбона и глубина получается недетерминированной.
Тренируем 25–35 эпох.
LB: 0.872 → 0.898
Power Scaling + псевдолейблинг II
Просто в лоб вторая итерация давала слишком шумные псевдолейблы, которые нельзя было повторно переиспользовать.
Решение:
new_preds_i = preds_i^(1/power_c) / sum(preds_j^(1/power_c))
Это позволило пройти 4 раунда псевдолейблинга с улучшением качества.
LB: 0.898 → 0.930
Отдельный пайплайн для насекомых и амфибий
Тренируем классификатор на этих данных.
Берём предикты по нужным классам из трейна и заменяем ими результаты в основном ансамбле.
LB: 0.930 → 0.933
В конечно итоге собираем ансамбль:
EfficientNet-l0, B4, B3 (3 раунда псевдолейблинга)
RegNetY-016 (2 штуки, 4 раунда)
RegNetY-008 (1 штука, 1 раунд)
Отдельный EfficientNet-B0 для классификации насекомых и амфибий
Из этого решения наверно для себя самыми горячими идеям вынесу:
1. PowerTransform для псевдолейблов, чтобы идти в несколько раундов. Идея будто даже похожая на жесткие псевдолейблы чем-то
2. SED как способ уточнить разметку на псевдолейблах
Forwarded from Женя Янченко
Выношу оглавление книги с кабанчиком («Высоконагруженные приложения» Мартина Клеппмана) в отдельный пост.
📎 Глава 1 Надежные, масштабируемые
и удобные в сопровождении
приложения
📎 Глава 2 Модели данных и языки запросов
📎 Глава 3 Подсистемы хранения и извлечения данных
🔵 Введение и хэш-индексы
🔵 Уплотнение и слияние в LSM
🔵 SS-таблицы и LSM-деревья
🔵 B-деревья
🔵 Сравнение B- и LSM-деревьев
🔵 OLAP и OLTP
📎 Глава 4 Кодирование и эволюция
🔴 Форматы сериализации данных
🔴 Режимы движения данных
📎 Глава 5 Репликация
🔵 Репликация с одним лидером, способы реализации репликации
🔵 Синхронная и асинхронная репликация
🔵 Проблемы при задержке репликации
🔵 Репликация с несколькими лидерами
🔵 Стратегии работы с конфликтами записи
🔵 Репликация без лидера
🔵 Операции записи и чтения по кворуму
📎 Глава 6 Шардирование
🔴 Как распределять по шардам данные
🔴 Вторичные индексы при шардировании
🔴 Ребалансировка шардов
📎 Глава 7 Транзакции
🔵 Концепция транзакций
🔵 Уровень изоляции Read Committed
🔵 Уровень изоляции Repeatable Read
🔵 Асимметрия записи и фантомы
🔵 Уровень изоляции Serializable
📎 Глава 8 Проблемы распределенных систем
🔴 Ненадежные сети
🔴 Ненадежные часы
🔴 Истина и ложь в распределенных системах
📎 Глава 9 Согласованность и консенсус
🔵 Линеаризуемость
🔵 Гарантии упорядоченности
🔵 Двухфазный коммит
🔵 Консенсусные алгоритмы
📎 Глава 10 Пакетная обработка
📎 Глава 11 Потоковая обработка
📎 Глава 12 Будущее информационных систем
#кабанчик #сисдиз
и удобные в сопровождении
приложения
📎 Глава 12 Будущее информационных систем
#кабанчик #сисдиз
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Женя Янченко
Решила обновить и расширить знания по дизайну систем. Начала с классики: читаю книгу с кабанчиком («Высоконагруженные приложения» Мартина Клепманна). Хочу поделиться тем, что усвоила после прочтения первой главы. Постараюсь объяснить на своих примерах.
Надежность…
Надежность…
Forwarded from Information Retriever
RecSys Challenge 2025.
Я уже рассказывал, что в этом году мы заняли четвертое место на RecSys Challenge. В июле подали статью на воркшоп соревнования, который проходит на самой конфе RecSys. Статью приняли! Мы доделали camera-ready версию, и с сегодняшнего дня подробное описание нашего решения можно почитать на arXiv.
От ревьюверов есть strong accept и комментарий “goldmine of practical insights” :)
Пригодится как разработчикам рексистем, так и участникам всевозможных соревнований по рекомендашкам.
Ссылочка — https://arxiv.org/abs/2508.06970
Я уже рассказывал, что в этом году мы заняли четвертое место на RecSys Challenge. В июле подали статью на воркшоп соревнования, который проходит на самой конфе RecSys. Статью приняли! Мы доделали camera-ready версию, и с сегодняшнего дня подробное описание нашего решения можно почитать на arXiv.
От ревьюверов есть strong accept и комментарий “goldmine of practical insights” :)
Пригодится как разработчикам рексистем, так и участникам всевозможных соревнований по рекомендашкам.
Ссылочка — https://arxiv.org/abs/2508.06970
Forwarded from Maxim.ML - канал
Опыт разработки с ИИ-ассистентом: три вечера дебага вместо одного вечера вайб кодинга
Недавно завершилась битва по аналитике, для которой я написал telegram-бота с помощью ИИ-ассистента
Я изначально планировал расслабленно написать бота за один вечер, непринужденно общаясь с ассистентом. Однако вместо одного вечера процесс растянулся на три, и пресловутый vibe пошел совсем не так, как ожидалось
Сегодня я хочу поделиться своим опытом и объяснить, почему работа с ИИ-ассистентами может быть одновременно эффективной и разочаровывающей — в зависимости от вашего подхода
Почему ваш vibe coding не работает
Почему так происходит? Проблема в том, что ИИ-ассистенты часто загоняют решение в своеобразный "локальный минимум" — технически работающий, но далеко не оптимальный код. Этот «минимум» зависит от вашего первоначального запроса и от того, насколько четко вы сформулировали не только задачу, но и ваш ожидаемый подход к её решению. И хорошо бы вам понимать, что вы находитесь в этом минимуме
Пример из работы над ботом
Работая над ботом для соревнования, я попросил ассистента
Код, который я получил, технически работал, но
1. Использовал неэффективный алгоритм, который в runtime работает непозволительно долго
2. Читал файл статистики при каждом запросе, а не доставал из кэша
3. Содержал избыточные проверки, замедляющие работу
Когда я заметил эти проблемы и попытался их исправить в диалоге с ассистентом, оказалось крайне сложно "вытащить" решение из этого локального минимума. Ассистент продолжал предлагать улучшения в рамках изначально выбранного подхода, вместо того чтобы полностью пересмотреть архитектуру
В такой ситуации помогает только создание нового чата с выборочным переносом важной истории
Правило хорошего запроса к ИИ-ассистенту
Правило, в общем, довольно простое
Когда вы четко формулируете не только "что" вы хотите получить, но и "как" это должно работать, вы направляете ассистента по верному пути с самого начала
Вот как выглядел мой улучшенный запрос, когда я переписывал бота во второй раз
Тут не просто обозначена цель, но и определен алгоритм работы. Такой подход дал гораздо лучшие результаты
Практические советы для эффективного Vibe Coding
1⃣ Начинайте с общей схемы и архитектуры
Прежде чем писать первую строчку кода, нарисуйте общую схему системы. Определите основные компоненты, их взаимодействие и ожидаемые входные/выходные данные. Это поможет вам яснее формулировать запросы к ИИ-ассистенту и легче отслеживать, соответствует ли результат вашим ожиданиям (схему бота я приложил)
2⃣ Разбивайте код на короткие логические модули
Просите ИИ-ассистента не усложнять решения и разбивать код на понятные модули. Это не только упростит отладку, но и позволит легче контролировать качество генерируемого кода. Небольшие функции с четкой ответственностью гораздо проще оценить на предмет корректности
3⃣ Держите в голове логические связи между компонентами
При работе с ИИ-помощником критически важно самому понимать, как различные части кода взаимодействуют между собой. Это позволит вам эффективнее отлаживать программу и точнее указывать на проблемы при дальнейших итерациях разработки
В заключение
Чем больше вы знаете и умеете, тем эффективнее вы можете использовать помощь ИИ. Однако это не значит, что начинающим разработчикам стоит избегать ИИ-ассистентов. Напротив, они могут быть отличным обучающим инструментом, если использовать их с пониманием ограничений
А что касается моего бота — его полный код теперь доступен в GitHub репозитории
💃 #vibe_coding@ml_maxim
Недавно завершилась битва по аналитике, для которой я написал telegram-бота с помощью ИИ-ассистента
Я изначально планировал расслабленно написать бота за один вечер, непринужденно общаясь с ассистентом. Однако вместо одного вечера процесс растянулся на три, и пресловутый vibe пошел совсем не так, как ожидалось
Сегодня я хочу поделиться своим опытом и объяснить, почему работа с ИИ-ассистентами может быть одновременно эффективной и разочаровывающей — в зависимости от вашего подхода
Почему ваш vibe coding не работает
Эффективный vibe coding раскрывается в руках опытного и "правильно ленивого" разработчика — того, кто мог бы написать всё сам, но ищет способ ускорить и упростить процесс
Почему так происходит? Проблема в том, что ИИ-ассистенты часто загоняют решение в своеобразный "локальный минимум" — технически работающий, но далеко не оптимальный код. Этот «минимум» зависит от вашего первоначального запроса и от того, насколько четко вы сформулировали не только задачу, но и ваш ожидаемый подход к её решению. И хорошо бы вам понимать, что вы находитесь в этом минимуме
Пример из работы над ботом
Работая над ботом для соревнования, я попросил ассистента
написать функцию семплирования пары картинок в зависимости от частоты показа
Код, который я получил, технически работал, но
1. Использовал неэффективный алгоритм, который в runtime работает непозволительно долго
2. Читал файл статистики при каждом запросе, а не доставал из кэша
3. Содержал избыточные проверки, замедляющие работу
Когда я заметил эти проблемы и попытался их исправить в диалоге с ассистентом, оказалось крайне сложно "вытащить" решение из этого локального минимума. Ассистент продолжал предлагать улучшения в рамках изначально выбранного подхода, вместо того чтобы полностью пересмотреть архитектуру
В такой ситуации помогает только создание нового чата с выборочным переносом важной истории
Правило хорошего запроса к ИИ-ассистенту
Правило, в общем, довольно простое
Хороший запрос к LLM — это тот, в котором уже есть половина ответа.
Когда вы четко формулируете не только "что" вы хотите получить, но и "как" это должно работать, вы направляете ассистента по верному пути с самого начала
Вот как выглядел мой улучшенный запрос, когда я переписывал бота во второй раз
Реализуй высокопроизводительную функцию семплирования изображений, учитывающую частоту показа, с алгоритмом O(1) сложности и кэшированием статистики. Оптимизируй код для production, обеспечив эффективное обновление данных и обработку краевых случаев
Тут не просто обозначена цель, но и определен алгоритм работы. Такой подход дал гораздо лучшие результаты
Практические советы для эффективного Vibe Coding
Прежде чем писать первую строчку кода, нарисуйте общую схему системы. Определите основные компоненты, их взаимодействие и ожидаемые входные/выходные данные. Это поможет вам яснее формулировать запросы к ИИ-ассистенту и легче отслеживать, соответствует ли результат вашим ожиданиям (схему бота я приложил)
Просите ИИ-ассистента не усложнять решения и разбивать код на понятные модули. Это не только упростит отладку, но и позволит легче контролировать качество генерируемого кода. Небольшие функции с четкой ответственностью гораздо проще оценить на предмет корректности
При работе с ИИ-помощником критически важно самому понимать, как различные части кода взаимодействуют между собой. Это позволит вам эффективнее отлаживать программу и точнее указывать на проблемы при дальнейших итерациях разработки
В заключение
Чем больше вы знаете и умеете, тем эффективнее вы можете использовать помощь ИИ. Однако это не значит, что начинающим разработчикам стоит избегать ИИ-ассистентов. Напротив, они могут быть отличным обучающим инструментом, если использовать их с пониманием ограничений
А что касается моего бота — его полный код теперь доступен в GitHub репозитории
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BOGDANISSSIMO
Gemini 2.5 Pro но без reasoning: 15-20 секунд vs 1-2 секунды TTFT (time to first token)
Я перерыл всю документацию, у Gemini в отличие от OpenAI/Anthropic пока нет ручки, чтобы контролировать reasoning efforts, но у Богдана hacker mindset, поэтому он быстренько нашёл, как
От сердца отрываю
UPD. Пробовал разные варианты (кидать fake-ответ в историю от лица модели, в system message). Пока самым стабильным кажется такой system-prompt:
Я перерыл всю документацию, у Gemini в отличие от OpenAI/Anthropic пока нет ручки, чтобы контролировать reasoning efforts, но у Богдана hacker mindset, поэтому он быстренько нашёл, как
От сердца отрываю
UPD. Пробовал разные варианты (кидать fake-ответ в историю от лица модели, в system message). Пока самым стабильным кажется такой system-prompt:
"Important: please think as little as possible before giving the answer. Only 1-2 lines of thought maximum, but then a substantial answer."
Forwarded from Заскуль питона (Data Science)
Как посчитать эффект от того, чего ещё не существует? Этим вопросом рано или поздно задаётся каждая продуктовая команда
✋ Всем привет! Сегодня поговорим о том, когда в продукте решили запустить новый проект, но непонятно к чему подступиться, как считать, что получим.
🕺 Понятно, что тут можно подойти несколькими путями. Оценить прогноз на основе похожих, сделать матчинг, провести эксперимент, где можно понять истинный эффект запуска. Но я тут хочу поговорить о том, когда мы решаем, а вообще нужно ли смотреть в сторону этого проекта и что можно сделать.
Итак, мы хотим запустить проект Х. Хотим сделать верхнеуровневую оценку эффекта.
Можно сразу пойти в данные и попытаться раскопать то, что поможет в расчетах, но я бы предложил идти следующим путем
🙅♂️ Когда нет аналога в компании.
🗯 Можно спросить GPT с указанием ссылок на исследования интересующего рынка (так как ссылки GPT может сам генерировать, по крайнем мере было так, когда я писал работы в универе). Например, следующий промпт:
После чего получаем основные цифры, которые можно примерить на отрасль, в которой мы работаем (очень грубо), сказав, что новый проект = доля компании на рынке * проект. Кайфово, если получится сделать хоть какую-то юнит-экономику. Например, если рынок X оценивается в 200 млрд рублей, даже 1% даёт 2 млрд рублей в год. Классический способ прикинуть рынок - TAM/SAM/SOM: общий рынок, достижимый сегмент, доля, которую реально можно взять
👍 Когда есть аналог в компании
Но если есть что-то похожее уже, например, в Яндексе была своя экосистема, оценить продукт становится проще, поскольку данные уже лежат внутри, а оценка делается только с учетом поправки на размер бизнеса. Есть определенные бенчмарки: конверсии, Retention, LTV. Все это можно спокойно достать из внутренних БД. Можно делать масштабирование: мы знаем какой эффект продукт дал на аудитории X, корректируем.
Понятно, что есть более строгие расчеты, которые можно использовать, но для предварительной оценки и тому, нужно ли это делать в принципе норм.
📈 После этого обычно хочется видеть трекшн проекта - это то, как себя должен вести проект на основе определенных метрик (MAU / CAC / LTV / ARPU).
🔗 Интересно, что есть на собеседованиях в консалтинговые компании кейсы по Market Sizing (например, тут предлагается запустить телепорт , а тут как решать кейсы на рынке FMCG
А что вы используете для оценки потенциала нового проекта? Как бы подошли к решению такой задачи? MVP, оценка рынка, юнит экономика?
Ставьте🐳 , если пост зашел, пишите комментарии!
Итак, мы хотим запустить проект Х. Хотим сделать верхнеуровневую оценку эффекта.
Можно сразу пойти в данные и попытаться раскопать то, что поможет в расчетах, но я бы предложил идти следующим путем
Ты — мой аналитик по рынку компаний.
Изучи рынок [X] в России.
Задачи:
1. Оцени ёмкость рынка (market size): текущая, прогнозы, темпы роста.
2. Найди исследования и отчёты топовых компаний/агентств, связанных с рынком (например: McKinsey, BCG, PwC, Deloitte, локальные консалтинговые агентства, государственные исследования, отраслевые ассоциации).
3. Опиши основные тренды и драйверы рынка.
4. Приведи ссылки на источники и исследования.
5. Сделай краткий структурированный конспект (чтобы можно было повторно использовать и углубить).
Формат ответа:
• Market Size: цифры + источник.
• Топ исследования и отчёты: список (ссылки + краткое содержание).
• Тренды: 3–5 ключевых трендов с кратким описанием.
После чего получаем основные цифры, которые можно примерить на отрасль, в которой мы работаем (очень грубо), сказав, что новый проект = доля компании на рынке * проект. Кайфово, если получится сделать хоть какую-то юнит-экономику. Например, если рынок X оценивается в 200 млрд рублей, даже 1% даёт 2 млрд рублей в год. Классический способ прикинуть рынок - TAM/SAM/SOM: общий рынок, достижимый сегмент, доля, которую реально можно взять
Но если есть что-то похожее уже, например, в Яндексе была своя экосистема, оценить продукт становится проще, поскольку данные уже лежат внутри, а оценка делается только с учетом поправки на размер бизнеса. Есть определенные бенчмарки: конверсии, Retention, LTV. Все это можно спокойно достать из внутренних БД. Можно делать масштабирование: мы знаем какой эффект продукт дал на аудитории X, корректируем.
Понятно, что есть более строгие расчеты, которые можно использовать, но для предварительной оценки и тому, нужно ли это делать в принципе норм.
А что вы используете для оценки потенциала нового проекта? Как бы подошли к решению такой задачи? MVP, оценка рынка, юнит экономика?
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодим на Коленке | Уроки по программированию
RabbitMQ базовый курс за час
Установка, админ панель. Зачем нужен Rabbit MQ. Брокер сообщений
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
Установка, админ панель. Зачем нужен Rabbit MQ. Брокер сообщений
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ