Я бы не был столь категоричен. Пока мы знаем следующее:
Есть много рутинных вещей в IT, которые ИИ может делать быстрее и лучше человека. Это точно останется.
Есть новые области (по которым мало контекста в обучающей выборке), большие проекты со сложной бизнес-логикой и много других мест, в которых ИИ откровенно не силён.
Стоимость обучения моделей и их эксплуатации растут. Причём стоимость обучения растёт нелинейно в зависимости от размера моделей.
Очень много компаний в гонке за ИИ делают то, что выглядит как классический "пузырь". В том числе, поддерживая этот пузырь прогнозами вида "ИИ может всё"
В какой именно момент наступит баланс, пока предсказать сложно. Есть вероятность, что "суперИИ" сделают раньше, чем сдуется накачка деньгами, и тогда вы будете правы. Есть вероятность, что деньги в пузыре кончатся и тогда мы будем наблюдать классическую "яму страданий" классической кривой Гартнера с отскоком в виде прекращения массового выпуска новых ЛЛМ и резким задиранием цен на токены в уже существующих моделях.
Да. Условные ребята, которые шли в IT за лёгкими и быстрыми деньгами, с очень высокой степенью вероятности сейчас останутся не у дел. В каком-то смысле требования к программистам сейчас откатываются назад, во времена 90-х - начала 0-х. Если ты не фанатеешь от профессии и не готов активно осваивать новые технологии, то упс...
Да, но я думаю, что старое доброе "Какое ТЗ, такой и результат" ещё долго не потеряет актуальность. Агенты умеют в "перелопачу 100500 источников" и найду что-то похожее, но ни одна ЛЛМ не в состоянии написать условного клиента к АПИ, если документация значительно различается с фактическими ответами.
По части объёма задач лично у меня: "где бы найти время на нормальный рефакторинг?". Обычно кусками время приходится выискивать при том, что процентов 10 времени у нас на техдолг и так явно заложено. И это старый (14+ лет) проект со стабильным ядром системы, а украшать в АПИ особо нечего. И у коллег, на сколько я вижу, примерно похожий расклад.
Но да, проблемы на рынке не только из-за ИИ, тут я полностью согласен.
Рискну предположить, что многое зависит от конкретной задачи. Рост объёмов данных в 100 раз за 15 лет имеет место быть, но 95+% этих данных - условные "видео с котиками", которые хорошо ложатся в концепцию распределённого хранения, но не требуют дополнительной обработки.
При этом действительно востребованных для анализа данных гораздо меньше (даже с учётом попыток строить аналитику на чём угодно) и в ряде задач потребность в быстром доступе к данным никуда не денется.
В условном интернет-магазине непосредственно под задачи покупок будут по-прежнему использоваться старые добрые СУБД, при этом какая-нибудь аналитика с рекомендациями по типу закупаемого на склад кошачьего питания на основании того, видео с какими котиками постят покупатели у себя в соцсети да, вполне себе потребует обработки данных из таких распределённых хранилищ.
На самом деле это очень сильно напоминает концепцию шардирования, когда по какому-то ключу (хешу), определяется, в какой шарде надо искать данные.
Самая большая проблема здесь, как вы сами отметили, неравномерное распределение ключа. Даже единичный случайный выброс (2,1,5,10000) ломает всю картину.
Но если мы по какой-то причине знаем распределение и можем гарантировать его ограниченность и равномерность распространения данных внутри исходного массива, то да, такой подход вполне будет работать.
Да. Ключевые слова: плагин Remotely Save + Webdav + Облако. Так как Хабр не очень любит ссылки в комментах, скинул ссылку на подробную инструкцию в личку.
Спасибо за замечание. Полностью согласен. В статье "минимально достаточный" код, чтобы не раздувать объём не существенными подробностями. В реальном проекте кода, понятно, несколько больше.
Кажется, что ничего из перечисленного не подпадает под определение "более-менее современная версия EF одно выражение Where трансформирует во что-то кроме SELECT … FROM … WHERE … ". Но это, в любом случае, думаю, не принципиально.
Сам по себе риск однозначно есть, вы абсолютно правы. На сколько он большой - вопрос дискуссионный. Мне кажется, что преимущества перевешивают риски, вам - что нет.
В любом случае, инструмент есть, а пользоваться им, или нет, уже пусть читатели сами решают.
А можно, пожалуйста, практический пример того, как более-менее современная версия EF одно выражение Where трансформирует во что-то кроме SELECT … FROM … WHERE …? Спрашиваю без малейшего стёба, так как я такой риск сознательно откидывал как несущественный.
Я прекрасно понимаю, как можно «положить» этот запрос, но честно смог придумать только четыре сценария:
Применение ForUpdate к сложносоставному запросу, к которому в принципе нельзя применять эту команду на уровне SQL. Ну как бы сам себе злобный Буратино, не надо отвёрткой гвозди забивать.
В будущих версиях EF решат сломать обратную совместимость при генерации запросов и, например, начать явно прописывать ; в конце. Ок, это будет не первый на моей памяти случай, когда внешняя библиотека что-то ломает. Заранее это не предскажешь, так как могут и две ; подряд поставить, например. Тут, главное, при подъёме версий библиотек автотесты не забывать гонять.
Смена базы данных, при которой надо вместо FOR UPDATE начинать писать совсем другой код и по другим правилам. Тут тоже заранее хз, что делать, так как смена базы дело достаточно капитальное и не зная целевую базу сложно универсальный код написать. Тем более, что тут любой raw sql или вызов хранимую отломится точно также.
Другой интерсептор, написанный без учёта совместимости с уже имеющимися. Например, добавляющий в конец SELECT запроса ; по принципу «а для красоты». Такое только на ревью отслеживать, плюс, опять же, автотесты.
Применять FOR UPDATE на какой-нибудь сложный кросс-джойн по нескольким таблицам с агрегаторами и группировкой - не надо так. Он там просто не сработает, причём EF там будет ни при чём. Ну а что нагенерирует EF на более-менее типовой селект по одной таблице с WHERE в качестве условия - вариантов там не особо много.
Плюс сам по себе механизм интерсепторов подразумевает наличие некоторых скилов в EF и базе у человека, который пишет сам интерсептор. А дальнейшее использование ничем не отличается от каких-нибудь агрегаторов. Их точно также не везде можно использовать, и можно ошибку словить, если сделаешь это криво.
Да, но лучше, думаю, просто Ordinal в этом случае использовать, так как смысла нет регистро-независимое сравнение делать. Тут жёстко прописанная константа, которую мы вряд ли просто так менять будем, а на проверку вариантов написания букв в разных регистрах тоже время тратится.
Зависит от. Понятно, что если структура базы такая, что нагенерированный EF код надо постоянно перепроверять, то ну его нафиг. Тут, да, никакие интерсепторы не помогут - только RawSql, а если кривых запросов ещё и достаточно солидный процент от общего числа, то стоит в принципе подумать на тему отказа от EF.
Но сделать интерсептор для того же For Update вместо переписывания в 3-х местах кода на нативный SQL - вполне себе годное решение, как мне кажется. И да, я полностью согласен, что хранимка в данном случае работала бы немного быстрее. Нюанс в том, что при ожидаемой частоте апдейтов потратили бы больше времени разработчика на переписывание, чем сэкономили бы машинного времени при такой оптимизации.
Дисплей на тенях - вряд ли, хотя всё возможно. А вот часть логической операции «исключающее или» для чисто оптических компьютеров - сделано. Понятно, что от этого до практического применения ещё очень далеко, да и цена такого «процессора» космическая, но тенденция интересная.
Большинство. По моим наблюдениям тех, кто вообще без вышки, единицы при весьма солидной общей базе наблюдения. То есть в районе 1% или даже ниже. Возможно, у меня немного искажённая картина, но в любом случае речь про единицы процентов.
На будущее, однозначно рекомендую использовать вместо среднего медиану. Она как раз не чувствительна к выбросам, по типу тех, что бывали у вас в начале.
Но на практике такие вещи могут быть нужны при отладке, тут да, а потом выпиливаться либо самим разработчиком, либо на ревью.
Ну, либо если такой сценарий реально зачем-то нужен на проде и есть описанные риски, то флаг IsTraceEnabled ставим в false и для этого запроса работает старая логика логирования.
Я бы не был столь категоричен. Пока мы знаем следующее:
Есть много рутинных вещей в IT, которые ИИ может делать быстрее и лучше человека. Это точно останется.
Есть новые области (по которым мало контекста в обучающей выборке), большие проекты со сложной бизнес-логикой и много других мест, в которых ИИ откровенно не силён.
Стоимость обучения моделей и их эксплуатации растут. Причём стоимость обучения растёт нелинейно в зависимости от размера моделей.
Очень много компаний в гонке за ИИ делают то, что выглядит как классический "пузырь". В том числе, поддерживая этот пузырь прогнозами вида "ИИ может всё"
В какой именно момент наступит баланс, пока предсказать сложно. Есть вероятность, что "суперИИ" сделают раньше, чем сдуется накачка деньгами, и тогда вы будете правы. Есть вероятность, что деньги в пузыре кончатся и тогда мы будем наблюдать классическую "яму страданий" классической кривой Гартнера с отскоком в виде прекращения массового выпуска новых ЛЛМ и резким задиранием цен на токены в уже существующих моделях.
Да. Условные ребята, которые шли в IT за лёгкими и быстрыми деньгами, с очень высокой степенью вероятности сейчас останутся не у дел. В каком-то смысле требования к программистам сейчас откатываются назад, во времена 90-х - начала 0-х. Если ты не фанатеешь от профессии и не готов активно осваивать новые технологии, то упс...
Да, но я думаю, что старое доброе "Какое ТЗ, такой и результат" ещё долго не потеряет актуальность. Агенты умеют в "перелопачу 100500 источников" и найду что-то похожее, но ни одна ЛЛМ не в состоянии написать условного клиента к АПИ, если документация значительно различается с фактическими ответами.
И соглашусь, и нет.
По части объёма задач лично у меня: "где бы найти время на нормальный рефакторинг?". Обычно кусками время приходится выискивать при том, что процентов 10 времени у нас на техдолг и так явно заложено. И это старый (14+ лет) проект со стабильным ядром системы, а украшать в АПИ особо нечего. И у коллег, на сколько я вижу, примерно похожий расклад.
Но да, проблемы на рынке не только из-за ИИ, тут я полностью согласен.
Рискну предположить, что многое зависит от конкретной задачи. Рост объёмов данных в 100 раз за 15 лет имеет место быть, но 95+% этих данных - условные "видео с котиками", которые хорошо ложатся в концепцию распределённого хранения, но не требуют дополнительной обработки.
При этом действительно востребованных для анализа данных гораздо меньше (даже с учётом попыток строить аналитику на чём угодно) и в ряде задач потребность в быстром доступе к данным никуда не денется.
В условном интернет-магазине непосредственно под задачи покупок будут по-прежнему использоваться старые добрые СУБД, при этом какая-нибудь аналитика с рекомендациями по типу закупаемого на склад кошачьего питания на основании того, видео с какими котиками постят покупатели у себя в соцсети да, вполне себе потребует обработки данных из таких распределённых хранилищ.
На самом деле это очень сильно напоминает концепцию шардирования, когда по какому-то ключу (хешу), определяется, в какой шарде надо искать данные.
Самая большая проблема здесь, как вы сами отметили, неравномерное распределение ключа. Даже единичный случайный выброс (2,1,5,10000) ломает всю картину.
Но если мы по какой-то причине знаем распределение и можем гарантировать его ограниченность и равномерность распространения данных внутри исходного массива, то да, такой подход вполне будет работать.
Да. Ключевые слова: плагин Remotely Save + Webdav + Облако. Так как Хабр не очень любит ссылки в комментах, скинул ссылку на подробную инструкцию в личку.
F
Спасибо за замечание. Полностью согласен. В статье "минимально достаточный" код, чтобы не раздувать объём не существенными подробностями. В реальном проекте кода, понятно, несколько больше.
Кажется, что ничего из перечисленного не подпадает под определение "более-менее современная версия EF одно выражение Where трансформирует во что-то кроме SELECT … FROM … WHERE … ". Но это, в любом случае, думаю, не принципиально.
Сам по себе риск однозначно есть, вы абсолютно правы. На сколько он большой - вопрос дискуссионный. Мне кажется, что преимущества перевешивают риски, вам - что нет.
В любом случае, инструмент есть, а пользоваться им, или нет, уже пусть читатели сами решают.
А можно, пожалуйста, практический пример того, как более-менее современная версия EF одно выражение Where трансформирует во что-то кроме SELECT … FROM … WHERE …? Спрашиваю без малейшего стёба, так как я такой риск сознательно откидывал как несущественный.
Я прекрасно понимаю, как можно «положить» этот запрос, но честно смог придумать только четыре сценария:
Применение ForUpdate к сложносоставному запросу, к которому в принципе нельзя применять эту команду на уровне SQL. Ну как бы сам себе злобный Буратино, не надо отвёрткой гвозди забивать.
В будущих версиях EF решат сломать обратную совместимость при генерации запросов и, например, начать явно прописывать ; в конце. Ок, это будет не первый на моей памяти случай, когда внешняя библиотека что-то ломает. Заранее это не предскажешь, так как могут и две ; подряд поставить, например. Тут, главное, при подъёме версий библиотек автотесты не забывать гонять.
Смена базы данных, при которой надо вместо FOR UPDATE начинать писать совсем другой код и по другим правилам. Тут тоже заранее хз, что делать, так как смена базы дело достаточно капитальное и не зная целевую базу сложно универсальный код написать. Тем более, что тут любой raw sql или вызов хранимую отломится точно также.
Другой интерсептор, написанный без учёта совместимости с уже имеющимися. Например, добавляющий в конец SELECT запроса ; по принципу «а для красоты». Такое только на ревью отслеживать, плюс, опять же, автотесты.
Применять FOR UPDATE на какой-нибудь сложный кросс-джойн по нескольким таблицам с агрегаторами и группировкой - не надо так. Он там просто не сработает, причём EF там будет ни при чём. Ну а что нагенерирует EF на более-менее типовой селект по одной таблице с WHERE в качестве условия - вариантов там не особо много.
Плюс сам по себе механизм интерсепторов подразумевает наличие некоторых скилов в EF и базе у человека, который пишет сам интерсептор. А дальнейшее использование ничем не отличается от каких-нибудь агрегаторов. Их точно также не везде можно использовать, и можно ошибку словить, если сделаешь это криво.
Да, но лучше, думаю, просто Ordinal в этом случае использовать, так как смысла нет регистро-независимое сравнение делать. Тут жёстко прописанная константа, которую мы вряд ли просто так менять будем, а на проверку вариантов написания букв в разных регистрах тоже время тратится.
Спасибо!
Зависит от. Понятно, что если структура базы такая, что нагенерированный EF код надо постоянно перепроверять, то ну его нафиг. Тут, да, никакие интерсепторы не помогут - только RawSql, а если кривых запросов ещё и достаточно солидный процент от общего числа, то стоит в принципе подумать на тему отказа от EF.
Но сделать интерсептор для того же For Update вместо переписывания в 3-х местах кода на нативный SQL - вполне себе годное решение, как мне кажется. И да, я полностью согласен, что хранимка в данном случае работала бы немного быстрее. Нюанс в том, что при ожидаемой частоте апдейтов потратили бы больше времени разработчика на переписывание, чем сэкономили бы машинного времени при такой оптимизации.
В данном случае - однозначно. Скорее как устоявшаяся привычка.
Дисплей на тенях - вряд ли, хотя всё возможно. А вот часть логической операции «исключающее или» для чисто оптических компьютеров - сделано. Понятно, что от этого до практического применения ещё очень далеко, да и цена такого «процессора» космическая, но тенденция интересная.
Большинство. По моим наблюдениям тех, кто вообще без вышки, единицы при весьма солидной общей базе наблюдения. То есть в районе 1% или даже ниже. Возможно, у меня немного искажённая картина, но в любом случае речь про единицы процентов.
На будущее, однозначно рекомендую использовать вместо среднего медиану. Она как раз не чувствительна к выбросам, по типу тех, что бывали у вас в начале.
Либо просто запрос с длинным временем выполнения.
Но на практике такие вещи могут быть нужны при отладке, тут да, а потом выпиливаться либо самим разработчиком, либо на ревью.
Ну, либо если такой сценарий реально зачем-то нужен на проде и есть описанные риски, то флаг IsTraceEnabled ставим в false и для этого запроса работает старая логика логирования.