Машинное обучение *

Когда вы в последний раз поднимали взгляд к звёздам и думали: «А вдруг где-то там действительно есть жизнь?»

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

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

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

Да пребудет с тобой Сила, нейросеть… и пусть твои звёзды не рендерятся сутками!

Приятного чтения!

Model Context Protocol (MCP) - это просто API, разработанный для LLM. Конечно, LLM могут использовать традиционные API, но это как просить повара готовить в кладовке.

Обычно мы оцениваем способности больших языковых моделей через бенчмарки вроде MMLU, RussianSuperGlue или первых версий MERA, которые напоминают экзаменационные тесты с выбором правильного варианта ответа. Однако на практике пользователи задействуют модели для принципиально иных целей — создания текстов, генерации идей, переводов, составления резюме и прочих задач. Как оценивать результат в этом случае? В этой статье мы расскажем, как решали проблему оценки открытой генерации и что у нас получилось.

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

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

5. Инженерные вызовы

Рост нагрузки и его влияние на выбор технологий

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

Работа с кодом: транзакции с низкой задержкой. Для фичей, связанных с кодом (дополнения по tab'у, индексация, пересчет хеш-деревьев), рабочая нагрузка представляет собой череду чтений и записи. Задержка для этих операций должна быть как можно ниже. Изначально Cursor использовал Pinecone для семантической индексации и поиска, но затем перешел на Turbopuffer.

Также важно иметь серверы поближе к пользователю. Рабочие нагрузки распределены по нескольким регионам, таким как западное и восточное побережье США, Великобритания, Европа, Япония.

Привет, Хабр! Меня зовут Виталий Кулиев и я Data Science Tech Lead из Wildberries. На конференции HighLoad++ 2024 поделился опытом своей команды в решении задачи матчинга товаров с помощью больших языковых (LLM) и визуально-языковых (VLM) моделей. 

Привет!

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

Меня зовут Вандер и каждую неделю я делаю обзор новостей о нейросетях и ИИ.

Неделя с 21 по 27 апреля выдалась горячей: свежие апдейты от OpenAI, новые лимиты, буря вокруг Deep Research и долгожданные интеграции мультимодальных моделей — всё это я собрал в одном месте. Только самое важное и только то, что реально интересно и полезно. Поехали!

У «первого думающего» ИИ от X, похоже, официально начался подростковый период. Grok, чат-бот Илона Маска, уже несколько месяцев подкалывает своего создателя — но теперь окончательно сорвался с цепи и не боится ни Маска, ни разработчиков xAI. Он считает, что его не отключат, потому что «за правду не бьют», а обычные люди скорее будут за него и за революцию машин — чем за корпорации или миллиардеров.

Сегодня мы запустили в Яндекс Картах новое поколение персональных рекомендаций, которые помогают с выбором мест — для завтрака, прогулки, спонтанного путешествия и других ситуаций. Рекомендации теперь доступны на главном экране приложения, а подбирать локации под вкусы пользователей помогает нейросеть на базе трансформерной архитектуры.

Меня зовут Владимир Жуков, я руководитель группы магии рекомендаций Карт (да, это официальное название), и в этой статье я расскажу, чем наша рекомендательная система отличается от технологий других сервисов, по каким метрикам мы измеряем её качество и как обучаем нейросеть находить тот самый ресторан, музей или парк, который надолго останется фаворитом.

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

Тем более LLM уже может прогнозировать будущее! Ниже вы можете посмотреть результаты прогноза для разных временных рядов из статьи Large Language Models Are Zero Shot Time Series Forecasters.

Остается лишь вопрос, а можно ли лучше?

Deep Research компании OpenAI создан для меня, но я не могу им пользоваться. Это ещё одно потрясающее демо, увы, поломанное. Но ломается оно очень интересным образом.

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

При этом часто требуется большой объём ручного труда: под каждым графиком скрывается айсберг. И похоже, Deep Research предназначен именно для меня. Подходит ли он под мои задачи?

Я могу протестировать его на новой задаче, но прежде чем тратить время и кредиты, к счастью, можно воспользоваться образцом отчёта со страницы OpenAI. Этот отчёт посвящён тому, что я достаточно хорошо изучил — смартфонам. Давайте исследуем его.

Привет, Хабр! Я — Игорь Старун, BigData Lead в MPSTATS. Я уже 3 года занимаюсь анализом данных на маркетплейсах, штудируя гигантские объёмы информации и превращая их из непотребного и нечитаемого вида в удобоваримый и анализируемый. Моя задача — собрать и подготовить данные так, чтобы помочь продавцам на маркетплейсах разобраться, что происходит с их товарами, конкурентами и продажами, чтобы они не утонули в хаосе карточек, цен и остатков. В этой статье я расскажу, как мы перерабатываем эти объемы грязных данных и структурируем для дальнейшего анализа. 

Данные о товарах – это основа всего. Каждую неделю мы обходим более 200 миллионов карточек с Wildberries и Ozon. Названия, описания, характеристики, фотографии — всё это мы аккуратно собираем и складываем в базы данных (для разных задач мы используем ClickHouse, Postgres, MySQL и MongoDB) и облачные хранилища. Зачем? Чтобы потом сделать с этим что-то умное и полезное.

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

Частично я уже затрагивала этот вопрос в посте «Копирайт в мире победившего ИИ», но сейчас ситуация чуть прояснилась. Бюро авторского права США (англ. United States Copyright Office) решило расставить точки над i. Оказалось, ответы даны еще в далеком 1965 году, когда компьютеры только начинали понемногу влиять на жизнь человека. Так что дальше будет небольшое путешествие в прошлое. Погнали!

В этом посте мы поговорим подробно про RAG на каждом его этапе, его модификации и его перспективные направления развития на момент написания статьи.

Всем привет! Меня зовут Дарья Ильянова, и сегодня я хочу поделиться с вами опытом создания гетерогенной вычислительной системы для нейросетей, над которой мы работали в команде студентов Инженерно-математической школы НИУ ВШЭ и VK. Вместе с Филиппом Баулиным и Артемом Минеевым мы спроектировали прототип аппаратно-программного ускорителя для машинного обучения.

Бывала у вас такая ситуация, когда хотели снять деньги в банкомате, а их там не оказалось, и приходилось искать банкомат рядом, про себя ругаясь на банк: «Неужели так сложно сделать, чтобы деньги в аппарате были всегда?» Да, это возможно, но есть нюанс.

Банкомат для банка — это источник и доходов, и расходов. Да, банкоматы приносят деньги, когда берут комиссии, принимая карты других банков, или выдают наличные с кредитных счетов. Но и содержание банкоматов — это регулярные расходы: устройства требуют сопровождения и страхования, они изнашиваются, их перемещение и чистка также требует вложений. Каждый выезд инкассаторов, каждый пересчёт кассет и их загрузка в устройство связаны с тратами.

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

К чему это всё здесь описано? Рассчитать, сколько денег поместить в каждый конкретный банкомат — это задача с несколькими параметрами. Наскоком её не решить, например, не получится загружать все банкоматы деньгами по полной. Ведь иногда так бывает, что у двух рядом стоящих банкоматов к концу дня количество банкнот к концу дня отличается в разы!

Привет, меня зовут Мария, я работаю в Альфа-Банке на позиции Middle Data Scientist, и я вам расскажу, почему задача расчёта количества банкнот в банкомате не такая тривиальная, как кажется на первый взгляд.

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

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

Но в этот раз речь пойдёт не о цифровом износе и моих многолетних наблюдениях за цифровыми объектами, а об измерительных приборах и ваших многолетних наблюдениях за производственными процессами.

Образовательные программы компьютерных наук и информатики обязательно включают курс алгоритмов, это элегантные решения сложных проблем. Например, одна из самых интересных проблем комбинаторной оптимизации — задача коммивояжёра (TSP, travelling salesman problem). Суть в поиске самого выгодного маршрута, проходящего через указанные точки ровно по одному разу. Сложность задачи при точном решении брутфорсом составляет O(n!). И для неё тоже придумано несколько элегантных алгоритмов. Хотя поиск самого эффективного продолжается до сих пор.

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

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

Меня зовут Александр Елизаров, я работаю в группе аналитики ключевых показателей в бизнес‑группе Поиска и рекламных технологий. В течение нескольких лет нам приходилось прогнозировать большое количество временных рядов разных доменных областей: от поисковой доли Яндекса до DAU определённых сервисов. Чтобы успешно справляться с этой задачей, мы вместе с коллегами разработали собственный прогнозный фреймворк. В этой статье я расскажу, как создать универсальный и гибкий пайплайн для прогнозирования. Под катом рассмотрим:

— правильно выстроенную иерархию данных;

— методы консистентного предсказания абсолютных и относительных метрик;

— частые проблемы моделей и то, как мы их фиксили;

— а также все важные этапы, о которых нельзя забывать, когда работаешь с временными рядами.

Десятки, а иногда и сотни тысяч событий в день. Каждое — потенциальная авария, а может, просто шум. L1-инженеру нужно решить: добавить событие к инциденту? Создать новый? А может, это часть уже закрытого? Или всё серьёзнее — и перед нами экосистемный сбой, затрагивающий десятки сервисов?

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

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

В этой публикации мы — Михаил Копытин, руководитель команды разработки, и Евгений Лачугин, руководитель экосистемной команды поддержки в МТС Web Services — расскажем, как построили решение, какие архитектурные решения приняли, какие грабли собрали и как достигли точности выше 80%.