Часть 1. Прыжок веры. Waifu-2b

Итак, в декабре выходит долгожданная Sana. Мы бросаемся ее файнтюнить и понимаем что нас наебали.
- модель натренена в fp16 и банально падает по NaN (не хватает размерности)
- DC AE оказался как говорят американцы - результаты выглядят весьма спорными. По-русски вае курежит не только глаза и роты, но и лица с особымым цинизмом (на фоне чего особенно смешно выглядят комментарии лоуренса что их вае в отличие от остальных вае не деформирует лица)
- генерации выглядят крайне однотипно, даже на разных сидах (мы думали что дело в бедности ембедингов Гемма)
- трейн на квадратах - нельзя понять как хорошо модель адаптирует резолюшен

Стас заводит ишью с предложением перетренить в бф16 для повышение стабильности. Я прошу добавить кеширование и трейн в мультирезолюшен. Мы находим друг друга и объединяем усилия. Паралельно Саша не бросает надежды получить что то адекватное из sd35m (зря-зря)

Мы анализируем недостатки сана и пробуем их исправить:
- Стас пробует трейн на ембедингах сиглип
- Я тестирую разные ВАЕ и выбираю аура дифужен
- Саша разочаровавыется в сд35 и подключается к экспам с трейном сана (в тот момент я верю что нам нужен адафактор для стабилизации трейна, Саша адаптирует его)
- получаем промежуточные успешные результаты - модель тренится удивительно быстро как оказалось только в начале
Тем не менее сиглип ограничен небольшим количеством токенов и мы ищем более лучший ембединг. Как раз выходит МексМа-СигЛип от гугл с размером 512 токенов, с поддержкой 80 языков. Никем не протестированный. Стас помогает адаптировать модель и мы готовы к ретрейну Сана с нуля

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

Стен дает нам 2.5к на трейн и мы судорожно дебажим паралельно экспериментируя - стремясь максимально ускорить трейн. В итоге мы арендуем 2 H100 и запускаем трейн на НГ каникулы и уходим с чистой совесть бухать

При этом в качестве самой модели мы оставляем SanaTransformer2d - предполагая что в команде экс пиксарт (их же купил Нвидиа в которой работает Теро Карас!) работают не совсем раздолбаи и они обширно тестировали различные архитектуры перед тем как остановиться на этой (еще один прыжок веры - на этот раз в обрыв)

Через три недели получаем мультиязычную модель сомнительного качества
https://huggingface.co/AiArtLab/waifu-2b

( в карточке модели архитектура и код инференса)

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

Бэд ньюс: модель очень плохо адаптирует анатомию - переходим на трейн на "квадратах" чтобы получить хоть какой то результат - прототип. И понимаем что мы не можем сказать ETA когда модель станет лучше SDXL

Тем временем деньги заканчиваются. Начинаю разбираться как собственно работают эмбединги и понимаю что мы натренили не на мексма-сиглип - а только на мексма, лол. Что неплохо (80 языков из коробки) но можно лучше - достаточно сиглип привести в латентное пространство текста - чтобы получить абилку генерации по картинке нет.

Забавно что мы были чуть ли не первыми кто вообще взял мексма и получилось забавно:

Модель не генерит банан в форме осьминога, но генерит банан в форме octopus

Также например енот на мотоцикле - больше похож на крысу на велосипеде - но тем не менее.

Итого. Сломали стереотипы:

- Протестировали мультиязычность и доказали работоспособность. Получили отличный мультиязычный промпт фолоу - без жирных моделей а ля Т5!
- Затренили модель на 2 миллионах картинок - вместо 2 миллиардов
- Трейн занял примерно 3 недели, и обошелся в $3к

@Stangle - спасибо что поверил в трех дебилов!
@drimeF0 @ssssssssssssssssssssssssps @recoilme

Главное: мы поверили в себя

В следующей серии: проектируем свою архитектуру на этот раз без Сана

Тренд безопасности AI-агентов
#иб_для_ml

Что есть сейчас, и к чему идет этот тренд? Развивается, но почему?
Захотелось рассказать, что думаю на этот счет, и услышать ваше мнение. Так что ниже будет опрос)

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

