КайфКодинг

Привет! Делимся видеозаписями докладов после RecSys Meetup 🤘 1️⃣ «Трансформеры в персональных рекомендациях: от гипотез до AB-тестирования» | Иван Ващенко, DS Team Lead в команде персональных рекомендаций VK | YouTube | Презентация 2️⃣ «Semantic IDs: архитектура и наш опыт внедрения» | Александр Тришин, DS Stream Lead в команде персональных рекомендаций VK | YouTube | Презентация 3️⃣ «Как мы обучаем CLIP-ы для текстовых тегов» | Михаил Киндулов, Stream Lead в команде Поиск по фото VK | YouTube | Презентация 4️⃣ «Счастье пользователя vs счастье продавца. Онлайн-доранжирование и байесовская оптимизация в товарных рекомендациях» | Андрей Ветров, Data Scientist в команде товарных рекомендаций VK | YouTube | Презентация Смотрите фото, чтобы оценить атмосферу. И до встречи на следующих митапах! 🌟 @wb_space

Очень понравилось интервью основателя Lovable - насыщенное, плотное, с кучей идей. Lovable – это вайб-кодинг инструмент который умудрился за 8 месяцев рвануть с 0 до $100M+ ARR. Сейчас в нем создается 100к+ новых проектов ежедневно. Оказывается, они из Стокгольма. В начале это был стрельнувший проекта на гитбахе gpt-engineer, который ребята переделали в компанию. Мысли, которые зацепили: 1. Lovable – продукт для мира, где никто не пишет код Включая инженеров. Я думаю этот мир наступит и быстрее чем кажется. 2. 80% кейсов – реальные бизнес-приложения Это меня сильно удивило – я думал, там домашние поделки и прототипы, но нет. Они так и хотят – стать технической платформой и партнером для реальных бизнесов. В отличие, например, от Bolt.new, который позиционируется больше как инструмент прототипирования. Миссия у ребят крутая:

To unlock human creativity — by enabling anyone to create software

3. У application-layer AI-стартапов – т.е. конечных сервисов, а не создателей технологий – практически нет конкурентной защиты. Твоя защита – скорость, продукт, и долгосрочно – сформированный бренд. В подкасте есть классная аналогия. Такие компании – как курицы, выпущенные из пушки, и выиграют те курицы, которые быстрее машут крылышками. Ну да. 🐓 Маши крыльями или сдохнешь Отдельно хочу заметить очень крутого дерзкого интервьюера – подготовка, знания, скорость. Всем бы так. ссыль

Биохакинг за копейки Когда тебя будит паническая атака, то следующие несколько дней страшно засыпать. Страшно, что она повторится. Мне 27 и я изучаю все, чтобы больше она не повторилась: сдаю анализы, покупаю девайсы для трекинга сна/спорта/питания/веса, медитирую, КПТ-терапия. Консультируюсь с топовыми врачами и ведущими биохакерами. Это было 9 лет назад и стоило кучу денег. Невероятно сложно было найти толковых консультантов. Сейчас многое поменялось. На выходных разбирал свой геном с AI и за $20 получил 95% информации, которая тогда стоила сотни тысяч рублей. А кроме самой информации, еще и возможность сколько угодно раз уточнять что с чем связано, почему мне надо пить L-5-MTHF, откуда идет эта рекомендация и какой анализ проверяет эффективность конкретно этого БАДа. Это геймченджер, потому что когда я сдавал по 17 пробирок крови и пил десятки БАДов, постоянно забывал зачем это всё. Забывал и останавливался. Ясность для меня — ключевой драйвер, чтобы я что-то делал регулярно. Вот пример, как я анализировал геном: Скачал полный геном с 23andme, разбил на 2 части (целиком не влазит в окно контекста). Попросил Claude создать мне папки и в каждой поочередно выполнить свою задачу. Структура папок: 1 — DEEP RESEARCH. Изучить актуальные данные и исследования, на какие гены смотреть, что наиболее изучено и валидно. Собрать в документ. 2 — MY GENOME ANALYSIS. Проанализировать мой геном по ключевым генам из п.1 3 — SUMMARY. Собрать общий отчет: что нашлось, какие факторы риска и особенности у меня есть. 4 — ACTIONS. Создать документы по направлениям: спорт, еда, чекапы. В каждом написать план внедрения инсайтов из анализа генома.

