🚀 Изучаем SQL индексы!

Индексы в базах данных — это структуры, которые помогают ускорить поиск и извлечение данных.

Вот основные типы индексов:
✓ B-Tree индексы: Наиболее распространённый тип индексов. Используется для диапазонного поиска и поддерживает сортировку данных. Работает по принципу сбалансированного дерева.
✓ Hash индексы: Используются для быстрого поиска по точному совпадению. Не поддерживают диапазонные запросы, но могут быть очень быстрыми для конкретных значений.
✓ GiST (Generalized Search Tree): Позволяет создавать индексы для сложных типов данных, таких как географические данные. Поддерживает множество операций поиска.
✓ GIN (Generalized Inverted Index): Эффективен для индексации массивов и полнотекстового поиска. Использует инвертированный индекс, что делает его подходящим для текстовых данных.
✓ Кластеризованные индексы: Определяют физический порядок хранения данных в таблице. То есть физически сортирует строки таблицы в соответствии с индексом. Обычно создаются на первичном ключе и позволяют значительно ускорить чтение данных.
✓ Некластеризованный индекс (Nonclustered): Создаются отдельно от основной таблицы и содержат указатели на строки данных. Позволяют создавать несколько индексов для одной таблицы.
✓ Составные индексы: Индексы, которые включают несколько колонок таблицы. Полезны для запросов, которые фильтруют данные по нескольким полям.


В этом посте собраны полезные статьи и видео на YouTube о SQL индексах, которые помогут вам разобраться в этой важной теме:

📌 Статья: Влияние индексов БД на производительность выборки данных
📌 Статья: Обслуживание индексов MS SQL Server: как, когда и, главное, зачем?
📌 YouTube: Что такое SQL ИНДЕКСЫ за 10 минут: Объяснение с примерами
📌 YouTube: ИНДЕКСЫ В БАЗАХ ДАННЫХ. СОБЕС В OZON.
📌 YouTube: Как устроен B-TREE индекс в базах данных
📌 YouTube: EXPLAIN в базах данных за 10 минут
📌 YouTube: Андрей Сальников — Индексы в PostgreSQL. Как понять, что создавать
📌 YouTube: Оптимизация запросов с помощью индексов
📌 Статья: 14 вопросов об индексах в SQL Server, которые вы стеснялись задать

#Индексы #btree #hashindex #index

Немного рефлексии

Как-то я был на тренинге про то, как нетворкаться на мероприятиях, если ты представитель компании, которая это мероприятие делает. Вел его, кстати, Алексей Обровец, душевнейший человек и недавний гость в нашем подкасте «Кода кода».

Так вот там в начале было упражнение. Надо суметь за минутку рассказать (имитируя представление) ответы на три вопроса:
1. Кто я?
2. Какова моя экспертиза?
3. Чем и кому я могу быть полезен?

Недавно мы это обсуждали и один товарищ сказал, что испытал экзистенциальный кризис при этих ответах. Давайте разбираться, что там такого и зачем нам на это отвечать.

Кто я?
Тут хочется вспомнить классическую историю Жени Кота про то, как он заблудился в Мексике и хотел спросить дорогу. Местный житель спросил у него: «Ты кто?», и Женя ответил: «Я менеджер и фронтенд-разработчик», на что вопрошающий ответил: «А я – Хуан».

Это я к чему? К тому, что отвечая на этот вопрос и имея в виду даже работу, и то можно запутаться. Например, я формально ведущий технический менеджер проектов, но еще я выполняю роль тимлида команды, и вижу пользу и в том, и другом аспекте. Поэтому я представляюсь как «разнорабочий» 🙂

А вот если взглянуть на себя более целостно, то можно понять еще больше всякого, например, что твоя идентичность и самооценка со временем стала неотделима от работы.

