Вот вы совсем не правы. Никакого естественного сценария моторики стопы обложенными мягкими толстыми подошвами с ортоедическими стельксми не было в эволюции стопы. Если вы можете бегать только со всеми этими костылями возможно вам не полезно бегать для здоровья. Надо или нет уже ваше решение. Но кардио можно и другой активностью догнать, вместе с другими травмами)
Все сложнее. Масса моих знакомых распрощалась с суставами уже разрядниками, играючи осиливающими 150 в одном подходе обнявшись. Цифры без понимания, без осознания процесса, причин, это путь в не туда.
Кроссовки вообще противоестественны. Как компенсация противоестественного асфальта. Но я вам скажу что однотонные 42 км по ровной твёрдой поверхности это неестественно совсем вот никак.
Наш отдел по продаже каким то образом продал наш продукт совершенно не желающим думать индивидуумам. Отлично!
Значит мы думаем и принимаем решения за них.
Скорее всего мы когда-нибудь вывалимся в эксепшн с таким подходом. Но раз мы 90% этого бреда уже на уровне модели техподдержки локализовываем в какое то системное бегание по интерфейсу пользователем (т.е. прочтению справки), то обработку 90% эксепшена мы выносим уже в само приложение, уже в UI.
Остается 10% исключений с высокими весами т.е. работа для реальной техподдержки.
PROFIT? Возможно, но над подсчитать веса таких решений.
ПС1. Перевожу: мы интегрируем модуль техподдержки прям в приложуху, в каком либо виде, желательно вообще бесшовно. У нас есть бигдата действий пользователей, приводящих к проблемам. Приложуха отслеживает паттерны работы пользователя на предмет соответствия проблемным и ведет пользователя за ручку в светлое будущее мимо грабель.
Теперь вопрос - почему сразу в архитектуру, сам продукт не закладывать да хоть с помощью того же ии такой вариант реализации, который генерит обращения от уважаемых пользователей в техподдержку по минимуму, а не вал в "90% лень справку почитать"?
Не совсем правда ваша. Решения на ИИ могут удешевлять смежные конкурентные продукты насколько, что из "решений, которые не представлены в открытых источниках" будут переходить на "решения, которые в них представлены" и соответственно дешево автоматизированы.
Не думаю что вы сколь-нибудь часто сталкиваетесь с реальными задачами, где Ньютон и Эйлер безнадежно устарел. Может где на пике с выходом за граничные условия, но денег на такое обычно ни у кого нет.
ПС. арифметика то куда уж старее, а коптит еще старушка, подставляет плечи потомкам.
совсем не так. Никто на работе не дает оплаченный год вперед на "ты тут изучи всю базу по этой задаче, что там как от Аристотеля до хотя б 60х годов 20го века", а потом приходи с идеями будем мыслить что делать.
Я уже за три десятка лет много много раз пробовал что то новое изучать по классической программе с теоретических основ - не взлетало. Нужно много свободного времени и много свободной энергии. (здесь конечно еще играет и то, что первое теоретическое я получал потому что надо им и бежал по верхам не оглядываясь, а последующие потому что надо мне и застревал прям на входе т.к. копал очень глубоко и смежные дисциплины тоже).
Какую то пользу я от этого получал и иногда бОльшую, чем выпускники по тем профессиям, но...
Технически я могу нейросетку попросить мне полную копию такой то книги пересказать? Сколько это будет в токенах и стоимости? Что случиться с авторским правом при этом?
Вопрос в том что Вы не можете гарантировать что он что то там "запомнит". Мы ж даже не можем гарантировать повторяемость. Ну ок, мы создали что то очень прикольное, только это, судя по тыканием промптами в небо, черный ящик, мы даже не можем теорию по промптам подогнать к этому всему, у нас нет в нашем процессе сходимости решений к искомому и даже оценок сходится ли оно или расходится.
Если бы у нас была сходимость, то при каждом следующем уточнении мы бы получали более приближенное решение и все это промптотворчество было бы вопросом оптимизации количества запросов - ну чистые числовые методы решения задачи только по оси X у нас промпты вместо числовых значений. Какие то методы подбора промптом быстрее сходятся, какие то медленнее, но сходятся.
Давайте тогда уже выкатывать теорию сходящихся промптов, окна памяти там LLM-ки, что то вроде первый промпт описывает 80% задачи, базу, далее анализ ответа на угадала ли модель контекст и выправление ее рассуждений к решению. Ну и наблюдение и оценка насколько ее решения приближаются к искомому, а не уходят в разнос.
И конечно нам по ходу решения этой задачи придется "оцифровать" тексты и решения в математику, что бы сравнивать количественно результаты - это отдельный вопрос.
не ну как ребята, смотря что за метод и что подразумеваем под "писать". Иногда ж больше нескольких суток уходит на исправление одной-двух строчек и это не какой-нибудь там плавающий баг, а вполне себе бизнесс-логика, только заказанные ее изменения рушат архитектурную концепцию или размазаны по объектам тонким слоем. Иногда железячные и временные ограничения диктуют архитектурирование что в страшном сне потом снится и там тоже на скуле специфичную бизнес-логику вырисовывать это прям серьезно поболее чем пол-дня и даже дни.
Прочитать можно и условные письмена майя, только смысла в этом нет никакого кроме спортивного интереса - информация полученная из них не стоит усилий, на них затраченных. Нет там ничего про тайны вселенной и холодный термояд. Разве что прокачать скиллы расшифровки - полезная побочка, не более.
И в этом плане - донести до потомков как это работает - программный код проигрывает банальному хорошо написанному ТЗ искомой программы, где вместо скрижалей COBOL-а и сотен часов умственного реверс-инженеринга разработчик получает инструкцию как оно должно работать и создает реализацию на любом стильном модном молодежном инструменте, покрывает тестами и в прод.
Поэтому нет, для задачи самодокументирования текстовый именно программный код не лучшее решение. Если это активный стек разработки и активно развивающаяся программа то да, код текста не так уж и плох, но только в связке со сколь-нибудь вменяемым ТЗ, а если мы про некро-программы, похороненными миллионами строк кода и сотнями умерших зависимостей, то ТЗ в первую очередь.
Потому что все реализации будут опираться на какой-нибудь фреймворк и что бы понимать достоверно как оно вообще работало этот некро-фреймворк надо будет изучать, знать и экспериментировать. А фреймворк к тому моменту со своей средой исполнения уже будет безвозвратно мертв со всеми явными и неявными зависимостями и их характерными нигде не документированными очень важными багами, простите особенностями.
Вот вы совсем не правы. Никакого естественного сценария моторики стопы обложенными мягкими толстыми подошвами с ортоедическими стельксми не было в эволюции стопы. Если вы можете бегать только со всеми этими костылями возможно вам не полезно бегать для здоровья. Надо или нет уже ваше решение. Но кардио можно и другой активностью догнать, вместе с другими травмами)
12 у меня некоторые модели с длинной 29, но в главном соглашусь- на оверсайз делают периодически грандиозные скидки.
Дай обниму!(с) Самый важный вопрос - зачем бежишь, человек? задали.
Все сложнее. Масса моих знакомых распрощалась с суставами уже разрядниками, играючи осиливающими 150 в одном подходе обнявшись. Цифры без понимания, без осознания процесса, причин, это путь в не туда.
Кроссовки вообще противоестественны. Как компенсация противоестественного асфальта. Но я вам скажу что однотонные 42 км по ровной твёрдой поверхности это неестественно совсем вот никак.
А смысл, коллега? Расстояния, время, набор высоты, трейлы?
Какие задачи решает ваша обувь? 'Правильная' она для каких задач? Для каких стоп? Для какого анамнеза?
Бегать вредно? Да, вредно. Бегать полезно? Да, полезно. Смотря как, смотря зачем, смотря куда и смотря кому.
Бегать можно в ботинках и это будет правильно, можно босиком и тоже будет правильно, а можно и не бегать и видов бега тоже ведь масса.
Правда тут надо уже на старте закладывать, что вести за ручку она будет не пользователя, а другой ИИ, такие дела...
Наш отдел по продаже каким то образом продал наш продукт совершенно не желающим думать индивидуумам.
Отлично!
Значит мы думаем и принимаем решения за них.
Скорее всего мы когда-нибудь вывалимся в эксепшн с таким подходом.
Но раз мы 90% этого бреда уже на уровне модели техподдержки локализовываем в какое то системное бегание по интерфейсу пользователем (т.е. прочтению справки), то обработку 90% эксепшена мы выносим уже в само приложение, уже в UI.
Остается 10% исключений с высокими весами т.е. работа для реальной техподдержки.
PROFIT?
Возможно, но над подсчитать веса таких решений.
ПС1. Перевожу: мы интегрируем модуль техподдержки прям в приложуху, в каком либо виде, желательно вообще бесшовно. У нас есть бигдата действий пользователей, приводящих к проблемам. Приложуха отслеживает паттерны работы пользователя на предмет соответствия проблемным и ведет пользователя за ручку в светлое будущее мимо грабель.
Теперь вопрос - почему сразу в архитектуру, сам продукт не закладывать да хоть с помощью того же ии такой вариант реализации, который генерит обращения от уважаемых пользователей в техподдержку по минимуму, а не вал в "90% лень справку почитать"?
Зачем вообще пользователю читать справку?
UI должен сам по себе быть той справкой.
Не совсем правда ваша. Решения на ИИ могут удешевлять смежные конкурентные продукты насколько, что из "решений, которые не представлены в открытых источниках" будут переходить на "решения, которые в них представлены" и соответственно дешево автоматизированы.
Не думаю что вы сколь-нибудь часто сталкиваетесь с реальными задачами, где Ньютон и Эйлер безнадежно устарел. Может где на пике с выходом за граничные условия, но денег на такое обычно ни у кого нет.
ПС. арифметика то куда уж старее, а коптит еще старушка, подставляет плечи потомкам.
совсем не так. Никто на работе не дает оплаченный год вперед на "ты тут изучи всю базу по этой задаче, что там как от Аристотеля до хотя б 60х годов 20го века", а потом приходи с идеями будем мыслить что делать.
Я уже за три десятка лет много много раз пробовал что то новое изучать по классической программе с теоретических основ - не взлетало. Нужно много свободного времени и много свободной энергии. (здесь конечно еще играет и то, что первое теоретическое я получал потому что надо им и бежал по верхам не оглядываясь, а последующие потому что надо мне и застревал прям на входе т.к. копал очень глубоко и смежные дисциплины тоже).
Какую то пользу я от этого получал и иногда бОльшую, чем выпускники по тем профессиям, но...
ВУЗ ВУЗу очень большая рознь. Какой вид ВУЗов вы сейчас имеете в виду?
"I say: never be complete. I say: stop being perfect. I say: let's evolve, let the chips fall where they may"
Технически я могу нейросетку попросить мне полную копию такой то книги пересказать?
Сколько это будет в токенах и стоимости? Что случиться с авторским правом при этом?
Вопрос в том что Вы не можете гарантировать что он что то там "запомнит". Мы ж даже не можем гарантировать повторяемость. Ну ок, мы создали что то очень прикольное, только это, судя по тыканием промптами в небо, черный ящик, мы даже не можем теорию по промптам подогнать к этому всему, у нас нет в нашем процессе сходимости решений к искомому и даже оценок сходится ли оно или расходится.
Если бы у нас была сходимость, то при каждом следующем уточнении мы бы получали более приближенное решение и все это промптотворчество было бы вопросом оптимизации количества запросов - ну чистые числовые методы решения задачи только по оси X у нас промпты вместо числовых значений. Какие то методы подбора промптом быстрее сходятся, какие то медленнее, но сходятся.
Давайте тогда уже выкатывать теорию сходящихся промптов, окна памяти там LLM-ки, что то вроде первый промпт описывает 80% задачи, базу, далее анализ ответа на угадала ли модель контекст и выправление ее рассуждений к решению. Ну и наблюдение и оценка насколько ее решения приближаются к искомому, а не уходят в разнос.
И конечно нам по ходу решения этой задачи придется "оцифровать" тексты и решения в математику, что бы сравнивать количественно результаты - это отдельный вопрос.
Куда мы катимся, граждане?
Господа, пора впитывать новые веяния, а не вот это вот все...
не ну как ребята, смотря что за метод и что подразумеваем под "писать".
Иногда ж больше нескольких суток уходит на исправление одной-двух строчек и это не какой-нибудь там плавающий баг, а вполне себе бизнесс-логика, только заказанные ее изменения рушат архитектурную концепцию или размазаны по объектам тонким слоем. Иногда железячные и временные ограничения диктуют архитектурирование что в страшном сне потом снится и там тоже на скуле специфичную бизнес-логику вырисовывать это прям серьезно поболее чем пол-дня и даже дни.
Прочитать можно и условные письмена майя, только смысла в этом нет никакого кроме спортивного интереса - информация полученная из них не стоит усилий, на них затраченных. Нет там ничего про тайны вселенной и холодный термояд. Разве что прокачать скиллы расшифровки - полезная побочка, не более.
И в этом плане - донести до потомков как это работает - программный код проигрывает банальному хорошо написанному ТЗ искомой программы, где вместо скрижалей COBOL-а и сотен часов умственного реверс-инженеринга разработчик получает инструкцию как оно должно работать и создает реализацию на любом стильном модном молодежном инструменте, покрывает тестами и в прод.
Поэтому нет, для задачи самодокументирования текстовый именно программный код не лучшее решение. Если это активный стек разработки и активно развивающаяся программа то да, код текста не так уж и плох, но только в связке со сколь-нибудь вменяемым ТЗ, а если мы про некро-программы, похороненными миллионами строк кода и сотнями умерших зависимостей, то ТЗ в первую очередь.
Потому что все реализации будут опираться на какой-нибудь фреймворк и что бы понимать достоверно как оно вообще работало этот некро-фреймворк надо будет изучать, знать и экспериментировать. А фреймворк к тому моменту со своей средой исполнения уже будет безвозвратно мертв со всеми явными и неявными зависимостями и их характерными нигде не документированными очень важными багами, простите особенностями.