Для тех, кто интересуется - вот ссылка на контент (https://www.youtube.com/shorts/UyRozzRyY64) (это в блендере)

Сегодня общался с другом - они сделал 500 млн просмотров на нейроконтенте за 4 месяца

Плохие новости: там Google нашли фундаментальный баг в RAG TL;DR: оказалось, что всеми любимый и привычный поиск на эмбеддингах может не всё и имеет серьёзный фундаментальный предел. При фиксированной размерности вектора таким подходом просто невозможно находить все релевантные документы из базы. В своей работе Google доказали это и теоретически, и экспериментально. О чем вообще речь. Современный поиск и RAG часто опираются на single-vector эмбеддинги: у каждого запроса и документа – по одному вектору, похожесть меряем скалярным произведением/косинусом, дальше берем топ-k ближайших. И тут возникает вопрос: а вообще возможно ли при фиксированной размерности векторов построить такой поиск, который всегда будет возвращать правильные топ-k документов для любых запросов? Ответ – нет. И сбой происходит уже на очень простых примерах. Интуитивное объяснение, почему так: чем больше база знаний, тем больше разнообразных комбинаций запросов и релевантных документов нам нужно поддерживать. Но пространство поиска всегда ограничено размерностью эмбеддингов. Так вот, начиная с какого-то числа документов, расположить точки в этом пространстве так, чтобы для каждого запроса мы находили правильные доки, просто невозможно. Математическое объяснение для любителей:

Представим матрицу A, где строки – это запросы, а столбцы – документы, и на пересечении стоит 1, если документ релевантен, и 0 – если нет. Мы хотим, чтобы поиск на эмбеддингах воспроизводил именно такую матрицу «кто кому подходит». Тогда оценки похожести будут матрицей B = UᵀV, где U и V – это векторы запросов и документов в пространстве фиксированной размерности d. Но sign-rank матрицы (2A−1) может оказаться больше d, а это значит, что никакие d-мерные эмбеддинги не смогут построить B с правильными значениями. Формально: если sign-rank(A) > d, то корректное разделение релевантных и нерелевантных пар в таком пространстве просто невозможно, каким бы мегаумным ни был ваш эмбеддер.

То есть, например, если у вас эмбеддинги размерности 512, то ваш RAG будет работать нормально, пока документов в вашей базе менее 500 тысяч (а это довольно немного). При размерности 1024 – до ~4 млн. При 4096 – примерно до 250 млн. Дальше система начнет сыпаться. И эти расчеты Google подвели в идеальных условиях, когда векторы оптимизированы под задачу. На практике, когда вы не дообучаете эмбеддинги, пределы еще ниже. Чтобы показать это на практике, авторы придумали специальный бенчмарк LIMIT. Он построен так, что у каждого запроса релевантны ровно два документа, но комбинаций этих пар очень много. В итоге даже лучшие современные эмбеддеры (GritLM, Qwen3, Gemini и др.) показывают на LIMIT катастрофически низкий recall – около 20% (причём даже на маленькой версии датасета с 46 документами, караул!). Для сравнения, классический BM25 или multi-vector модели вроде ColBERT выбивают почти 100%. Фишка в том, что тут мы уже не зажаты одним вектором на документ и запрос. Например, у ColBERT стоится много векторов на документ. Ну короче, мораль такова: поиск на одном векторе – это удобно и быстро, но у него есть жёсткий фундаментальный предел. Поэтому для серьёзных систем RAG все-таки нужны гибридные подходы: разреженный поиск, multi-vector и прочее. Иначе – потолок 😐 Полный текст: On the Theoretical Limitations of Embedding-Based Retrieval

Куда сходить в последний день лета Centrale Bistro - это бывший шеф Белуги, с которым они звезду получили jinju Bistro - очень свежо и просто. Еще и в самой козырной локации сейчас Leo - тяжелый люкс и пицца по 2-5к Carniceria Vino - лучшее открытие 2024, если еще не была Kiyomi - одно из лучших открытий 2025, от шефа самого тяжелого московского японского люкса Jun, но дешевле, интерьер получше и покреативней

У Ленни вышла статья где рассказывается про то, почему AI продукты должны иметь другой цикл разработки. Авторы показали фреймворк CC/CD. TLDR: как писал много раз ранее, rolling updates с эскалацией сложности системы и evals для оценки технического качества. Две фундаментальные проблемы AI-продуктов: 1. Недетерминированность - пользователи пишут что угодно вместо нажатия строго определенных заранее кнопок, система отвечает по-разному на одинаковые запросы. Классический QA тут не работает. 2. Компромисс между агентностью и контролем - чем больше автономии даешь ИИ, тем меньше контроля остается у людей. Что такое CC/CD: Continuous Development: - Разбиваем большую цель на версии с растущей автономией (v1: AI-раб → v3: AI-коллега) - Настраиваем простейшее приложение с логированием всего подряд и возможностью передачи контроля человеку - Проектируем evals для измерения качества Continuous Calibration: - Запускаем на небольшой группе пользователей - Анализируем реальные данные и паттерны фейлов - Итеративно фиксим на основе данных Пример из жизни - автоматизация саппорта: - v1: Только роутинг тикетов по отделам - v2: Предложение решений на основе инструкций и/или базы знаний - v3: Автономное решение с эскалацией сложных кейсов до человека Главный принцип - не давать ИИ полную автономию сразу. Система должна заслужить доверие через постепенное увеличение ответственности и доказательство надежности на каждом этапе. Это как онбординг нового сотрудника. Сначала простые задачи, потом постепенное расширение полномочий по мере накопления доверия. По факту, это формализация того, что мы и так делаем в команде с нашими ассистентами и другими ИИ продуктами. Начинаем с простых сценариев, постепенно расширяем полномочия, мониторим каждый чих через evals, много бенчмаркинга.

Кого автоматизировать? Сегодня Sequoia выложила видео - де-факто продолжение AI Ascent мини конфы, о которой я писал в мае. Основные тезисы все те же, но меня заинтересовал вот этот слайд (см. аттач) из внутреннего мемо: отсортированные по размеру рынки США, где размер = колво людей в этой профессии, умноженное на среднюю зп. Тезис такой: AI - это когнитивная революция и заменит людей (по аналогии с индустриальной, автоматизировавшей заметную часть физического труда), поэтому в компании с фокусом на эти рынки и надо вкладывать. В ту же тему моя любимая статья от NfX про AI Workforce. В общем, поскольку слайд на данных 23го года и только про США, то я натравил своего дружбана на то, чтобы обновить инфу по США + сделать по РФ - добавил скрины в аттач + вот тут полные результаты. Топ 3 в США: медсестры, программисты и юристы; в РФ - водители, инженеры и охранники (!). Кто из вас автоматизирует кого? Делитесь в комментариях Кстати, в этом же видео есть эдакий запрос на стартапы (request for startups), а именно во что они вкладывают сейчас в AI: 1) Память агентов (вот тут размышлял об этом) 2) Протоколы межагентной коммуникации (делился тут) 3) Голосовые агенты (особенно enterprise, см вот тут подробнее) 4) AI безопасность (новые поверхности для атаки) 5) Open source AI (неожиданно) В общем, рекомендую посмотреть, особенно если не видели AI Ascent выступление.

