Вообще у меня были идеи прикрутить к инструмент языковую модель, чтобы результаты анализа выглядели как отчет для человека. Идея очень логичная. Т.е. сочетание алгоритмической логики и первичная интерпретация этого через 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 - это плоские таблицы, на нем выстроена его концепция.
Тема анализа таблиц интересная, она пока не закрыта полностью. Поэтому я буду развивать эту библиотеку. Если есть желания поучаствовать - пишите.
Также интересна обратная связь, пишите комментарии по применению 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 - это плоские таблицы, на нем выстроена его концепция.