Я нормально отношусь к минусам с пометкой: личная неприязнь. Ну кому-то я не мил. Бывает. Человек «отстрелялся», больше он минус не поставит.
А вот такие пометки, как: подозрительная активность, реклама вызывают удивление. В активности — ничего подозрительного. Ничего не рекламирую. И самое нехорошее, что обратной связи, о которой столько много говорят, таки нет. Я так и не понял, и что же у меня приняли за рекламу? Я бы и исправился, и перестал бы рекламировать то, не знаю что. Или прекратил себя вести подозрительно. Но гадать на кофейной гуще как-то не хочется.
Почему? Возможно, моё понимание этого вопроса неверно, поправьте меня, если я ошибаюсь.
Я считаю, что ИИ всё-таки выявляет закономерности, которые отражаются в коэффициентах, вычисляемых на основе обучающих данных. ИИ наблюдает явления (точнее, за него это делают), а затем выявляет зависимости. Таким образом, второй пункт однозначно применим, ведь ИИ находит закономерности в данных. Эти закономерности затем используются для обработки новых входных данных. По сути, ИИ преобразует входные сигналы, применяя те самые выявленные зависимости.
Наблюдение явления: ИИ анализирует большие объемы данных, которые представляют собой наблюдения различных явлений. Например, в случае с языковыми моделями, такими как GPT, данные включают миллиарды текстов, содержащих разнообразные примеры использования языка.
Выявление закономерностей: В процессе обучения ИИ использует алгоритмы, такие как градиентный спуск, для оптимизации весов модели. Эти веса отражают выявленные закономерности в данных. Например, модель может обнаружить, что после слов "как зовут Гагарина" с высокой вероятностью следует "Юрий".
Использование выявленных закономерностей: После обучения модель использует эти закономерности для генерации ответов на новые входные данные. Это позволяет ИИ преобразовывать входной сигнал (например, вопрос) в осмысленный выход (например, ответ), основываясь на выявленных закономерностях.
Генерализация: Ещё один важный аспект работы ИИ способность к генерализации, то есть применению выявленных закономерностей к новым, невиданным ранее данным. Это очень похоже на процесс, когда человек на основе наблюдений делает выводы и использует их в будущем для принятия решений.
1. Информация о типах колонок лежит в бд - у ИИ нет доступа к вашей БД.
Тип колонки в 99% успешно определяется по её содержимому. Также можно пробежать по результату глазами. Или засунуть в промт DDL таблиц.
2. Формировать ДТО по результату запроса (выборке с данными) - какая-то глупость.
Аргументация? Моя ситуация - работаю с легаси-кодом. Документации - ноль. Процедурный стиль. Спагетти-код. Я "причесал" длиннющий несопровождаемый запрос к БД, скормил результат ИИ и получил DTO, смысл которого в большей степени не в трансфере объектов, а чтобы IDE начало мне подсказывать поля, возвращаемые запросом, и я в стопятисотый раз не задавался вопросом, а что же эта простыня возвращает.
Так что не знаю, глупость это или не глупость, а я сделал себе в работе удобно. И сделал этот быстро.
3. ДТО должно задаваться явно на бэкенде, на основе среза сущностей, или там автогенерации кода.
Подскажите, как мне автосгенерировать DTO, в котором хранится результат запроса к нескольким таблицам, да ещё с использованием хранимых функций (реализующих вычислимые поля) и конструкции CASE WHEN в PostgreSQL?
Цель не в создании ценного программного обеспечения, а в решении бизнес-задач. Например, главному энергетику завода нужно прогнозировать количество потребляемой электроэнергии, так как завод платит не по факту, а покупает мощности заранее. Затем он должен следить за тем, чтобы не превышать эти объёмы, учитывая тарифные зоны. В реальной ситуации, если завод превышал объёмы, то даже останавливал литейку с электрическими печами, чтобы избежать штрафов. Раньше на заводе несколько сотрудниц вручную снимали показания со счётчиков и рассчитывали потреблённый объём. Теперь их заменили контроллером и программным обеспечением. Но цель здесь не в написании ПО, а в контроле объёмов потребляемой электроэнергии.
Анализ — это процесс разложения сложного явления, объекта или проблемы на составные части с целью их исследования, выявления закономерностей и взаимосвязей между ними. Цель анализа — понять структуру объекта, его функционирование и взаимодействие частей, а также выявить возможные причины или последствия происходящих изменений.
Обучающая выборка и алгоритмы позволяют модели распознавать паттерны, которые могут внешне напоминать анализ. Хотя это больше про статистику, чем про мышление или сознательный анализ.
ИИ использует свои знания набор вероятностей для токенов, сформированных на основе обучающих данных, для предсказания или выполнения задачи.
Так что в некотором смысле можно сказать, что ИИ "анализирует", но это следует понимать как процесс сложной обработки данных и выявления закономерностей, а не как человеческую способность к осмысленному размышлению.
Так преподавателям что нужно, чтобы школьник умел решать задачи, или чтобы он обладал навыком устного (или как это назвать) счёта? Отберите у современных самолётов приборы навигации и о ужас-ужас, пилоты впадут в ступор.
Есть задачи, связанные с творчеством, а есть не связанные. Написать сложный запрос к БД - творчество. Написать DTO к результатам данного запроса - рутина. Сгенерировать pdf к результатам данного запроса - рутина.
Здесь всё тоже самое, что и на кухне. Чтобы приготовить изысканное блюдо, придётся помыть овощи, почистить картофель, нарезать продукты на кусочки нужного размера. Здесь нет творчества. Здесь сплошная рутина.
Человеки почему-то считают, что оно залезет к ним в мозги и само узнает, как они на самом деле хотели
А вот тут как раз так и происходит. Обычно человеки не знают, что они хотят на самом деле. За десятилетия работы неоднократно сталкивался с ситуацией: "ой, а что, так можно было? А можно тогда ещё вот так..." Это поведение можно охарактеризовать фразой: аппетит приходит во время еды.
А ИИ предлагает решение на основе анализа 100500 решений, в том числе таких, какие пока ещё не приходят в голову заказчику, но вполне себе могут прийти во время разработки.
Т.е. получается, ИИ всё-таки может "предугадать" чего же они на самом деле хотят. Ну просто потому, что они сами об этом не знают.
Ваш пример выхолощенный. Вот иной пример: наконец-то закончен запрос к БД с использованием CTE, многочисленных join и union. Получаем результат запроса, отдаём его ИИ и просим создать DTO. Секунда и у нас класс DTO с типизированными полями. И этот класс написать нифига не короче, чем промт. При этотм очевидно, что работа простая, но рутинная.
Калькулятор никогда не заменит профессионального расчетчика. Считать следует в уме, без этого тупеют.
Калькулятор — это инструмент, как и любой другой, а главное в расчетах — это понимание, как они работают. Без знаний, как считать и что считать, никакой ум не спасет. Простое механическое вычисление без осмысления — это не умственный труд, а скорее цирковое представление. Примером могут служить инженеры-проектировщики электронных плат: их задача — знать, как все элементы схемы взаимодействуют между собой, чтобы создать рабочий проект. А тот, кто просто паяет детали на плату, не должен разбираться в сложных расчетах, его задача — выполнять механическую работу. Проектировщик — это расчетчик с глубокими знаниями, а калькулятор — лишь инструмент, помогающий ускорить рутинные операции.
В свое время кодил на ДВК, название редактора не помню, но по сути что-то вроде vi, знаешь хоткеи - будешь жить. Строк на экране было 24, на 80 символов. Из окошка в окошко переключаться не получится. Окошкек нету. Зато актуальными были распечатки - полотенца кода на рулоне бумажки, ибо 24 строки всё же маловато, чтобы охватить код. Так что Вы абсолютно правы, это было медленно. А если ещё учесть, что не было интернетов и приходилось изобретать велосипеды, то это было крайне медленно.
непосредственно кодинг это единственное вкусное в работе
Есть интересные задачи, действительно вкусные в работе. А есть рутина, которую нужно сделать, иначе вкусное работать не будет. Непосредственно кодинг не одинаков по вкусности.
Не вижу ничего плохого в передаче написания Boilerplate кода ИИ. Написание этого кода вручную — потеря времени и никакой выгоды для программиста. Простой пример: выборка из базы из кучи таблиц с кучей join и кучей полей в select. Показал результат запроса ИИ, попросил создать DTO, объяснил IDE, что вот эта функция возвращает коллекцию вот этих DTO и жизнь улучшается в разы. Теперь IDE услужливо подсказывает имена всех полей, и даже может показать их все, если с памятью совсем плохо.
Вообще просить ИИ написать код, который можешь написать сам — хорошая идея. Проситель так или иначе этот код напишет + сможет проконтролировать, чего там понаписал этот ИИ. А промахи этот ИИ совершает частенько. Остаётся контроль и исправление. Либо руками, либо повторными промтами.
А вот чего делать не нужно — так это тащить в разработку куски кода, которые непонятно как работают (для спрашивающего). Да, сейчас они вроде как и делают то, что нужно. Но будут ли этот делать в дальнейшем, с ростом кодовой базы и оптимально — большой вопрос.
Давно пора. А то пытаешься в деревне приложение банка открыть, и тоска берёт. Эх, были раньше мастера, которые картинку резали на кусочки, чтобы в каждом оказалась 4-х битовая палитра, но в картинке было куда больше цветов. И красиво, и весит копейки.
Я нормально отношусь к минусам с пометкой: личная неприязнь. Ну кому-то я не мил. Бывает. Человек «отстрелялся», больше он минус не поставит.
А вот такие пометки, как: подозрительная активность, реклама вызывают удивление. В активности — ничего подозрительного. Ничего не рекламирую. И самое нехорошее, что обратной связи, о которой столько много говорят, таки нет. Я так и не понял, и что же у меня приняли за рекламу? Я бы и исправился, и перестал бы рекламировать то, не знаю что. Или прекратил себя вести подозрительно. Но гадать на кофейной гуще как-то не хочется.
Так и человеки находят закономерности только в тех явлениях, которые наблюдают.
Сильно сомневаюсь. Не все вообще видели осьминогов, и мало кто представляет, что с ними делать и без языка жестов.
А если ещё учесть, что жестовых языков более одного, и органы жестикулирования отличаются от наших, то будет вообще ой...
Почему? Возможно, моё понимание этого вопроса неверно, поправьте меня, если я ошибаюсь.
Я считаю, что ИИ всё-таки выявляет закономерности, которые отражаются в коэффициентах, вычисляемых на основе обучающих данных. ИИ наблюдает явления (точнее, за него это делают), а затем выявляет зависимости. Таким образом, второй пункт однозначно применим, ведь ИИ находит закономерности в данных. Эти закономерности затем используются для обработки новых входных данных. По сути, ИИ преобразует входные сигналы, применяя те самые выявленные зависимости.
Наблюдение явления: ИИ анализирует большие объемы данных, которые представляют собой наблюдения различных явлений. Например, в случае с языковыми моделями, такими как GPT, данные включают миллиарды текстов, содержащих разнообразные примеры использования языка.
Выявление закономерностей: В процессе обучения ИИ использует алгоритмы, такие как градиентный спуск, для оптимизации весов модели. Эти веса отражают выявленные закономерности в данных. Например, модель может обнаружить, что после слов "как зовут Гагарина" с высокой вероятностью следует "Юрий".
Использование выявленных закономерностей: После обучения модель использует эти закономерности для генерации ответов на новые входные данные. Это позволяет ИИ преобразовывать входной сигнал (например, вопрос) в осмысленный выход (например, ответ), основываясь на выявленных закономерностях.
Генерализация: Ещё один важный аспект работы ИИ способность к генерализации, то есть применению выявленных закономерностей к новым, невиданным ранее данным. Это очень похоже на процесс, когда человек на основе наблюдений делает выводы и использует их в будущем для принятия решений.
Если нет, то можно засунуть тот же DDL в промт.
Тип колонки в 99% успешно определяется по её содержимому. Также можно пробежать по результату глазами. Или засунуть в промт DDL таблиц.
Аргументация? Моя ситуация - работаю с легаси-кодом. Документации - ноль. Процедурный стиль. Спагетти-код. Я "причесал" длиннющий несопровождаемый запрос к БД, скормил результат ИИ и получил DTO, смысл которого в большей степени не в трансфере объектов, а чтобы IDE начало мне подсказывать поля, возвращаемые запросом, и я в стопятисотый раз не задавался вопросом, а что же эта простыня возвращает.
Так что не знаю, глупость это или не глупость, а я сделал себе в работе удобно. И сделал этот быстро.
Подскажите, как мне автосгенерировать DTO, в котором хранится результат запроса к нескольким таблицам, да ещё с использованием хранимых функций (реализующих вычислимые поля) и конструкции CASE WHEN в PostgreSQL?
Спасибо!
Цель не в создании ценного программного обеспечения, а в решении бизнес-задач. Например, главному энергетику завода нужно прогнозировать количество потребляемой электроэнергии, так как завод платит не по факту, а покупает мощности заранее. Затем он должен следить за тем, чтобы не превышать эти объёмы, учитывая тарифные зоны. В реальной ситуации, если завод превышал объёмы, то даже останавливал литейку с электрическими печами, чтобы избежать штрафов. Раньше на заводе несколько сотрудниц вручную снимали показания со счётчиков и рассчитывали потреблённый объём. Теперь их заменили контроллером и программным обеспечением. Но цель здесь не в написании ПО, а в контроле объёмов потребляемой электроэнергии.
Анализ — это процесс разложения сложного явления, объекта или проблемы на составные части с целью их исследования, выявления закономерностей и взаимосвязей между ними. Цель анализа — понять структуру объекта, его функционирование и взаимодействие частей, а также выявить возможные причины или последствия происходящих изменений.
Обучающая выборка и алгоритмы позволяют модели распознавать паттерны, которые могут внешне напоминать анализ. Хотя это больше про статистику, чем про мышление или сознательный анализ.
ИИ использует
свои знаниянабор вероятностей для токенов, сформированных на основе обучающих данных, для предсказания или выполнения задачи.Так что в некотором смысле можно сказать, что ИИ "анализирует", но это следует понимать как процесс сложной обработки данных и выявления закономерностей, а не как человеческую способность к осмысленному размышлению.
Так преподавателям что нужно, чтобы школьник умел решать задачи, или чтобы он обладал навыком устного (или как это назвать) счёта? Отберите у современных самолётов приборы навигации и о ужас-ужас, пилоты впадут в ступор.
Есть задачи, связанные с творчеством, а есть не связанные. Написать сложный запрос к БД - творчество. Написать DTO к результатам данного запроса - рутина. Сгенерировать pdf к результатам данного запроса - рутина.
Здесь всё тоже самое, что и на кухне. Чтобы приготовить изысканное блюдо, придётся помыть овощи, почистить картофель, нарезать продукты на кусочки нужного размера. Здесь нет творчества. Здесь сплошная рутина.
А вот тут как раз так и происходит. Обычно человеки не знают, что они хотят на самом деле. За десятилетия работы неоднократно сталкивался с ситуацией: "ой, а что, так можно было? А можно тогда ещё вот так..." Это поведение можно охарактеризовать фразой: аппетит приходит во время еды.
А ИИ предлагает решение на основе анализа 100500 решений, в том числе таких, какие пока ещё не приходят в голову заказчику, но вполне себе могут прийти во время разработки.
Т.е. получается, ИИ всё-таки может "предугадать" чего же они на самом деле хотят. Ну просто потому, что они сами об этом не знают.
Ваш пример выхолощенный. Вот иной пример: наконец-то закончен запрос к БД с использованием CTE, многочисленных join и union. Получаем результат запроса, отдаём его ИИ и просим создать DTO. Секунда и у нас класс DTO с типизированными полями. И этот класс написать нифига не короче, чем промт. При этотм очевидно, что работа простая, но рутинная.
Калькулятор — это инструмент, как и любой другой, а главное в расчетах — это понимание, как они работают. Без знаний, как считать и что считать, никакой ум не спасет. Простое механическое вычисление без осмысления — это не умственный труд, а скорее цирковое представление. Примером могут служить инженеры-проектировщики электронных плат: их задача — знать, как все элементы схемы взаимодействуют между собой, чтобы создать рабочий проект. А тот, кто просто паяет детали на плату, не должен разбираться в сложных расчетах, его задача — выполнять механическую работу. Проектировщик — это расчетчик с глубокими знаниями, а калькулятор — лишь инструмент, помогающий ускорить рутинные операции.
Кочегары и работники паровозных колонок негодуют!
В свое время кодил на ДВК, название редактора не помню, но по сути что-то вроде vi, знаешь хоткеи - будешь жить. Строк на экране было 24, на 80 символов. Из окошка в окошко переключаться не получится. Окошкек нету. Зато актуальными были распечатки - полотенца кода на рулоне бумажки, ибо 24 строки всё же маловато, чтобы охватить код. Так что Вы абсолютно правы, это было медленно. А если ещё учесть, что не было интернетов и приходилось изобретать велосипеды, то это было крайне медленно.
Есть интересные задачи, действительно вкусные в работе. А есть рутина, которую нужно сделать, иначе вкусное работать не будет. Непосредственно кодинг не одинаков по вкусности.
Не вижу ничего плохого в передаче написания Boilerplate кода ИИ. Написание этого кода вручную — потеря времени и никакой выгоды для программиста. Простой пример: выборка из базы из кучи таблиц с кучей join и кучей полей в select. Показал результат запроса ИИ, попросил создать DTO, объяснил IDE, что вот эта функция возвращает коллекцию вот этих DTO и жизнь улучшается в разы. Теперь IDE услужливо подсказывает имена всех полей, и даже может показать их все, если с памятью совсем плохо.
Вообще просить ИИ написать код, который можешь написать сам — хорошая идея. Проситель так или иначе этот код напишет + сможет проконтролировать, чего там понаписал этот ИИ. А промахи этот ИИ совершает частенько. Остаётся контроль и исправление. Либо руками, либо повторными промтами.
А вот чего делать не нужно — так это тащить в разработку куски кода, которые непонятно как работают (для спрашивающего). Да, сейчас они вроде как и делают то, что нужно. Но будут ли этот делать в дальнейшем, с ростом кодовой базы и оптимально — большой вопрос.
FIDO?
Давно пора. А то пытаешься в деревне приложение банка открыть, и тоска берёт. Эх, были раньше мастера, которые картинку резали на кусочки, чтобы в каждом оказалась 4-х битовая палитра, но в картинке было куда больше цветов. И красиво, и весит копейки.
Не подскажете, какое решение для частого сервера используете? Железо у себя дома + белый IP у провайдера? Или иное решение?