В чем риск AI-агентов?
Именно благодаря действиям к двум существующим эфемерным рискам добавится третий, уже далеко не эфемерный.
Первые два - это репутационный ущерб организации, если сервис с LLM торчит наружу, и нарушение бизнес-процессов при нарушении ожидаемой от ответов GenAI-модели логики. И то, и другое, может произойти как вследствие недостаточной AI Safety (модель сама выдала случайно некорректный ответ), так и в следствие недостаточной AI Security (нарушитель вызвал генерацию некорректного ответа).
А вот третий риск, специфичный для AI-агентов - это его возможность совершать действия, которые могут повлечь негативные последствия. И веер угроз тут огромен - от выгрузки за пределы контура конфиденциальной информации до загрузки зараженного файла внутрь этого контура, от случайного удаления файлов до перевода средств не на тот счет и не в том размере.

В заключение
Известно, что GenAI-модели как продукт - убыточная история, история без KPI. Затраты на разработку, дообучение (не говоря уж про претрейн) очень тяжело покрыть с доходов при интеграции модели в какие-то сервисы. Но, с точки зрения имиджа и в надежде на развитие прикладного использования, вложения продолжаются. С появлением же у GenAI-моделей способности влиять на мир вокруг, все изменится. Сначала (в 2025 году) появятся игрушечные агенты, которые будильник по расписанию ставят и товары по ТЗ в браузере находят. А спустя еще год, максимум два - они смогут и покупать найденные товары (и продавать ваши будильники, хехе...), иными словами - смогут манипулировать ограниченными ресурсами. И весь арсенал промпт-атак на GenAI обретет смысл, киллчейн достроится до конца. Тогда и начнется раздолье.
А про то, какие будут промпт-атаки, и почему произойдут первые инциденты в области AI Security, я расскажу в следующем посте)



P. S. Не удержался я все-таки, приведу одно хорошее исчерпывающее определение агента, чтобы было.

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

При чем интересно - одна половина определения (про автономность и достижение поставленных целей) - это определение просто агента из мат. моделирования 1970х годов. А другая половина (про планирование, реагирование и взаимодействие) - это уже интеллектуальный агент, концепция которых была развита М. Вулдриджем в 1990х годах.

#quant #papers

Сделал обзор на различные методы биннинга

#featureengineering #pysr #symbolicregression

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

Читаю сейчас статью pysr, у них интересный подход с генетиком над признаками, отобранными бустингом.

Очень хочу сравнить их результаты со своими на том же игрушечном примере.

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

Ps. ДА! pysr отлично справился с моим примером!

import numpy as np, pandas as pd

n =100_000
a = np.random.rand(n)
b = np.random.rand(n)
c = np.random.rand(n)
d = np.random.rand(n)
e = np.random.rand(n)
f = np.random.rand(n)

y=a**2/b+f/5+np.log(c)*np.sin(d)

df = pd.DataFrame(
    {
        "a": a,
        "b": b,
        "c": c,  
        "d": d,
        "e": e,

    }
)

from pysr import PySRRegressor

model = PySRRegressor(
    maxsize=20,
    niterations=40,  # < Increase me for better results
    binary_operators=["+", "*"],
    unary_operators=[
        "cos",
        "exp",
        "log",
        "sin",
        "inv(x) = 1/x",
        # ^ Custom operator (julia syntax)
    ],
    extra_sympy_mappings={"inv": lambda x: 1 / x},
    # ^ Define operator for SymPy as well
    elementwise_loss="loss(prediction, target) = (prediction - target)^2",
    # ^ Custom loss function (julia syntax)
)

model.fit(df, y)

model.get_best()

после ~6 минут работы

complexity 14
loss 0.003329
score 0.947915
sympy_format a**2/b + log(c)*sin(d) + 0.09998281

#featureengineering #pysr #symbolicregression #todo

Библиотека pysr заслуживает пристального внимания. Она настолько хорошо сделана, глубока и функциональна, что просто загляденье.

Полностью готова к внедрению в бой, поддерживает оптимизации, кластера, логгинг в тензорборд, пре-отбор признаков с помощью ML, сохранение прогресса в файл и тёплый старт.

Зацените функциональность и количество опций:

