Обзор нового видео от Андрея Карпати

Редкая роскошь в наше время — обзор, написанный человеком.

Посмотрел свежее выступление Андрея Карпати в Y Combinator, которое недавно промелькнуло в нескольких каналах. Андрея я люблю больше всех из лидеров мнений в AI и слежу за ним, потому что он сохранил в себе майндсет инженера, что доказывает периодическими видео на ютубе с лайв кодингом. Я писал, что он сравнивал LLM с операционной системой. В этот раз про это тоже было, но было еще немало новых интересных аналогий.

В первой части Карпати предлагает новое понимание термина ПО

Software 1.0 — традиционный код для компьютеров
Software 2.0 — веса для нейросетей
Software 3.0 — промпты для LLM на естественном языке

И еще он приводит аналогию LLM с электричеством. Обучение LLM требует больших капитальных затрат — так же, как электросеть требует построить электростанцию. Операционные расходы инференс — как стоимость генерации энергии. Тарификация за миллион токенов — как тарификация за киловатт-часы. И так далее.

Вторая часть была о “психологии” нейросетей. Карпати сравнил LLM с людьми с психологическими особенностями — например, с аутизмом: где-то они очень странные, но в чем-то гениальны. LLM способны запоминать огромные массивы информации, но иногда ведут себя непредсказуемо, совершают глупые ошибки, галлюцинируют.

Третья часть — про ставку на частичную автономность и неверие в быстрое наступление AGI. Еще в 2013 году он катался на первом беспилотнике Waymo — тогда всё уже работало очень хорошо, но прошло 12 лет, и мы всё еще далеки от полностью автономных автомобилей. С LLM и агентами ситуация будет похожей: впереди еще огромный объем работы. Сейчас основное внимание уделяется созданию приложений с частичной автономностью: редакторы кода вроде Cursor, графические редакторы с частичной автоматизацией. LLM делают небольшую итерацию, человек её верифицирует, потом еще одна итерация — и так по кругу. И тут крутая фича — это ползунок степени автономности, которой можно настроить размер итерации.

Четвертая часть — про ставку на агентов. Агенты отличаются от обычных ботов тем, что понимают инструкции на человеческом языке. Это особенно важно, потому что на человеческом языке уже существует огромное количество инструкций. И новые инструкции тоже проще написать на человеческом. А там, где есть сложности в представлении информации, есть специальные построители контекста и хайповый нынче MCP протокол. Таким образом, агенты могут ходить по сайтам, нажимать кнопки, выполнять команды — и всё это будет программироваться куда проще, чем раньше.

💎 А вообще посмотрите сами. Если не узнаете что-то новое, то точно словите классный вайб. Буду рад вашим реакциям 🔥

#tech@big_ledovsky

Стоит ли идти в трансформерные рекомендации

Прочитал статью про новую рекомендательную модель Яндекса - ARGUS.

Ее активно пиарили в каналах, я слежу и за каналом руководителя их RnD отдела (кто не следит 🙂), и в целом слежу за областью. Мне пиарить не предлагали, поэтому напишу чисто свои выводы с менеджерским уклоном.

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

- Однако это и серьезные инвестиции. Чтобы дойти до хорошего внедрения Яндексу потребовалось вложить ресурсы топового по компетенциям отдела на целых три года

- Чтобы получить хороший результат нужен фокус. Яндексу потребовалось выделить специализированный RnD в отдельное подразделение. По моему опыту, «продакшн» команде ну очень сложно выкраивать время на такие задачи. Все что не дает результат за квартал, или хотя бы за полгода задвигается. А тут нужно было три года

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

Такие вот выводы

PS. А про наш путь и выводы обязательно еще будет в нашем канале

#tech@big_ledovsky

Хочу поделиться вакансией моего друга, Виталика Минаева, в ML Autotasking Старший DS инженер

ML Autotasking - это про выставление задач менеджерам по продажам. Направление горячее, импакт на бизнес большой!

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

Могу порекомендовать и Виталика, и команду. Будет интересно!

Резюме скидывайте напрямую Виталику в телегу – @vminaev88 =)

Впечатления с Fintech Data Day

Вчера выступал на Fintech Data Day. Доклад назывался - еком vs банки: отличия инфраструктуры данных на примерах.

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

Что было круто - в конференции чувствовался ламповый вайб. Наша сессия была чем-то средним между докладами и интервью, люди свободно задавали вопросы и знакомились, в том числе после докладов. Да и вы на видео можете посмотреть, доклад я затирал сидя на огромном кожаном кресле 😅 Думаю, что в такой атмосфере большая заслуга Саши Толмачёва, который организовывал конфу и вел в частности нашу секцию.

А так конечно приятно, что меня позвали. Здорово, что появилась новая классная конфа🔥

Ecom vs Банк: о в подходах работе с данными

Всем привет! Последнее время маловато пишу. Думаю так будет до конца лета, а потом начну новый сезон!

Как обещал, хочу поделиться о чем я рассказывал на Fintech Data Day. Вообще, я занимаюсь алгоритмами монетизации в Авито. И это совсем не то, что обычно понимают под словом финтех, хотя это тоже про деньги. Я был на конференции как человек из другой индустрии, у меня была задача сделать доклад на стыке. Тем более, что в банке я тоже прилично проработал.

Недолго думая я решил рассказать про 3 кейса, почему в некоторых продуктовых ecom компаниях очень быстро идет работа с области аналитики и DS. Сами идеи небольшие и как раз уместятся в один пост.

Активное использование событий как источника данных

Во многих компаниях, в т. ч. в банках, доставка данных в хранилище данных строится на базе технологии CDC, change data capture. При всех плюсах у этого подхода есть пару недостатков: CDC реплики делать дорого и дорого поддерживать, а структуры баз данных сервисов не предназначены для аналитических запросов. Поэтому создание витрин напрямую из сырых реплик требует значительных ресурсов и сложных методологий (привет 6-я нормальная форма и data vault). Зато, в хранилище всегда лежит точная копия данных.

Но часто прямо 100%-ная точность не нужна. В итоге вы же считаете агрегированные метрики или достаете небольшой семпл конкретных примеров. Если потеряете одну строчку - ну ничего страшного. Продуктовые компании этим активно пользуются и часть своей аналитики строят на событиях. Это когда вы в середине какого-то процесса отправляете сообщение в формате JSON с какими-то данными и они летят в сторону хранилища. Получается сильно быстрее: и само событие добавить дело нехитрое, и потом на стороне аналитики джойнить нужно меньше. Пропадают события нечасто, но такое может быть. И уж если пропадет, то пропадет насовсем. Такая плата за эффективность.

Возможность тестирования на проде для ускорения работы

В банках прод обычно держат за семью печатями. А когда вы работаете с аналитикой или ML-сценариями, отладиться в тестовой среде просто невозможно.

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

Поэтому работу с продом нужно не запрещать, а нужно создавать безопасные подходы работы.

Прямой доступ аналитиков к некоторым продовым API

И развивая предыдущую историю. Аналитикам и DS-ам нужно в некоторых сценариях ходить в продовые API. Например, где-то можно нужно запустить тест. Где-то нужно поискать баги. Где-то получить данные в моменте. Если на каждую проблему откатывать сервис, уходить в тестовый контур, и пытаться воспроизвести проблему, то можно фичи делать бесконечно. С дата-центричными сервисами такое плохо работает.

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

Спасибо что дочитали! Надеюсь было интересно ❤️

#tech