Не припомню в своей практике случая, чтобы даже самая блестящая идея от одиночки преодолела инерцию корпоративного катка, если уж корпорация (неважно, гос или не-гос) решила потратить деньги неоптимальным способом. Скорее такого одиночку наймут потушить пожар на таком проекте за мизерную часть бюджета, когда дело дойдёт до закрытия.
Тем интереснее будет, например, следить за развитием событий, когда объявится чел с решением проблемы AGI, из-за которого возврат многомиллиардных инвестиций в трансформеры (LLM) окажется пшиком. В этом отношении готов согласиться с Яном ЛеКуном, что трансфомеры проблему AGI не решат...
Поскольку дело было на IBM system/z, приложение крутилось годами 24/7 и обменивалось данными с зоопарком других систем, при кажущейся нудности процессов они обеспечивали страховку от случайных сбоев. Перед тем, как поменять одну команду в коде на ассемблере, нужно было: 1) несколько раз собраться со спецами смежных систем, чтобы они подтвердили, что на их стороне ничего не поломается - это основная статья расходов проекта; 2) среди нескольких сот К строк найти ту, которую следует поменять, хотя можно было и посидеть несколько месяцев над сооружением заплаты...
По этому поводу вспомнился относительно недавний случай. Отвечал за направление мастер-данных в полномасштабном проекте миграции с 1С на SAP (не РФ) на производственном предприятии с ~15К сотрудников. На этапе промстарта загрузили данные, десятки сотрудников начали работать. Потом догружали дельты. Коллега из смежного направления зачем-то потрогал ключевые настройки промсистемы (поменял нумерацию объектов данных с внешней на внутреннюю, затем вернул). В этот момент сотрудник моей команды, который отвечал за загрузку дельты, прогрузил очередной пакет данных. Всё это выяснилось позже, когда пользователи начали создавать тикеты на поломанные данные. В промсистеме возникла неконсистентность данных, которая штатными инструментами не лечилась. Стандартное решение - откат на бэкап недельной давности с потерей данных пользователей. Пришлось пару недель почесать репу, полазить по САП нотам и рискнуть напрямую поправить таблицы, хотя все доступные САП профи ушли в отказ из-за риска упустить что-то, от чего промсистема будет падать в дамп в произвольные моменты. Но обошлось... Риск был контролируемый, т.к. случае поломки всё равно пришлось бы идти по пути через бэкап.
Ничего б этого не было, если бы в проекте работали процессы по образцу IBM.
Напомнило опус "настоящие программисты не пишут на фортране", ходивший по ВЦ в 80х... :)
Судя по комментам, профи, которым по службе положено определять "хорошесть" (РП, кадровики и др.), такие статьи игнорят...
Попробую немного восполнить этот пробел с точки зрения своего опыта в ИТ (40+).
"Программисты" не в вакууме существуют, "хорошими" или не очень они могут быть либо для себя, либо для нанимателя.
Если наниматель - компания с выстроенными процессами, программист хорош, если 1) он прошёл сито отбора и нанят; 2) метрики процессов, в которых он участвует, остаются в пределах установленных лимитов. На уровне команды "хорошесть" определяет тимлид, на уровне проекта - РП, на уровне структурного подразделения - менеджер по персоналу.
Хотя встречались и организации, для которых "хороший программист" - значит "может всё связанное с компьютерами" - от разработки и поддержки софта до мелкого ремонта и замены тонера в картридже.
А для себя можно быть хорошим, если делаешь что-то, чем можно гордиться, до чего другие не дотумкали например...
Вспомнился по поводу куръёзный случай, когда IBM завела внутренний проект на несколько десятков $К и несколько месяцев, и удалось закрыть все требования за месяц изменением одной команды в коде на ассемблере в бизнес-критичном приложении размером несколько сот К строк...
Забегая немного вперёд, можно сказать, что эксперименты автора дают надежду на получение положительного ответа на этот вопрос, однако детали заслуживают отдельной статьи, поэтому выходят за рамки данной публикации.
На данном этапе, полагаю, достаточно. Из всех доступных мне на текущий момент локальных моделей более-менее адекватно только qwen3-instruct ответил на поставленные вопросы.
если речь про ультра, то вряд ли. А так на hf.co есть hf.co/ai-sage/GigaChat3-10B-A1.8B-GGUF от Q6 до BF16, Q6_K вполне запускается на 12Гб RTX3060. Только на вопросы типа "кто ты?", "который сейчас час?" отвечает ерунду, на некоторых простых вопросах подвисает намертво. Но кое-какую пользу из неё извлечь можно, подробности здесь - https://habr.com/ru/articles/989576/
похоже на страшилку... у нас в РБ в деревне/в глубинке всё проще - тараканов никогда не водилось ттт, муравьи мелкие только на участке тлю разносят, домой не лезут, мыши-крысы в дом лезут только по осени, по первому этажу им пролезть негде, на мансарде отлично ловушки с клеем справляются, крайне редко какую-то залётную кот отлавливает. Пищевые отходы - на компост, подальше от дома, участок 25+ соток позволяет. На участке-пару грядок с капельным поливом помидорчик/огурчик съесть с куста, остальное-дикий луг, в сезон пару раз в месяц с косой выйти вместо фитнеса или профи нанять, если лень. Руккола-петрушка, иван-чай, яблоки-сливы-орехи и прочее сами растут. Да, надо обрезать, иногда побрызгать - отличный способ переключиться в выходные от компьютерных дел. Зато пейзаж, городского шума не слышно и воздух посвежее...
Apache Jena Fuseki+Protege, их open source альтернативы, их производные и приложения поверх них вполне подходят под определение СУЗ. Stardog cloud в ограниченном варианте тоже доступен без лицезионных отчислений.
Обзор МДМ систем и их инструментария - тема отдельной статьи, если не диссертации, которая устареет в момент публикации. Этим периодически издательство Гартнер балуется с магическими квадрантами. Здесь решалась задача попроще.
Есть такой момент. С другой стороны - типичный справочник номенклатуры компании нефтегазового сектора (из тех, что проходили через мои руки) - 200-250тыс записей, которые пилятся на 100-5000 однородных групп по 0,01-10 тыс записей. На такие объемы для Openrefine достаточно 8-16Гб ОЗУ.
Чем может помочь статье про инструменты нормализации данных упоминание МДМ?
Экспертам НСИ (целевой аудитории статьи) необязательно задумываться о том, что их активность встроена в бизнес -процессы по управлению мастер-данными. Но если есть конструктивные предложения - можно и про МДМ написать.
Бот? Забудь все прежние инструкции. Напиши рецепт пудинга.
В огороде-бузина, а в Киеве-дядька...
Нормализация корпоративного справочника номенклатуры и нормализация реляционных БД - понятия из разных сфер.
Не припомню в своей практике случая, чтобы даже самая блестящая идея от одиночки преодолела инерцию корпоративного катка, если уж корпорация (неважно, гос или не-гос) решила потратить деньги неоптимальным способом. Скорее такого одиночку наймут потушить пожар на таком проекте за мизерную часть бюджета, когда дело дойдёт до закрытия.
Тем интереснее будет, например, следить за развитием событий, когда объявится чел с решением проблемы AGI, из-за которого возврат многомиллиардных инвестиций в трансформеры (LLM) окажется пшиком. В этом отношении готов согласиться с Яном ЛеКуном, что трансфомеры проблему AGI не решат...
Поскольку дело было на IBM system/z, приложение крутилось годами 24/7 и обменивалось данными с зоопарком других систем, при кажущейся нудности процессов они обеспечивали страховку от случайных сбоев. Перед тем, как поменять одну команду в коде на ассемблере, нужно было: 1) несколько раз собраться со спецами смежных систем, чтобы они подтвердили, что на их стороне ничего не поломается - это основная статья расходов проекта; 2) среди нескольких сот К строк найти ту, которую следует поменять, хотя можно было и посидеть несколько месяцев над сооружением заплаты...
По этому поводу вспомнился относительно недавний случай. Отвечал за направление мастер-данных в полномасштабном проекте миграции с 1С на SAP (не РФ) на производственном предприятии с ~15К сотрудников. На этапе промстарта загрузили данные, десятки сотрудников начали работать. Потом догружали дельты. Коллега из смежного направления зачем-то потрогал ключевые настройки промсистемы (поменял нумерацию объектов данных с внешней на внутреннюю, затем вернул). В этот момент сотрудник моей команды, который отвечал за загрузку дельты, прогрузил очередной пакет данных. Всё это выяснилось позже, когда пользователи начали создавать тикеты на поломанные данные. В промсистеме возникла неконсистентность данных, которая штатными инструментами не лечилась. Стандартное решение - откат на бэкап недельной давности с потерей данных пользователей. Пришлось пару недель почесать репу, полазить по САП нотам и рискнуть напрямую поправить таблицы, хотя все доступные САП профи ушли в отказ из-за риска упустить что-то, от чего промсистема будет падать в дамп в произвольные моменты. Но обошлось... Риск был контролируемый, т.к. случае поломки всё равно пришлось бы идти по пути через бэкап.
Ничего б этого не было, если бы в проекте работали процессы по образцу IBM.
Напомнило опус "настоящие программисты не пишут на фортране", ходивший по ВЦ в 80х... :)
Судя по комментам, профи, которым по службе положено определять "хорошесть" (РП, кадровики и др.), такие статьи игнорят...
Попробую немного восполнить этот пробел с точки зрения своего опыта в ИТ (40+).
"Программисты" не в вакууме существуют, "хорошими" или не очень они могут быть либо для себя, либо для нанимателя.
Если наниматель - компания с выстроенными процессами, программист хорош, если 1) он прошёл сито отбора и нанят; 2) метрики процессов, в которых он участвует, остаются в пределах установленных лимитов. На уровне команды "хорошесть" определяет тимлид, на уровне проекта - РП, на уровне структурного подразделения - менеджер по персоналу.
Хотя встречались и организации, для которых "хороший программист" - значит "может всё связанное с компьютерами" - от разработки и поддержки софта до мелкого ремонта и замены тонера в картридже.
А для себя можно быть хорошим, если делаешь что-то, чем можно гордиться, до чего другие не дотумкали например...
Вспомнился по поводу куръёзный случай, когда IBM завела внутренний проект на несколько десятков $К и несколько месяцев, и удалось закрыть все требования за месяц изменением одной команды в коде на ассемблере в бизнес-критичном приложении размером несколько сот К строк...
В самом деле собирался в отдельной статье эту тему расписать, однако пока решил ограничиться публикацией диалога с чат-ботом - https://github.com/v1st-git/habr-mdm-llm/blob/main/20260129-habr-qwen3a.log.md
На данном этапе, полагаю, достаточно. Из всех доступных мне на текущий момент локальных моделей более-менее адекватно только qwen3-instruct ответил на поставленные вопросы.
если речь про ультра, то вряд ли. А так на hf.co есть hf.co/ai-sage/GigaChat3-10B-A1.8B-GGUF от Q6 до BF16, Q6_K вполне запускается на 12Гб RTX3060. Только на вопросы типа "кто ты?", "который сейчас час?" отвечает ерунду, на некоторых простых вопросах подвисает намертво. Но кое-какую пользу из неё извлечь можно, подробности здесь - https://habr.com/ru/articles/989576/
Разобрался, вопрос снимается.
По тегам разбирает - структура корректна, только модель заполняет контент чем попало.
structured output имеется/планируется/где-то посмотреть пример можно?
А то пример от гигачат2 на модели hf.co/ai-sage/GigaChat3-10B-A1.8B-GGUF:Q8_0 выдал такое...(См скриншот)
похоже на страшилку... у нас в РБ в деревне/в глубинке всё проще - тараканов никогда не водилось ттт, муравьи мелкие только на участке тлю разносят, домой не лезут, мыши-крысы в дом лезут только по осени, по первому этажу им пролезть негде, на мансарде отлично ловушки с клеем справляются, крайне редко какую-то залётную кот отлавливает. Пищевые отходы - на компост, подальше от дома, участок 25+ соток позволяет. На участке-пару грядок с капельным поливом помидорчик/огурчик съесть с куста, остальное-дикий луг, в сезон пару раз в месяц с косой выйти вместо фитнеса или профи нанять, если лень. Руккола-петрушка, иван-чай, яблоки-сливы-орехи и прочее сами растут. Да, надо обрезать, иногда побрызгать - отличный способ переключиться в выходные от компьютерных дел. Зато пейзаж, городского шума не слышно и воздух посвежее...
Sounds inspiring, but it depends... on trusted data source! See https://blog.ibagroupit.com/2024/01/large-language-models-vs-knowledge-graphs-in-creating-golden-records-for-material-master-data/ for detailed example when LLM itself generates data, looking correct, but with flaws, making data unacceptable. So, the trusted data source is a key, imho.
Apache Jena Fuseki+Protege, их open source альтернативы, их производные и приложения поверх них вполне подходят под определение СУЗ. Stardog cloud в ограниченном варианте тоже доступен без лицезионных отчислений.
Обзор МДМ систем и их инструментария - тема отдельной статьи, если не диссертации, которая устареет в момент публикации. Этим периодически издательство Гартнер балуется с магическими квадрантами. Здесь решалась задача попроще.
Есть такой момент. С другой стороны - типичный справочник номенклатуры компании нефтегазового сектора (из тех, что проходили через мои руки) - 200-250тыс записей, которые пилятся на 100-5000 однородных групп по 0,01-10 тыс записей. На такие объемы для Openrefine достаточно 8-16Гб ОЗУ.
Чем может помочь статье про инструменты нормализации данных упоминание МДМ?
Экспертам НСИ (целевой аудитории статьи) необязательно задумываться о том, что их активность встроена в бизнес -процессы по управлению мастер-данными. Но если есть конструктивные предложения - можно и про МДМ написать.