Смешались логические предпосылки диктуемые предметной областью — узлы (может быть 1), и технические — архитектура узла. И да, ансамбль лишь вариант архитектуры узла.
А в остальном всё верно 0.95³ = 0.86, но что это нам дает без данных точности монолитной модели и реальных данных каждого из узла цепочки? Может там 0.95*0.98*0.99 против 0.9? Причем это только для одного из классов первого и второго узла. А полная оценка, какой-то из агрегатов оценок, по количеству моделей третьего узла.
Провалившись в одной цепочке, можно выиграть в другой. Что важнее? А если цепочек 50? И что важнее перепутать лежащего кота с собакой, или с кучей мусора?
Ну и еще один минус морфтаггеров, возможно более важный — это еще одна предметная область. Их цель все слова, без упора на морфологическую омографию. Принципы похожи, но нюансы переворачивают всё.
В прошлом посте описывал один свой старый экперимент... стер. Цель, с помощью PyMorphy (единственный источник знаний), найти существительные с разным написанием ед.рд/мн.им и перенести эти знания на соответствующий тип омографа (скалы, горы, реки итд). Понимая множество упрощений и допущений, результат довольно ошеломительный и точно перспективный.
Может именно поэтому, так настойчиво предлагаю рассмотреть морфологические омографы как отдельную предметную область. При вашем-то опыте и целеполагании... ну а нет, так нет.
Немного другое имел ввиду. Смысловые и морфологические омографы, это две разные предметные области, а не одна, собственно омографы. Уж очень сильно они отличаются. Если их разделить, подобранные для каждой архитектуры сеток/датасетов, покажут себя намного лучше, чем если попытку разобрать эти различия возложить на одну. Причем легче по ресурсам.
А так регистр и позиция … это как раз (барабанная дробь) же регулярка!
Еще бы завести понятие сессии. Имя — книгоспецифичное явление. Но это действительно, пусть пользователь решает другими средствами.
Тема настолько же объемная, как ремонт. Можно только остановить, а не закончить. Надеюсь лишь, что языковые модели когда-то дойдут до реального, а не вероятностного понимания смысла текста. Как минимум, до уровня приемлемого для подготовки датасета.
Появилось ли у вас разделение подходов разрешения по типу омографа? Морфологические — меняется форма, а не смысл, — отлично перенимают свойства у синонимов и даже просто сопоставимых по склонению слов. Важны морфологические формы контекста. Можно обойтись без разметки. Смысловые — меняется как форма, так и смысл, — скорее важен сам контекст. Вплоть до раздельного обучения. Собственные — О́дин, Ангара́, Ма́ша, Ва́ля — достаточно позиции в предложения и регистра, вместо исключения из списка омографов.
Также удивило первое же слово из технического списка тем, что люди путаются. 1. ед, населенный пункт: выехал из села́; 2. мн, населенный пункт: города и сёла; 3 жр, действие: се́ла в машину. Вначале прогон по смыслу, потом по форме.
Когнитивные возможности мозга ограничены. Кошелек Миллера и прочее. У std::string 14 конструкторов и 119 методов. Из которых 10 версий split и 15 trim. При этом strip_suffix решается через trip_suffix и ends_with.
Где-то выиграли, где-то проиграли. Хотели как лучше, чтобы на каждую задачу по точному методу, получили как всегда, они потерялись. Слишком хорошо, много синтаксического сахара, тоже не хорошо.
Ну да. То или иное слово, но накосячит. Тут главное разделять "анализатор" и "архиватор", и не превратить одно в другое. Без словаря все-равно не обойтись. Если словарь плюс более худая модель весит меньше, чем меньший словарь с более толстой моделью, то зачем ее утолщать?
в английском этого в принципе на малых моделях сложно достичь.
На малой модели невозможно, на малых моделях — спорно. Ансамбль из одного худого классификатора "кластера" и 4 худых g2p, выдал заметно лучшее качество, чем у одной толстой модели сопоставимого размера. Причем провал в основном из-за последнего "кластера" — разное. То есть, вангую, рост количества худых, еще некоторое время давал бы линейный прирост качества. А для оптимизации, возникало подозрение, что энкодер g2p можно было сделать общим. Но исследовательский зуд утих и тема удалена в мусорку.
Фонетика английского действительно любопытна. Даже если не брать исключения и имена собственные. Недавно в исследовательских целях смотрел на CMUdict. Минималистичная, пара десятков килобайт g2p моделька, влёт изучала половину корпуса. Стало интересно, что да, а что нет. Заметил, что в заимствованных словах — из итальянского, латыни, русского (!), других языков, которые из-за незнания опознать не смог — кроме написания, почти прямо заимствуется и произношение. То есть другие правила фонемизации. Это невозможно понять, можно только запомнить (анекдот про тарельку и фасол). После наивной кластеризации и их обучении по отдельности, качество каждой подмодели резко выросло.
Вы кажется не поняли смысл моего поста. Он не про вайб, а как раз наоборот. Есть проект/модуль или нечто высокого уровня, написанный на каком-то из языков программирования — C/C++, Java, Python. Работающий, функциональный, (достаточно) качественный. Это идеальный промт. Перепиши, например, на Rust.
Можно ли осознать и впитать нюансы верхнего уровня, не проведя кучу часов на нижнем?
Вы смотрите с позиции того, кто этот нижний уровень исходил вдоль и поперек. Тогда можно свалить на LLM. Но, кмк, невозможно развиваться в архитектуре, изначально сваливая написание.
Недавно иначе взглянул на тезис "Достаточно подробная спецификация — это код". Не как повод похоливарить, а представить код работающего проекта, в качестве этой спецификации. Вместо ее описания на естественном языке. Куда уж подробнее.
Сетка должна уметь написать код на целевом языке, с учетом его практик и концепций. Показать свой действительный уровень. И это не просто показатель уровня, а полезность в рефакторинге и переносе прототипов в другую среду.
Все такие статьи структурно однобоки. Берут проблемные места других языков и показывают как их сделать хорошо. Это хорошо. Но не может быть, что в других языках нет хороших мест, которые альтернативой реализуются проблемно. А вот об этом ни слова. Либо читать другую однобокую статью, "хейт".
Возьмем классическое "беспроблемное" наследование много-от-одного. Структура на 5 полей, реализация на 15 методов. В одном наследнике переопределяется метод 7, в другом 7 и 9, в третьем 8, 9 и добавляется 16 "служебный". Какой-то из них может добавить поле в состояние. Другой может стать предком для еще одного наследника. Переопределение какого-то метода, лишь добавление всего одной операции до или после метода предка.
Как? Трейты? Еще трейты? Добавление нового класса в проект потребует переписать существующий код? А без переписывания? Я не знаю. Пока присматриваюсь, хоть уже и долго. Но нигде не встречал удобного решения вполне рядовых задач.
Вы не это предлагаете. Возможно я сам некорректно выразился. Явно вывести, это разделение на "в этом миграции", а вот "в этом запросы". Снижение связности, модульность, гибкость.
Можно резюмировать ваш подход: источник истины — схема описанная миграциями. Именно так, неразрывно. В этом его сила и... слабость. Например:
снимает необходимость с ваших джавистов, растовщиков и тд знать чего-либо про SQL
А если сам с усам? Не хочу каждый запрос отдавать в репозиторий администратора. Останется вне контроля? А если захочется? Клонировать репозиторий миграций, при наличии живой базы?
Буду думать надо разделением контроля. Получить поток данных без DBError и принять поток данных без TypeError. И всё на уровне не запроса, а запросОВ. Извлекаются нужные метаданные, устраняется дублирование, проверяются атомарные токены, при необходимости имеем аналог sourceMap для возврата от токенов к исходному коду запросов.
Ну да. Источник истины для схемы код миграций. Источник истины для запросов схема данных.
В целом все хорошо. Но код миграций надо вывести из-под приложения. Явно!!! Отдельная версионируемая сущность. Ничего не знающая про приложения. Но приложения могут знать про миграции. Мейнтейнером при этом может быть как "владелец" приложения, так и любой другой субъект. На суть это не влияет, только на организацию процесса.
В этом что-то есть. Спасибо за приведение моих размышлений в порядок.
У вас по сути гибридный подход. Миграции code-first, ведь sql это тоже код; запросы проверяются strorage-first. В случае "чужой" базы, при много приложений к одной базе, её структура вам доступна в режиме read only. Научимся удобно работать при таких ограничениях, будет удобно всегда. Но если концепция хоть частично содержит code-first, удобно не будет.
Вспомнил свой давний эксперимент времен Дельфи. В самой базе хранил repr_rus и description полей. И что-то при новом взгляде, в этом есть.
Мы сейчас говорим фактически о метаданных. Данных (DML) описания данных (schema). Которые могут "расползтись". Но база данных, в том числе инструмент обеспечения ссылочной целостности данных. В том числе ссылочной целостности с схемой, хранящейся в служебных таблицах.
Так какая часть у запросов может разойтись со схемой? И почему бы ее не хранить в "уголке" этой схемы? Источник истины не [только] база, но и данные под ее ссылочным контролем.
Вы кажется сейчас совместили приложение у пользователя и приложение у разработчика.
Что произойдет у пользователя, в случае расхождения со схемой, причем расхождения такого, которое можно поймать типобезопасностью/программно? Приложение упадет. Так или иначе. При старте или в процессе, выбор неоднозначный. Возможно текущая сессия не затронет измененный участок развесистой схемы. Тогда пусть работает?
А у разработчика... это не столько фича, сколько, кмк, смещение источника истины. Много-к-одному должно решаться иначе, концептуально, либо начнутся костыли натягивания одного на другое.
И еще, считаю один-к частным случаем много-к. Если научиться хорошо и удобно работать с "чужой" схемой, расширить дополнительными плюшками при "владении" своей намного проще.
Понятно. Однако связь проект-хранилище один-к-одному хоть и распространена, но далеко не единственная. Актуальна периодическая проверка корректности интеграции, по событию или расписанию. Либо, как уже упоминали, отдельный абстрагированный от языка слой в роли истины. Либо, все (?) базы внутри себя уже хранят этот, примененный к ним истинный DDL. Чем не источник?
Это не в критику вашего проекта, а лишь определение областей применения.
Все узкие места вроде известны. Но почему нет для них шаблонных решений, либо их недостаточно популяризуют. Нужна графовая структура? Берешь библиотеку, описываешь узлы и связи, цепляешь полезную нагрузку — пользуешься. Привык к определенным паттернам наследования, переопределить пару методов из пачки, добавить пару возможностей включая небольшое расширение внутреннего состояния? Смотришь best practice и делаешь удобно в концепциях языка. Раз сделал, два сделал, посоветовал коллеге, вот и нету слабых мест. Остались только сильные.
Смешались логические предпосылки диктуемые предметной областью — узлы (может быть 1), и технические — архитектура узла. И да, ансамбль лишь вариант архитектуры узла.
А в остальном всё верно 0.95³ = 0.86, но что это нам дает без данных точности монолитной модели и реальных данных каждого из узла цепочки? Может там 0.95*0.98*0.99 против 0.9? Причем это только для одного из классов первого и второго узла. А полная оценка, какой-то из агрегатов оценок, по количеству моделей третьего узла.
Провалившись в одной цепочке, можно выиграть в другой. Что важнее? А если цепочек 50? И что важнее перепутать лежащего кота с собакой, или с кучей мусора?
Ну и еще один минус морфтаггеров, возможно более важный — это еще одна предметная область. Их цель все слова, без упора на морфологическую омографию. Принципы похожи, но нюансы переворачивают всё.
В прошлом посте описывал один свой старый экперимент... стер. Цель, с помощью PyMorphy (единственный источник знаний), найти существительные с разным написанием ед.рд/мн.им и перенести эти знания на соответствующий тип омографа (скалы, горы, реки итд). Понимая множество упрощений и допущений, результат довольно ошеломительный и точно перспективный.
Может именно поэтому, так настойчиво предлагаю рассмотреть морфологические омографы как отдельную предметную область. При вашем-то опыте и целеполагании... ну а нет, так нет.
Немного другое имел ввиду. Смысловые и морфологические омографы, это две разные предметные области, а не одна, собственно омографы. Уж очень сильно они отличаются. Если их разделить, подобранные для каждой архитектуры сеток/датасетов, покажут себя намного лучше, чем если попытку разобрать эти различия возложить на одну. Причем легче по ресурсам.
Еще бы завести понятие сессии. Имя — книгоспецифичное явление. Но это действительно, пусть пользователь решает другими средствами.
Тема настолько же объемная, как ремонт. Можно только остановить, а не закончить. Надеюсь лишь, что языковые модели когда-то дойдут до реального, а не вероятностного понимания смысла текста. Как минимум, до уровня приемлемого для подготовки датасета.
Появилось ли у вас разделение подходов разрешения по типу омографа? Морфологические — меняется форма, а не смысл, — отлично перенимают свойства у синонимов и даже просто сопоставимых по склонению слов. Важны морфологические формы контекста. Можно обойтись без разметки. Смысловые — меняется как форма, так и смысл, — скорее важен сам контекст. Вплоть до раздельного обучения. Собственные — О́дин, Ангара́, Ма́ша, Ва́ля — достаточно позиции в предложения и регистра, вместо исключения из списка омографов.
Также удивило первое же слово из технического списка тем, что люди путаются. 1. ед, населенный пункт: выехал из села́; 2. мн, населенный пункт: города и сёла; 3 жр, действие: се́ла в машину. Вначале прогон по смыслу, потом по форме.
Когнитивные возможности мозга ограничены. Кошелек Миллера и прочее. У std::string 14 конструкторов и 119 методов. Из которых 10 версий split и 15 trim. При этом strip_suffix решается через trip_suffix и ends_with.
Где-то выиграли, где-то проиграли. Хотели как лучше, чтобы на каждую задачу по точному методу, получили как всегда, они потерялись. Слишком хорошо, много синтаксического сахара, тоже не хорошо.
Ну да. То или иное слово, но накосячит. Тут главное разделять "анализатор" и "архиватор", и не превратить одно в другое. Без словаря все-равно не обойтись. Если словарь плюс более худая модель весит меньше, чем меньший словарь с более толстой моделью, то зачем ее утолщать?
На малой модели невозможно, на малых моделях — спорно. Ансамбль из одного худого классификатора "кластера" и 4 худых g2p, выдал заметно лучшее качество, чем у одной толстой модели сопоставимого размера. Причем провал в основном из-за последнего "кластера" — разное. То есть, вангую, рост количества худых, еще некоторое время давал бы линейный прирост качества. А для оптимизации, возникало подозрение, что энкодер g2p можно было сделать общим. Но исследовательский зуд утих и тема удалена в мусорку.
Фонетика английского действительно любопытна. Даже если не брать исключения и имена собственные. Недавно в исследовательских целях смотрел на CMUdict. Минималистичная, пара десятков килобайт g2p моделька, влёт изучала половину корпуса. Стало интересно, что да, а что нет. Заметил, что в заимствованных словах — из итальянского, латыни, русского (!), других языков, которые из-за незнания опознать не смог — кроме написания, почти прямо заимствуется и произношение. То есть другие правила фонемизации. Это невозможно понять, можно только запомнить (анекдот про тарельку и фасол). После наивной кластеризации и их обучении по отдельности, качество каждой подмодели резко выросло.
Вы кажется не поняли смысл моего поста. Он не про вайб, а как раз наоборот. Есть проект/модуль или нечто высокого уровня, написанный на каком-то из языков программирования — C/C++, Java, Python. Работающий, функциональный, (достаточно) качественный. Это идеальный промт. Перепиши, например, на Rust.
Можно ли осознать и впитать нюансы верхнего уровня, не проведя кучу часов на нижнем?
Вы смотрите с позиции того, кто этот нижний уровень исходил вдоль и поперек. Тогда можно свалить на LLM. Но, кмк, невозможно развиваться в архитектуре, изначально сваливая написание.
Недавно иначе взглянул на тезис "Достаточно подробная спецификация — это код". Не как повод похоливарить, а представить код работающего проекта, в качестве этой спецификации. Вместо ее описания на естественном языке. Куда уж подробнее.
Сетка должна уметь написать код на целевом языке, с учетом его практик и концепций. Показать свой действительный уровень. И это не просто показатель уровня, а полезность в рефакторинге и переносе прототипов в другую среду.
Все такие статьи структурно однобоки. Берут проблемные места других языков и показывают как их сделать хорошо. Это хорошо. Но не может быть, что в других языках нет хороших мест, которые альтернативой реализуются проблемно. А вот об этом ни слова. Либо читать другую однобокую статью, "хейт".
Возьмем классическое "беспроблемное" наследование много-от-одного. Структура на 5 полей, реализация на 15 методов. В одном наследнике переопределяется метод 7, в другом 7 и 9, в третьем 8, 9 и добавляется 16 "служебный". Какой-то из них может добавить поле в состояние. Другой может стать предком для еще одного наследника. Переопределение какого-то метода, лишь добавление всего одной операции до или после метода предка.
Как? Трейты? Еще трейты? Добавление нового класса в проект потребует переписать существующий код? А без переписывания? Я не знаю. Пока присматриваюсь, хоть уже и долго. Но нигде не встречал удобного решения вполне рядовых задач.
Вы не это предлагаете. Возможно я сам некорректно выразился. Явно вывести, это разделение на "в этом миграции", а вот "в этом запросы". Снижение связности, модульность, гибкость.
Можно резюмировать ваш подход: источник истины — схема описанная миграциями. Именно так, неразрывно. В этом его сила и... слабость. Например:
А если сам с усам? Не хочу каждый запрос отдавать в репозиторий администратора. Останется вне контроля? А если захочется? Клонировать репозиторий миграций, при наличии живой базы?
Буду думать надо разделением контроля. Получить поток данных без DBError и принять поток данных без TypeError. И всё на уровне не запроса, а запросОВ. Извлекаются нужные метаданные, устраняется дублирование, проверяются атомарные токены, при необходимости имеем аналог sourceMap для возврата от токенов к исходному коду запросов.
Ну да. Источник истины для схемы код миграций. Источник истины для запросов схема данных.
В целом все хорошо. Но код миграций надо вывести из-под приложения. Явно!!! Отдельная версионируемая сущность. Ничего не знающая про приложения. Но приложения могут знать про миграции. Мейнтейнером при этом может быть как "владелец" приложения, так и любой другой субъект. На суть это не влияет, только на организацию процесса.
В этом что-то есть. Спасибо за приведение моих размышлений в порядок.
У вас по сути гибридный подход. Миграции code-first, ведь sql это тоже код; запросы проверяются strorage-first. В случае "чужой" базы, при много приложений к одной базе, её структура вам доступна в режиме read only. Научимся удобно работать при таких ограничениях, будет удобно всегда. Но если концепция хоть частично содержит code-first, удобно не будет.
Вспомнил свой давний эксперимент времен Дельфи. В самой базе хранил repr_rus и description полей. И что-то при новом взгляде, в этом есть.
Мы сейчас говорим фактически о метаданных. Данных (DML) описания данных (schema). Которые могут "расползтись". Но база данных, в том числе инструмент обеспечения ссылочной целостности данных. В том числе ссылочной целостности с схемой, хранящейся в служебных таблицах.
Так какая часть у запросов может разойтись со схемой? И почему бы ее не хранить в "уголке" этой схемы? Источник истины не [только] база, но и данные под ее ссылочным контролем.
Вы кажется сейчас совместили приложение у пользователя и приложение у разработчика.
Что произойдет у пользователя, в случае расхождения со схемой, причем расхождения такого, которое можно поймать типобезопасностью/программно? Приложение упадет. Так или иначе. При старте или в процессе, выбор неоднозначный. Возможно текущая сессия не затронет измененный участок развесистой схемы. Тогда пусть работает?
А у разработчика... это не столько фича, сколько, кмк, смещение источника истины. Много-к-одному должно решаться иначе, концептуально, либо начнутся костыли натягивания одного на другое.
И еще, считаю один-к частным случаем много-к. Если научиться хорошо и удобно работать с "чужой" схемой, расширить дополнительными плюшками при "владении" своей намного проще.
Понятно. Однако связь проект-хранилище один-к-одному хоть и распространена, но далеко не единственная. Актуальна периодическая проверка корректности интеграции, по событию или расписанию. Либо, как уже упоминали, отдельный абстрагированный от языка слой в роли истины. Либо, все (?) базы внутри себя уже хранят этот, примененный к ним истинный DDL. Чем не источник?
Это не в критику вашего проекта, а лишь определение областей применения.
Уточните пожалуйста, migrations это таки code-first или я недопонял? А если поправили базу через DDL? Или вообще ее схема/миграции вне нашего доступа?
Все узкие места вроде известны. Но почему нет для них шаблонных решений, либо их недостаточно популяризуют. Нужна графовая структура? Берешь библиотеку, описываешь узлы и связи, цепляешь полезную нагрузку — пользуешься. Привык к определенным паттернам наследования, переопределить пару методов из пачки, добавить пару возможностей включая небольшое расширение внутреннего состояния? Смотришь best practice и делаешь удобно в концепциях языка. Раз сделал, два сделал, посоветовал коллеге, вот и нету слабых мест. Остались только сильные.