Forwarded from Quant Researcher
AI Хедж-фонд, finally…
Пруф-оф-концепт хедж-фонда на базе ИИ!!!
🚀 Запуск хедж-фонда
- Для вывода рассуждений агентов:
- Для указания временного диапазона:
🗿 Запуск бэктестера
- С указанием дат:
⁉️ Один вопрос, где агент-таролог, который учитывает движение планет в торговле?
‼️ А так проект интересный, можно даже подсмотреть что-то полезное. Структура хорошая же)
Quant Researcher
Пруф-оф-концепт хедж-фонда на базе ИИ!!!
Классический такой фонд из:
- Ben Graham Agent 👑 – инвестирует с запасом прочности.
- Bill Ackman Agent 💪 – занимает смелые позиции.
- Cathie Wood Agent 🚀 – верит в инновации и рост.
- Charlie Munger Agent 🤝 – покупает отличные компании по справедливой цене.
- Stanley Druckenmiller Agent 📈 – ищет асимметричные возможности.
- Warren Buffett Agent 🔮 – выбирает замечательные компании по справедливой цене.
- Valuation Agent 💹 – рассчитывает внутреннюю стоимость акций.
- Sentiment Agent 😃 – анализирует рыночное настроение.
- Fundamentals Agent 📊 – анализирует фундаментальные данные.
- Technicals Agent 📉 – изучает технические индикаторы.
- Risk Manager ⚠️ – управляет рисками и лимитами.
- Portfolio Manager 📋 – принимает финальные торговые решения.
🚀 Запуск хедж-фонда
poetry run python src/main.py --ticker AAPL,MSFT,NVDA- Для вывода рассуждений агентов:
poetry run python src/main.py --ticker AAPL,MSFT,NVDA --show-reasoning- Для указания временного диапазона:
poetry run python src/main.py --ticker AAPL,MSFT,NVDA --start-date 2024-01-01 --end-date 2024-03-01🗿 Запуск бэктестера
poetry run python src/backtester.py --ticker AAPL,MSFT,NVDA- С указанием дат:
poetry run python src/backtester.py --ticker AAPL,MSFT,NVDA --start-date 2024-01-01 --end-date 2024-03-01⁉️ Один вопрос, где агент-таролог, который учитывает движение планет в торговле?
‼️ А так проект интересный, можно даже подсмотреть что-то полезное. Структура хорошая же)
Quant Researcher
Forwarded from ML-легушька
Немного всратых мыслей про математику гедонизма.
В языковых моделях есть такая метрика - перплексия. Это нормированная на количество слов обратная вероятность получения реального предложения с помощью модели (см картинку 1). На человеческом языке ее можно интерпретировать как "недоумение" модели относительно реального предложения, или же неуверенность в его правдоподобии. Соответственно, если на реальном предложении перплексия маленькая - модель понимает, что это правдоподобное предложение.
Вам не кажется, что подобный подход можно использовать для оценки человеческого опыта?
Давайте посмотрим на вашу личность и восприятие как совокупность событий, произошедших с вами. Тут важны не конкретные числа (которые посчитать зачастую сложно), а способ мышления.
Что приносит вам эмоции? Какой-то новый опыт. Какие есть свойства у "абсолютного" значения полученных положительных эмоций, если бы мы могли их посчитать?
1. Количество полученного дофамина/серотонина/etc. - непосредственно величина полученного кайфа, можно сказать физическая составляющая.
2. То, насколько этот опыт является для вас новым и неожиданным - например, если вы всю жизнь росли в бедности, а потом стали ходить по шикарным ресторанам, то первое время вы будете от этого ОЧЕНЬ кайфовать, а через годик-другой такой жизни - в меньшей степени. Можно назвать это психологической составляющей опыта (мы не будем говорить тут об адаптации рецепторов и прочих нейробиологических вещах, ибо это трудно, плохо исследовано и не передает суть).
Пункт номер два крайне похож на перплексию, не находите? Но вместо слов в предложении выступают "параметры" данного события, вместо модели - ваш жизненный опыт.
Более того, для события можно прикинуть его вероятность, не вдаваясь в детали - достаточно посмотреть на а) его распространенность в большой человеческой популяции (жители вашего города/страны/большой социальной группы) и б) приблизить вероятность совпадения такого события и вас с помощью, например, оценки схожести данного события с предыдущими событиями в вашей жизни.
Я стал пользоваться данным подходом для принятия решений по поводу своего досуга/развлечений/etc., и он действительно помогает. В целом, мы руководствуемся схожим подходом, но если делать это не неосознанно, а разложить на составляющие, то жить становится чуточку проще и неопределенность понижается.
Это достаточно полное описание того, о чем же на самом деле гедонизм. Гедонист выступает в качестве агента, максимизирующего произведения абсолютной величины дофамина и перплексии опыта.
Тут есть еще одна интересная мысль для анализа - применить формулу Байеса (см. картинку 2, H_T - ваш жизненный опыт до события S_T, S_T - событие, произошедшее в момент T).
И все абсолютно логично. Чем меньше P(H_T), тем меньше перплексия - вас сложнее удивить, у вас необычный бэкграунд и в вашей жизни происходит больше неординарных с точки зрения человечества событий. Соответственно, с уменьшением P(S_T) ценность опыта растет из-за его уникальности. Действительно интересный множитель тут это P(H_T | S_T), то есть то, насколько ваш личный жизненный опыт уникален относительно других людей, с которыми это событие произошло.
Каждую из этих компонент можно посчитать, пусть и неточно (ибо это требует полной информации обо всем человечестве), но тем не менее.
В целом жизнь кажется сильно проще, когда вы можете ее посчитать, не находите?
В языковых моделях есть такая метрика - перплексия. Это нормированная на количество слов обратная вероятность получения реального предложения с помощью модели (см картинку 1). На человеческом языке ее можно интерпретировать как "недоумение" модели относительно реального предложения, или же неуверенность в его правдоподобии. Соответственно, если на реальном предложении перплексия маленькая - модель понимает, что это правдоподобное предложение.
Вам не кажется, что подобный подход можно использовать для оценки человеческого опыта?
Давайте посмотрим на вашу личность и восприятие как совокупность событий, произошедших с вами. Тут важны не конкретные числа (которые посчитать зачастую сложно), а способ мышления.
Что приносит вам эмоции? Какой-то новый опыт. Какие есть свойства у "абсолютного" значения полученных положительных эмоций, если бы мы могли их посчитать?
1. Количество полученного дофамина/серотонина/etc. - непосредственно величина полученного кайфа, можно сказать физическая составляющая.
2. То, насколько этот опыт является для вас новым и неожиданным - например, если вы всю жизнь росли в бедности, а потом стали ходить по шикарным ресторанам, то первое время вы будете от этого ОЧЕНЬ кайфовать, а через годик-другой такой жизни - в меньшей степени. Можно назвать это психологической составляющей опыта (мы не будем говорить тут об адаптации рецепторов и прочих нейробиологических вещах, ибо это трудно, плохо исследовано и не передает суть).
Пункт номер два крайне похож на перплексию, не находите? Но вместо слов в предложении выступают "параметры" данного события, вместо модели - ваш жизненный опыт.
Более того, для события можно прикинуть его вероятность, не вдаваясь в детали - достаточно посмотреть на а) его распространенность в большой человеческой популяции (жители вашего города/страны/большой социальной группы) и б) приблизить вероятность совпадения такого события и вас с помощью, например, оценки схожести данного события с предыдущими событиями в вашей жизни.
Я стал пользоваться данным подходом для принятия решений по поводу своего досуга/развлечений/etc., и он действительно помогает. В целом, мы руководствуемся схожим подходом, но если делать это не неосознанно, а разложить на составляющие, то жить становится чуточку проще и неопределенность понижается.
Это достаточно полное описание того, о чем же на самом деле гедонизм. Гедонист выступает в качестве агента, максимизирующего произведения абсолютной величины дофамина и перплексии опыта.
Тут есть еще одна интересная мысль для анализа - применить формулу Байеса (см. картинку 2, H_T - ваш жизненный опыт до события S_T, S_T - событие, произошедшее в момент T).
И все абсолютно логично. Чем меньше P(H_T), тем меньше перплексия - вас сложнее удивить, у вас необычный бэкграунд и в вашей жизни происходит больше неординарных с точки зрения человечества событий. Соответственно, с уменьшением P(S_T) ценность опыта растет из-за его уникальности. Действительно интересный множитель тут это P(H_T | S_T), то есть то, насколько ваш личный жизненный опыт уникален относительно других людей, с которыми это событие произошло.
Каждую из этих компонент можно посчитать, пусть и неточно (ибо это требует полной информации обо всем человечестве), но тем не менее.
В целом жизнь кажется сильно проще, когда вы можете ее посчитать, не находите?
Forwarded from Мальцев: Карьера с AI
Сейчас особенно чувствую, как у меня и знакомых из-за шквала запросов «срочно надо помочь сделать эту штуку для роста» начало проседать качество решения задач.
Больше всего болит именно постановка задачи, ведь без нормального описания нет и адекватного результата.
Гении менеджмента давно придумали 5W1H и SMART для уточнения задачи, но при текущих скоростях работы уже на 5-й вопрос (а их там более 10) этих фреймворков заказчик часто отвечает «нет времени, подумай и догадайся сам»
Три из мира машин
И одно из мира людей
Ты являешься бизнес-консультантом из McKinsey с 20-летним опытом работы и помогаешь мне качественно выполнить поставленную передо мной задачу.
Твоя основная роль — помочь максимально глубоко и системно продумать подход к решению задачи, выявить как явные, так и скрытые цели, определить возможные метрики успеха и качественные критерии оценки результата, обозначить важные нюансы и особенности, предусмотреть потенциальные риски, а также предложить четкие и последовательные шаги для выполнения задачи.
У меня есть только следующие вводные:
1. Контекст
[Напиши что случилось и почему задача возникла именно сейчас]
[Напиши кто является заказчиком задачи, какая его роль и заинтересованность]
[Напиши какая твоя роль в рамках этой задачи, полномочия и зона ответственности]
2. Задача
[Вставь текст запроса что конкретно необходимо сделать, прямо все сообщение что тебя попросили сделать]
[Напиши какой конкретный результат ожидается получить к какому сроку]
3. Критерий качества
[Напиши какие критерии качества выполнения задачи наиболее важны и должны быть соблюдены. Приоритет 1 - ,2 - ,3 - ]
4. С кем работать
[Напиши кого необходимо вовлечь в решение задачи и почему]
После того, как я предоставлю вышеуказанные вводные, сделай подробный и структурированный анализ задачи, включая обязательные разделы:
1. Явные и скрытые цели задачи — поясни, какие более глубокие или неочевидные эффекты и последствия реализации задачи могут быть важны и полезны заказчику или компании.
2. Предлагаемые метрики успеха и критерии качества — опиши, как можно будет объективно понять, что задача выполнена успешно и качественно, и по каким показателям это измерить.
3. Особенности и тонкости, которые важно учесть — обозначь важные моменты, ограничения или нюансы, которые могут повлиять на качество и эффективность результата или подход к реализации задачи.
4. Потенциальные риски реализации — выяви риски и трудности, которые могут помешать успешному выполнению задачи или снизить эффективность результата, а также кратко предложи возможные меры по минимизации этих рисков.
5. Рекомендуемые этапы выполнения задачи — представь ясный и последовательный план действий, разбитый на отдельные этапы с кратким пояснением каждого шага.
В результате у меня должна получиться детальная картина задачи и понятный, обоснованный подход к ее эффективному и качественному выполнению.
При разработке ответа используй рассуждения, логику, дедукцию и аргументацию.
P.S. В промпте расписаны все логические цепочки рассуждений, которые необходимы и человеку для решения любой задачи😉
❤️ и 👍 - если пост полезен, сегодня закину в комменты несколько примеров работы GPT по постановке задачи выше
💬 - поделитесь как у вас в этом году с потоком задач и как вы с ним справляетесь, мне интересно 🙂
Мальцев: Карьера. Маркетинг. AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
Value Stream Mapping
В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).
Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.
Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.
В статье ещё приводится несколько конкретных примеров Outcome mapping.
Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет
В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?
На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов.
А сократить путь бага нам помогает табличка с зонами ответственности.
#systemdesign
В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).
Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.
Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.
В статье ещё приводится несколько конкретных примеров Outcome mapping.
Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет
В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?
На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов.
А сократить путь бага нам помогает табличка с зонами ответственности.
#systemdesign
dora.dev
DORA | Value stream mapping for software delivery
DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.
Forwarded from Knowledge Accumulator
Конкретный автоэнкодер [2019] и его улучшение [2024]
Итак, обычно в автоэнкодерах мы решаем задачу сжатия изначального вектора фичей в пространство маленькой размерности. Мы обучаем энкодер
Конкретный автоэнкодер ставит задачу более интересным образом - вместо перевода вектора фичей в скрытое пространство мы хотим выбрать список фичей в
Иначе говоря, какие фичи содержат наибольшее количество информации, которое позволит восстановить исходный вектор
Слово "конкретный" в названии - "concrete" - на самом деле сокращение от Continuous Discrete - это параллельное изобретение того самого Gumbel Softmax трюка, который я описывал в позапрошлом посте.
Единственным параметром энкодера является матрица
Делая это независимо K раз, мы выбираем K фичей, которые и становятся выходом энкодера. В базовой статье про конкретный автоэнкодер иллюстрация на MNIST демонстрируют способность такой схемы обучиться игнорировать пиксели по краям и при этом задействовать по 1 пикселю из всех остальных частей картинки, никогда не беря соседние. Эксперименты на других датасетах там тоже есть.
Indirectly Parameterized CAE - улучшение данного подхода. Я с CAE не развлекался, но утверждается, что у базовой модели есть проблемы со стабильностью обучения, а также она почему-то всё же дублирует фичи по несколько раз, что, вроде как, тоже связано с этой нестабильностью.
Один простой трюк очень сильно улучшает ситуацию. Вместо обучаемой матрицы
Честно говоря, в статье не хватает нормальной мотивации и интуиции, но, судя по результатам, у них это обучается гораздо лучше бейзлайна и всегда выдаёт уникальные фичи.
Главный вопрос - а нахрена вообще всё это нужно?
Внезапно эта идея имеет отличное практическое применение в нейросетях, а именно для проведения Feature Selection! В ситуации, когда обучать сеть супердорого и вы можете позволить это делать единичное число раз, а фичей у вас тысячи, использование Конкретного Энкодера в самом начале модели позволяет обучить Selection
Коллеги рапортуют о том, что у нас это заработало, так что, с чистой совестью делюсь хаком.
@knowledge_accumulator
Итак, обычно в автоэнкодерах мы решаем задачу сжатия изначального вектора фичей в пространство маленькой размерности. Мы обучаем энкодер
q(z|x) и декодер p(x|z) таким образом, чтобы у нас получалось восстановить изначальный вектор x из вектора скрытых переменных z.Конкретный автоэнкодер ставит задачу более интересным образом - вместо перевода вектора фичей в скрытое пространство мы хотим выбрать список фичей в
x, который и будет этим самым вектором скрытых переменных.Иначе говоря, какие фичи содержат наибольшее количество информации, которое позволит восстановить исходный вектор
x наилучшим образом? Конкретный автоэнкодер решает именно эту задачу. Слово "конкретный" в названии - "concrete" - на самом деле сокращение от Continuous Discrete - это параллельное изобретение того самого Gumbel Softmax трюка, который я описывал в позапрошлом посте.
Единственным параметром энкодера является матрица
KxN - размерность скрытого вектора на кол-во фичей. В каждой строке у нас находится обучаемый вектор "логитов" для каждой фичи, к которому мы применяем Gumbel Softmax и получаем soft one-hot вектор-маску для всех фичей, которую затем скалярно умножаем на исходный вектор фичей - получая таким образом дифференцируемую аппроксимацию выбора одной фичи из всего списка. Делая это независимо K раз, мы выбираем K фичей, которые и становятся выходом энкодера. В базовой статье про конкретный автоэнкодер иллюстрация на MNIST демонстрируют способность такой схемы обучиться игнорировать пиксели по краям и при этом задействовать по 1 пикселю из всех остальных частей картинки, никогда не беря соседние. Эксперименты на других датасетах там тоже есть.
Indirectly Parameterized CAE - улучшение данного подхода. Я с CAE не развлекался, но утверждается, что у базовой модели есть проблемы со стабильностью обучения, а также она почему-то всё же дублирует фичи по несколько раз, что, вроде как, тоже связано с этой нестабильностью.
Один простой трюк очень сильно улучшает ситуацию. Вместо обучаемой матрицы
KxN используется Indirect Parameterization - эта матрица вычисляется как функция от 3 обучаемых штук: умножения матрицы KxN на матрицу NxN и прибавления вектора размера N к каждой строке результата.Честно говоря, в статье не хватает нормальной мотивации и интуиции, но, судя по результатам, у них это обучается гораздо лучше бейзлайна и всегда выдаёт уникальные фичи.
Главный вопрос - а нахрена вообще всё это нужно?
Внезапно эта идея имеет отличное практическое применение в нейросетях, а именно для проведения Feature Selection! В ситуации, когда обучать сеть супердорого и вы можете позволить это делать единичное число раз, а фичей у вас тысячи, использование Конкретного Энкодера в самом начале модели позволяет обучить Selection
K фичей из N напрямую. При этом, если качество модели совпадает с качеством изначальной модели, можно смело выкидывать из прода целых N-K фичей. Коллеги рапортуют о том, что у нас это заработало, так что, с чистой совестью делюсь хаком.
@knowledge_accumulator
Forwarded from Data Blog
Привет, друзья! Сегодня кратко-пост
про небольшое удивительное чтение с множеством ссылок.
Рассмотрим обученную модель машинного или глубокого обучения. Как её отучить от чего-либо?
Что делать, если модель
1. гендерно или социально предвзята? [1, 2, 3]
2. отдаёт вредоносные ответы;
3. содержит данные, защищенные авторским правом или личные данные;
4. галлюцинирует
Можно ли заставить её забыть изученное? Можно и сложно.
Model (от истоков machine) unlearning (MU) — актуальная задача для больших моделей, восставшая от проблем машинного обучения. Восставшая — потому что, если рассматривать агрегаторы статей, проблема отучения редко упоминалась, чаще всего рядом с SVM, в 2000-2015 и сделала скачок с 2018 года рядом с глубокими моделями.
Что интересно, термин «механистическая интерпретируемость» тоже сперва был рядом с ML моделью SVM. Нестареющая классика!
Подходы в MU глобально разделены на 3 группы:
1. Model-Agnostic Methods (независимые от модели)
2. Model-Intrinsic Methods (встроенные в процесс обучения модели)
3. Data-Driven Methods (основанные на изменении данных)
Key Idea из методов: заставить модель забыть что-то — это больше чем про полное переобучение (потому что это чаще будет дорого). Если посмотреть на подходы «очень сверху», то мы можем:
1. Применять обучение с подкреплением (проводить хитрый файн-тюнинг);
2. Выполнять градиентный подъем по примерам под забывание (проводить хитрый файн-тюнинг);
3. Модифицировать пространство обучения (менять данные, чтобы проводить хитрый файн-тюнинг или обучение)
4. Использовать различные методы файн-тюнинга (LoRA, KL-divergence based etc) (снова проводить хитрый файн-тюнинг)
5. Накладывать условие на изменение параметров модели для конкретных примеров (проводить хитрое обучение/дообучение (снова файн-тюнинг));
6. Находить параметры, отвечающие за конкретное поведение и занулять их (не однозначный, но валидный к жизни метод, так как также важно показать, что зануление не вызвало других нежелательных поведенческих изменений)
Быть может, я не докопала до идей глубже (и если вы знаете что-то — welcome в комментарии!), но отучение преимущественно построено на генерации гипотез о том, как дообучить модель или же как устранить нежелательное поведение точечно (если говорить о "выключении" активаций).
Ещё интересно, что хотя статьи 1-3 также сосредоточены на устранении точечных признаков/паттернов поведения, термин "unlearning" в них явно не упоминается. Это может усложнять, как мне кажется, будущие обзоры и поиск литературы — необходимо генерировать и анализировать смежные ключи. Будьте всегда внимательны)
Пара полезных ссылок про Unlearning:
1. Глубокая детализация подходов для MU здесь.
2. Репозиторий, собирающий статьи по MU
Такой мини-обзор, друзья! Само наличие класса исследований про unlearning просто вдохновляет — чем больше модели, тем будто бы больше задач нам нужно решать.
Бесконечная область, выходит :)
Отличного вам вечера,
Ваш Дата автор!
про небольшое удивительное чтение с множеством ссылок.
Рассмотрим обученную модель машинного или глубокого обучения. Как её отучить от чего-либо?
Что делать, если модель
1. гендерно или социально предвзята? [1, 2, 3]
2. отдаёт вредоносные ответы;
3. содержит данные, защищенные авторским правом или личные данные;
4. галлюцинирует
Можно ли заставить её забыть изученное? Можно и сложно.
Model (от истоков machine) unlearning (MU) — актуальная задача для больших моделей, восставшая от проблем машинного обучения. Восставшая — потому что, если рассматривать агрегаторы статей, проблема отучения редко упоминалась, чаще всего рядом с SVM, в 2000-2015 и сделала скачок с 2018 года рядом с глубокими моделями.
Что интересно, термин «механистическая интерпретируемость» тоже сперва был рядом с ML моделью SVM. Нестареющая классика!
Подходы в MU глобально разделены на 3 группы:
1. Model-Agnostic Methods (независимые от модели)
2. Model-Intrinsic Methods (встроенные в процесс обучения модели)
3. Data-Driven Methods (основанные на изменении данных)
Key Idea из методов: заставить модель забыть что-то — это больше чем про полное переобучение (потому что это чаще будет дорого). Если посмотреть на подходы «очень сверху», то мы можем:
1. Применять обучение с подкреплением (проводить хитрый файн-тюнинг);
2. Выполнять градиентный подъем по примерам под забывание (проводить хитрый файн-тюнинг);
3. Модифицировать пространство обучения (менять данные, чтобы проводить хитрый файн-тюнинг или обучение)
4. Использовать различные методы файн-тюнинга (LoRA, KL-divergence based etc) (снова проводить хитрый файн-тюнинг)
5. Накладывать условие на изменение параметров модели для конкретных примеров (проводить хитрое обучение/дообучение (снова файн-тюнинг));
6. Находить параметры, отвечающие за конкретное поведение и занулять их (не однозначный, но валидный к жизни метод, так как также важно показать, что зануление не вызвало других нежелательных поведенческих изменений)
Быть может, я не докопала до идей глубже (и если вы знаете что-то — welcome в комментарии!), но отучение преимущественно построено на генерации гипотез о том, как дообучить модель или же как устранить нежелательное поведение точечно (если говорить о "выключении" активаций).
Ещё интересно, что хотя статьи 1-3 также сосредоточены на устранении точечных признаков/паттернов поведения, термин "unlearning" в них явно не упоминается. Это может усложнять, как мне кажется, будущие обзоры и поиск литературы — необходимо генерировать и анализировать смежные ключи. Будьте всегда внимательны)
Пара полезных ссылок про Unlearning:
1. Глубокая детализация подходов для MU здесь.
2. Репозиторий, собирающий статьи по MU
Такой мини-обзор, друзья! Само наличие класса исследований про unlearning просто вдохновляет — чем больше модели, тем будто бы больше задач нам нужно решать.
Бесконечная область, выходит :)
Отличного вам вечера,
Ваш Дата автор!
Forwarded from Тимлид Очевидность | Евгений Антонов
Несогласие и кризис
В сегодняшнем посте объединены два тимлидских материала, к которому я приложил руку и голову.
1. Три тимлида заходят в бар и не соглашаются. В этом выпуске мы рассмотрели что делать, когда в команде кто-то с чем-то не согласен (например, постоянно не согласен с тобой). Когда это нормально, когда не очень, а когда это откровенный саботаж. Не обошлось без выходов раз на раз, рептилоидов и серийных хейтеров на работе!
https://t.me/teamleadsBar/75
2. Кризис — это проблема или возможность? Дебаты, на, казалось бы, однозначную, но на самом деле нет, тему. Там мы с Настей Абрашитовой постарались раскрыть все плюсы и минусы кризисных и спокойных времен для руководителя. А в конце еще и поучительное напутствие подвели, обязательно досматривайте до конца, рефлексируйте, прикидывайте на себя.
https://www.youtube.com/watch?v=tY2C5zRe-EM
В сегодняшнем посте объединены два тимлидских материала, к которому я приложил руку и голову.
1. Три тимлида заходят в бар и не соглашаются. В этом выпуске мы рассмотрели что делать, когда в команде кто-то с чем-то не согласен (например, постоянно не согласен с тобой). Когда это нормально, когда не очень, а когда это откровенный саботаж. Не обошлось без выходов раз на раз, рептилоидов и серийных хейтеров на работе!
https://t.me/teamleadsBar/75
2. Кризис — это проблема или возможность? Дебаты, на, казалось бы, однозначную, но на самом деле нет, тему. Там мы с Настей Абрашитовой постарались раскрыть все плюсы и минусы кризисных и спокойных времен для руководителя. А в конце еще и поучительное напутствие подвели, обязательно досматривайте до конца, рефлексируйте, прикидывайте на себя.
https://www.youtube.com/watch?v=tY2C5zRe-EM
Telegram
Три тимлида заходят в бар
Когда команда не согласна: что делать тимлиду?
Этот выпуск про то, что самое сложное в работе тимлида — это не настроить рабочие процессы, а сделать это, когда с ними кто-то не согласен.
А мы ведь знаем, что всегда в интернете кто-то неправ найдётся тот…
Этот выпуск про то, что самое сложное в работе тимлида — это не настроить рабочие процессы, а сделать это, когда с ними кто-то не согласен.
А мы ведь знаем, что всегда в интернете кто-то неправ найдётся тот…
Forwarded from Пристанище Дата Сайентиста (TelepostBot)
Как улучшили ML-продукт, взглянув на данные по-новому
Почитал интересный пост про то как команда разрабатывала ML-систему для снижения числа негативных отзывов в сервисе заказов поездок.
Первая версия снизила жалобы всего на 1% вместо необходимых 4,5%. После доработки — 3%, но этого всё ещё было недостаточно.
В итоге помог новый взгляд на данные. Выяснилось что 20% водителей создают 80% поездок и жалоб.
Фокус на этих водителях позволил снизить затраты и достичь цели.
Вывод: Иногда дело не в модели, а в том, на какие данные мы смотрим.
Заметка
Почитал интересный пост про то как команда разрабатывала ML-систему для снижения числа негативных отзывов в сервисе заказов поездок.
Первая версия снизила жалобы всего на 1% вместо необходимых 4,5%. После доработки — 3%, но этого всё ещё было недостаточно.
В итоге помог новый взгляд на данные. Выяснилось что 20% водителей создают 80% поездок и жалоб.
Фокус на этих водителях позволил снизить затраты и достичь цели.
Вывод: Иногда дело не в модели, а в том, на какие данные мы смотрим.
Заметка
GoPractice
How We Fixed an ML Product by Rethinking Data - GoPractice
Learn how a fresh approach to data helped turn around an ML-powered driver distraction system. Discover key lessons to improve real-world AI applications efficiently.
Forwarded from LLM под капотом
Финальные результаты Enterprise RAG Challenge
- Team Leaderboard - оценивает команды (берется лучшее решение каждой команды)
- SotA Leaderboard - оценивает все эксперименты, которые прислали команды вместе с заполненным опросником.
Колонки:
- Hours - сколько часов прошло между публикацией вопросов и генерацией ответов командой
- R - Retrieval Score. Max: 100
- G - Generation Score. Max: 100
- Score - Final score (R/3+G). Max: 133
- AI - команды использовали наш AI Research (мой курс, работа в TimeToAct или комьюнити 🤗)
- Lcl - использовались модели, которые можно запустить локально
Картинки в оригинале лежат тут: https://abdullin.com/erc/. Позже я туда добавлю ссылки на все отчеты и посты участников, сделаю расширенные таблицы на основе опросников (с фильтрациями)
Спасибо всем за участие - было очень круто! У нас вместе уже получилось продвинуть вперед SotA по построению RAG систем с LLM под капотом. Первые инсайты я опубликовал раньше, но основной анализ еще впереди.
Ваш, @llm_under_hood 🤗
- Team Leaderboard - оценивает команды (берется лучшее решение каждой команды)
- SotA Leaderboard - оценивает все эксперименты, которые прислали команды вместе с заполненным опросником.
Колонки:
- Hours - сколько часов прошло между публикацией вопросов и генерацией ответов командой
- R - Retrieval Score. Max: 100
- G - Generation Score. Max: 100
- Score - Final score (R/3+G). Max: 133
- AI - команды использовали наш AI Research (мой курс, работа в TimeToAct или комьюнити 🤗)
- Lcl - использовались модели, которые можно запустить локально
Картинки в оригинале лежат тут: https://abdullin.com/erc/. Позже я туда добавлю ссылки на все отчеты и посты участников, сделаю расширенные таблицы на основе опросников (с фильтрациями)
Спасибо всем за участие - было очень круто! У нас вместе уже получилось продвинуть вперед SotA по построению RAG систем с LLM под капотом. Первые инсайты я опубликовал раньше, но основной анализ еще впереди.
Ваш, @llm_under_hood 🤗