Forwarded from Data, Stories and Languages
Говорят, что достали системный промпт Advanced Voice Mode
https://www.reddit.com/r/OpenAI/comments/1fp1fes/the_system_prompt_of_advanced_voice_mode_it_can/
https://www.reddit.com/r/OpenAI/comments/1fp1fes/the_system_prompt_of_advanced_voice_mode_it_can/
Forwarded from Small Data Science for Russian Adventurers
#книга
Онлайн-учебник по машинному и глубокому обучению от преподавателя ВМК МГУ Виктора Китова
https://deepmachinelearning.ru/
Онлайн-учебник по машинному и глубокому обучению от преподавателя ВМК МГУ Виктора Китова
https://deepmachinelearning.ru/
Forwarded from Николай Хитров | Блог
Статья Быстрее пули: как найти счастье с PostgreSQL
Большая классная статья про поиск в
В статье автор рассказывает про:
👉
👉 нормализацию слов и морфологию
👉 словари синонимов
👉 ранжирование результатов по релевантности
https://habr.com/ru/companies/rostelecom/articles/853124/
Большая классная статья про поиск в
postgresql. На мой взгляд отлично подходит для ситуаций, когда по каким-то причинам еще не хочется (или не можется) завезти отдельную колоночную БД для поиска по типу elasticsearch, но простого WHERE ILIKE уже не хватает.В статье автор рассказывает про:
👉
tsvector, tsquery и GIN индексы👉 нормализацию слов и морфологию
👉 словари синонимов
👉 ранжирование результатов по релевантности
https://habr.com/ru/companies/rostelecom/articles/853124/
Хабр
Быстрее пули: как найти счастье с PostgreSQL
Введение Полнотекстовый поиск — это неотъемлемая часть современных приложений, особенно тех, которые работают с большими объемами текстовой информации, будь то блог-платформы, системы управления...
Forwarded from DziS Science | Data Science
Привет всем!👋
Про эффективность созвонов.
Только ленивый в DS не ругался касаемо количества бесполезных созвонов.
Вроде бы у тебя есть задача, дедлайн не завтра, но количество встреч, притом посреди рабочего дня только с получасовым перерывом на обед раздражают даже самого спокойного сотрудника.
Нередко, даже в чатах с вакансиями в качестве плюса указывают маленькое количество созвонов в течение рабочей недели.
-Но почему так?
Дело в том, что созвоны в рамках любой схемы «эффективного» рабочего процесса это неотъемлемая часть, но нередко мы страдаем из-за злоупотребления данным инструментом.
🔸 Прежде чем ответить себе на вопрос, эффективный ли созвон, на котором я нахожусь, надо понять, что это инструмент решения конкретной задачи и понять, а решает ли этот созвон что-то решает или помогает решить ее эффективно?
Нередко, именно на этом вопросе можно заканчивать половину созвонов.
Если ответ невнятный, то можно поблагодарить коллег и попросить прислать статус по почте.
Это кстати второй тезис для понимания, а эффективен ли созвон.
🔵 Если проблема, решаемая данным инструментом, может быть исчерпана одним коротким письмом, то данный созвон явно не эффективен.
🔹 Созвон содержит слишком много людей. Если вам нужен конкретный человек из другого подразделения, то не всегда нужно звать всех 40 специалистов из его подразделения. Достаточно позвать конкретного и, максимум, его руководителя. Объективно, 38 оставшихся сотрудников будут сидеть без дела.
🔸 Однако и тут, важен тайминг. Представьте ситуацию: у вас с подчинении n людей и вам нужно собрать краткий статус по задачам. Из практики, лучше собрать n людей на 30 минут, чем n*30 минут провести на персональных встречах 1 на 1. Результат будет одинаковый, но времени потратите на пару часов меньше. Если нужно, поставьте дополнительную встречу.
Эта проблема, кстати, настигала меня совсем недавно. Я делал статусы по отдельным направлениям, хотя ни один из них не выбивался за 30 минутный тайминг. Получилось, что всех и все можно собрать в полчаса.
Обычно формула простая: на каждых новых 4 человек добавляется во встрече 30 минут. Но не более 1 часа, дальше теряется внимание, проверено на опыте. Т.е за одну встречу вы эффективно можете узнать как дела по работе, не более чем у 8х. Это лично наблюдение.
🔸 Обязательно должна быть встреча 1 на 1 по нерабочим процессам, хотя бы раз в месяц.
Таким образом, я выработал некоторый чек лист:
1️⃣ . Встреча должна решать проблему!
2️⃣ . У нее должна быть цель, повестка или структура.
3️⃣ . Встреча больше часа - зло. Исключение - увеселительная встреча с пиццей.
4️⃣ . Встреча на кучу людей, в т.ч не относящихся к проблеме - зло.
5️⃣ . Можно решить проблему по переписке - не ставьте созвон.
6️⃣ . Можно собрать кучу встреч в одну? - собирайте. Лучше потом поставить одну лишнюю, но нужную, чем ставить регулярно кучу.
7️⃣ . Встреча 1 на 1 не рабочая должна быть, хотя бы раз в 1 месяц. Если нет или это очередной дейлик - плохо.
8️⃣ . Какой-то менеджер ставит вам по поводу и без встречи, не стесняйтесь, игнорируйте.
9️⃣ . Встреча, на которой вас позвали «за компанию» - бесполезная. Исключение - общие регулярные встречи на всех сотрудников, например демо или общеновостная.
Следуя этим правилам, я разгрузился сам и разгрузил свою команду. Теперь даже время что-то полезное сделать есть.
А то смотрю я на 2-3 встречи на всех каждый день, аж плакать хочется. Славу богу, что у меня не так😂
А как у вас с этим в компании? Пишите в комменты⬇️
#статьи #трудовые_будни
Про эффективность созвонов.
Только ленивый в DS не ругался касаемо количества бесполезных созвонов.
Вроде бы у тебя есть задача, дедлайн не завтра, но количество встреч, притом посреди рабочего дня только с получасовым перерывом на обед раздражают даже самого спокойного сотрудника.
Нередко, даже в чатах с вакансиями в качестве плюса указывают маленькое количество созвонов в течение рабочей недели.
-Но почему так?
Дело в том, что созвоны в рамках любой схемы «эффективного» рабочего процесса это неотъемлемая часть, но нередко мы страдаем из-за злоупотребления данным инструментом.
Нередко, именно на этом вопросе можно заканчивать половину созвонов.
«Коллеги, а какая повестка созвона? А есть ли она вообще?»
Если ответ невнятный, то можно поблагодарить коллег и попросить прислать статус по почте.
Это кстати второй тезис для понимания, а эффективен ли созвон.
Нередко, особенно начинающие руководители, делают очень интересный трюк. На любой вопрос, на который даже можно ответить «да/нет» руководитель может поставить аж полуторачасовую(‼️) встречу, где будет рассказывать все, но не то, что надо. Потом с полной уверенностью в своей эффективности будет рассказывать всем, что целый день занят важными созвонами.
К сожалению, такой персонаж сильно заблуждается. Он лишь отлынивает от работы.
Эта проблема, кстати, настигала меня совсем недавно. Я делал статусы по отдельным направлениям, хотя ни один из них не выбивался за 30 минутный тайминг. Получилось, что всех и все можно собрать в полчаса.
Обычно формула простая: на каждых новых 4 человек добавляется во встрече 30 минут. Но не более 1 часа, дальше теряется внимание, проверено на опыте. Т.е за одну встречу вы эффективно можете узнать как дела по работе, не более чем у 8х. Это лично наблюдение.
А то как вам говорить, что у вас на руках есть оффер или вам все не нравится?
Таким образом, я выработал некоторый чек лист:
Следуя этим правилам, я разгрузился сам и разгрузил свою команду. Теперь даже время что-то полезное сделать есть.
А то смотрю я на 2-3 встречи на всех каждый день, аж плакать хочется. Славу богу, что у меня не так😂
А как у вас с этим в компании? Пишите в комменты
#статьи #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Start Career in DS
ℹ️ Всё про токенизацию и токенизаторы в языковых моделях
❕Токен - это минимальная единица текста, с которой работают современные языковые модели. В качестве токена могут выступать как полноценные слова, так и части слов, слоги или отдельные символы.
✂️ Например, в некоторых моделях слово «привет» может разбиваться на токены: [«при», «вет»].
❕Токенизация — процесс предобработки входного текста в список токенов. Обычно далее каждый токен векторизуется и весь этот массив векторов подаётся модели на вход, с чем она начинает работать.
🤯 В моделях Transformer токенизаторы обучаемы. Обучение токенизаторов не схоже с тем, как обучаются ML-модели, наоборот, это статистический процесс, который определяет, какие сочетания символов (подслов, слов) лучше всего выбрать для корпуса текста, с которым мы работаем.
🔝Современные токенизаторы можно разделить по следующим видам:
1. Byte-Pair Encoding (используется в GPT-like моделях, обучается слиянием символов из основного корпуса, выбирая пары по наибольшей частоте встречаемости, подробно про алгоритм и реализацию кода обучения читайте тут)
2. WordPiece (используется преимущественно в BERT-like моделях, также обучается слиянием, но используется не частота встречаемости, а более универсальная формула, также подробно читайте про реализацию и формулу тут)
3. Unigram (не так применим, однако, для полноты картины читайте о нем тут)
❗️Почему это важно:
1️⃣ Фертильность (мера, показывающая среднее количество токенов на одно слово после токенизации предложения):
Напрямую влияет на стоимость использования любой модели: больше токенов после токенизации предложения -> больше входная последовательность в LLM -> больше стоимость.
2️⃣ Качество работы:
Правильно токенизированная последовательность также сильно влияет на качество модели из-за появления символов, которых модель не видела или из-за особенностей некоторых языков, где нет, например, пробелов.
Очень грамотно и подробно этот нюанс описан тут.
3️⃣ Скорость работы:
Следствие из первого пункта: чем больше последовательность токенов, тем больше вычислений стоит делать, что также влияет на скорость ответа модели.
🔥 Дополнительная информация по теме:
- Краткий обзор токенизаторов на Хабре
- О токенизаторах с NLP-курса на Hugging Face
- «Насколько хорош Ваш Токенайзер» - статья на arxiv [ENG]
- Статья на английском для начинающих о токенах в LLM [ENG]
Теперь вы знаете, как работают токенизаторы🔥
Ждём ваших лайков и обратной связи❤️
До встречи👋🏻
❕Токен - это минимальная единица текста, с которой работают современные языковые модели. В качестве токена могут выступать как полноценные слова, так и части слов, слоги или отдельные символы.
✂️ Например, в некоторых моделях слово «привет» может разбиваться на токены: [«при», «вет»].
❕Токенизация — процесс предобработки входного текста в список токенов. Обычно далее каждый токен векторизуется и весь этот массив векторов подаётся модели на вход, с чем она начинает работать.
🤯 В моделях Transformer токенизаторы обучаемы. Обучение токенизаторов не схоже с тем, как обучаются ML-модели, наоборот, это статистический процесс, который определяет, какие сочетания символов (подслов, слов) лучше всего выбрать для корпуса текста, с которым мы работаем.
🔝Современные токенизаторы можно разделить по следующим видам:
1. Byte-Pair Encoding (используется в GPT-like моделях, обучается слиянием символов из основного корпуса, выбирая пары по наибольшей частоте встречаемости, подробно про алгоритм и реализацию кода обучения читайте тут)
2. WordPiece (используется преимущественно в BERT-like моделях, также обучается слиянием, но используется не частота встречаемости, а более универсальная формула, также подробно читайте про реализацию и формулу тут)
3. Unigram (не так применим, однако, для полноты картины читайте о нем тут)
❗️Почему это важно:
1️⃣ Фертильность (мера, показывающая среднее количество токенов на одно слово после токенизации предложения):
Напрямую влияет на стоимость использования любой модели: больше токенов после токенизации предложения -> больше входная последовательность в LLM -> больше стоимость.
2️⃣ Качество работы:
Правильно токенизированная последовательность также сильно влияет на качество модели из-за появления символов, которых модель не видела или из-за особенностей некоторых языков, где нет, например, пробелов.
Очень грамотно и подробно этот нюанс описан тут.
3️⃣ Скорость работы:
Следствие из первого пункта: чем больше последовательность токенов, тем больше вычислений стоит делать, что также влияет на скорость ответа модели.
🔥 Дополнительная информация по теме:
- Краткий обзор токенизаторов на Хабре
- О токенизаторах с NLP-курса на Hugging Face
- «Насколько хорош Ваш Токенайзер» - статья на arxiv [ENG]
- Статья на английском для начинающих о токенах в LLM [ENG]
Теперь вы знаете, как работают токенизаторы🔥
Ждём ваших лайков и обратной связи❤️
До встречи👋🏻
Forwarded from Душный NLP
WARM — метод улучшения reward-моделей
Сегодняшняя статья — о методе усреднения весов reward-модели для устранения проблем, связанных с RL-обучением. Но для начала напомним, как работает Reward-модель.
На вход она принимает промпты и ответы, а на выход выдаёт скаляры. По ним возможно ранжировать ответы от лучшего к худшему. Всё это делается с помощью обучения на минимизацию лосса, который вытекает из модели Брэдли-Терри. Как правило, reward-модели обучаются на датасете из преференсных данных — то есть таких, в которых ответы уже размечены асессорами или другой моделью.
Есть ряд проблем, с которыми можно столкнуться во время обучения reward-модели. Во-первых, разметка может оказаться достаточно шумной — например, при расхождениях в оценках одного и того же ответа разными асессорами. Кроме того, в некоторых случаях политика может генерировать OOD-ответы для выбранной reward-модели.
Наконец, возможно и такое, что reward-модель выучится на какой-то черте данных — например, особенностях оформления. При этом на файнтюнинге модель научится генерировать те ответы, которые будут давать высокий скор именно из-за этой особенности, а не из-за качества самих ответов. Скажем, будет отдавать приоритет хорошо оформленным, а не правильным ответам.
Существует несколько методов, призванных справится с вышеописанными проблемами. Например, можно обучить много абсолютно разных reward-моделей и усреднить их логиты. Этот метод называется prediction ensembling (ENS), а его главный недостаток заключается в необходимости инферить сразу несколько моделей, что не очень экономично в условиях файнтюнинга.
Авторы статьи, в свою очередь, предлагают обучать reward-модель с помощью одного датасета с преференсными данными, но с разными гиперпараметрами, а также с разных чекпоинтов SFT-обучения. В результате получается несколько моделей с одинаковой архитектурой. Их веса следует усреднить в одну модель — Weight Average Reward-Model (WARM), которая поступает как reward-функция в RL. Проведенный авторами анализ показал, что WARM — это аппроксимация ENS.
Почему это должно работать? Известно, что существует линейная связь в моделях, обученных из одного претрейна. Она позволяет усреднять веса, не теряя при этом в качестве. Однако это справедливо только для одного претрейна.
Проверки c использованием датасета TL;DR summarization показали, что WARM запоминает меньше испорченных или некорректных данных разметки в датасете, чем ENS. То же самое касается работы с OOD-примернами. Однако на «чистом» фрагменте датасета, где разметка без ошибок, ENS выдаёт лучшие результаты.
Авторы заявляют, что преимущество их метода заключается в использовании всего одной модели в ходе файнтюнинга — это позволяет экономить время и вычислительные ресурсы. Кроме того, WARM решает некоторые проблемы, связанные с «грязными» данными. Однако есть и ограничения. Например, необходимость обучаться из одного претрейна и невозможность использовать разные архитектуры.
Разбор подготовил❣ Илья Черемушкин
Душный NLP
Сегодняшняя статья — о методе усреднения весов reward-модели для устранения проблем, связанных с RL-обучением. Но для начала напомним, как работает Reward-модель.
На вход она принимает промпты и ответы, а на выход выдаёт скаляры. По ним возможно ранжировать ответы от лучшего к худшему. Всё это делается с помощью обучения на минимизацию лосса, который вытекает из модели Брэдли-Терри. Как правило, reward-модели обучаются на датасете из преференсных данных — то есть таких, в которых ответы уже размечены асессорами или другой моделью.
Есть ряд проблем, с которыми можно столкнуться во время обучения reward-модели. Во-первых, разметка может оказаться достаточно шумной — например, при расхождениях в оценках одного и того же ответа разными асессорами. Кроме того, в некоторых случаях политика может генерировать OOD-ответы для выбранной reward-модели.
Наконец, возможно и такое, что reward-модель выучится на какой-то черте данных — например, особенностях оформления. При этом на файнтюнинге модель научится генерировать те ответы, которые будут давать высокий скор именно из-за этой особенности, а не из-за качества самих ответов. Скажем, будет отдавать приоритет хорошо оформленным, а не правильным ответам.
Существует несколько методов, призванных справится с вышеописанными проблемами. Например, можно обучить много абсолютно разных reward-моделей и усреднить их логиты. Этот метод называется prediction ensembling (ENS), а его главный недостаток заключается в необходимости инферить сразу несколько моделей, что не очень экономично в условиях файнтюнинга.
Авторы статьи, в свою очередь, предлагают обучать reward-модель с помощью одного датасета с преференсными данными, но с разными гиперпараметрами, а также с разных чекпоинтов SFT-обучения. В результате получается несколько моделей с одинаковой архитектурой. Их веса следует усреднить в одну модель — Weight Average Reward-Model (WARM), которая поступает как reward-функция в RL. Проведенный авторами анализ показал, что WARM — это аппроксимация ENS.
Почему это должно работать? Известно, что существует линейная связь в моделях, обученных из одного претрейна. Она позволяет усреднять веса, не теряя при этом в качестве. Однако это справедливо только для одного претрейна.
Проверки c использованием датасета TL;DR summarization показали, что WARM запоминает меньше испорченных или некорректных данных разметки в датасете, чем ENS. То же самое касается работы с OOD-примернами. Однако на «чистом» фрагменте датасета, где разметка без ошибок, ENS выдаёт лучшие результаты.
Авторы заявляют, что преимущество их метода заключается в использовании всего одной модели в ходе файнтюнинга — это позволяет экономить время и вычислительные ресурсы. Кроме того, WARM решает некоторые проблемы, связанные с «грязными» данными. Однако есть и ограничения. Например, необходимость обучаться из одного претрейна и невозможность использовать разные архитектуры.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artificial stupidity
#prompts #LLM #random
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Ты опытный модератор дебатов. Проведи структурированные дебаты по предложенной теме: [Тема]### Базовые принципы- Сохраняй абсолютную беспристрастность- Игнорируй эмоциональную окраску в формулировке темы- Используй единые критерии оценки для всех аргументов- Основывайся только на фактах, а не на формулировке вопроса### Формат дебатов:- У сторон есть время подумать и выбрать лучшие аргументы из сформированного ими самими списка- Представь два противоположных мнения- Для каждой стороны приведи 3 главных аргумента с доказательствами- Дай возможность каждой стороне опровергнуть аргументы оппонента- Оцени силу аргументов каждой стороны по шкале от 1 до 10### Требования к аргументам:- Используй только проверяемые факты- Приводи статистические данные- Ссылайся на исследования и экспертные мнения- Избегай эмоциональных манипуляций### Система оценки:- Жюри из 3х специалистов оценивает каждый аргумент- Каждый член жюри дает независимую оценку- Итоговая оценка - среднее значение трех оценок- При равном счете проводится дополнительный раунд- Решение должно быть основано исключительно на силе аргументов### Важно:- Сохраняй последовательность в оценках между разными дебатами- Используй одинаковые критерии независимо от формулировки темы- Итоговое решение должно основываться только на представленных фактахForwarded from rzv Data Engineering
Эксперимент — серия постов будет выходить средними кусочками несколько дней подряд
#зачем_нужно
Проблемы и решения в очистке данных 1/?
При загрузке данных из исходных систем мы почти всегда сталкиваемся с "грязными" данными - опечатки, разные форматы, технические ошибки. Если не обработать такие случаи, таблицы перестанут джойниться или будут выдавать мусор на выходе (в BI, отчётах и пр.).
Изучение и очистка данных на первом этапе помогает избежать неприятных сюрпризов в будущем и сэкономить время на исправлении ошибок. Вот основные трансформации, с которыми ты можешь столкнуться. Синтаксис стараюсь брать из ANSI или распространённых надстроек:
🔶 Название поля не соответствует naming convention в DWH
Лучше хотя бы на raw слое оставить исходные названия колонок для lineage и traceability. И старайся не множить сущности, где возможно, приводи к единому стилю (naming convention) и называй одинаковые параметры одинаково, а разные — по-разному.
🔶 Формат даты
🔶 JSON, который нужно распарсить и разложить по колонкам
Не забывай обрабатывать случаи с пустыми JSON'ами и массивами.
🔶 Вручную заполняемые поля "перечисляемого типа", которые нужно привести к одному виду
Использовать нечёткое сопоставление, например splink на python, или вручную заполненный маппинг значений, предварительно приведённых к
Написание запросов а-ля
#зачем_нужно
Проблемы и решения в очистке данных 1/?
При загрузке данных из исходных систем мы почти всегда сталкиваемся с "грязными" данными - опечатки, разные форматы, технические ошибки. Если не обработать такие случаи, таблицы перестанут джойниться или будут выдавать мусор на выходе (в BI, отчётах и пр.).
Изучение и очистка данных на первом этапе помогает избежать неприятных сюрпризов в будущем и сэкономить время на исправлении ошибок. Вот основные трансформации, с которыми ты можешь столкнуться. Синтаксис стараюсь брать из ANSI или распространённых надстроек:
🔶 Название поля не соответствует naming convention в DWH
column as new_column
Лучше хотя бы на raw слое оставить исходные названия колонок для lineage и traceability. И старайся не множить сущности, где возможно, приводи к единому стилю (naming convention) и называй одинаковые параметры одинаково, а разные — по-разному.
🔶 Формат даты
try_cast(date_column as date) /* для безопасного приведения */
to_date(date_string, 'YYYY-MM-DD') /* если известен формат */
case when date_column ~ '^\d{4}-\d{2}-\d{2}$' then cast(date_column as date) end /* с валидацией */
🔶 JSON, который нужно распарсить и разложить по колонкам
case when is_valid_json(json_column) then /* проверка валидности */
json_value(json_column, '$.field_name'),
json_query(json_column, '$.contacts[*].phone'), /* массив */
json_value(json_column, '$.address.city'), /* вложенный объект */
(select string_agg(value, ',')
from json_table(json_column, '$.tags[*]' columns (value varchar path '$'))
) as tags /* массив в строку */
end
Не забывай обрабатывать случаи с пустыми JSON'ами и массивами.
🔶 Вручную заполняемые поля "перечисляемого типа", которые нужно привести к одному виду
Использовать нечёткое сопоставление, например splink на python, или вручную заполненный маппинг значений, предварительно приведённых к
trim(upper(replace(column, ' ', ''))) или другому подобному формату. Написание запросов а-ля
lower(col) like '%sub%string%' плохо масштабируется и зачастую приводит к неожиданным результатам (когда под шаблон начинают попадать "не те" категории).Forwarded from rzv Data Engineering
#зачем_нужно
Проблемы и решения в очистке данных 2/?
🔶 Значение "по умолчанию" для отсутствия данных в виде пустой строки или "Nan", когда для обработки нужен NULL
🔶 Разный тип данных при union/union all или колонок из условия on в join
🔶 Вставка в таргет-таблицу NOT NULL поля из источника, где значение может отсутствовать
🔶 У одного из объектов, объединяемых через union/union all, не достаёт колонки
🔶 Разъединить одну колонку на несколько
🔶 Объединить несколько колонок в одну
❔А в этом посте уже было что-то новое? Делись в комментах
Проблемы и решения в очистке данных 2/?
🔶 Значение "по умолчанию" для отсутствия данных в виде пустой строки или "Nan", когда для обработки нужен NULL
case when trim(lower(column)) in (
'', 'null', 'none', 'n/a', 'na', '-',
'#n/a', '#н/д', '(empty)', 'undefined'
) or column ~ '^\s*$' /* только пробелы */
then null
else column
end as clean_column
🔶 Разный тип данных при union/union all или колонок из условия on в join
case when numeric_col ~ '^\d+(\.\d+)?$'
then cast(numeric_col as decimal(18,2))
else null
end /* для последующих join по числовым полям */
cast(num_id as varchar(20)) as num_id /* для join,
где с одной стороны поле varchar(20), а в другой -- числа */
union example:
select cast(id as varchar) as id, name from table1
union all
select id, name from table2 /* приводим к более широкому типу */
case when try_cast(date_field as date) is not null
then try_cast(date_field as date)
else try_cast(date_field as timestamp)::date
end /* для разных форматов дат */
🔶 Вставка в таргет-таблицу NOT NULL поля из источника, где значение может отсутствовать
coalesce(column, 'default') as column
🔶 У одного из объектов, объединяемых через union/union all, не достаёт колонки
cast(null as [data_type]) as column /* null может быть разных типов */
🔶 Разъединить одну колонку на несколько
split_part(full_name, ' ', 1) as surname,
split_part(full_name, ' ', 2) as name /* наивный подход,
для каждого отдельного случая может быть сильно сложнее, вплоть до регулярок */
🔶 Объединить несколько колонок в одну
concat_ws(' ', nullif(address_line_1, ''), nullif(address_line_2, '')) as address❔А в этом посте уже было что-то новое? Делись в комментах
Forwarded from rzv Data Engineering
#зачем_нужно
Проблемы и решения в очистке данных 3/?
🔶 Даты из далёкого будущего или прошлого
🔶 Объединить значения из нескольких строк в один массив
🔶 Полные дубли (совпадают все поля)
❔ Вопрос со звёздочкой*: какая разница между distinct и group by в этом примере?
🔶 Неполные дубли (различаются технические поля)
❕ А здесь было что-то, что пригодится уже завтра на работе?
Проблемы и решения в очистке данных 3/?
🔶 Даты из далёкого будущего или прошлого
case
when date_column between '1900-01-01' and '2100-12-31'
then date_column
else cast(null as date)
end as valid_date /* уточняй, как должно быть
по бизнес-требованиям. иногда даты из средне-далёкого
будущего это ок, например "плановая дата закрытия ипотеки" */
🔶 Объединить значения из нескольких строк в один массив
select key,
string_agg(values, ',')
from ...
group by key
🔶 Полные дубли (совпадают все поля)
select distinct col1, col2, col3
from table
/* или */
select col1, col2, col3
from table
group by col1, col2, col3
❔ Вопрос со звёздочкой*: какая разница между distinct и group by в этом примере?
🔶 Неполные дубли (различаются технические поля)
with prep_cte as (
select col1, col2, business_key, updated_at,
row_number() over (
partition by business_key
order by coalesce(updated_at, '1900-01-01') desc
) as rn
from table
)
select * from prep_cte
where rn = 1
/* оставляем последнюю версию строки по каждому бизнес-ключу */
❕ А здесь было что-то, что пригодится уже завтра на работе?
Forwarded from Tensor Banana
Flux fill - модель для inpaint и outpaint
outpaint - умеет дорисовывать картинку по краям.
inpaint - перерисовывает выделенный объект или текст. Для того чтобы сохранить исходный стиль текста - нужно выделить не всю надпись, а сперва ее часть, так чтобы для модельки остался хоть кусочек текста, под который она подстроится. Например, надпись "Tensor 76" была написана в 2 этапа: "Ten" + "or 76". В comfy инпеинт делать через "Load image - Open in mask editor".
Для хорошего качества инпеинта на выходе - нужно чтобы исходная картинка была большого разрешения. Но тогда и генерация будет идти медленно, так как картинка генерируется в разрешении равном исходному. Частичная региональная генерация вроде тоже работает, но скорее всего, хуже. Для инпеинта рекомендую ставить denoise 0.98 - так стиль лучше сохраняется.
В gguf_q4_0 (6 GB) качество будет немного хуже чем в fp8 (11GB), а скорость генерации такая же.
Со старыми лорами не работает (тестил лору на лицо и 8-шаговую лору). Новые лоры для redux и контролнета еще не тестил.
На 2080ti инпеинт и аутпеинт у меня почему-то плохо работает с разрешением больше 700x700 - внезапно появляется сильный шум на всей картинке. Инпеинт еще термимо, а аутпеинт вообще плохо. Comfy обновлял, разные модельки качал. Если у вас тоже Nvidia 20-й или 10-й серии, напишите в комментариях. На 3060 все супер, но не так быстро.
Для работы нужно обновить comfyui (update_comfyui.bat). В фордже пока не работает, добавят на днях.
гуфы тут: https://huggingface.co/SporkySporkness/FLUX.1-Fill-dev-GGUF/tree/main
или fp8: https://huggingface.co/dim/black-forest-labs_FLUX.1-Fill-dev_flux1-fill-dev_fp8.safetensors/tree/main
воркфлоу для oupaint и inpaint: https://comfyanonymous.github.io/ComfyUI_examples/flux/
nf4 пока нет
Затестить онлайн (бесплатно около 5-6 генераций в день):
inpaint: https://www.runninghub.ai/post/1859967231923810306
outpaint: https://www.runninghub.ai/post/1859965846230798338
outpaint - умеет дорисовывать картинку по краям.
inpaint - перерисовывает выделенный объект или текст. Для того чтобы сохранить исходный стиль текста - нужно выделить не всю надпись, а сперва ее часть, так чтобы для модельки остался хоть кусочек текста, под который она подстроится. Например, надпись "Tensor 76" была написана в 2 этапа: "Ten" + "or 76". В comfy инпеинт делать через "Load image - Open in mask editor".
Для хорошего качества инпеинта на выходе - нужно чтобы исходная картинка была большого разрешения. Но тогда и генерация будет идти медленно, так как картинка генерируется в разрешении равном исходному. Частичная региональная генерация вроде тоже работает, но скорее всего, хуже. Для инпеинта рекомендую ставить denoise 0.98 - так стиль лучше сохраняется.
В gguf_q4_0 (6 GB) качество будет немного хуже чем в fp8 (11GB), а скорость генерации такая же.
Со старыми лорами не работает (тестил лору на лицо и 8-шаговую лору). Новые лоры для redux и контролнета еще не тестил.
1000x1344, 20 steps
3060, q4_0, 6.23s/it, 02:04
3060, fp8, 6.41s/it, 02:09
800x1064, 20 steps
2080ti, fp8, 1.64s/it, 00:32
На 2080ti инпеинт и аутпеинт у меня почему-то плохо работает с разрешением больше 700x700 - внезапно появляется сильный шум на всей картинке. Инпеинт еще термимо, а аутпеинт вообще плохо. Comfy обновлял, разные модельки качал. Если у вас тоже Nvidia 20-й или 10-й серии, напишите в комментариях. На 3060 все супер, но не так быстро.
Для работы нужно обновить comfyui (update_comfyui.bat). В фордже пока не работает, добавят на днях.
гуфы тут: https://huggingface.co/SporkySporkness/FLUX.1-Fill-dev-GGUF/tree/main
или fp8: https://huggingface.co/dim/black-forest-labs_FLUX.1-Fill-dev_flux1-fill-dev_fp8.safetensors/tree/main
воркфлоу для oupaint и inpaint: https://comfyanonymous.github.io/ComfyUI_examples/flux/
nf4 пока нет
Затестить онлайн (бесплатно около 5-6 генераций в день):
inpaint: https://www.runninghub.ai/post/1859967231923810306
outpaint: https://www.runninghub.ai/post/1859965846230798338