Решите за минуту

Когда тестируешь open source модель на русском языке

You Suck at "Vibe Coding" Because You Suck at Coding Senior SWE here. I maintain systems doing millions monthly. I use Claude Code 90% of the time. While you're complaining your for-loops are going nuts, I'm shipping 10x faster with better tests. The problem isn't vibe coding. The problem is you. 1. Your Prompts Are Garbage "Fix my auth bug" isn't a prompt. It's a prayer. Tell the AI WHERE the problem is. Show the error. Explain what should happen. If you can't explain the problem clearly, that's on you. 2. Stop Using Autoaccept Anyone using autoaccept deserves their bugs. READ EVERY LINE. Always. It's a suggestion, not gospel. 3. Less Code = Better Code Saw Paul Graham praising some founder for generating 10k lines daily with AI. Good luck maintaining that mess. Good engineering means minimal changes. If your AI rewrites half your codebase for one feature, you're doing it wrong. 4. Fix Your Folder Structure Your repo is a mess. That's why AI gets confused. Make it simple: feats/[feature-name]/[files]. If a human can't scan it quickly, neither can AI. 5. It's a Tool, Not Magic "Vibe coding is bad" is like saying "knives are dangerous." Yeah, if you're an idiot with them. Learn to use the tool properly. 6. Use Voice for Prompts Pro tip most of you miss: dictate your prompts. You give 3x more context speaking vs typing. I use writevoice.io (I built it). WillowVoice and Flow work too. When you speak, you naturally explain edge cases and assumptions you'd skip when typing. 7. Stop Mixing Features in One Chat Long conversations about 3 different features confuse the AI. Change chats between features. If you tell AI "I ate strawberries and now I'm late for school, what's my salary?" it'll think you're a farmer. Context switching breaks AI just like it breaks humans. There's research on this. 8. Document Changes, But Keep It Short Keep a log file. Write one-sentence updates after each feature/big change. That's it. These breadcrumbs save hours of explaining context later. Stop blaming the tool. Start learning how to use it.

