Софт для пролов станет еще более прожорливый, еще более глючный и одновременно более примитивный. Критичный софт продолжат писать кожанные, возможно с использованием заточенных на проблемную область llm для быстрой генерации небольших модулей с хорошо описанным функционалом. Пробовал cursor. Он по docstring вполне себе генерит такие модули. Но ревью кода и юнит-тесты все равно на мне.
Недавно ит-аналитику в разговоре сказал "машина Тьюринга". В ответ "что это?" :) Не понимание основ рождает романтические заблуждения.
ML это программирование машины на примерах. Есть императивный метод, есть декларативный метод и вот еще есть метод на примерах.
Чтобы что-то хорошее получить, надо оценивать применимость метода, подбирать переменные, формулировать формально цель обучения, собирать презентативную сбалансированную базу более менее независимых и актуальных примеров. Годная база примеров вещь дорогая, поэтому надо тонко настраивать архитектуру модели, чтобы из минимума степеней свободы выжать максимум точности, подтвержденной на тестовых примерах (ошибка обобщения - слыхали о такой?). А потом еще модель надо мониторить и при необходимости переобучать. Вот это ML.
Питон это инструмент оркестровки специализированных компонент. Любое иное его использование в продуктовой среде, это ошибка или вынужденное зло.
Примеры нормального использования:
DAG в Airflow
Cкрипт, 99% времени которого приходится на выполнение методов ML-библиотеки (scikit-learn, TensorFlow, PyTorch и др.)
Скрипт Spark application
Задачи перекладывания данных. Типа взять данные от одного компонента, изменить формат и отдать в другой к компонент. В таких задачах 99% времени тратиться на передачу по сети, работы с файлами или базой данных.
Разные утилитные скрипты для администрирования систем. Например, скрипты CI/CD.
Разовые скрипты обработки файлов. Ну там, убрать из csv особые символы, которые модуль импорта в БД не может обработать. Распарсить файл архива электронных писем и затем положить их в БД.
UDF функции, для расширения состава функций БД, где не хватает возможностей родного языка программирования БД.
От версии к версии Python затраты на операции могут значительно меняться. Тем более сильно может все измениться, если вы используете "ускорители" типа PyPy или Numba. Поэтому главное, чтобы код выглядел хорошо (главное, понятно выглядело), без явно неоптимальных конструкций. Типа, где можно циклом или itertools посчитать, не надо рекурсию использовать.
На базе нейросетей можно реализовать базовые элементарные логические элементы, такие как штрих Шефера и стрелку Пирса
Но кто организует порядок работы этих элементов ?
В статье предлагается вариант кодирования правил перехода нейронной сетью. То есть предлагаемый подход вполне может быть объединен с нейросетевым подходом, включать его как элемент базы.
Да, имеется ввиду только ML. Экспертные продукционные системы и др. за рамками.
Машина Тьюринга, это лента, головка и набор правил перехода. Ничего не меняем в ленте и головке. Меняем состав правил, начальные данные на ленте, начальное положение и состояние головки. Так мы можем настроить машину на решение любой определенной задачи, если она вообще решается алгоритмически. Например, хотим сортировать список чисел любого конечного размера - один набор правил, хотим переводить текст с английского на финский - другой набор правил и т. д.
Возьмем мощную по потенциальным возможностям архитектуру ИНС - полносвязную рекуррентную сеть. Мы можем менять веса синапсов, начальные состояния нейронов и кодирование входных данных.
Допустим сеть состоит из бесконечного количества нейронов и синапсов. Как настроены начальные веса ? Если случайным образом, то для приведения их к подходящему значению нам понадобится бесконечное количество действий. Синапсов то ведь бесконечно много. Ок, тогда пусть все начальные веса и состояния будут нулевыми. Но тогда это эквивалентно тому, что сеть конечная, но мы можем добавлять к ней новые нейроны и синапсы, пока сеть не начнет решать необходимую нам задачу.
При таких условиях нет возможности собрать сеть, способную обрабатывать данные любого конечного размера. Потому, что нейронная сеть, при любой ее конфигурации, принадлежит классу конечных автоматов. Конечное количество нейронов, конечное количество состояний == конечный автомат.
Для машины Тьюринга же, если задача алгоритмически решаема, всегда можно подобрать таблицу переходов конечного размера, чтобы машина могла решать задачу любой конечной размерности без переделок.
Пусть для практических задач можно ограничить размер данных сверху. Если у машины Тьюринга ограничить ленту, то она превратиться в конечный автомат. Тогда да, такая урезанная машина Тьюринга станет, с точки зрения математики, равна нейронной сети, ибо оба станут относится к конечным автоматам. Хотя и тут есть нюансы. Для удвоения размера обрабатываемых данных для машины Тьюринга достаточно увеличить длину ленты. Менять правила переходов не требуется. В случае же нейронной сети понадобится увеличивать размер сети и переобучать ее. Почувствуйте разницу.
Ну ок, математически все это конечные автоматы. Надо тогда смотреть на задачу. Одну задачу, с учетом возможностей и ограничений доступных нам физических компьютеров, проще решить конечным автоматом, другую нейронной сетью. Например, сортировку списка чисел лучше сделает конечный автомат (CPU обыкновенный или это), а распознавать что-то шаблонное на изображении видимо лучше с помощью нейронной сети.
Но есть задачи, решение которых традиционно (императивным или декларативным формальным языком) закодировать сложно и нейронные сети отработанных архитектур не справляются. Например, качественное решение требует рекуррентной нейронной сети. Математически они многое могут, но обучать их в общем случае сложно (градиент "гаснет" или "взрывается"). Хотелось бы иметь чего-то еще гибкого, настраиваемого на примерах (называю это программированием на примерах), потенциально более мощного, чем нейронные сети. Вот и предлагается попробовать иную базу вычислений. Нейронные сети брали свою базу из интерпретации данных нейрофизиологии. Предлагаемый в статье подход берет базу из формализмов теории вычислений.
---
Насчет "кирпич" vs "комфортное жилье". Комфорт здесь определяется наличием эффективных методов "обучения", программных библиотек и аппаратной поддержки. Если некое направление прямо сейчас не имеет всего этого, это не повод не развивать направление. Когда-то и нейросети не имели этого. Фрэнк Розенблатт начинал с одним паяльником.
Рассматриваемые здесь "мутанты" машины Тьюринга вполне могут использовать SIMD и CUDA. Дело только за отработанными методами оптимизации, удобными библиотеками и шаблонами сценариев использования.
Представьте себе такую картинку. Студия. В студии несколько человек и LLM. Произносится слово (для людей это слово, для LLM последовательность символов из заданного алфавита ) - "шляпа". У одного человека рождается образ дамы в старинной дамской шляпке. У другого - соломенная шляпа на голове лошади, у третьего - кривой код попавший в прод. В "голове" LLM светится последовательность символов "Ш Л Я П А" и у нее тысячи связей разной "толщины" и с разными дополнительными условиями с "Л О Ш А Д Ь", "В И Н Т А Ж", ...
Одно из печальных последствий. Я учился писать, читая лучшие образцы (классическая литература, статьи в тематических журналах от специалистов и т.п.) На чем будет учиться молодежь ? Предвижу деградацию и ненасильственное окончательное рабство прола (1984) от машин.
Можно было бы дополнить реальными практическими примерами.
Я думал, что фрейворк относится к дизайну. Пример rest api - это архитектура. На какой базе реализован сервис - postgresql + fastapi или mysql + Node.js это уже дизайн. Завтра реализация сервиса изменится, но пока api стабилен менять архитектуру не требуется.
Хотя это конечно зависит от уровня рассмотрения - архитектура предприятия, архитектура приложения, архитектура компонента, архитектура модуля, архитектура класса. Сделали мы класс в старом стиле, с явно прописанными get/set-рами или применили декоратор dataclass это уже дизайн. Трогает изменение другие компоненты - архитектура, не трогает - дизайн.
Можно спокойно добавить новый источник, не волнуясь, что загрузка других источников и отчеты посыпятся Вторым шагом можно спокойно подцепить новые сателиты и линки к отчетам.
1) На первый взгляд order_detail не нужен. Если не бояться версионности в линках, то достаточно линка, связывающего заказ с продуктом и сателита линка с атрибутами линка (количество и цена). order_detail позволяет убрать версионность из линка, перенеся ее в искуственную сущность, но понимать это сложней. В общем, считаю, что не надо боятся версионности в линках, где она требуется. Так проще и эффективней. 2) Зачем id-шники в сателитах ? Это бизнес-ключи и их место только в хабах. Данные можно связывать хэш-ключами.
"Бытие определяет сознание". Звучит обидно. Не согласен. Сознание определяет бытие. Червю в куче грязи рай, а мне ад.
---
Возмем крайний случай, некого "маньяка". Мне совершенно все равно, виноват он или нет. В случае угрозы я попытаюсь ее устранить и все.
Никакие социальные условия "маньяка" не исправят. Могут притормозить, заставить быть более осторожным. Но он все равно будет стремиться совершить свое дело. Не надо никакого "морального осуждения". Просто изолируйте его.
Да, похоже было такое. Грубо говоря я был дорогой спец по спец вопросам. Компания изменила свой профиль и я как бы стал лишним и дорогим. Просто по сути отстранили от задач и через некоторое время предложили по соглашению сторон. Ок, к рукрводству вопросов нет, а вот к некоторым коллегам вопросов много. Возможно кто-то хотел протащить в компанию знакомого на освободившееся место. Так что не факт, что это была инициатива высшего руководства.
Вообще я патологически плохо переношу конфликты. Но ипотека сильно укрепляет волю :)
Согласен. Общий случай не доказан. Но сейчас не могут. Допустим мы вознамерились "найчить" этому нейросетку. Придумаем формальный язык, способный описать любые логические игры (упс, такой язык невозможен. Гёдель запрешает.). Натренируем LLM на описаниях логических игр. Получим генератор описаний, на первый взгляд похожих на описание новых игр. В лучшем случае LLM уловит что-то общее в существующих играх и сделает гибрид.
ИИ - Иллюзия Интеллекта. alpha-beta pruning в шахматных программах тоже варианты просчитывает, только по этому поводу хайпа нет.
LLM просто генерят пустословие (люди тоже так умеют), повторяют типичное продолжение текста со случайными вариациями, для поддержания иллюзии разумности у неискушенной публики. А под капотом 2*2=4.
Софт для пролов станет еще более прожорливый, еще более глючный и одновременно более примитивный. Критичный софт продолжат писать кожанные, возможно с использованием заточенных на проблемную область llm для быстрой генерации небольших модулей с хорошо описанным функционалом. Пробовал cursor. Он по docstring вполне себе генерит такие модули. Но ревью кода и юнит-тесты все равно на мне.
Они галлюционируют и врут со страшной силой. Другого и быть не может.
Какие такие вы знаете "некритичные" задачи ?
Недавно ит-аналитику в разговоре сказал "машина Тьюринга". В ответ "что это?" :) Не понимание основ рождает романтические заблуждения.
ML это программирование машины на примерах. Есть императивный метод, есть декларативный метод и вот еще есть метод на примерах.
Чтобы что-то хорошее получить, надо оценивать применимость метода, подбирать переменные, формулировать формально цель обучения, собирать презентативную сбалансированную базу более менее независимых и актуальных примеров. Годная база примеров вещь дорогая, поэтому надо тонко настраивать архитектуру модели, чтобы из минимума степеней свободы выжать максимум точности, подтвержденной на тестовых примерах (ошибка обобщения - слыхали о такой?). А потом еще модель надо мониторить и при необходимости переобучать. Вот это ML.
Питон это инструмент оркестровки специализированных компонент. Любое иное его использование в продуктовой среде, это ошибка или вынужденное зло.
Примеры нормального использования:
DAG в Airflow
Cкрипт, 99% времени которого приходится на выполнение методов ML-библиотеки (scikit-learn, TensorFlow, PyTorch и др.)
Скрипт Spark application
Задачи перекладывания данных. Типа взять данные от одного компонента, изменить формат и отдать в другой к компонент. В таких задачах 99% времени тратиться на передачу по сети, работы с файлами или базой данных.
Разные утилитные скрипты для администрирования систем. Например, скрипты CI/CD.
Разовые скрипты обработки файлов. Ну там, убрать из csv особые символы, которые модуль импорта в БД не может обработать. Распарсить файл архива электронных писем и затем положить их в БД.
UDF функции, для расширения состава функций БД, где не хватает возможностей родного языка программирования БД.
От версии к версии Python затраты на операции могут значительно меняться. Тем более сильно может все измениться, если вы используете "ускорители" типа PyPy или Numba.
Поэтому главное, чтобы код выглядел хорошо (главное, понятно выглядело), без явно неоптимальных конструкций. Типа, где можно циклом или itertools посчитать, не надо рекурсию использовать.
Но кто организует порядок работы этих элементов ?
В статье предлагается вариант кодирования правил перехода нейронной сетью. То есть предлагаемый подход вполне может быть объединен с нейросетевым подходом, включать его как элемент базы.
Да, имеется ввиду только ML. Экспертные продукционные системы и др. за рамками.
Машина Тьюринга, это лента, головка и набор правил перехода. Ничего не меняем в ленте и головке. Меняем состав правил, начальные данные на ленте, начальное положение и состояние головки. Так мы можем настроить машину на решение любой определенной задачи, если она вообще решается алгоритмически. Например, хотим сортировать список чисел любого конечного размера - один набор правил, хотим переводить текст с английского на финский - другой набор правил и т. д.
Возьмем мощную по потенциальным возможностям архитектуру ИНС - полносвязную рекуррентную сеть. Мы можем менять веса синапсов, начальные состояния нейронов и кодирование входных данных.
Допустим сеть состоит из бесконечного количества нейронов и синапсов. Как настроены начальные веса ? Если случайным образом, то для приведения их к подходящему значению нам понадобится бесконечное количество действий. Синапсов то ведь бесконечно много. Ок, тогда пусть все начальные веса и состояния будут нулевыми. Но тогда это эквивалентно тому, что сеть конечная, но мы можем добавлять к ней новые нейроны и синапсы, пока сеть не начнет решать необходимую нам задачу.
При таких условиях нет возможности собрать сеть, способную обрабатывать данные любого конечного размера. Потому, что нейронная сеть, при любой ее конфигурации, принадлежит классу конечных автоматов. Конечное количество нейронов, конечное количество состояний == конечный автомат.
Для машины Тьюринга же, если задача алгоритмически решаема, всегда можно подобрать таблицу переходов конечного размера, чтобы машина могла решать задачу любой конечной размерности без переделок.
Пусть для практических задач можно ограничить размер данных сверху. Если у машины Тьюринга ограничить ленту, то она превратиться в конечный автомат. Тогда да, такая урезанная машина Тьюринга станет, с точки зрения математики, равна нейронной сети, ибо оба станут относится к конечным автоматам. Хотя и тут есть нюансы. Для удвоения размера обрабатываемых данных для машины Тьюринга достаточно увеличить длину ленты. Менять правила переходов не требуется. В случае же нейронной сети понадобится увеличивать размер сети и переобучать ее. Почувствуйте разницу.
Ну ок, математически все это конечные автоматы. Надо тогда смотреть на задачу. Одну задачу, с учетом возможностей и ограничений доступных нам физических компьютеров, проще решить конечным автоматом, другую нейронной сетью. Например, сортировку списка чисел лучше сделает конечный автомат (CPU обыкновенный или это), а распознавать что-то шаблонное на изображении видимо лучше с помощью нейронной сети.
Но есть задачи, решение которых традиционно (императивным или декларативным формальным языком) закодировать сложно и нейронные сети отработанных архитектур не справляются. Например, качественное решение требует рекуррентной нейронной сети. Математически они многое могут, но обучать их в общем случае сложно (градиент "гаснет" или "взрывается"). Хотелось бы иметь чего-то еще гибкого, настраиваемого на примерах (называю это программированием на примерах), потенциально более мощного, чем нейронные сети. Вот и предлагается попробовать иную базу вычислений. Нейронные сети брали свою базу из интерпретации данных нейрофизиологии. Предлагаемый в статье подход берет базу из формализмов теории вычислений.
---
Насчет "кирпич" vs "комфортное жилье". Комфорт здесь определяется наличием эффективных методов "обучения", программных библиотек и аппаратной поддержки. Если некое направление прямо сейчас не имеет всего этого, это не повод не развивать направление. Когда-то и нейросети не имели этого. Фрэнк Розенблатт начинал с одним паяльником.
Рассматриваемые здесь "мутанты" машины Тьюринга вполне могут использовать SIMD и CUDA. Дело только за отработанными методами оптимизации, удобными библиотеками и шаблонами сценариев использования.
Соотношение уровней шума и полезного сигнала имеет значение.
Представьте себе такую картинку. Студия. В студии несколько человек и LLM. Произносится слово (для людей это слово, для LLM последовательность символов из заданного алфавита ) - "шляпа". У одного человека рождается образ дамы в старинной дамской шляпке. У другого - соломенная шляпа на голове лошади, у третьего - кривой код попавший в прод. В "голове" LLM светится последовательность символов "Ш Л Я П А" и у нее тысячи связей разной "толщины" и с разными дополнительными условиями с "Л О Ш А Д Ь", "В И Н Т А Ж", ...
Одно из печальных последствий. Я учился писать, читая лучшие образцы (классическая литература, статьи в тематических журналах от специалистов и т.п.) На чем будет учиться молодежь ? Предвижу деградацию и ненасильственное окончательное рабство прола (1984) от машин.
Я узнал, что такое лидкод :)
Нас учили на кафедре, все эти штучки дрючки конечно прикольно, но в российской реальности кормить вас будут 1С и эскуэль :) Так реально и выходит.
Можно было бы дополнить реальными практическими примерами.
Я думал, что фрейворк относится к дизайну. Пример rest api - это архитектура. На какой базе реализован сервис - postgresql + fastapi или mysql + Node.js это уже дизайн. Завтра реализация сервиса изменится, но пока api стабилен менять архитектуру не требуется.
Хотя это конечно зависит от уровня рассмотрения - архитектура предприятия, архитектура приложения, архитектура компонента, архитектура модуля, архитектура класса. Сделали мы класс в старом стиле, с явно прописанными get/set-рами или применили декоратор dataclass это уже дизайн. Трогает изменение другие компоненты - архитектура, не трогает - дизайн.
🤖Победителей определял ИИ ? 🦧
order_detail выглядить искусственным с точки зрения OLTP, но он нужен, чтобы линки были без версий в DWH.
Можно спокойно добавить новый источник, не волнуясь, что загрузка других источников и отчеты посыпятся
Вторым шагом можно спокойно подцепить новые сателиты и линки к отчетам.
1) На первый взгляд order_detail не нужен. Если не бояться версионности в линках, то достаточно линка, связывающего заказ с продуктом и сателита линка с атрибутами линка (количество и цена). order_detail позволяет убрать версионность из линка, перенеся ее в искуственную сущность, но понимать это сложней. В общем, считаю, что не надо боятся версионности в линках, где она требуется. Так проще и эффективней.
2) Зачем id-шники в сателитах ? Это бизнес-ключи и их место только в хабах. Данные можно связывать хэш-ключами.
"Бытие определяет сознание". Звучит обидно. Не согласен. Сознание определяет бытие. Червю в куче грязи рай, а мне ад.
---
Возмем крайний случай, некого "маньяка". Мне совершенно все равно, виноват он или нет. В случае угрозы я попытаюсь ее устранить и все.
Никакие социальные условия "маньяка" не исправят. Могут притормозить, заставить быть более осторожным. Но он все равно будет стремиться совершить свое дело. Не надо никакого "морального осуждения". Просто изолируйте его.
Воля есть. Она в основе всего.
Свобода это возможности реализации воли. Ее может быть больше или меньше в моменте.
Да, похоже было такое. Грубо говоря я был дорогой спец по спец вопросам. Компания изменила свой профиль и я как бы стал лишним и дорогим. Просто по сути отстранили от задач и через некоторое время предложили по соглашению сторон. Ок, к рукрводству вопросов нет, а вот к некоторым коллегам вопросов много. Возможно кто-то хотел протащить в компанию знакомого на освободившееся место. Так что не факт, что это была инициатива высшего руководства.
Вообще я патологически плохо переношу конфликты. Но ипотека сильно укрепляет волю :)
Согласен. Общий случай не доказан. Но сейчас не могут.
Допустим мы вознамерились "найчить" этому нейросетку.
Придумаем формальный язык, способный описать любые логические игры (упс, такой язык невозможен. Гёдель запрешает.). Натренируем LLM на описаниях логических игр. Получим генератор описаний, на первый взгляд похожих на описание новых игр. В лучшем случае LLM уловит что-то общее в существующих играх и сделает гибрид.
ИИ - Иллюзия Интеллекта.
alpha-beta pruning в шахматных программах тоже варианты просчитывает, только по этому поводу хайпа нет.
LLM просто генерят пустословие (люди тоже так умеют), повторяют типичное продолжение текста со случайными вариациями, для поддержания иллюзии разумности у неискушенной публики. А под капотом 2*2=4.
"Но ведь и люди так же " - это доказано ?