model = PySRRegressor(
    populations=8,
    # ^ Assuming we have 4 cores, this means 2 populations per core, so one is always running.
    population_size=50,
    # ^ Slightly larger populations, for greater diversity.
    ncycles_per_iteration=500,
    # ^ Generations between migrations.
    niterations=10000000,  # Run forever
    early_stop_condition=(
        "stop_if(loss, complexity) = loss < 1e-6 && complexity < 10"
        # Stop early if we find a good and simple equation
    ),
    timeout_in_seconds=60 * 60 * 24,
    # ^ Alternatively, stop after 24 hours have passed.
    maxsize=50,
    # ^ Allow greater complexity.
    maxdepth=10,
    # ^ But, avoid deep nesting.
    binary_operators=["*", "+", "-", "/"],
    unary_operators=["square", "cube", "exp", "cos2(x)=cos(x)^2"],
    constraints={
        "/": (-1, 9),
        "square": 9,
        "cube": 9,
        "exp": 9,
    },
    # ^ Limit the complexity within each argument.
    # "inv": (-1, 9) states that the numerator has no constraint,
    # but the denominator has a max complexity of 9.
    # "exp": 9 simply states that `exp` can only have
    # an expression of complexity 9 as input.
    nested_constraints={
        "square": {"square": 1, "cube": 1, "exp": 0},
        "cube": {"square": 1, "cube": 1, "exp": 0},
        "exp": {"square": 1, "cube": 1, "exp": 0},
    },
    # ^ Nesting constraints on operators. For example,
    # "square(exp(x))" is not allowed, since "square": {"exp": 0}.
    complexity_of_operators={"/": 2, "exp": 3},
    # ^ Custom complexity of particular operators.
    complexity_of_constants=2,
    # ^ Punish constants more than variables
    select_k_features=4,
    # ^ Train on only the 4 most important features
    progress=True,
    # ^ Can set to false if printing to a file.
    weight_randomize=0.1,
    # ^ Randomize the tree much more frequently
    cluster_manager=None,
    # ^ Can be set to, e.g., "slurm", to run a slurm
    # cluster. Just launch one script from the head node.
    precision=64,
    # ^ Higher precision calculations.
    warm_start=True,
    # ^ Start from where left off.
    turbo=True,
    # ^ Faster evaluation (experimental)
    extra_sympy_mappings={"cos2": lambda x: sympy.cos(x)**2},
    # extra_torch_mappings={sympy.cos: torch.cos},
    # ^ Not needed as cos already defined, but this
    # is how you define custom torch operators.
    # extra_jax_mappings={sympy.cos: "jnp.cos"},
    # ^ For JAX, one passes a string.
)

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

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

#graph #courses

Выжимка по каждой лекции https://miro.com/app/board/uXjVIdbackI=/?share_link_id=992426564760

#mlops #courses

Machine Learning in Production by Carnegie Mellon University

This is a course for those who want to build software products with machine learning, not just models and demos. We assume that you can train a model or build prompts to make predictions, but what does it take to turn the model into a product and actually deploy it, have confidence in its quality, and successfully operate and maintain it at scale?

The course is designed to establish a working relationship between software engineers and data scientists: both contribute to building ML-enabled systems but have different expertise and focuses. To work together they need a mutual understanding of their roles, tasks, concerns, and goals and build a working relationship. This course is aimed at software engineers who want to build robust and responsible products meeting the specific challenges of working with ML components and at data scientists who want to understand the requirements of the model for production use and want to facilitate getting a prototype model into production; it facilitates communication and collaboration between both roles. The course is a good fit for student looking at a career as an ML engineer. The course focuses on all the steps needed to turn a model into a production system in a responsible and reliable manner.

It covers topics such as:
- How to design for wrong predictions the model may make?
How to assure safety and security despite possible mistakes? How to design the user interface and the entire system to operate in the real world?
- How to reliably deploy and update models in production?
How can we test the entire machine learning pipeline? How can MLOps tools help to automate and scale the deployment process? How can we experiment in production (A/B testing, canary releases)? How do we detect data quality issues, concept drift, and feedback loops in production?
- How to scale production ML systems?
How do we design a system to process huge amounts of training data, telemetry data, and user requests? Should we use stream processing, batch processing, lambda architecture, or data lakes?
- How to test and debug production ML systems?
How can we evaluate the quality of a model’s predictions in production? How can we test the entire ML-enabled system, not just the model? What lessons can we learn from software testing, automated test case generation, simulation, and continuous integration for testing for production machine learning?
- Which qualities matter beyond a model’s prediction accuracy?
How can we identify and measure important quality requirements, including learning and inference latency, operating cost, scalability, explainablity, fairness, privacy, robustness, and safety? Does the application need to be able to operate offline and how often do we need to update the models? How do we identify what’s important in a ML-enabled product in a production setting for a business? How do we resolve conflicts and tradeoffs?
How to work effectively in interdisciplinary teams?
How can we bring data scientists, software engineers, UI designers, managers, domain experts, big data specialists, operators, legal council, and other roles together and develop a shared understanding and team culture?

Link: Course

Navigational hashtags: #armcourses
General hashtags: #ml #dl #machinelearning #deeplearning #mlsystemdesign #mlops #mlsysdes

@data_science_weekly