Forwarded from Knowledge Accumulator
Gumbel-Softmax - памятка себе на будущее
Итак, представим что у нас есть какая-то вероятностная модель, в которой сэмплирование из распределения является её частью. Самым банальным примером, пожалуй, является VAE.
VAE - это автоэнкодер, состоящий из моделей
При обучении подобной модели у нас возникает градиент ошибки по сэмплу из
Его суть в том, что процесс сэмплирования отделяют от основной цепочки вычислений и оформляют как входную вершину вычислительного графа. В случае с нормальным распределением, мы сначала отдельно сэмплируем
Gumbel-Softmax - то же самое, но для категориального распределения.
Вместо обычного VAE давайте взглянем на VQ-VAE - альтернативный вариант автоэнкодера, в котором вместо сжатия в нормальное распределение происходит сжатие в категориальное распределение на "коды". Внутри модели хранится Codebook, который превращает номер кода обратно в эмбеддинг во время декодинга.
Итак, в сердцевине модели находится такая цепочка вычислений:
Gumbel-Softmax позволит приближенно осуществить этот переход с помощью детерминированной операции. Если к логарифму от вектора
Последняя проблема - argmax сам недифференцируем, поэтому его заменяют на софтмакс с маленькой температурой. В итоге, получая на вход
Самый большой затык вызывает следующий вопрос - в чём профит этой штуки по сравнению с тем, чтобы просто использовать
Я объясняю это так - во время обучения мы хотим, чтобы все последующие части модели получали на вход реалистичные сэмплы из категориального распределения. Если наша модель будет учиться на размазанных векторах, то мы не сможем во время инференса просто начать сэмплировать код - декодер не выкупит этот пранк.
А что делать в случае, когда нам реально нужен строгий one-hot вектор, например, если это RL и мы совершаем действие? Авторы оригинальной статьи предлагают комбинировать Straight Through Estimator и Gumbel Softmax, т.е. использовать
@knowledge_accumulator
Итак, представим что у нас есть какая-то вероятностная модель, в которой сэмплирование из распределения является её частью. Самым банальным примером, пожалуй, является VAE.
VAE - это автоэнкодер, состоящий из моделей
q(z|x) и p(x|z), которые выдают распределение на скрытую компоненту z по входу x и наоборот. В базовом варианте z имеет нормальное распределение N(m;d), и энкодер выдаёт параметры этого распределения - средние m и ст. отклонения d.При обучении подобной модели у нас возникает градиент ошибки по сэмплу из
z. Как пробросить градиент назад в модели "сквозь" это сэмплирование? В лоб сделать это не получится, и для этого применяют простой советский Reparametrization Trick.Его суть в том, что процесс сэмплирования отделяют от основной цепочки вычислений и оформляют как входную вершину вычислительного графа. В случае с нормальным распределением, мы сначала отдельно сэмплируем
eps из N(0;1), а затем умножаем его на d и прибавляем m. По факту результат тот же самый, но он превращает нейросеть в цепочку детерминированных операций и позволяет пробрасывать градиент бэкпропом. Gumbel-Softmax - то же самое, но для категориального распределения.
Вместо обычного VAE давайте взглянем на VQ-VAE - альтернативный вариант автоэнкодера, в котором вместо сжатия в нормальное распределение происходит сжатие в категориальное распределение на "коды". Внутри модели хранится Codebook, который превращает номер кода обратно в эмбеддинг во время декодинга.
Итак, в сердцевине модели находится такая цепочка вычислений:
logits -> probs -> one-hot vector -> embedding. При переходе из probs к one-hot vector как раз и возникает сэмплирование из категориального распределения, сквозь которое нельзя пробросить градиент напрямую.Gumbel-Softmax позволит приближенно осуществить этот переход с помощью детерминированной операции. Если к логарифму от вектора
probs прибавить вектор из распределения Гумбеля (аналог N(0;1) в данном случае), то argmax итогового вектора будет распределён так же, как и исходное распределение.Последняя проблема - argmax сам недифференцируем, поэтому его заменяют на софтмакс с маленькой температурой. В итоге, получая на вход
[0.2;0.8], эта операция будет выдавать [0.001; 0.999] в 80% случаев и [0.999;0.001] в 20 процентах случаев.Самый большой затык вызывает следующий вопрос - в чём профит этой штуки по сравнению с тем, чтобы просто использовать
[0.2;0.8] в дальнейших операциях, если там всё равно не требуется строгий one-hot вектор? Я объясняю это так - во время обучения мы хотим, чтобы все последующие части модели получали на вход реалистичные сэмплы из категориального распределения. Если наша модель будет учиться на размазанных векторах, то мы не сможем во время инференса просто начать сэмплировать код - декодер не выкупит этот пранк.
А что делать в случае, когда нам реально нужен строгий one-hot вектор, например, если это RL и мы совершаем действие? Авторы оригинальной статьи предлагают комбинировать Straight Through Estimator и Gumbel Softmax, т.е. использовать
[1; 0], а градиент пробрасывать так, как будто там был [0.999; 0.001]. Но я никогда не встречал применения такой схемы.@knowledge_accumulator
Forwarded from IT analysis • Системный и бизнес анализ
Разбор задачи с собеседования на системного аналитика. Часть 2
Продолжаем разбор задачи с собеседования на позицию системного аналитика, с условием задачи можете ознакомиться в предыдущем посте. Сегодня разберём как описать логику сервиса.
Начнем с выбора способа.
1️⃣ Логику можем описать в визуальном формате с помощью UML Sequence диаграммы или в текстовом формате с помощью сценария использования.
На собеседовании могут дать возможность выбрать любой из методов, а могут попросить описать с использованием конкретного метода. Поэтому нужно быть готовым к любому исходу и уметь работать как с sequence диаграммой, так и со сценариями использования.
Я решил выбрать второй способ и описать логику с помощью Use Case. Рассмотрим сценарий: «Купить авиабилеты»
Для описания сценария использования нам нужно:
а. Определить действующие лица сценария.
b. Определить системы, которые будут участвовать в сценарии.
c. Обозначить триггеры и предусловия.
d. Сформировать основной сценарий.
e. Проработать альтернативные сценарии.
2️⃣ Выделим действующее лицо и системы, которые принимают участие в нашем сценарии. Пусть это будет "Пользователь", "Мобильное приложение"/"Система" и "Авиакомпания-партнер".
3️⃣ Обозначим предусловие, необходимое для старта:
4️⃣ Начнём формировать описание основного сценария. Описание должно удовлетворять следующим правилам:
1. Система должна подсказывать следующий шаг
2. Пользователь может только предоставляет данные, он не может выполнять операции
3. Система должна сообщать о результатах операции
Например,
5️⃣ После проработки основного сценария можно приступить к формированию альтернативных потоков. Нужно последовательно пройтись по каждому пункту из основного сценария и определить, какие ещё исходы возможны при выполнении этого действия.
Например, для пункта 5 один из альтернативных сценариев может быть следующим:
Такой последовательности действий можно придерживаться при решении подобных задач в работе и на собеседовании. Сохраняйте и делитесь с коллегами, если было полезно😉
#ITInterview
Продолжаем разбор задачи с собеседования на позицию системного аналитика, с условием задачи можете ознакомиться в предыдущем посте. Сегодня разберём как описать логику сервиса.
Начнем с выбора способа.
На собеседовании могут дать возможность выбрать любой из методов, а могут попросить описать с использованием конкретного метода. Поэтому нужно быть готовым к любому исходу и уметь работать как с sequence диаграммой, так и со сценариями использования.
Я решил выбрать второй способ и описать логику с помощью Use Case. Рассмотрим сценарий: «Купить авиабилеты»
Для описания сценария использования нам нужно:
а. Определить действующие лица сценария.
b. Определить системы, которые будут участвовать в сценарии.
c. Обозначить триггеры и предусловия.
d. Сформировать основной сценарий.
e. Проработать альтернативные сценарии.
Пользователь должен быть авторизован в системе
1. Система должна подсказывать следующий шаг
2. Пользователь может только предоставляет данные, он не может выполнять операции
3. Система должна сообщать о результатах операции
Например,
1. Пользователь выбирает дату вылета, город отправления и город прибытия
2. Система показывает доступные рейсы в соотв. с фильтрами
3. Пользователь выбирает определенный рейс
4. Система запрашивает информацию о свободных местах в авиакомпании-партенере для определенного рейса
5. Авиакомпания-партнер предоставляет информацию о свободных местах для определенного рейса
6. Система показывает форму бронирования свободные мест на выбранный рейс
.....
Например, для пункта 5 один из альтернативных сценариев может быть следующим:
5а. Все места заняты: Авиакомпания-партнер предоставляет информацию о том, что на рейсе нет свободных мест
Такой последовательности действий можно придерживаться при решении подобных задач в работе и на собеседовании. Сохраняйте и делитесь с коллегами, если было полезно
#ITInterview
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM под капотом
Победители Enterprise RAG Challenge!
Я поздравляю всех победителей и участников. Мы сейчас не только классное соревнование устроили, но и сделали прямо громадный research по практическому сравнению эффективности разных архитектур на конкретной бизнес-задаче. Плюс получили живой опыт работы документами и PDF (кто бодался с отчетом на 1000 страниц - ставьте 🤝)
Отчеты, ссылки, посты, leaderboards, ground truth - все это мы будем выкладывать и дублировать в ближайшие недели.
Итак, победители. Теоретический максимум - 133 (100 за ответы и 33 за retrieval)
IBM WatsonX AI Track 🏆
3. nightwalkers - 356ef42c: 96.7.
Векторный RAG с deepseek-r1-distill-llama-70b и granite-embedding-107m-multilingual embeddings
2. A.Rasskazov/V.Kalesnikau - efabd48e: 109.3
multi_agent_ibm_openai - meta-llama/llama-3-405b-instruct, ibm/granite-embedding-107m-multilingual, text-embedding-3-small, gpt-4o-mini
1. Ilia Ris - 25fabf22: 120.3
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + SO reparser + Majority vote (Self-Consistency); llm = llama-3.3 70b from IBM WatsonX
Main Track 🏆
3. hopeless - 6b0d78ba: 117.5
gpt-4o-2024-08-06
Dynamic Structured Output + SEC EDGAR Ontologies
Query Expansion with selecting indicators on CBOW similarity
Majority Selection for several runs (works for pages and final answers)
Chunking by pages only with focus on balancing pages vs tokens
2. Emil Shagiev - 0a878232: 121.6
gpt-4o-mini-2024-07-18, gpt-4o-2024-08-06, o3-mini-2025-01-31
1. Query Expansion
2. Search relevant pages using with fast and cheap LLM
3. Answer questions
4. Finalize answers
1. Ilia Ris - 320a7d36: 121.6
o3-mini
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + Majority vote (Self-Consistency); llm = o3-mini
Еще раз поздравляю всех! SotA Leaderboard - в комментариях.
А вообще - что вам больше всего запомнилось в этом соревновании? Я думаю про третий раунд, уже с reasoning и поглубже в бизнес. Надо такое?
Ваш, @llm_under_hood 🤗
PS: Если еще хотите поучаствовать ради опыта в соревновании, то еще не поздно. Submission API я пока выключать не буду - пара команд попросила отсрочку до следующей недели.
Я поздравляю всех победителей и участников. Мы сейчас не только классное соревнование устроили, но и сделали прямо громадный research по практическому сравнению эффективности разных архитектур на конкретной бизнес-задаче. Плюс получили живой опыт работы документами и PDF (кто бодался с отчетом на 1000 страниц - ставьте 🤝)
Отчеты, ссылки, посты, leaderboards, ground truth - все это мы будем выкладывать и дублировать в ближайшие недели.
Итак, победители. Теоретический максимум - 133 (100 за ответы и 33 за retrieval)
IBM WatsonX AI Track 🏆
3. nightwalkers - 356ef42c: 96.7.
Векторный RAG с deepseek-r1-distill-llama-70b и granite-embedding-107m-multilingual embeddings
2. A.Rasskazov/V.Kalesnikau - efabd48e: 109.3
multi_agent_ibm_openai - meta-llama/llama-3-405b-instruct, ibm/granite-embedding-107m-multilingual, text-embedding-3-small, gpt-4o-mini
1. Ilia Ris - 25fabf22: 120.3
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + SO reparser + Majority vote (Self-Consistency); llm = llama-3.3 70b from IBM WatsonX
Main Track 🏆
3. hopeless - 6b0d78ba: 117.5
gpt-4o-2024-08-06
Dynamic Structured Output + SEC EDGAR Ontologies
Query Expansion with selecting indicators on CBOW similarity
Majority Selection for several runs (works for pages and final answers)
Chunking by pages only with focus on balancing pages vs tokens
2. Emil Shagiev - 0a878232: 121.6
gpt-4o-mini-2024-07-18, gpt-4o-2024-08-06, o3-mini-2025-01-31
1. Query Expansion
2. Search relevant pages using with fast and cheap LLM
3. Answer questions
4. Finalize answers
1. Ilia Ris - 320a7d36: 121.6
o3-mini
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + Majority vote (Self-Consistency); llm = o3-mini
Еще раз поздравляю всех! SotA Leaderboard - в комментариях.
А вообще - что вам больше всего запомнилось в этом соревновании? Я думаю про третий раунд, уже с reasoning и поглубже в бизнес. Надо такое?
Ваш, @llm_under_hood 🤗
PS: Если еще хотите поучаствовать ради опыта в соревновании, то еще не поздно. Submission API я пока выключать не буду - пара команд попросила отсрочку до следующей недели.
Forwarded from LLM под капотом
Первые инсайты из Enterprise RAG Challenge r2
Мы с вами их обнаружили вместе!
Во-первых, качество извлечения документов важно для точности. Тут внезапно хорошо себя проявила библиотечка Docling от IBM (даже за пределами WatsonX AI Track).
Во-вторых, при наличии хорошой архитектуры можно получить высокие результаты даже на локальных моделях.
Смотрим на архитектуру Ильи, которую он запускал на разных моделях.
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + SO CoT + SO reparser
Видно, что по мере снижения размера модели, у нас снижается качество ответов. Но оно падает не так быстро, как можно было бы ожидать. Я думаю, что это все благодаря качественно сделанной Retrieval части - она “облегчает” работу LLM на финальных этапах.
В-третьих, в топовых решениях часто используются reasoning паттерны на основе SO CoT (Structured Outputs + Chain of Thought == Custom Chain of Thought). Причем они работают даже там, где SO нет и впомине (только нужно использовать Schema Repair).
В-четвертых, в ситуациях со сложно предсказуемыми вопросами хороший векторный поиск пока до сих пор работает чуть лучше решений без векторов.
Самый главный вывод для меня - с локальными моделями, оказывается, можно делать сильно больше и сильно лучше, чем казалось раньше. Они могут составить неплохую конкуренцию облачным моделям, если выжимать максимум из их способностей.
---
- Победители Enterprise RAG Challenge r2
- Табличка с результатами (лучший результат от каждой команды)
Ваш, @llm_under_hood 🤗
Мы с вами их обнаружили вместе!
Во-первых, качество извлечения документов важно для точности. Тут внезапно хорошо себя проявила библиотечка Docling от IBM (даже за пределами WatsonX AI Track).
Во-вторых, при наличии хорошой архитектуры можно получить высокие результаты даже на локальных моделях.
Смотрим на архитектуру Ильи, которую он запускал на разных моделях.
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + SO CoT + SO reparser
o3-mini R: 83.8 │ G: 81.8 │ Score: 123.7
llama3.3-70b R: 83.9 │ G: 72.8 │ Score: 114.8
llama-3.1 8b R: 81.1 │ G: 68.7 │ Score: 109.3
R - Retrieval score
G - Generation score
Видно, что по мере снижения размера модели, у нас снижается качество ответов. Но оно падает не так быстро, как можно было бы ожидать. Я думаю, что это все благодаря качественно сделанной Retrieval части - она “облегчает” работу LLM на финальных этапах.
В-третьих, в топовых решениях часто используются reasoning паттерны на основе SO CoT (Structured Outputs + Chain of Thought == Custom Chain of Thought). Причем они работают даже там, где SO нет и впомине (только нужно использовать Schema Repair).
В-четвертых, в ситуациях со сложно предсказуемыми вопросами хороший векторный поиск пока до сих пор работает чуть лучше решений без векторов.
Самый главный вывод для меня - с локальными моделями, оказывается, можно делать сильно больше и сильно лучше, чем казалось раньше. Они могут составить неплохую конкуренцию облачным моделям, если выжимать максимум из их способностей.
---
- Победители Enterprise RAG Challenge r2
- Табличка с результатами (лучший результат от каждой команды)
Ваш, @llm_under_hood 🤗
Forwarded from Дратути Антон
Профилировщики
Есть такой момент: код работает 1 час вместо 1 минуты. Это вообще нормально?🏥
У меня был скрипт, который работал ну жутко долго. Из "замечательных" его свойств было:
— Обилие библиотек, которые делали одно и то же;
— Тонна строк кода, которые сложно уместить в контекст.
Примечательно и другое: всего 10000 семплов прогонялось в скрипте, а занимало целый час. Моё алгоритмическое чутьё подозревает степенную сложность у алгоритмов в коде🤓 . Но как всю эту лютейшую дичь искать глазами в такой простыне? Вообще не представляю. Значит, нужон профилировщик.
Я достаточно давно не использовал подобный инструментарий для Python кода, а потому вообще всё забыл. Погуглил, наткнулся на Austin — и правда кайфанул.
Во-первых, как мне показалось, он практически не влияет на код. Видимо, профилировка методом сбора статистик из стека вызовов сделана классно.
Во-вторых, установил и запустил — из коробки работает норм. Не нужно настраивать, читать 100500 толмутов документации, чтобы сделать запуск.
В-третьих, реалтайм построение flamegraph. Запускаешь, смотришь, останавливаешься в любой момент — и сразу видно, где всё тормозит.
Также в тулзе есть профилировщик памяти, но я юзал для этих целей memray (тож рекомендую).
В результате, я минут за 5 нашёл проблемные места и получил свою заветную одну минуту времени работы! Скорее всего вы даже лучше меня знаете, что лучше всего использовать для отладки проблем с производительностью приложений на Python. Но я считаю, что этот фреймворк — абсолютное величие для тех, кто хочет что-то быстренько ускорить на коленке.
И вот какой у меня возник вопрос: сколько бы эту задачу делал ИИ-агент и вообще смог ли бы он её сделать?
Есть такой момент: код работает 1 час вместо 1 минуты. Это вообще нормально?
У меня был скрипт, который работал ну жутко долго. Из "замечательных" его свойств было:
— Обилие библиотек, которые делали одно и то же;
— Тонна строк кода, которые сложно уместить в контекст.
Примечательно и другое: всего 10000 семплов прогонялось в скрипте, а занимало целый час. Моё алгоритмическое чутьё подозревает степенную сложность у алгоритмов в коде
Я достаточно давно не использовал подобный инструментарий для Python кода, а потому вообще всё забыл. Погуглил, наткнулся на Austin — и правда кайфанул.
Во-первых, как мне показалось, он практически не влияет на код. Видимо, профилировка методом сбора статистик из стека вызовов сделана классно.
Во-вторых, установил и запустил — из коробки работает норм. Не нужно настраивать, читать 100500 толмутов документации, чтобы сделать запуск.
В-третьих, реалтайм построение flamegraph. Запускаешь, смотришь, останавливаешься в любой момент — и сразу видно, где всё тормозит.
Также в тулзе есть профилировщик памяти, но я юзал для этих целей memray (тож рекомендую).
В результате, я минут за 5 нашёл проблемные места и получил свою заветную одну минуту времени работы! Скорее всего вы даже лучше меня знаете, что лучше всего использовать для отладки проблем с производительностью приложений на Python. Но я считаю, что этот фреймворк — абсолютное величие для тех, кто хочет что-то быстренько ускорить на коленке.
И вот какой у меня возник вопрос: сколько бы эту задачу делал ИИ-агент и вообще смог ли бы он её сделать?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дратути Антон
Потестил Mistral OCR
Чо могу сказать: очень хорошо, но есть куда стремиться
— Русская рукописка точно не работает;
— Русский/Английский печатный работает очень хорошо;
— Формулы я так и не нашёл пока багов, даже сложные индексы находит;
— Иногда (редко) сжевывает какие-то столбцы в таблицах;
— Явных жоский галлюцинаций я не нашёл;
— Мне показалось, что очень хорошо строит layout.
Не знаю, что ребята делают под капотом, но это работает турбо быстро! Я заливал pdfки и меньше чем за минуту ко мне прилетал уже готовый markdown. В общем, топчик!
Оригиналы скринов, документов и распознаваний приложу в комментарии!
Чо могу сказать: очень хорошо, но есть куда стремиться
— Русская рукописка точно не работает;
— Русский/Английский печатный работает очень хорошо;
— Формулы я так и не нашёл пока багов, даже сложные индексы находит;
— Иногда (редко) сжевывает какие-то столбцы в таблицах;
— Явных жоский галлюцинаций я не нашёл;
— Мне показалось, что очень хорошо строит layout.
Не знаю, что ребята делают под капотом, но это работает турбо быстро! Я заливал pdfки и меньше чем за минуту ко мне прилетал уже готовый markdown. В общем, топчик!
Оригиналы скринов, документов и распознаваний приложу в комментарии!
Forwarded from Нейросети и Блендер
Media is too big
VIEW IN TELEGRAM
Офигенный workflow от аниматора Cuco
Это как раз идеальный пример, как художник может использовать AI для упрощения процессов не особо теряя в качестве.
-- Тут обучение Лоры на своих артах, особенно когда их мало.
-- Создание всего окружения в своём стиле + создание простых сцен. Я делал что-то похожее здесь.
-- Создание простых анимаций использую только линии и затем Lineart на своей Лоре чтобы сделать финальную картинку.
-- Далее AnimateDiff с Lineart ControlNet для сцен + Лора. И вот уже у нас офигенные слои, которые можно будем потом композить.
Автор: LINK
Это как раз идеальный пример, как художник может использовать AI для упрощения процессов не особо теряя в качестве.
-- Тут обучение Лоры на своих артах, особенно когда их мало.
-- Создание всего окружения в своём стиле + создание простых сцен. Я делал что-то похожее здесь.
-- Создание простых анимаций использую только линии и затем Lineart на своей Лоре чтобы сделать финальную картинку.
-- Далее AnimateDiff с Lineart ControlNet для сцен + Лора. И вот уже у нас офигенные слои, которые можно будем потом композить.
Автор: LINK
Forwarded from Maxim Beregov
Очень советую систему DISC для оценки людей, которая поможет хаотичные мысли сложить в систему.
https://huntflow.media/disc/
https://huntflow.media/disc/
Журнал Хантфлоу
Модель DISC: что это, 4 типа личности, как использовать в управлении персоналом
Модель DISC — поведенческая методика для HR, включает 4 типа личности сотрудников. Помогает оптимизировать подбор персонала. Дали описание типологии, способы тестирования, рассказали, как использовать на практике.