@wataru Про алгоритм. Если мы удаляем B. То у нас остается два столбца, A и C, они тоже один-к-одному (для один-к-одному выполняется правило: A=B, B=C => A=C). Т.е. когда-то мы пару А, С найдем и удалим один из них. Т.е. по мне алгоритм верный. И он делает меньше операций теоретически. Но вот написать сходу я его не могу в Python, не очевидный подход...
В целом да, согласен. Ваш алгоритм более оптимальный. Правда, сходу, я не могу представить как его на python реализовать, чтобы было коротко и понятно... Количество столбцов у таблице нечасто бывает более 300, поэтому оптимизацию я тут на второе место поставил. Граф использован, скорее, как удобная абстракция, которая скрывает от нас циклы.
Есть кстати одно место в моей библиотеки, где критически важно реализовать его супер оптимально, возможно даже на C++/C. Это поиск потенциальных ключей. Сейчас я это сделал как простой перебор комбинаций не более соответствующей длины (например, не более пяти). Но видимо, это не самый оптимальный алгоритм. Есть некоторые работы, но сложновато показалось (ссылка).
Мне ближе подход через графы, т.к. он более универсальный, решает целый комплекс задач. Ну а обходы мы же не вручную делаем, всё за нас делает networkx, а мы только пишем питоновский glue).
А как мы выглядел Unioin-find в python для данной задачке? я сходу не нашел в гугле
прочитал про max_weight_matching, видимо да, это прямой путь к решению задачи. Даже реберный граф не надо делать. И в networkx он есть. Я просто не знал этот алгоритм
Знали бы, что это NP-complete - отменили бы корпоратив))
Вообще у меня были идеи прикрутить к инструмент языковую модель, чтобы результаты анализа выглядели как отчет для человека. Идея очень логичная. Т.е. сочетание алгоритмической логики и первичная интерпретация этого через LLM может дать отличную начальную точку для анализа человеком.
Еще раз уточню, что мой инструмент фокусируется на одной большой сложной таблице (такие часто возникают в бизнес среде). Интересно, но такого инструмента я ни разу не видел (только FDtool). А вот анализ связанных таблиц (база данных, схемы данных) - думаю другая история.
Вообще это интересно, что решая обычные бизнес задачи мы часто оперируем терминами реляционных баз данных, сами того не подозревая. Т.е. базы данных - это важно. Одна из целей статьи - это как раз донести важность понимания основ баз данных и хранения информации.
SQL у меня на начальном уровне, в работе активно использую python и excel.
Вопрос: есть ли в реляционных базах данных инструменты, аналогичные тому, что я описываю в статье? Например, инструмент помогающий найти функциональные зависимости, которые явно не видны. Или например рекомендующие нормализацию таблиц. Подозреваю, что я не первый кто задается такими вопросами) Почти уверен, что есть нечто такое, но ни разу не встречал.
Потенциальным ключом может быть не только набор столбцов, но и включающее их выражение. Да, не каждое выражение может быть первичным ключом, есть ограничения... но кандидатом - запросто.
Определение потенциальных ключей я беру классическое, т.е. не привязанное к базам данных. Определение из википедии: "A candidate key, or simply a key, of a relational database is any set of columns that have a unique combination of values in each row, with the additional constraint that removing any column could produce duplicate combinations of values. ". Т.е. в части прикладных инструментов (реляционных БД) вы, думаю, правы. Но классика все-таки предполагает, что ключи - это подмножества столбцов. В моей практике классика удобнее. Если бы я работа много с SQL думаю статья была бы совершенно о другом :)
Пардон, а какое отношение это имеет к понятию "Архитектура плоской таблицы"? То, что вы описываете - это внешние ключи, связи между таблицами, понятие уровня схемы данных... да элементарно требует минимум двух таблиц (даже в случае self-reference, когда это две копии одной таблицы).
Термин "архитектура плоской таблице" не официальный. Т.е. эталонного определения, насколько я знаю, нет. В статье я описываю случай именно одной таблицы. Это связано со спецификой данных, с которыми я работаю. Обычно в фокусе одна таблица. Часто сильно денормализованная и сложная.
Внешние ключи, схемы данных - это другая область. Я это не рассматривал. Опять же, потому, редко встречаю именно базы данных (нормализованные взаимосвязанные таблицы). Чаще - отдельные сложные таблицы.
кросс энкодер помогает только на шаге 4. Остальное - классический RAG пайплайн, о нем много пишут на хабре, можно посмотреть. Причем в БД может быть много кусков, поэтому сначала надо использовать быстрый би-энкодер. А потом уже когда кусков мало, можно использовать точный и медленный кросс энкодер.
Отлично, я как раз хотел показать, что нейросети стали ближе к нам, к бизнес задачам
Все слои были в torch.float32. Т.к. сеть маленькая (130 млн. весов), то с этим не заморачивался. Насколько я знаю перевести сеть на torch.float16 не так, чтобы совсем просто... обычно эти вопросы возникают с LLM
Загруженная на gpu модель и состояние оптимайзера занимал 2.7 Гб на первом gpu. Предполагаю, что это не только веса, но и статистика оптимайзера.
При обучении всей модели kaggle показывал что первый gpu загружен на 11-12 Гб. Тут играет роль размер батча - 8. Мы одновременно обрабатываем 8 примеров за раз на gpu. Больший размер батча приводил к Out of memory (если бы можно было, я бы поставил больше). Т.е. сам по себе кол-во обучающих данных роли не играет.
Второй gpu всегда был пустой, т.к. разделение модели на 2 gpu требует определенных действий. Я пока не стал это делать. В целом размер батча (8 семплов) меня устраивал.
По поводу файнтюна LLM сложные вопросы. LLM обычно огромные. В labse 130 млн. весов, в приличной LLM 7 млрд. весов (mistral, openchat). Файнтюнить надо будет через PEFT с квантованием или еще как то. Область интересная, но сложная. Мне понравилась вот эта статья Ильи Гусева и код обучения.
По своей сути Power Query тоже плоский инструмент, оптимизирован для плоских таблиц (даже с учетом языка М внутри), думаю VBA как раз более гибкая штука тут. Например, если надо перевести иерархию из формата 1 в формат 6. Я думаю Query для этой задачи не очень оптимален. Тут нужен алгоритм, а это сразу ЯП - vba или python.Или например, задача на проверку режим сортировки иерархии. Тут я бы сразу python открыл, алгоритм достаточно нетривиальный будет)
«Формат 6. Путь к листу (только листы)» - самый удобный в плане анализа сводными таблицами. Но у нас обычно в таблице основной Формат 1 + по необходимости переводим в Формат 2 (для обработки сводными таблицами). Формат 1 нужен для визуального представления
Соглашусь, иерархии - это проблема, т.к. плоский мир (excel, pandas) с ними плохо работает. Интересно, что графы не доставляют столько проблем в Excel))) там мы сразу честно понимаем, что хранить надо в техническом формате (напр., список ребер и вершин), а обрабатывать с помощью vba или python (DFS, BFS). В случае иерархий по другому получается, она очень часто используется в бизнесе и люди сразу хотят видеть ее визуально, ну и плюс vba, python не каждый знает. При обработке/проверке иерархий мы часто используем python, vba. Это помогает. Иного способа не знаю)
В Excel нет инструментов, которые бы облегчали работу с иерархиями (группировка строк - скорее визуальный инструмент, скрыть строки). Ну может быть это и норм, т.к. по сути Excel - это плоские таблицы, на нем выстроена его концепция.
@wataru
Про алгоритм. Если мы удаляем B. То у нас остается два столбца, A и C, они тоже один-к-одному (для один-к-одному выполняется правило: A=B, B=C => A=C). Т.е. когда-то мы пару А, С найдем и удалим один из них. Т.е. по мне алгоритм верный. И он делает меньше операций теоретически. Но вот написать сходу я его не могу в Python, не очевидный подход...
В целом да, согласен. Ваш алгоритм более оптимальный. Правда, сходу, я не могу представить как его на python реализовать, чтобы было коротко и понятно...
Количество столбцов у таблице нечасто бывает более 300, поэтому оптимизацию я тут на второе место поставил. Граф использован, скорее, как удобная абстракция, которая скрывает от нас циклы.
Есть кстати одно место в моей библиотеки, где критически важно реализовать его супер оптимально, возможно даже на C++/C. Это поиск потенциальных ключей. Сейчас я это сделал как простой перебор комбинаций не более соответствующей длины (например, не более пяти). Но видимо, это не самый оптимальный алгоритм. Есть некоторые работы, но сложновато показалось (ссылка).
Мне ближе подход через графы, т.к. он более универсальный, решает целый комплекс задач. Ну а обходы мы же не вручную делаем, всё за нас делает networkx, а мы только пишем питоновский glue).
А как мы выглядел Unioin-find в python для данной задачке? я сходу не нашел в гугле
Спасибо за комментарий!
прочитал про max_weight_matching, видимо да, это прямой путь к решению задачи. Даже реберный граф не надо делать. И в networkx он есть. Я просто не знал этот алгоритм
Знали бы, что это NP-complete - отменили бы корпоратив))
Тема анализа таблиц интересная, она пока не закрыта полностью. Поэтому я буду развивать эту библиотеку. Если есть желания поучаствовать - пишите.
Также интересна обратная связь, пишите комментарии по применению FlatTableAnalysis или просто мысли по анализу плоской таблицы.
Вообще у меня были идеи прикрутить к инструмент языковую модель, чтобы результаты анализа выглядели как отчет для человека. Идея очень логичная. Т.е. сочетание алгоритмической логики и первичная интерпретация этого через LLM может дать отличную начальную точку для анализа человеком.
Еще раз уточню, что мой инструмент фокусируется на одной большой сложной таблице (такие часто возникают в бизнес среде). Интересно, но такого инструмента я ни разу не видел (только FDtool).
А вот анализ связанных таблиц (база данных, схемы данных) - думаю другая история.
Вообще это интересно, что решая обычные бизнес задачи мы часто оперируем терминами реляционных баз данных, сами того не подозревая. Т.е. базы данных - это важно. Одна из целей статьи - это как раз донести важность понимания основ баз данных и хранения информации.
SQL у меня на начальном уровне, в работе активно использую python и excel.
Вопрос: есть ли в реляционных базах данных инструменты, аналогичные тому, что я описываю в статье? Например, инструмент помогающий найти функциональные зависимости, которые явно не видны. Или например рекомендующие нормализацию таблиц.
Подозреваю, что я не первый кто задается такими вопросами) Почти уверен, что есть нечто такое, но ни разу не встречал.
Определение потенциальных ключей я беру классическое, т.е. не привязанное к базам данных. Определение из википедии: "A candidate key, or simply a key, of a relational database is any set of columns that have a unique combination of values in each row, with the additional constraint that removing any column could produce duplicate combinations of values. ".
Т.е. в части прикладных инструментов (реляционных БД) вы, думаю, правы. Но классика все-таки предполагает, что ключи - это подмножества столбцов. В моей практике классика удобнее. Если бы я работа много с SQL думаю статья была бы совершенно о другом :)
Термин "архитектура плоской таблице" не официальный. Т.е. эталонного определения, насколько я знаю, нет. В статье я описываю случай именно одной таблицы. Это связано со спецификой данных, с которыми я работаю. Обычно в фокусе одна таблица. Часто сильно денормализованная и сложная.
Внешние ключи, схемы данных - это другая область. Я это не рассматривал. Опять же, потому, редко встречаю именно базы данных (нормализованные взаимосвязанные таблицы). Чаще - отдельные сложные таблицы.
кросс энкодер помогает только на шаге 4. Остальное - классический RAG пайплайн, о нем много пишут на хабре, можно посмотреть.
Причем в БД может быть много кусков, поэтому сначала надо использовать быстрый би-энкодер. А потом уже когда кусков мало, можно использовать точный и медленный кросс энкодер.
е5 вроде как один из лучших сейчас (ссылка), хотя я обычно использую его мультиязычную версию (intfloat/e5-large-v2)
еще можно смотреть рейтинг на huggingface (ссылка)
Отлично, я как раз хотел показать, что нейросети стали ближе к нам, к бизнес задачам
Все слои были в torch.float32. Т.к. сеть маленькая (130 млн. весов), то с этим не заморачивался. Насколько я знаю перевести сеть на torch.float16 не так, чтобы совсем просто... обычно эти вопросы возникают с LLM
Загруженная на gpu модель и состояние оптимайзера занимал 2.7 Гб на первом gpu. Предполагаю, что это не только веса, но и статистика оптимайзера.
При обучении всей модели kaggle показывал что первый gpu загружен на 11-12 Гб. Тут играет роль размер батча - 8. Мы одновременно обрабатываем 8 примеров за раз на gpu. Больший размер батча приводил к Out of memory (если бы можно было, я бы поставил больше). Т.е. сам по себе кол-во обучающих данных роли не играет.
Второй gpu всегда был пустой, т.к. разделение модели на 2 gpu требует определенных действий. Я пока не стал это делать. В целом размер батча (8 семплов) меня устраивал.
По поводу файнтюна LLM сложные вопросы. LLM обычно огромные. В labse 130 млн. весов, в приличной LLM 7 млрд. весов (mistral, openchat). Файнтюнить надо будет через PEFT с квантованием или еще как то. Область интересная, но сложная. Мне понравилась вот эта статья Ильи Гусева и код обучения.
а зачем в проекте по сжатию используется "парафразер"?
С первого взгляда мы помещаем картинку на лист в Excel, RGB цветом делаем заливку. Но только не понял зачем нужны были rotate и flip картинки.
мы кстати используем обратную логику, рисуем эксель листы для обзорного анализа)
https://youtu.be/I55ZZqxxGEs
По своей сути Power Query тоже плоский инструмент, оптимизирован для плоских таблиц (даже с учетом языка М внутри), думаю VBA как раз более гибкая штука тут. Например, если надо перевести иерархию из формата 1 в формат 6. Я думаю Query для этой задачи не очень оптимален. Тут нужен алгоритм, а это сразу ЯП - vba или python.Или например, задача на проверку режим сортировки иерархии. Тут я бы сразу python открыл, алгоритм достаточно нетривиальный будет)
комментарий удален
pivot = сводная таблица, да
«Формат 6. Путь к листу (только листы)» - самый удобный в плане анализа сводными таблицами. Но у нас обычно в таблице основной Формат 1 + по необходимости переводим в Формат 2 (для обработки сводными таблицами). Формат 1 нужен для визуального представления
Соглашусь, иерархии - это проблема, т.к. плоский мир (excel, pandas) с ними плохо работает. Интересно, что графы не доставляют столько проблем в Excel))) там мы сразу честно понимаем, что хранить надо в техническом формате (напр., список ребер и вершин), а обрабатывать с помощью vba или python (DFS, BFS). В случае иерархий по другому получается, она очень часто используется в бизнесе и люди сразу хотят видеть ее визуально, ну и плюс vba, python не каждый знает.
При обработке/проверке иерархий мы часто используем python, vba. Это помогает. Иного способа не знаю)
В Excel нет инструментов, которые бы облегчали работу с иерархиями (группировка строк - скорее визуальный инструмент, скрыть строки). Ну может быть это и норм, т.к. по сути Excel - это плоские таблицы, на нем выстроена его концепция.