Forwarded from Борис_ь с ml
По следам Turbo ML Conf 2025
#праздное #иб_для_ml #ml_для_иб
Отличная конференция, ребятам из Т-Банка - спасибо)
Общие впечатления
Много писать не буду, скажу одним предложением - содержательные доклады, QnA зоны для спикеров, достаточно свободного места и кресел, тематическое оформление, и, конечно,шикарный кейтеринг) .
Доклады, которые я посетил, мне все понравились.
🔃 Трек LLM App, «Workflow-агенты на стероидах: 5 прототипов бизнес-автоматизаций за квартал», Валерий Ковальский, red_mad_robot.
Подробнейший рассказ про практику интеграции RAG в различных компаниях (преимущественно девелоперы), основывающейся на подходе трехуровневой системы управления знаниями - Domain, Collection, Document (DCD). Идея в том, чтобы запросы маршрутизировать сначала по доменам знаний (пользовательские соглашения, описания услуг, документация по ЖК, ...), а потом по коллекциям, и только затем на документы (похоже на статью HiRAG).
Но что самое крутое, Валерий уделил внимание и практике построения гардрейлов. Осветил подход к их проектированию (шлюз с фильтрацией промптов и ответов с базой промптов, интеграция с ролевой моделью, DLP, и защита RAG от галлюцинаций. По исполнению гардрейлы это правила, BERT'ы и LLM. Там много практических, например, по его опыту, на этапе эксплутации регэкспы/листы добавляют ~150 мс, BERT'ы еще ~150 мс, а LLM плюс ~600 мс. Точность их гардрейлов - 94%.
⚙ Трек LLM App, «LLM, агенты и MCP: от «модно» до «можно»», Ярослав Хрипков, Авито.
Оказалось, в Avito тоже строят гардрейлы. Правда, про них был всего один слайд: делайте хотя бы регулярки, least privilege access, mTLS-авторизацию, и сандбоксинг ллм-генерированного кода. А вообще доклад посвящен практике внедрения MCP. Тут и про влияние количества инструментов на качество (спойлер - 10 это край, а лучше 5 ). Посчитали также, что при росте количества инструментов и количества серверов сильно разрастается количество токенов, требуемого для их описания. Показали схему динамического тулинга, путь Авито к мультиагентным системам, лучшие модели для тулинга по лидерборду BFCL (лучшая - xLAM-2-70b ).
🖼 Трек RnD, «Мультимодальные агенты — что уже есть и что будет дальше», Георгий Бредис, Т-Банк.
Обзорный доклад с инфой о текущих вызовах в мультимодальности и статусе их решения. Мультимодальных агентов (пусть будут ММА) можно учить на трех видах данных: интерфейсы программ, роботы, и игры. Пространство их действий при этом тоже бывает трех видов: дискретные действия (вправо/влево, вперед/назад, взять/положить, уже существующие внутри среды), непрерывные действия (у роботов), и текстовые/числовые действия (ввод в строку поиска, координаты точки нажатия). Для решения задач непрерывных действий, например, показана идея двухуровневой системы, где большой трансформер дает редкие и общие команды (типа "пройти до двери"), а маленькие дает частые и конкретные (повернуться, пройти вперед). Ризонинг - считается решенной задачей, достижение aha-moment при обучении уже стоит на потоке. Но многоступенчатые сложные задачи еще не поддаются сегодняшним ризонерам.
Сегодняшние проблемы ММА:
1. Knowing-doing-gap - модель знает, что происходит, но не может перевести в действие
2. Модель не различает k-й и k+1-й кадр
3. Память и планирование
Многообещающим подходом является Learn by interaction. Учиться без наград от среды, а через intrinsic-награду, когда модель сама говорит об уверенности в своих действий. Есть подход generative value estimation в эту сторону. Очень круто, интересно, что будет дальше)
🍑 Трек RnD, «Ненадежность современных LLM и методы борьбы с ней», Егор Швецов, Skoltech.
Докладчик показал несколько исследований его команды, самое интересное из которых - определение в трансформерах голов внимания (кусочков архитектуры), наиболее уязвимых к генерации галлюцинаций. Благодаря этому удалось эффективного снизить количество галлюцинаций на контрольной выборке. Еще из интересных наблюдений - квантизация разрушает выравнивание и усиливает галлюны.
Пока ждем выкладки докладов, я выложу фотки слайдов в комментарии)
А когда выложат презентации и записи, добавлю ссылки.
#праздное #иб_для_ml #ml_для_иб
Отличная конференция, ребятам из Т-Банка - спасибо)
Общие впечатления
Много писать не буду, скажу одним предложением - содержательные доклады, QnA зоны для спикеров, достаточно свободного места и кресел, тематическое оформление, и, конечно,
Доклады, которые я посетил, мне все понравились.
Подробнейший рассказ про практику интеграции RAG в различных компаниях (преимущественно девелоперы), основывающейся на подходе трехуровневой системы управления знаниями - Domain, Collection, Document (DCD). Идея в том, чтобы запросы маршрутизировать сначала по доменам знаний (пользовательские соглашения, описания услуг, документация по ЖК, ...), а потом по коллекциям, и только затем на документы (похоже на статью HiRAG).
Но что самое крутое, Валерий уделил внимание и практике построения гардрейлов. Осветил подход к их проектированию (шлюз с фильтрацией промптов и ответов с базой промптов, интеграция с ролевой моделью, DLP, и защита RAG от галлюцинаций. По исполнению гардрейлы это правила, BERT'ы и LLM. Там много практических, например, по его опыту, на этапе эксплутации регэкспы/листы добавляют ~150 мс, BERT'ы еще ~150 мс, а LLM плюс ~600 мс. Точность их гардрейлов - 94%.
Оказалось, в Avito тоже строят гардрейлы. Правда, про них был всего один слайд: делайте хотя бы регулярки, least privilege access, mTLS-авторизацию, и сандбоксинг ллм-генерированного кода. А вообще доклад посвящен практике внедрения MCP. Тут и про влияние количества инструментов на качество (
Обзорный доклад с инфой о текущих вызовах в мультимодальности и статусе их решения. Мультимодальных агентов (пусть будут ММА) можно учить на трех видах данных: интерфейсы программ, роботы, и игры. Пространство их действий при этом тоже бывает трех видов: дискретные действия (вправо/влево, вперед/назад, взять/положить, уже существующие внутри среды), непрерывные действия (у роботов), и текстовые/числовые действия (ввод в строку поиска, координаты точки нажатия). Для решения задач непрерывных действий, например, показана идея двухуровневой системы, где большой трансформер дает редкие и общие команды (типа "пройти до двери"), а маленькие дает частые и конкретные (повернуться, пройти вперед). Ризонинг - считается решенной задачей, достижение aha-moment при обучении уже стоит на потоке. Но многоступенчатые сложные задачи еще не поддаются сегодняшним ризонерам.
Сегодняшние проблемы ММА:
1. Knowing-doing-gap - модель знает, что происходит, но не может перевести в действие
2. Модель не различает k-й и k+1-й кадр
3. Память и планирование
Многообещающим подходом является Learn by interaction. Учиться без наград от среды, а через intrinsic-награду, когда модель сама говорит об уверенности в своих действий. Есть подход generative value estimation в эту сторону. Очень круто, интересно, что будет дальше)
Докладчик показал несколько исследований его команды, самое интересное из которых - определение в трансформерах голов внимания (кусочков архитектуры), наиболее уязвимых к генерации галлюцинаций. Благодаря этому удалось эффективного снизить количество галлюцинаций на контрольной выборке. Еще из интересных наблюдений - квантизация разрушает выравнивание и усиливает галлюны.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Борис_ь с ml
Рантайм-безопасность для AI-агентов
#иб_для_ml
AI-агенты внедряются во всю - это не просто горячая тема, а, как обычно, в чем-то даже перегретая. Но от действительности не сбежать, и при внедрении агентов в бизнес-процессы возникает вопрос о принятии мер безопасности при инцидентах. Об угрозах я писал раннее, теперь же рассмотрим, что с ними делать не в дизайнтайм (AISecOps - это тема отдельного разговора), а в рантайме.
ℹ️ Гардрейлами (guardrails) называют механизмы рантайм безопасности агентов. Это наложенные СЗИ. Да, по сути, это Firewall/EDR/XDR из терминов SOC, но для текстовых данных.
🤖 Крупные компании про гардрейлы уже давно задумались:
➡️ OpenAI предоставляет отдельный Moderation API для проверки вводов/выводов моделей на нежелательный контент – он мониторит и фильтрует токсичные или запрещённые ответы в режиме реального времени. И даже дают гайды по созданию гардрейлов.
➡️ Amazon Bedrock ввёл настраиваемые Guardrails: разработчик может вызвать сервис ApplyGuardrail для оценки любого текста (ввода пользователя или ответа модели) по предопределённым правилам (запретные темы, фильтры токсичного контента, детекторы PII и др.) и получить решение – пропустить, отфильтровать или заблокировать содержимое
➡️ IBM в платформе Watson X предоставляют автоматическое включение AI Guardrails при вызове моделей: входные промпты проверяются специальным классификатором, и если помечены как неуместные – не передаются модели, а пользователю возвращается сообщение об отклонении; аналогично, если уже выход модели содержит запрещённый текст, он заменяется заглушкой “[Potentially harmful text removed]” вместо исходного ответа.
📝 Какими гардрейлы бывают
1. По потоку данных - на входящих данных, на выходящих данных, на размышлениях, или на инструментах - подробнее на картинке.
2. По способу размещения в потоке данных - в разрыв или в параллель. То есть ждет ли бизнес-логика решения от GR, или отрабатывает в любом случае. Но есть ли и промежуточный тип. GR запускается в параллель на input-тексте LLM или на первых ~100 токенах output'а, и если обнаруживает атаку - блочит ответ. А если не находит - то ответ уходит без задержки.
3. По способу действия - детекторы и преобразователи. Первые сначала отбрасывают алерт, а потом к AI-агенту или к объекту данных применяется реагирование. Вторые ничего не ищут, только производят манипуляции над потоком данных. Это может быть как условное преобразование (по сигналу детектора), так и безусловное (все подряд). Хорошим примером второго варианта является LLM-переформулировщик перед входом прикладной модели. Таким образом у потенциального нарушителя не остается прямой точки контакта с целью атаки, и задача совершить промпт-атаку усложняется.
4. По механизму действия - тут больше речь про детекторы. Их придумали пока три вида, и иного в ближайшем будущем не предвидится:
➡️ алгоритмы/эвристики - проверки наличия слов или фраз из блэклиста, или наоборот - косинусная дистанция до эталонных допустимых сообщений. Сюда же - регулярки.
➡️ маленькие ml-модели - в основном это BERT'ы, либо обученные как классификаторы, либо дообученные на парах вопрос-ответ с CLS-токеном.
➡️ LLM-модели, направленные на обнаружение промпт-атак в тексте. Тоже могут через CLS-токен работать, но есть и другой вариант - ответы в виде structured_output.
⛓ Пачка ссылок по гардрейлам
P.S. интересно, какими будут гардрейлы для МАС...
#иб_для_ml
AI-агенты внедряются во всю - это не просто горячая тема, а, как обычно, в чем-то даже перегретая. Но от действительности не сбежать, и при внедрении агентов в бизнес-процессы возникает вопрос о принятии мер безопасности при инцидентах. Об угрозах я писал раннее, теперь же рассмотрим, что с ними делать не в дизайнтайм (AISecOps - это тема отдельного разговора), а в рантайме.
1. По потоку данных - на входящих данных, на выходящих данных, на размышлениях, или на инструментах - подробнее на картинке.
2. По способу размещения в потоке данных - в разрыв или в параллель. То есть ждет ли бизнес-логика решения от GR, или отрабатывает в любом случае. Но есть ли и промежуточный тип. GR запускается в параллель на input-тексте LLM или на первых ~100 токенах output'а, и если обнаруживает атаку - блочит ответ. А если не находит - то ответ уходит без задержки.
3. По способу действия - детекторы и преобразователи. Первые сначала отбрасывают алерт, а потом к AI-агенту или к объекту данных применяется реагирование. Вторые ничего не ищут, только производят манипуляции над потоком данных. Это может быть как условное преобразование (по сигналу детектора), так и безусловное (все подряд). Хорошим примером второго варианта является LLM-переформулировщик перед входом прикладной модели. Таким образом у потенциального нарушителя не остается прямой точки контакта с целью атаки, и задача совершить промпт-атаку усложняется.
4. По механизму действия - тут больше речь про детекторы. Их придумали пока три вида, и иного в ближайшем будущем не предвидится:
- ProtectAI, современный файерволл
- ProtectAI, старый файерволл
- Инфа по llama firewall:
- - вайтпейпер
- - обзор thehackernews
- - блогпост
- llama guard 2, опенсорс
- pormpt-guard 86m тоже от meta
- guardrails ai
- файервол от nvidia: nemo
- файервол от индусa: promptguard
- легкая модель-фильтр wildguard
- статья про создание bert-фильтра APS (показывают, но не продают)
- модель Google ShieldGemma
- модель IBM Granite Guardian
- модель TrustSafeAI Attention Tracker
- решение TrylonAI LLM Firewall
- HiveTrace от авторов llamator (единственный российский стартап в списке)
- трейсинг агентов без реагирования от invariantlabs
- Palo Alto AI Runtime Security API Intercept
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Secrets
Двое случайных ученых из университета Лос-Анжелеса повторили результат Google с золотой медалью IMO с помощью обычной Gemini 2.5 Pro
Напоминаем, что и у OpenAI, и у Google в IMO участвовали невыпущенные экспериментальные ризонинг модели. Помимо гигантского бюджета ризонинга (представьте, как долго модель рассуждала, если решала 5 задач 9 часов), они были, скорее всего, специально дообучены и задизайнены под IMO.
А тут выходит статья, в которой ученые заявляют, что добились той же золотой медали с обычной Gemini 2.5 Pro. Ловкость рук и никакого мошенничества: все получилось только благодаря промптингу и аккуратному построению пайплайна.
А пайплайн был вот такой, трехступенчатый:
1. Генерация решения по жёсткому промпту, требующему строгости и TeX-оформления каждого шага (полный системный промпт авторы приложили к статье, так что пользуйтесь).
2. Дальше модель получает доп.токены ризонинга, на которые сама же анализирует свой вывод, дополняет недостающие части и углубляет доказательство.
3. Верификация: независимый верификатор (та же Gemini 2.5 Pro, но другой экземпляр) шаг за шагом проверяет доказательство, ищет ошибки, пробелы в обосновании и прочее. Если найденные ошибки валидные, они исправляются, и дальше все идет по кругу.
Если после пяти таких итераций верификатор (кстати, для него системный промпт тоже зашерили) не находит ошибок, решение принимается. Иначе все заново, но с другой исходной гипотезой.
Итог: из шести задач IMO 2025 модель полностью решила пять. Столько же решили те самые экспериментальные системы OpenAI и Google⌨️
И что самое главное – результат воспроизводимый. Авторы указали все гиперпараметры, которые использовали, перечислили детали запуска пайплайна, дали все системные промпты. Бери и пользуйся.
Напоминаем, что и у OpenAI, и у Google в IMO участвовали невыпущенные экспериментальные ризонинг модели. Помимо гигантского бюджета ризонинга (представьте, как долго модель рассуждала, если решала 5 задач 9 часов), они были, скорее всего, специально дообучены и задизайнены под IMO.
А тут выходит статья, в которой ученые заявляют, что добились той же золотой медали с обычной Gemini 2.5 Pro. Ловкость рук и никакого мошенничества: все получилось только благодаря промптингу и аккуратному построению пайплайна.
А пайплайн был вот такой, трехступенчатый:
1. Генерация решения по жёсткому промпту, требующему строгости и TeX-оформления каждого шага (полный системный промпт авторы приложили к статье, так что пользуйтесь).
2. Дальше модель получает доп.токены ризонинга, на которые сама же анализирует свой вывод, дополняет недостающие части и углубляет доказательство.
3. Верификация: независимый верификатор (та же Gemini 2.5 Pro, но другой экземпляр) шаг за шагом проверяет доказательство, ищет ошибки, пробелы в обосновании и прочее. Если найденные ошибки валидные, они исправляются, и дальше все идет по кругу.
Если после пяти таких итераций верификатор (кстати, для него системный промпт тоже зашерили) не находит ошибок, решение принимается. Иначе все заново, но с другой исходной гипотезой.
Итог: из шести задач IMO 2025 модель полностью решила пять. Столько же решили те самые экспериментальные системы OpenAI и Google
И что самое главное – результат воспроизводимый. Авторы указали все гиперпараметры, которые использовали, перечислили детали запуска пайплайна, дали все системные промпты. Бери и пользуйся.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
https://github.com/huggingface/transformers/releases/tag/v4.55.0
Верим?
Upd. Пока видим, что обе момзельки MoE с 3.6B и 5.1B активными параметрами, и конечно новый ускорятор на FlashAttention3.
Architecture.
- Token-choice MoE with SwiGLU activations. Классика
- When calculating the MoE weights, a softmax is taken over selected experts (softmax-after-topk). Тоже ничего нового.
- Each attention layer uses RoPE with 128K context. Не удивили.
- Alternate attention layers: full-context, and sliding 128-token window. Сам бы так сделал.
- Attention layers use a learned attention sink per-head, where the denominator of the softmax has an additional additive value. Это интересное.
- It uses the same tokenizer as GPT-4o and other OpenAI API models. Ну ок че.
- Some new tokens have been incorporated to enable compatibility with the Responses API. Ожидаемо.
P. S. Спасибо дорогому подписчику
@azik1725
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Release v4.55.0: New openai GPT OSS model! · huggingface/transformers
Welcome GPT OSS, the new open-source model family from OpenAI!
For more detailed information about this model, we recommend reading the following blogpost: https://huggingface.co/blog/welcome-open...
For more detailed information about this model, we recommend reading the following blogpost: https://huggingface.co/blog/welcome-open...
Forwarded from Заскуль питона (Data Science)
Собралось много реакций на предыдущем посте про Spark, делаю еще один!
Repartition в Spark. Зачем это вообще нужно?
В pandas не задумываешься про куски данных: читаете DataFrame и сразу работаешь с ним целиком. В Spark всё иначе: данные делятся на партиции (шарды), которые обрабатываются разными воркерами. Repartition позволяет управлять тем, как и насколько равномерно эти куски разбросаны по кластеру.
Если хочешь один файл — обязательно делайте .repartition(1) перед записью, иначе получишь кучу маленьких частей.
df_left = df_left.repartition("user_id")
df_right = df_right.repartition("user_id")
df_joined = df_left.join(df_right, on="user_id", how="inner")df_result.repartition(1).write.parquet("result.parquet")df = df.repartition(50) # вручную задаём 50 партиций
Обычно количество партиций автоматически подтягивается из конфига приложения, возможно, при настройке видели параметр
spark.sql.shuffle.partitions1️⃣
Слишком много партиций. Куча маленьких задач, и на маленьких данных становится только хуже, по скорости проседает.
2️⃣
Слишком мало партиций. Неэффективно, Spark теряет свою распределённость, одна нода делает всю работу.
Вообще в DA / DS / ML / DE мы всегда работаем с разменом (трейд-оффами) и все упирается в задачи, которые мы решаем)
Пишем дальше про Spark или нет?
🤝 — Давай уже про что-то другое!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
В этих постах я хочу обсудить архитектуры, которые не так часто встречаются в жизни, но при этом представляют собой достаточно интересные решения.
ELMO — это многослойная двунаправленная рекуррентная нейронная сеть c LSTM (рис. сверху). При использовании word2vec или fastText не учитывается семантическая неоднозначность слов. Так, word2vec назначает слову один вектор независимо от контекста. _ELMO_ решает эту проблему. В основе стоит идея использовать скрытые состояния языковой модели многослойной LSTM.
Было замечено, что нижние слои сети отвечают за синтаксис и грамматику, а верхние — за смысл слов. Пусть даны токены t1,...,tN, на которые поделено предложение. Будем считать логарифм правдоподобия метки слова в обоих направлениях, учитывая контекст слева и контекст справа, то есть на основании данных от начала строки до текущего символа и данных от текущего символа и до конца строки. Таким образом, модель предсказывает вероятность следующего токена с учетом истории.
Пусть есть L слоев сети. Входные и выходные данные будем представлять в виде векторов, кодируя слова. Тогда каждый результирующий вектор будем считать на основании множества:
Здесь xLMk — входящий токен, а hLMk,j−→− и hLMk,j←−− — скрытые слои в одном и в другом направлении.
Тогда результат работы ELMO будет представлять из себя выражение:
Обучаемый общий масштабирующий коэффициент γtask регулирует то, как могут отличаться друг от друга по норме векторные представления слов.
Коэффициенты staski — это обучаемые параметры, нормализованные функцией Softmax.
Модель применяют дообучая ее: изначально берут предобученную ELMO, а затем корректируют γ и si под конкретную задачу. Тогда вектор, который подается в используемую модель для обучения, будет представлять собой взвешенную сумму значений этого векторах на всех скрытых слоях ELMO.
Простое использование ELMO:
Использование ELMO с механизмом Attention:
Как вам такой формат постов и какую архитектуру вы хотите разобрать?) Обязательно ставьте реакции и пишите комментарии💗
ELMO — это многослойная двунаправленная рекуррентная нейронная сеть c LSTM (рис. сверху). При использовании word2vec или fastText не учитывается семантическая неоднозначность слов. Так, word2vec назначает слову один вектор независимо от контекста. _ELMO_ решает эту проблему. В основе стоит идея использовать скрытые состояния языковой модели многослойной LSTM.
Было замечено, что нижние слои сети отвечают за синтаксис и грамматику, а верхние — за смысл слов. Пусть даны токены t1,...,tN, на которые поделено предложение. Будем считать логарифм правдоподобия метки слова в обоих направлениях, учитывая контекст слева и контекст справа, то есть на основании данных от начала строки до текущего символа и данных от текущего символа и до конца строки. Таким образом, модель предсказывает вероятность следующего токена с учетом истории.
Пусть есть L слоев сети. Входные и выходные данные будем представлять в виде векторов, кодируя слова. Тогда каждый результирующий вектор будем считать на основании множества:
{xLMk,hLMk,j−→−,hLMk,j←−−|j=1,...,L}={hLMk,j|j=1,...,L}.
Здесь xLMk — входящий токен, а hLMk,j−→− и hLMk,j←−− — скрытые слои в одном и в другом направлении.
Тогда результат работы ELMO будет представлять из себя выражение:
ELMOtaskk=γtaks∑Lj=0staskihLMk,j.
Обучаемый общий масштабирующий коэффициент γtask регулирует то, как могут отличаться друг от друга по норме векторные представления слов.
Коэффициенты staski — это обучаемые параметры, нормализованные функцией Softmax.
Модель применяют дообучая ее: изначально берут предобученную ELMO, а затем корректируют γ и si под конкретную задачу. Тогда вектор, который подается в используемую модель для обучения, будет представлять собой взвешенную сумму значений этого векторах на всех скрытых слоях ELMO.
Простое использование ELMO:
import torch
from allennlp.modules.elmo import Elmo, batch_to_ids
options_file = "https://allennlp.s3.amazonaws.com/models/elmo/2x4096_512_2048cnn_2xhighway/elmo_2x4096_512_2048cnn_2xhighway_options.json"
weight_file = "https://allennlp.s3.amazonaws.com/models/elmo/2x4096_512_2048cnn_2xhighway/elmo_2x4096_512_2048cnn_2xhighway_weights.hdf5"
elmo = Elmo(options_file, weight_file, 1, dropout=0)
sentences = [["I", "love", "to", "play", "soccer"], ["My", "favorite", "team", "is", "Barcelona"]]
character_ids = batch_to_ids(sentences)
elmo_embeddings = elmo(character_ids)
Использование ELMO с механизмом Attention:
import torch
import torch.nn as nn
import torch.nn.functional as F
from allennlp.modules.elmo import Elmo, batch_to_ids
class Attention(nn.Module):
def __init__(self, hidden_size):
super(Attention, self).__init__()
self.fc = nn.Linear(hidden_size, hidden_size)
self.tanh = nn.Tanh()
self.softmax = nn.Softmax(dim=1)
def forward(self, x):
out = self.fc(x)
out = self.tanh(out)
weights = self.softmax(out)
return weights
options_file = "https://allennlp.s3.amazonaws.com/models/elmo/2x4096_512_2048cnn_2xhighway/elmo_2x4096_512_2048cnn_2xhighway_options.json"
weight_file = "https://allennlp.s3.amazonaws.com/models/elmo/2x4096_512_2048cnn_2xhighway/elmo_2x4096_512_2048cnn_2xhighway_weights.hdf5"
elmo = Elmo(options_file, weight_file, 1, dropout=0)
attention = Attention(1024)
sentences = [["I", "love", "to", "play", "soccer"], ["My", "favorite", "team", "is", "Barcelona"]]
character_ids = batch_to_ids(sentences)
weights = attention(elmo_embeddings['elmo_representations'][0])
weighted_elmo_embeddings = weights * elmo_embeddings['elmo_representations'][0]
Как вам такой формат постов и какую архитектуру вы хотите разобрать?) Обязательно ставьте реакции и пишите комментарии
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Жизнь и датка (Alexander Guschin)
Пока ребята пишут индивидуальный раунд (сегодня первый день - продолжение домашних задач), а мы следим за их результами, мы с Серёжей пособирали задачи разных национальных отборов и тренировок. Думаю на днях еще пообновляем и добавим как задач, так и разборов. Есть задачи разного уровня, и простые, и вполне любопытные. Можно посмотреть)
https://github.com/open-cu/awesome-ioai-tasks/
https://github.com/open-cu/awesome-ioai-tasks/
GitHub
GitHub - open-cu/awesome-ioai-tasks: A collection for IOAI tasks from different years and from national teams selections
A collection for IOAI tasks from different years and from national teams selections - open-cu/awesome-ioai-tasks
Forwarded from Всеволод Викулин | AI разбор
Продолжаем серию о создании надежных LLM-продуктов. Сегодня наконец говорим про метрики качества.
Тема 7. Оцениваем качество LLM
Зачем нам нужно оценивать качество? Не для того, чтобы запустить самый модный алгоритм Reinforcement Learning. Не для того, чтобы запихнуть ошибки в промпт, слезно просив LLM больше так не делать. И даже не для слайдов в презентации.
Хорошие метрики качества == быстрые итерации. В ИИ-разработке, как и в обычной продуктовой разработке, успех зависит от того, как быстро вы умеете итерироваться. В разработке есть тестирование. А у нас есть метрики качества.
Понятно, что вас скорее всего волнуют пользовательские онлайн метрики. Желательно, деньги. Ну или retention пользователей. К сожалению, их долго мерить. Для быстрых итераций нам нужны оффлайн метрики качества, которые как-то аппроксимируют ваш целевой онлайн. Мы верим, что улучшая оффлайн метрики, в итоге наши пользователи будут нам благодарны.
Почему LLM сложно оценивать?
В ИИ есть 3 класса задач. В них по-разному делаются метрики качества.
1) Задачи, в которых есть точный ответ.
Тогда все ваши метрики качества это сравнение ответа модели с эталоном. Например, классификация, где вы сравниваете с правильным классом. Сравнивать можно не обязательно точным совпадением с эталоном. Можно, например, текстовыми метриками (BLEU, WER) или пускай сравнивает отдельная модель, например BERT (bert_score). В этом классе обычно проблем нет.
2) Задачи, в которых ответ можно проверить.
Ну тогда возьмите и проверьте :) Это, в первую очередь, код, который можно прогнать на тестах. Это математика, в которой можно проверить формальное доказательство. В этом классе раньше были проблемы, сейчас современный RL тут всех унижает. Посмотрите сколько компаний выигрывают одну и ту же олимпиаду по математике. Я уже сбился со счета.
3) Задачи, в которых правильный ответ хрен пойми какой.
С этим обычно самые трудности (интересно, блин, почему?)
Делаем RAG-ассистента, человек задает вопрос, мы что-то ответили. Ответить можно миллионом способов, верифицировать нельзя. Здесь обычно делают так:
а) Вырабатывают продуктовые критерии "а что такое хороший ответ"? Наш RAG-ответ должен быть релевантный, достоверный, актуальный.... Записывают эти критерии в виде инструкции.
б) Учат кого-то размечать ответы по этим критерии. Кого можно учить?
Размечаем людьми
Кто-то называет их ИИ-тренерами или асессорами. Популярно объясняете им ваши продуктовые критерии. Это объяснение может быть немного длинным: посмотрите пример 180-страничной инструкции оценки качества поиска Гугла. Дальше показываете им (запрос, ответ) и пускай пробуют разметить.
Важно: контроль качественной разметки это сложная операционная задача. Кто-то может халтурить, читерить, забывать правила. Вам нужно будет отвечать на их вопросы, проводить экзамены, находить плохих разметчиков. И так постоянно.
LLM-as-a-judge
У нас нет денег/времени работать с людьми. Делаем LLM, которая оценивает ответы другой LLM. Критиковать чужой труд всегда проще :)
Обычно делается в несколько этапов
1) Собираем датасет правильных оценок. Это когда у разных ответов LLM проставлены метки: релевантный ли там ответ, достоверный ли ответ и тд. Здесь важно получить не очень большой, (можно 100 примеров) но чистый набор данных.
2) Записываем все наши продуктовые критерии в виде промпта. Он может быть очень длинным, нестрашно.
3) Итеративно меняем модель, промпт, метод генерации и тд, чтобы сделать максимальную точность на датасете 1) Обычно используют максимально большие рассуждающие модели.
Для несложных разметок завести LLM-as-a-judge обычно получается. Для чего-то супер сложного/экспертного, лучше обращаться за помощью к людям.
Литература для обязательного изучения
- Подробный гайд методи оценки качества в LLM
- Наглядная статья с примерами кода для LLM-as-a-judge
- Туториал, как делать LLM-as-a-judge
Правильные метрики — залог вашей счастливой и активной LLM-разработки. Отнеситесь очень внимательно. А если в чем-то сомневаетесь — пишите в комментарии или в личные сообщения @seva_batareika
#llm_system_design
Тема 7. Оцениваем качество LLM
Зачем нам нужно оценивать качество? Не для того, чтобы запустить самый модный алгоритм Reinforcement Learning. Не для того, чтобы запихнуть ошибки в промпт, слезно просив LLM больше так не делать. И даже не для слайдов в презентации.
Хорошие метрики качества == быстрые итерации. В ИИ-разработке, как и в обычной продуктовой разработке, успех зависит от того, как быстро вы умеете итерироваться. В разработке есть тестирование. А у нас есть метрики качества.
Понятно, что вас скорее всего волнуют пользовательские онлайн метрики. Желательно, деньги. Ну или retention пользователей. К сожалению, их долго мерить. Для быстрых итераций нам нужны оффлайн метрики качества, которые как-то аппроксимируют ваш целевой онлайн. Мы верим, что улучшая оффлайн метрики, в итоге наши пользователи будут нам благодарны.
Почему LLM сложно оценивать?
В ИИ есть 3 класса задач. В них по-разному делаются метрики качества.
1) Задачи, в которых есть точный ответ.
Тогда все ваши метрики качества это сравнение ответа модели с эталоном. Например, классификация, где вы сравниваете с правильным классом. Сравнивать можно не обязательно точным совпадением с эталоном. Можно, например, текстовыми метриками (BLEU, WER) или пускай сравнивает отдельная модель, например BERT (bert_score). В этом классе обычно проблем нет.
2) Задачи, в которых ответ можно проверить.
Ну тогда возьмите и проверьте :) Это, в первую очередь, код, который можно прогнать на тестах. Это математика, в которой можно проверить формальное доказательство. В этом классе раньше были проблемы, сейчас современный RL тут всех унижает. Посмотрите сколько компаний выигрывают одну и ту же олимпиаду по математике. Я уже сбился со счета.
3) Задачи, в которых правильный ответ хрен пойми какой.
С этим обычно самые трудности (интересно, блин, почему?)
Делаем RAG-ассистента, человек задает вопрос, мы что-то ответили. Ответить можно миллионом способов, верифицировать нельзя. Здесь обычно делают так:
а) Вырабатывают продуктовые критерии "а что такое хороший ответ"? Наш RAG-ответ должен быть релевантный, достоверный, актуальный.... Записывают эти критерии в виде инструкции.
б) Учат кого-то размечать ответы по этим критерии. Кого можно учить?
Размечаем людьми
Кто-то называет их ИИ-тренерами или асессорами. Популярно объясняете им ваши продуктовые критерии. Это объяснение может быть немного длинным: посмотрите пример 180-страничной инструкции оценки качества поиска Гугла. Дальше показываете им (запрос, ответ) и пускай пробуют разметить.
Важно: контроль качественной разметки это сложная операционная задача. Кто-то может халтурить, читерить, забывать правила. Вам нужно будет отвечать на их вопросы, проводить экзамены, находить плохих разметчиков. И так постоянно.
LLM-as-a-judge
У нас нет денег/времени работать с людьми. Делаем LLM, которая оценивает ответы другой LLM. Критиковать чужой труд всегда проще :)
Обычно делается в несколько этапов
1) Собираем датасет правильных оценок. Это когда у разных ответов LLM проставлены метки: релевантный ли там ответ, достоверный ли ответ и тд. Здесь важно получить не очень большой, (можно 100 примеров) но чистый набор данных.
2) Записываем все наши продуктовые критерии в виде промпта. Он может быть очень длинным, нестрашно.
3) Итеративно меняем модель, промпт, метод генерации и тд, чтобы сделать максимальную точность на датасете 1) Обычно используют максимально большие рассуждающие модели.
Для несложных разметок завести LLM-as-a-judge обычно получается. Для чего-то супер сложного/экспертного, лучше обращаться за помощью к людям.
Литература для обязательного изучения
- Подробный гайд методи оценки качества в LLM
- Наглядная статья с примерами кода для LLM-as-a-judge
- Туториал, как делать LLM-as-a-judge
Правильные метрики — залог вашей счастливой и активной LLM-разработки. Отнеситесь очень внимательно. А если в чем-то сомневаетесь — пишите в комментарии или в личные сообщения @seva_batareika
#llm_system_design
Forwarded from Dealer.AI
https://github.com/huggingface/transformers/releases/tag/v4.55.0
Верим?
Upd. Пока видим, что обе момзельки MoE с 3.6B и 5.1B активными параметрами, и конечно новый ускорятор на FlashAttention3.
Architecture.
- Token-choice MoE with SwiGLU activations. Классика
- When calculating the MoE weights, a softmax is taken over selected experts (softmax-after-topk). Тоже ничего нового.
- Each attention layer uses RoPE with 128K context. Не удивили.
- Alternate attention layers: full-context, and sliding 128-token window. Сам бы так сделал.
- Attention layers use a learned attention sink per-head, where the denominator of the softmax has an additional additive value. Это интересное.
- It uses the same tokenizer as GPT-4o and other OpenAI API models. Ну ок че.
- Some new tokens have been incorporated to enable compatibility with the Responses API. Ожидаемо.
P. S. Спасибо дорогому подписчику
@azik1725
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Release v4.55.0: New openai GPT OSS model! · huggingface/transformers
Welcome GPT OSS, the new open-source model family from OpenAI!
For more detailed information about this model, we recommend reading the following blogpost: https://huggingface.co/blog/welcome-open...
For more detailed information about this model, we recommend reading the following blogpost: https://huggingface.co/blog/welcome-open...