Как я выгляжу для своей команды разработки

У нас в InfluAI мощный анонс🔥 https://influai.world/v2/onboarding Теперь вы можете взять свою фотку, ссылку на профиль и за один клик получить копию популярного тренда, но с вашим лицом и под тему вашего профиля♥️ Мою фотку на входе и результат на выходе можно прикрепила выше🔥 Никаких длинных онбордингов. Жду ваших видосов. Первые бесплатно Лайк, репост, обняли

Какие молодцы!

Как решать сложные проблемы не на вайбе Все мы сталкиваемся в программировании с сетками с какими-от багами, которые ну никак не могут быть решены с налету, попытками уговоров агента, либо принимая все его предложения. Часто люди даже сдаются и просто откатывают такой код, справедливо полагая, что фиксить его будет тяжелее, чем написать снова. Но есть типы функционала, которые нам приходится реализовывать, и который при этом сетки часто пишут неверно с первого раза. Это деплой, многопоточность, мета-промптинг, нюансы авторизации, код из новых библиотек и т.д. Мы не можем просто их "не решать", так как заменить их нечем, а что-то делать нужно. Поэтому делюсь с вами системным алгоритмом, используя который можно раскалывать даже достаточно сложные кодинговые задачки. 1) Описываем баг. Либо сами (подробно), либо кормим Gemini 2.5 pro в AI студии логи работы вашего кода и просим сказать, что там не так. Она съедает до 1 млн контекста — идеально для анализа логов (я работаю в основном по логам, т.к. много бэкенда, фронтам нужно иначе). 2) Несем результат в Шотган и выбираем промпт "Find bug" — получаем потенциальный стектрейс проблемы. 2.1) Если она понятна и проста, то далее тащим результат тоже в шотган и применяем dev промпт. Затем полученный дифф интегрируем хоть руками хоть курсором. 2.2) Если непонятна, то отдельным промптом просим Find bug агента дать вам список файлов, которые имеют отношение к проблеме, это пригодится нам далее. 3) Что если проблема не пофиксилась с первого/второго раза. Короче говоря, творческая в плохом смысле. Тогда нас будет выручать GPT-5 Его особенность в том, что ему нужно очень сурово препарировать контекст. Итак, открываете ChatGPT 5-thinking модель и даете следующий промпт:

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам]. 

Расскажи мне причины бага, и почему он возник. 

Прикладываю контекст

Архитектура
====
 {описание архитектуры которое я надеюсь вы делаете для своих тасок, шотган -> Architecture}. 
