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
Forwarded from Reliable ML
Как нанять хорошего CDO - Part #2
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook - Part #1 здесь
Продолжаю делиться моментами, которые показались интересными в книге CDO Playbook.
В книге есть отдельная большая глава с рекомендациями для бизнеса о том, как нанять хорошего CDO и о том, как ему помочь, чтобы все получилось.
Кого надо нанимать
- Нанимайте специалиста в области данных. Не generalist people.
- Гипер важный навык - способность к переговорам с очень большим набором разных стейкхолдеров. Но первично - быть специалистом.
- Надо определиться, какой тип CDO нужен, по типам, выделяемым в книге - first CDO и second CDO (обсуждали в первой части обзора). Зависит от этапа зрелости компании в части работы с данными. Для каждого из типов CDO важны свой набор техскиллов, опыт и мотивация.
- Подумайте, чем вы можете мотивировать хорошего CDO для работы с вами. Что может повлиять на его мотивацию: оргсетап и близость к CEO (будет подробнее дальше), насколько интересные у вас данные и насколько масштабны проблемы для решения и вообще, что вы хотите сделать с помощью цифровой трансформации.
- Состояние данных может быть настолько плохим, что вам сложно будет кого то найти, или, наоборот, слишком хорошим. Поэтому во всех случаях не стоит затягивать с решением о сетапе роли CDO.
- Чтобы хорошо нанять, важно привлечь тех, кто разбирается. И вообще, рынок жесткий, сложно нанять. Скорее всего, вам точно нужна будет помощь. От того, кто поможет сформулировать описание роли и условия. И кто знает людей на рынке. Авторы книги развивают свой консалтинговый бизнес, разумеется.
Как засетапить CDO
- Очень важно наделить CDO достаточным уровнем полномочий для кросс доменных инициатив, установки политик и стандартов. Часто проблемы с внедрением дата стратегии и движением компании в дата дривен историю случаются из за слишком джуниорного сетапа CDO.
- Чем больше уровней между CEO, Правлением и CDO, тем меньше эффекта от роли будет. И нужно быть уверенным, что CDO репортит тому, у кого реально есть данные. Если CDO находится в департаменте, который только получает, но не производит данные - можно получить много проблем, связанных с оторванностью как CDO, так и его руководителя от реальных проблем.
- Аллергия на сетап внутри IT структуры. Важно разнести, когда пихают дату в ИТ получается не очень. Тут прям у авторов книги аллергия и явно болезненный опыт, связанный с взаимоотношением CDO и IT. Неприятие сквозит через всю книгу про то, что IT и работа с данными - это очень разное и это нельзя смешивать управленчески ни за что и никогда. Хотя стоит отметить, что по статистике сетап CDO внутри IT-департаментов остается пока достаточно распространенным вариантом. По последним доступным обзорам у около 25% компаний CDO размещен под ИТ-директором, а у около 35% компаний - в бизнес-единицах.
Как помочь вашему CDO
- Если вы наняли своего первого CDO, то ему очень важна поддержка во внедрении вижена и дата стратегии. И эта поддержка должна быть всем видна. Engagement бизнеса в дата трансформацию - это в первую очередь ответственность CEO/менеджера. Иначе большой риск быстрого выгорания и ухода CDO. И замену по опыту найти очень трудно.
- Не нужно обделять вниманием важность избавления от легаси дата продуктов и автоматизации ручной отчетности. Важно выделять на это время, чтобы не стопорить дата офис в будущем.
- Дата трансформация это долго и ресурсозатратно. Нужно быть к этому готовым, прежде чем идешь в эту историю. Нужно быть готовым к go slow to speed up подходу (особенно в начале пути), не пытаться съесть слона целиком.
- Дайте CDO свободу делать свою работу. Помогайте найти небольшие кейсы и маленькие победы, которые станут первыми шагами на пути к трансформации бизнеса.
- Почти в каждом пункте подчеркивается важность поддержки. ПОЛНОЙ поддержки. Так капслоком и написано, видно, что выстрадано.
Вот такие вот рекомендации. А что откликается вам?
Ваш @Reliable ML
#business #обзор_книги #cdo
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook - Part #1 здесь
Продолжаю делиться моментами, которые показались интересными в книге CDO Playbook.
В книге есть отдельная большая глава с рекомендациями для бизнеса о том, как нанять хорошего CDO и о том, как ему помочь, чтобы все получилось.
Кого надо нанимать
- Нанимайте специалиста в области данных. Не generalist people.
- Гипер важный навык - способность к переговорам с очень большим набором разных стейкхолдеров. Но первично - быть специалистом.
- Надо определиться, какой тип CDO нужен, по типам, выделяемым в книге - first CDO и second CDO (обсуждали в первой части обзора). Зависит от этапа зрелости компании в части работы с данными. Для каждого из типов CDO важны свой набор техскиллов, опыт и мотивация.
- Подумайте, чем вы можете мотивировать хорошего CDO для работы с вами. Что может повлиять на его мотивацию: оргсетап и близость к CEO (будет подробнее дальше), насколько интересные у вас данные и насколько масштабны проблемы для решения и вообще, что вы хотите сделать с помощью цифровой трансформации.
- Состояние данных может быть настолько плохим, что вам сложно будет кого то найти, или, наоборот, слишком хорошим. Поэтому во всех случаях не стоит затягивать с решением о сетапе роли CDO.
- Чтобы хорошо нанять, важно привлечь тех, кто разбирается. И вообще, рынок жесткий, сложно нанять. Скорее всего, вам точно нужна будет помощь. От того, кто поможет сформулировать описание роли и условия. И кто знает людей на рынке. Авторы книги развивают свой консалтинговый бизнес, разумеется.
Как засетапить CDO
- Очень важно наделить CDO достаточным уровнем полномочий для кросс доменных инициатив, установки политик и стандартов. Часто проблемы с внедрением дата стратегии и движением компании в дата дривен историю случаются из за слишком джуниорного сетапа CDO.
- Чем больше уровней между CEO, Правлением и CDO, тем меньше эффекта от роли будет. И нужно быть уверенным, что CDO репортит тому, у кого реально есть данные. Если CDO находится в департаменте, который только получает, но не производит данные - можно получить много проблем, связанных с оторванностью как CDO, так и его руководителя от реальных проблем.
- Аллергия на сетап внутри IT структуры. Важно разнести, когда пихают дату в ИТ получается не очень. Тут прям у авторов книги аллергия и явно болезненный опыт, связанный с взаимоотношением CDO и IT. Неприятие сквозит через всю книгу про то, что IT и работа с данными - это очень разное и это нельзя смешивать управленчески ни за что и никогда. Хотя стоит отметить, что по статистике сетап CDO внутри IT-департаментов остается пока достаточно распространенным вариантом. По последним доступным обзорам у около 25% компаний CDO размещен под ИТ-директором, а у около 35% компаний - в бизнес-единицах.
Как помочь вашему CDO
- Если вы наняли своего первого CDO, то ему очень важна поддержка во внедрении вижена и дата стратегии. И эта поддержка должна быть всем видна. Engagement бизнеса в дата трансформацию - это в первую очередь ответственность CEO/менеджера. Иначе большой риск быстрого выгорания и ухода CDO. И замену по опыту найти очень трудно.
- Не нужно обделять вниманием важность избавления от легаси дата продуктов и автоматизации ручной отчетности. Важно выделять на это время, чтобы не стопорить дата офис в будущем.
- Дата трансформация это долго и ресурсозатратно. Нужно быть к этому готовым, прежде чем идешь в эту историю. Нужно быть готовым к go slow to speed up подходу (особенно в начале пути), не пытаться съесть слона целиком.
- Дайте CDO свободу делать свою работу. Помогайте найти небольшие кейсы и маленькие победы, которые станут первыми шагами на пути к трансформации бизнеса.
- Почти в каждом пункте подчеркивается важность поддержки. ПОЛНОЙ поддержки. Так капслоком и написано, видно, что выстрадано.
Вот такие вот рекомендации. А что откликается вам?
Ваш @Reliable ML
#business #обзор_книги #cdo
Forwarded from Start Career in DS
▶️ Продолжение серии видео от 3Blue1Brown про нейронные сети!
Ранее мы уже писали про серию их постов, переведённую на русский язык, там были видео про работу нейронных сетей в целом, градиентный спуск и обратное распространение ошибки.
Ребята в комментариях дополнили, что у 3B1B на английском есть ещё 3 видео!
Дополняем свою подборку ими. Кроме того, у этих видео есть весьма качественный русский дубляж 🙂
[ENG + RUS] Transformers (how LLMs work) explained visually | DL5
Объясняет что происходит внутри трансформера в начале и в конце обучения. Показывает геометрическое представаление эмбеддинга слов в многомерном пространстве
[ENG + RUS] Attention in transformers, visually explained | DL6
Иллюстрация работы механизмов внимания на примере простого предложения. Показывает взаимодействие эмбеддингов слов в предложении между собой и разницу между self-attention и cross-attention
[ENG + RUS] How might LLMs store facts | DL7
Как устроены многослойные перцептроны. Понятная иллюстрация того, как модель сохраняет факты
Ждём ваших ❤️ и 🔥!
Ранее мы уже писали про серию их постов, переведённую на русский язык, там были видео про работу нейронных сетей в целом, градиентный спуск и обратное распространение ошибки.
Ребята в комментариях дополнили, что у 3B1B на английском есть ещё 3 видео!
Дополняем свою подборку ими. Кроме того, у этих видео есть весьма качественный русский дубляж 🙂
[ENG + RUS] Transformers (how LLMs work) explained visually | DL5
Объясняет что происходит внутри трансформера в начале и в конце обучения. Показывает геометрическое представаление эмбеддинга слов в многомерном пространстве
[ENG + RUS] Attention in transformers, visually explained | DL6
Иллюстрация работы механизмов внимания на примере простого предложения. Показывает взаимодействие эмбеддингов слов в предложении между собой и разницу между self-attention и cross-attention
[ENG + RUS] How might LLMs store facts | DL7
Как устроены многослойные перцептроны. Понятная иллюстрация того, как модель сохраняет факты
Ждём ваших ❤️ и 🔥!