Forwarded from ML Advertising
Сделал подборку туториалов по промпт инжинирингу для LLM:
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Claude API Docs
Prompt engineering overview
Claude API Documentation
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №4. Choosing Technologies Across the Data Engineering Lifecycle. Часть №3
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №5. Data Generation in Source Systems. Часть №1 Источники исходных данных для Data системы.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №5. Data Generation in Source Systems. Часть №2 Важные термины и паттерны в контексте Data Generation
🔹Change Data Capture (CDC)
CDC это прием подразумевающий что мы извлекаем из СУБД каждое событие изменения состояния (вставка, обновление, удаление).
CDC используется для:
- репликации между базами данных практически в режиме реального времени
- создания потока событий для последующей обработки.
🔹Логи / Журнал СУБД как источник информации
Журнал базы данных могут быть очень полезным инструментом для создания Data систем, в частности стать источником информации для CDC системы, в результате работы которой можно получить поток событий изменений СУБД.
Журнал фиксирует основную информацию о событии (запросе) + метаданные (пользователь, настройки итп)
Журнал можно хранить по разному. Бинарный формат эффективен с точки зрения хранения и ввода-вывода, в то время как полуструктурированный текст переносимый и легко парсится.
🔹CRUD (Create, Read, Update, Destroy)
CRUD - это термин описывающий основные операции над данными в программировании. Он широко используется в API и базах данных для хранения и извлечения данных.
🔹Insert-only сценарий
Подход "Только для вставки" подразумевает что все данные в хранилище неизменяемые, следовательно если нам требуется внести изменение то мы создаем новые строки с измененным состоянием.
Основной известный мне пример такого подхода - событийные системы и брокеры сообщений. Event Sourcing и вот это вот всё. Важно помнить что на больших нагрузках хранилище может очень быстро распухнуть и это нужно закладывать в план масштабирования.
🔹Change Data Capture (CDC)
CDC это прием подразумевающий что мы извлекаем из СУБД каждое событие изменения состояния (вставка, обновление, удаление).
CDC используется для:
- репликации между базами данных практически в режиме реального времени
- создания потока событий для последующей обработки.
🔹Логи / Журнал СУБД как источник информации
Журнал базы данных могут быть очень полезным инструментом для создания Data систем, в частности стать источником информации для CDC системы, в результате работы которой можно получить поток событий изменений СУБД.
Журнал фиксирует основную информацию о событии (запросе) + метаданные (пользователь, настройки итп)
Журнал можно хранить по разному. Бинарный формат эффективен с точки зрения хранения и ввода-вывода, в то время как полуструктурированный текст переносимый и легко парсится.
🔹CRUD (Create, Read, Update, Destroy)
CRUD - это термин описывающий основные операции над данными в программировании. Он широко используется в API и базах данных для хранения и извлечения данных.
🔹Insert-only сценарий
Подход "Только для вставки" подразумевает что все данные в хранилище неизменяемые, следовательно если нам требуется внести изменение то мы создаем новые строки с измененным состоянием.
Основной известный мне пример такого подхода - событийные системы и брокеры сообщений. Event Sourcing и вот это вот всё. Важно помнить что на больших нагрузках хранилище может очень быстро распухнуть и это нужно закладывать в план масштабирования.
Forwarded from LLM под капотом
Можно ли использовать LLM для оптимизации промптов?
Время от времени кто-нибудь в чате поднимает этот вопрос. Более того, я сам в курсе рассказывал про использование мощных моделей в дистилляции инструкций для моделей послабее.
Казалось бы, что может быть сложного в том, чтобы задать вопрос:
А потом просто автоматизировать процесс перебора вариантов.
Проблема в том, что в итоге будет ерунда и каша. LLM по своей природе усредняют ответы, чтобы понравиться среднему читателю. Их к этому приучили через RLHF. На скриншоте пример того, как ChatGPT o1 pro пару минут назад у меня банально скатилась в китайский, настолько она старалась сгладить логические углы.
А при работе с какими-то исключениями и конкретными кейсами нам не нужно сглаживать углы. Наоборот, надо раскручивать размышления, раскапывать нестыковки.
Поэтому лучше работает, когда мы даем мощной LLM материал для размышлений и просим ее проанализировать ошибки. А потом глазами просматриваем результаты и сами изменяем промпт.
Получается в итоге тот же паттерн "Human in the Loop", даже для оптимизации логических блоков. Как без него обойтись в разработке систем с LLM под капотом - я пока не знаю.
Ваш, @llm_under_hood 🤗
Время от времени кто-нибудь в чате поднимает этот вопрос. Более того, я сам в курсе рассказывал про использование мощных моделей в дистилляции инструкций для моделей послабее.
Казалось бы, что может быть сложного в том, чтобы задать вопрос:
Эй, ChatGPT, вот тебе исходный промпт и вот результаты его работы. Перепиши промпт так, чтобы этих ошибок больше не было.
А потом просто автоматизировать процесс перебора вариантов.
Проблема в том, что в итоге будет ерунда и каша. LLM по своей природе усредняют ответы, чтобы понравиться среднему читателю. Их к этому приучили через RLHF. На скриншоте пример того, как ChatGPT o1 pro пару минут назад у меня банально скатилась в китайский, настолько она старалась сгладить логические углы.
А при работе с какими-то исключениями и конкретными кейсами нам не нужно сглаживать углы. Наоборот, надо раскручивать размышления, раскапывать нестыковки.
Поэтому лучше работает, когда мы даем мощной LLM материал для размышлений и просим ее проанализировать ошибки. А потом глазами просматриваем результаты и сами изменяем промпт.
Получается в итоге тот же паттерн "Human in the Loop", даже для оптимизации логических блоков. Как без него обойтись в разработке систем с LLM под капотом - я пока не знаю.
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Новую PDF распознавалку от IBM подвезли - SmolDocling
Это vision LM в 256M. Говорят, что работает лучше Qwen2.5VL, но не со всеми языками. Импонирует то, что модель извлекает не просто текст, а сразу структуру.
Что там под капотом?
- Это vision LM со специальными токенами для элементов markdown
- Основана на SmolVLM-256M — самой компактной vision LM.
- Обучена на страницах и транскрипциях Docling (с использованием нового формата DocTags для лучшего отображения элементов и их местоположения).
- Читает документ за 0.35 секунды (на A100) при использовании 0.5 GB VRAM.
- Доступна в Hugging Face transformers и vLLM.
Модельку качать тут, пробовать тут.
Кто-нибудь уже пробовал на своих задачах?
Ваш, @llm_under_hood 🤗
PS: Whitepaper: https://arxiv.org/html/2503.11576v1
Это vision LM в 256M. Говорят, что работает лучше Qwen2.5VL, но не со всеми языками. Импонирует то, что модель извлекает не просто текст, а сразу структуру.
Что там под капотом?
- Это vision LM со специальными токенами для элементов markdown
- Основана на SmolVLM-256M — самой компактной vision LM.
- Обучена на страницах и транскрипциях Docling (с использованием нового формата DocTags для лучшего отображения элементов и их местоположения).
- Читает документ за 0.35 секунды (на A100) при использовании 0.5 GB VRAM.
- Доступна в Hugging Face transformers и vLLM.
Модельку качать тут, пробовать тут.
Кто-нибудь уже пробовал на своих задачах?
Ваш, @llm_under_hood 🤗
PS: Whitepaper: https://arxiv.org/html/2503.11576v1
Forwarded from LLM под капотом
Все архитектуры Enterprise RAG Challenge
Вот вам обновленный и интерактивный leaderboard по результатам второго раунда Enterprise RAG Challenge: https://abdullin.com/erc/. Можно кликать на команды и читать про детали их решений на основе заполненных опросников. Если у команды было несколько экспериментов, то в карточке они тоже будут упомянуты.
В итоге у нашего коммьюнити получилось мощное исследование разных RAG архитектур на практической бизнес-задаче!
Причем, leaderboard с деталями решений - это далеко не последний результат. Я попозже дополню эту таблицу ссылками на посты и исходники, которые мне присылают.
А еще мы потихоньку начинаем планировать третий round. Его в итоге обсуждений решили сделать более организованным, чтобы выхлоп от R&D был интереснее и полезнее для всех в нашем комьюнити.
Идея простая - учимся на своих ошибках и двигаемся дальше.
В первом раунде мы обнаружили, что решения на базе SO / CoT легко занимают первое место. Вывод - сделаем генератор вопросов менее предсказуемым, чтобы SO/CoT жизнь маслом не казалась.
Второй раунд - многие использовали SO/CoT без векторов, но в итоге победило решение Ильи. Он заранее собрал инфраструктуру для оценки своего пайплайна и перебрал варианты его настройки на основе тестового набора данных.
Вывод - заранее соберем нормальную инфраструктуру для оценки пайплайнов и опубликуем ее вместе с тестовыми данными для всех желающих. Чтобы каждый мог быстро ставить разные эксперименты и оценивать их результаты.
И посмотрим, что получится в третьем раунде. Ведь интересно же, правда?)
Ваш, @llm_under_hood 🤗
Вот вам обновленный и интерактивный leaderboard по результатам второго раунда Enterprise RAG Challenge: https://abdullin.com/erc/. Можно кликать на команды и читать про детали их решений на основе заполненных опросников. Если у команды было несколько экспериментов, то в карточке они тоже будут упомянуты.
В итоге у нашего коммьюнити получилось мощное исследование разных RAG архитектур на практической бизнес-задаче!
Причем, leaderboard с деталями решений - это далеко не последний результат. Я попозже дополню эту таблицу ссылками на посты и исходники, которые мне присылают.
А еще мы потихоньку начинаем планировать третий round. Его в итоге обсуждений решили сделать более организованным, чтобы выхлоп от R&D был интереснее и полезнее для всех в нашем комьюнити.
Идея простая - учимся на своих ошибках и двигаемся дальше.
В первом раунде мы обнаружили, что решения на базе SO / CoT легко занимают первое место. Вывод - сделаем генератор вопросов менее предсказуемым, чтобы SO/CoT жизнь маслом не казалась.
Второй раунд - многие использовали SO/CoT без векторов, но в итоге победило решение Ильи. Он заранее собрал инфраструктуру для оценки своего пайплайна и перебрал варианты его настройки на основе тестового набора данных.
Вывод - заранее соберем нормальную инфраструктуру для оценки пайплайнов и опубликуем ее вместе с тестовыми данными для всех желающих. Чтобы каждый мог быстро ставить разные эксперименты и оценивать их результаты.
И посмотрим, что получится в третьем раунде. Ведь интересно же, правда?)
Ваш, @llm_under_hood 🤗
Forwarded from Artem Ryblov’s Data Science Weekly
Machine Learning from Scratch by Danny Friedman
This book is for readers looking to learn new machine learning algorithms or understand algorithms at a deeper level. Specifically, it is intended for readers interested in seeing machine learning algorithms derived from start to finish. Seeing these derivations might help a reader previously unfamiliar with common algorithms understand how they work intuitively. Or, seeing these derivations might help a reader experienced in modeling understand how different algorithms create the models they do and the advantages and disadvantages of each one.
This book will be most helpful for those with practice in basic modeling. It does not review best practices—such as feature engineering or balancing response variables—or discuss in depth when certain models are more appropriate than others. Instead, it focuses on the elements of those models.
Link: Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning
@data_science_weekly
This book is for readers looking to learn new machine learning algorithms or understand algorithms at a deeper level. Specifically, it is intended for readers interested in seeing machine learning algorithms derived from start to finish. Seeing these derivations might help a reader previously unfamiliar with common algorithms understand how they work intuitively. Or, seeing these derivations might help a reader experienced in modeling understand how different algorithms create the models they do and the advantages and disadvantages of each one.
This book will be most helpful for those with practice in basic modeling. It does not review best practices—such as feature engineering or balancing response variables—or discuss in depth when certain models are more appropriate than others. Instead, it focuses on the elements of those models.
Link: Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning
@data_science_weekly
Forwarded from Quant Valerian
Пятничная рубрика "Пыльный чулан"
Вообще должен был быть юбилей с достижением мной пятидесяти проведенных архитектурных секций, но кандидаты посливались в последний момент.
Но это не повод оставить вас без поста с полезняхами! Вспоминаем всё полезное для подготовки к систем дизайну (архитектуре).
- Теория распределенных систем и вычислений. Неплохой пост для тех, кто чувствует нехватку теоретической базы. Особенно полезная там ссылка на гигантскую компиляцию Йельского университета, она регулярно обновляется. В ней есть все современные темы, о которых я слышал.
- Применение теории для построения реальных систем. Мне нравится курс Олега Бунина в на Физтехе. Там разобрано много стандартных паттернов проектирования высоконагруженных систем. Особенно классно, что в записи есть и разборы кейсов.
- Если мы говорим про собесы, то недавно мне скинули целый сайт методичку для FAANG'овских систем дизайнов. Там и задачи есть, можно порешать, а потом свериться с решением. Для меня особенно полезно было посмотреть, как они оценивают уровень, и насколько это совпадает с нашими оценками. Довольно сильно совпадает, BTW.
- Ну и наконец максимально практичная штука — заказ железа. Мы этим занимаемся раз в год стабильно. Чаще всего можно оттолкнуться от текущей утилизации и прикидок по росту, но иногда в планах какие-то новые сервисы или даже системы сервисов. Как быть рассказываю в моих постах.
Вообще должен был быть юбилей с достижением мной пятидесяти проведенных архитектурных секций, но кандидаты посливались в последний момент.
Но это не повод оставить вас без поста с полезняхами! Вспоминаем всё полезное для подготовки к систем дизайну (архитектуре).
- Теория распределенных систем и вычислений. Неплохой пост для тех, кто чувствует нехватку теоретической базы. Особенно полезная там ссылка на гигантскую компиляцию Йельского университета, она регулярно обновляется. В ней есть все современные темы, о которых я слышал.
- Применение теории для построения реальных систем. Мне нравится курс Олега Бунина в на Физтехе. Там разобрано много стандартных паттернов проектирования высоконагруженных систем. Особенно классно, что в записи есть и разборы кейсов.
- Если мы говорим про собесы, то недавно мне скинули целый сайт методичку для FAANG'овских систем дизайнов. Там и задачи есть, можно порешать, а потом свериться с решением. Для меня особенно полезно было посмотреть, как они оценивают уровень, и насколько это совпадает с нашими оценками. Довольно сильно совпадает, BTW.
- Ну и наконец максимально практичная штука — заказ железа. Мы этим занимаемся раз в год стабильно. Чаще всего можно оттолкнуться от текущей утилизации и прикидок по росту, но иногда в планах какие-то новые сервисы или даже системы сервисов. Как быть рассказываю в моих постах.
Telegram
Quant Valerian
Как считать железо
У меня в очередной раз наступила пора подсчёта железа (пока я писал пост, она уже закончилась, но да ладно). Нужно прикинуть, сколько процессоров, памяти, дисков и сети понадобится сервисам и базам данных, за которые я отвечаю. Навык считать…
У меня в очередной раз наступила пора подсчёта железа (пока я писал пост, она уже закончилась, но да ладно). Нужно прикинуть, сколько процессоров, памяти, дисков и сети понадобится сервисам и базам данных, за которые я отвечаю. Навык считать…
Forwarded from AbstractDL
M-Attack: как обмануть GPT-4.5 и Gemini
Все привыкли, что атаковать современные мультимодальные модели (типа GPT-4o, Claude, Gemini и т.п.) крайне сложно — особенно, если это black-box модели, где нет доступа к градиентам и архитектуре. Стандартные подходы атак типа "выдать одну картинку за другую" часто генерируют какие-то невнятные шумы, которые либо игнорируются моделью, либо приводят к абстрактным ответам типа "размытое изображение".
Но оказалось, что проблема была не в самих моделях, а в подходе к генерации возмущений. В свежей статье предложили очень простой, но мощный подход — M-Attack:
1. Берём исходную и целевую картинки.
2. На каждом шаге рандомно crop'аем кусок исходного изображения (50-100% площади) и затем ресайзим обратно до исходного размера.
3. Заставляем эмбеддинги этого кусочка максимально приблизиться к эмбеддингам целевого изображения оптимизируясь в white-box режиме по ансамблю открытых визуальных моделей (например, CLIP, ViT и тп).
И всё! После нескольких итераций в центральной области картинки "проявляется" целевая семантика, при этом возмущения выглядят крайне незаметно и аккуратно (в отличие от других подходов).
Авторы добились совершенно впечатляющих результатов: успех атаки (ASR) превышает 90% (!) для GPT-4.5, GPT-4o и даже для o1 и Gemini. Код и датасет из 100 атакованных картинок выложили в открытый доступ.
Статья, GitHub, dataset
Все привыкли, что атаковать современные мультимодальные модели (типа GPT-4o, Claude, Gemini и т.п.) крайне сложно — особенно, если это black-box модели, где нет доступа к градиентам и архитектуре. Стандартные подходы атак типа "выдать одну картинку за другую" часто генерируют какие-то невнятные шумы, которые либо игнорируются моделью, либо приводят к абстрактным ответам типа "размытое изображение".
Но оказалось, что проблема была не в самих моделях, а в подходе к генерации возмущений. В свежей статье предложили очень простой, но мощный подход — M-Attack:
1. Берём исходную и целевую картинки.
2. На каждом шаге рандомно crop'аем кусок исходного изображения (50-100% площади) и затем ресайзим обратно до исходного размера.
3. Заставляем эмбеддинги этого кусочка максимально приблизиться к эмбеддингам целевого изображения оптимизируясь в white-box режиме по ансамблю открытых визуальных моделей (например, CLIP, ViT и тп).
И всё! После нескольких итераций в центральной области картинки "проявляется" целевая семантика, при этом возмущения выглядят крайне незаметно и аккуратно (в отличие от других подходов).
Авторы добились совершенно впечатляющих результатов: успех атаки (ASR) превышает 90% (!) для GPT-4.5, GPT-4o и даже для o1 и Gemini. Код и датасет из 100 атакованных картинок выложили в открытый доступ.
Статья, GitHub, dataset
Forwarded from Артем
Мне кажется это из разряда подобных иллюзий. Если смотреть издали видно одно, вглядеться в детали - другое. Современные нейросети явно делают упор на детали. В данном изображении ни одна сетка не смогла разглядеть Че Гевару.