===

Необходимые файлы /собираем индексилкой, или просто шотганом, ШотганПро умеет это делать автоматически). Важно — не весь проект/ 
===
[список файлов и их кода]
===

Мнение тестировщика, но я не уверен что оно корректное/замечание про неуверенность важно, т.к. иначе модель зацепится за эти выводы, а т.к. баг не пофиксился легко, то очень часто они неверные/
====
[складываем отчет от Gemini]
====

GPT-5 выплюнет в вас достаточно сложными рассуждениями и кусками кода, которые вы плохо поймете. Но это не беда, потому что: 4) Тащим теперь это в шотган к dev агенту или в курсор. Тупо копируем и говорим

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам] /короче то же что и GPT-5/

Вот предложение архитектора
====
[Пространный бред от GPT-5]
====

Верифицируй и реши задачу

И вот это уже с большой вероятностью сработает А далее можно продолжать фигачить ваш курсорный или CC-шный вайб в промышленных объемах =) В целом, секрет заключается в тщательном отборе контекста для моделей, с соблюдением двух принципиальных моментов — Помнить, что модели не знают ничего за пределами их контекста — Не подходить к ним с человеческими мерками. Модели уже умнее людей в ряде задач, и то что для вас "какой-то бред", для них валидный инпут, который не нуждается в пояснениях. Нужно уметь этот момент почувствовать. Это мой способ. Пишите, если у вас есть свой, будет интересно почитать комментарии.

Andrew Ng об AI и разработке Как я упомянул во вчерашнем посте, Andrew Ng вчера поделился своими мыслями про то, как AI меняет разработку —> ключевые тезисы: 1) в AI Fund они заметили, что сильным предиктором успеха инновационного проекта является скорость, с которой команда двигается (execution speed) 2) Именно эту ценность дает AI в разработке новых продуктов: если его достаточно тяжело использовать в существующих продкшн проектах и выигрыш c натяжкой может дать 30-50% в сокращении скорости разработки, то для разработки прототипов ускорение в 10 раз. Именно для этого и надо использовать AI 3) Код больше не является таким ценным артефактом разработки, как был раньше. Более того, возможно даже и архитектура таковой не является. Его словами:

"Even choosing the architecture for an application is closer to a 2-way than a 1-way door"

с намеком на критерий сложности решений Безоса 4) Какими навыками должен обладать AI Engineer, по его мнению? 3 блока: - навыки написания кода с помощью AI (ai assisted coding) - понимание ключевых блоков AI разработки: промпты, RAG, агенты, эвалы, MCP, voice. Мне было важно узнать, что темы курса AI Product Engineer хорошо соотносятся с этим - понимание full stack, архитектуры, базовых навыков продакт-менеджмента и дизайна Эндрю подчеркнул, что они работают со многими компаниями из Fortune 500 и не хватает именно таких спецов. И как ему обидно, что выпускники Computer Science зачастую не знакомы с этими блоками выше. 5) И ключевая мысль: что раньше узкое место в разработке продуктов было именно написание кода, сейчас же оно смещается в product management: сбор фидбека и взаимодействие с пользователями/клиентами. Я, разумеется, спросил его про virtual user boards и сможет ли AI расшить и это узкое место —> он согласился, что много интересного ресерча делается в этом направлении, но отметил, что для b2b продуктов зачастую данные об их пользователях отсутствуют в интернет, поэтому LLM не очень хорошо могут "воспроизводить" такие персоны. Тем не менее, это безусловно перспективная тема и он следит за тем, что происходит тут. В целом, я не устану повторять, что то, что Andrew говорил лет 6-7 назад становится мейнстримом через 3-4 года - например, про AI как электричество (см. посты 1, 2, 3 от 2017-2019), поэтому я очень рекомендую прислушаться к этим мыслям, даже если они пока кажутся "шарлатанскими". И посмотрите обязательно это видео 8-летней давности В аттаче слайды с моего пересказа этого выступления на сессии AI Product Engineer сегодня.