Какова моя экспертиза?
Очень важный вопрос. Он и для самооценки, как специалиста, важен, и для карьеры, работы, денег и всего прочего, что мы в айтишечке обсуждаем. Вы не представляете, как много я видел людей, которые не задавались этим вопросом (а может боялись задаваться) хоть иногда и просто плыли по течению. А потом, когда доплывали до точки, где надо менять работу (сокращают, или надо больше денег, или переезжают), то оказывается «ой-ой-ой, я в болоте засиделся и стагнировал годами, а рынок труда хочет совсем другого».

Чем и кому я могу быть полезен?
Ответ на этот вопрос поможет сформулировать понятную ценность от вас и вашей экспертизы. Это пригодится и для резюме, и чтобы понимать, где лучше принести пользу на работе, где навести всякие горизонтальные связи в компании, и просто что-то факультативное для себя придумать.

Например, про себя я знаю, что у меня хорошо получается работа с людьми, я умею и люблю заниматься общественно-полезной деятельностью. Поэтому я очень полезен нашим деврелам (чтобы выступать от имени компании и продвигать бренд), или другим коллегам-тимлидам (никогда не отказываю в том, чтобы обсудить тимлидские проблемы и способы их решения), и любым другим тимлидам, желающим ими стать, или желающим помочь своим тимлидам в компании (так 4 года назад и родился мой небольшой и ламповый консалтинг).

Итог
Призываю вас выделить 10-15-30 минут, чтобы подумать и сформулировать ответы на эти 3 вопроса. Искренне уверен, что это может вам пригодиться если не прямо сейчас, то в обозримом будущем.

🤯 Энтузиаст дропнул запрос, который помогает Claude 3.5 Sonnet превзойти OpenAI o1 в рассуждениях! Промпт запускает целую цепочку мыслей из 20-50 шагов перед тем, как выдать ответ.

В некоторых тестах такой подход позволил Claude 3.5 Sonnet достичь уровня GPT-4 и o1. Запрос будет работать не только в Claude, но и во многих других LLM, чтобы поднять их эффективность на максимум.

Сохраняйте, чтобы попробовать — тут.

_______
Источник | #notboring_tech
@F_S_C_P

Стань спонсором!

#llm #cv #gan

Почему модели генерации изображений не умели генерировать тексты?

Я всегда думал что это просто недостаточный обучающий сет, либо задача слишком сложная, либо разрешение латентов недостаточное. И у меня даже был план обучить SDXL на текстах и сгенерировать датасет для этого (картинка прилагается. Но там всё неправильно)

Оказалось что просто CLIP энкодер слабоват. Генерация изображений нормально работает только с хорошим энкодером текстов. Во ВСЕХ работах, где заменяли CLIP на T5 или на что-то подобное, тексты генерируются хорошо.

Причём, можно выбросить вообще оба CLIP энкодера из SDXL и оставить только один T5 и всё равно будет лучше типография.

Ключевая статья:
https://arxiv.org/html/2403.09622v1

Другие примеры помимо FLUX и SD3:
https://github.com/deep-floyd/IF
https://github.com/TencentQQGYLab/ELLA

#dl #audio

https://github.com/SWivid/F5-TTS

A Fairytaler that Fakes Fluent and Faithful Speech with Flow Matching

This paper introduces F5-TTS, a fully non-autoregressive text-to-speech system based on flow matching with Diffusion Transformer (DiT). Without requiring complex designs such as duration model, text encoder, and phoneme alignment, the text input is simply padded with filler tokens to the same length as input speech, and then the denoising is performed for speech generation, which was originally proved feasible by E2 TTS. However, the original design of E2 TTS makes it hard to follow due to its slow convergence and low robustness. To address these issues, we first model the input with ConvNeXt to refine the text representation, making it easy to align with the speech. We further propose an inference-time Sway Sampling strategy, which significantly improves our model’s performance and efficiency. This sampling strategy for flow step can be easily applied to existing flow matching based models without retraining. Our design allows faster training and achieves an inference RTF of 0.15, which is greatly improved compared to state-of-the-art diffusion-based TTS models. Trained on a public 100K hours multilingual dataset, our Fairytaler Fakes Fluent and Faithful speech with Flow matching (F5-TTS) exhibits highly natural and expressive zero-shot ability, seamless code-switching capability, and speed control efficiency. Demo samples can be found at https://SWivid.github.io/F5-TTS. We will release all code and checkpoints to promote community development.

#prompt

https://education.yandex.ru/handbook/prompting

DuoAttention: Efficient Long-Context LLM Inference with Retrieval and Streaming Heads

В конце апреля разбирал статью про Retrieval Heads (пост является пререквизитом для понимания этого) — механизм в LLM, который позволяет модели находить и копировать нужные факты из части промпта. Если вы даёте на вход 10 страниц текста и задаёте вопрос — Retrieval Heads обратят внимание на потенциальные место ответа и «вытащат» его. Когда Retrieval Heads лажают, появляется контекстуальная галлюцинация.

Однако чем длиннее контекст, тем дольше работает модель — ведь нужно сделать больше вычислений, и, что не менее важно, хранить больше данных в памяти (обо всех прошлых страницах). Такое называется KV cache.

Фреймворк DuoAttention предлагает следующее:
1) генерируем набор синтетических данных, в которых точно требуется «вспоминать» контекст (в промпт вставляют части «запомни это: <длинное предложение>», а в коцне просят написать все такие части)
2) прогоняем его через модель и сохраняем выходные значения (последние эмбеддинги)
3) дальше тренируем модель-маску, которая описывает зануление/занижение оценок каждой головы (которая может быть Retrieval Heads). Тренировка производится с L1 регуляризацией, чтобы проредить маску. Идея такая, что если мы зануляем Retrieval Head, то это существенно ломает предсказания модели на задаче «вспоминания» частей промпта, а если что-то другое — то влияние минимально
4) после обучения на ~2000 шагов (несколько часов, в зависимости от модели и GPU) остаётся финальная маска влияния на возможность модели свпоминать. В ней значения бинаризуются (на 1 и 0) через сравнение с некоторой константой, подбираемой по перцентилю
5) этот процесс нужно повторять самому для каждой модели один раз перед запуском

Всё! Теперь маску можно применять: значения Retrieval Head сохраняются для всех слов, а остальная информация отбрасывается, если находится дальше, чем K токенов от текущего места. Например, если вы обрабатываете 50'000 токенов, то держите на готове последние, скажем, 1024 токена (и весь KV cache для них), и значения Retrieval Head для всех остальных 49k. Если модели нужно обратиться к данным из начала промта — у нас для этого сохранена лишь часть данных, которая, как показывают эксперименты, достаточна для того, чтобы вспомнить их.

На экспериментах с длинным контекстом показывают, что если брать половину всех Heads (то есть подбирать такой порог, чтобы ровно половина отсекалась), то:
— на одну карту с 80GB для 8B модели теперь влазит 3.3M токенов контекста (если делать квантизацию кэша; без DuoAttention 1.8M, без квантизации всего 0.52M)
— потребление памяти меньше в 1.67-2.55 раз — потому что надо меньше хранить в памяти, мы часть выкидываем
— задержка генерации меньше в 1.5-2.18 раз — потому что нужно меньше считать

Очень хороший пример как методы интерпретации (обнаружение Retrieval Heads) позволяют улучшать практические кейсы с использованием моделей.

#featureselection #chan

Я напомню про вот эту классную лекцию по отбору признаков и оценке их важности. Эрни тут даёт неправильное определение bias & variance (нет, это не in-sample vs out-of-sample ошибки, но я понимаю его идею).
Что же касается важности, они действительно для одной и той же модели значительно меняется при разных случайных сидах ) Так что имейте в виду и усредняйте оценки.

https://www.youtube.com/watch?v=2-5HYJ0HhyQ