Я вот пока тоже не очень вижу смысл сейчас в таком виде использовать но вполне может оказаться что таких домашних применений столько же, сколько у компьютеров. Когда-то IBM не понимала зачем обычным людям компьютеры, это же только банкирам надо и учёным. Если Claw будет встроена в телефон на глубоком уровне, вполне может прижиться. И у обычных людей тоже много повторяющихся задач.
Так из чего тогда вы делаете вывод, что на общение на английском намного лучше для нейросети, чем на русском если вы не проводите сравнений в одинаковых условиях? За год модели сильно изменились.
Синтаксис это ж слишком узко, там и грамматика хорошо фиксируется и более высокоуровневые связи. Статистика уже тогда. Ну, так-то и у нейронов тогда тоже нет семантики, это свёртка биологических и физических процессов, всей истории с ними происходящей. А в итоге текст на Хабре пишется. Опять философия больше.
Я думаю, если уровень английского не native speaker, то намного больше неоднозначностей и искажений вносится именно корявым английским, чем если по-русски корректно излагать. Как ни крути у каждого слова множество неоднозначных оттенков, которые только нейтив хорошо уловит.
Хорошо бы примеры, а не полагаться на чей-то опыт.
Ну, вот для муравьиной симуляции, полностью навайбкоженой https://d3ffcn.csb.app/ когда сталкиваюсь с плохой обучаемостью, я для начала описываю суть проблемы. Она выдаёт возможные причины, потом идем по шагам - что как сделано и для чего. Оцениваю и если надо углубляюсь. Она описывает все возможные популярные варианты, например, поиска выхода из локальных максимумов. Я оцениваю, что применимо для игрушечных условий симуляции, что слишком сложно и ресурсоемко. Если что-то непонятно, спрашиваю. Потом, когда на чём-то остановились, говорю ей чтоб делала. Проверяю результат. Это и для исправления и для новой генерации подходит. Но полезно, конечно, вникать, потому что любое решение - компромисс между чем-то. Можно спрашивать чем хорош и плох такой-то подход. В сложных областях, конечно, полезно параллельно теоретический бэкграунд прокачивать. Одна нейросеть не даст образования по крайней мере не при таком подходе. Тем более что в режиме кода она всё-таки скудные текстовые пояснения выдаёт.
Вопрос философский скорее, настолько же отдалённый от практических задач, как и в целом пост. Семантика векторного пространства эмбеддингов тогда тоже "аналоговая" и что нам с этого? Полезность и возможность использования обычного языка для кодинга с нейросетями это ничуть не уменьшает, а скорее наоборот.
Это нормально когда не знаешь чего хочешь в деталях. Часто написание программы это именно поиск, а не кодирование уже чётко известной задачи. Вот в поиске нейросети тоже хорошо помогают, разъясняют, предоставляют возможности для выбора, самообразования и прочего. Конечно, есть оговорки, они не научат прямо какой-то сложной области и когда нет в целом понимания бывает полезнее не просто мучать вопросами ходя по кругу, а почитать что-то базовое. Но это если совсем новая область или библиотека. Там лучше с её доки начать и пробежаться по API чтоб знать возможности для начала. А насчёт экспериментов, так с ИИ их проще делать во много раз. Попробуйте дать Claude Opus на Арене свою задачу хорошо описанную, только оставьте нейросети манёвр для действий, разъяснений, может быть уточнений даже, а не пишите сразу сделай так-то.
Вы его скорее всего как-то не так спрашиваете или используете. Можно блуждать вокруг да около, ища идеальное решение, но с ИИ можно за вечер проверить сразу все варианты и посмотреть какой больше подойдёт. А переделка не будет ужасом потом, с ним и переделаете за другой вечер, если что.
Ну да, для того трансформеры и придумывали, чтобы контекст улавливать. Проблема надуманная поднята, актуальная только если задача по 1 (одному) промпту сделать сразу сложное приложение и менять его запрещено.
Часто постулируется факт, что ни один ИИ никогда не дорастёт своим скудным электронным умишком и не сравнится в гениальности распознавания запросов заказчика так, как это делает программист.
Да какая двусмысленность команд, откуда эти надуманные проблемы? Я вот за 25+ лет работы не сталкивался с проектами, которые бы были детально описаны и по этому описанию без изменений реализовывались. Очень давно да, пытались в ТЗ, но те времена уже давно прошли. Проекты - результат постоянного взаимодействия. Для этого и придумали эдайл всякий, спринты. Есть MVP, описанный больше как набор идей, из которых дизайнер или команда будет что-то создавать, есть подгонка под реальность, которая тоже постоянно меняется, есть изменение видения того, как что должно работать и что удобнее после отзывов. Любую задачу можно декомпозировать и описывать по частям, эволюционно. Всё это вполне однозначно описывается человеческим языком. Кроме может дизайна и логотипов каких-то, но для этого есть другие инструменты.
Экспертность иногда полезна, иногда наоборот создаёт зашоренный взгляд на вещи. Но иногда бывает нужно ее остановить от явно ошибочных направлений. А вот чтобы ИИ говорила, что требование не ложится в архитектуру приложения, надо её... спрашивать. Неожиданно, да? :) Но вот именно такой режим мне кажется оптимальным, особенно если вы выходите чуть из вашей предметной области, где точно эксперт. А быть экспертом во всём даже в рамках IT ну никак невозможно. Дайте ей описание того, что вы хотите, чего опасаетесь, какой результат был бы оптимален, что сейчас есть. Переключите в режим планирования, тогда не будет сразу бежать исполнять. Пообщайтесь с моделью, это полезно. И она лучше требования уловит, подтянет правильные куски латентного пространства к контексту, и вы её будете контролировать и много нового узнавать. Когда инструмент уже не код, а речь, нужно и способ общения менять.
Я вот пока тоже не очень вижу смысл сейчас в таком виде использовать но вполне может оказаться что таких домашних применений столько же, сколько у компьютеров. Когда-то IBM не понимала зачем обычным людям компьютеры, это же только банкирам надо и учёным. Если Claw будет встроена в телефон на глубоком уровне, вполне может прижиться. И у обычных людей тоже много повторяющихся задач.
Конечно, каждый сам выбирает как использовать инструменты и совсем всё он не заменит.
Странно, что не видите. Вот всё это может сделать сам или помочь разобраться ИИ.
Так из чего тогда вы делаете вывод, что на общение на английском намного лучше для нейросети, чем на русском если вы не проводите сравнений в одинаковых условиях? За год модели сильно изменились.
Синтаксис это ж слишком узко, там и грамматика хорошо фиксируется и более высокоуровневые связи. Статистика уже тогда. Ну, так-то и у нейронов тогда тоже нет семантики, это свёртка биологических и физических процессов, всей истории с ними происходящей. А в итоге текст на Хабре пишется. Опять философия больше.
Я думаю, если уровень английского не native speaker, то намного больше неоднозначностей и искажений вносится именно корявым английским, чем если по-русски корректно излагать. Как ни крути у каждого слова множество неоднозначных оттенков, которые только нейтив хорошо уловит.
Хорошо бы примеры, а не полагаться на чей-то опыт.
Ну, вот для муравьиной симуляции, полностью навайбкоженой https://d3ffcn.csb.app/ когда сталкиваюсь с плохой обучаемостью, я для начала описываю суть проблемы. Она выдаёт возможные причины, потом идем по шагам - что как сделано и для чего. Оцениваю и если надо углубляюсь. Она описывает все возможные популярные варианты, например, поиска выхода из локальных максимумов. Я оцениваю, что применимо для игрушечных условий симуляции, что слишком сложно и ресурсоемко. Если что-то непонятно, спрашиваю. Потом, когда на чём-то остановились, говорю ей чтоб делала. Проверяю результат. Это и для исправления и для новой генерации подходит. Но полезно, конечно, вникать, потому что любое решение - компромисс между чем-то. Можно спрашивать чем хорош и плох такой-то подход. В сложных областях, конечно, полезно параллельно теоретический бэкграунд прокачивать. Одна нейросеть не даст образования по крайней мере не при таком подходе. Тем более что в режиме кода она всё-таки скудные текстовые пояснения выдаёт.
Вопрос философский скорее, настолько же отдалённый от практических задач, как и в целом пост. Семантика векторного пространства эмбеддингов тогда тоже "аналоговая" и что нам с этого? Полезность и возможность использования обычного языка для кодинга с нейросетями это ничуть не уменьшает, а скорее наоборот.
Это нормально когда не знаешь чего хочешь в деталях. Часто написание программы это именно поиск, а не кодирование уже чётко известной задачи. Вот в поиске нейросети тоже хорошо помогают, разъясняют, предоставляют возможности для выбора, самообразования и прочего. Конечно, есть оговорки, они не научат прямо какой-то сложной области и когда нет в целом понимания бывает полезнее не просто мучать вопросами ходя по кругу, а почитать что-то базовое. Но это если совсем новая область или библиотека. Там лучше с её доки начать и пробежаться по API чтоб знать возможности для начала. А насчёт экспериментов, так с ИИ их проще делать во много раз. Попробуйте дать Claude Opus на Арене свою задачу хорошо описанную, только оставьте нейросети манёвр для действий, разъяснений, может быть уточнений даже, а не пишите сразу сделай так-то.
И что же в семантике аналогово?
Вы точно понимаете что такое аналоговый и дискретный сигналы?
Вы его скорее всего как-то не так спрашиваете или используете. Можно блуждать вокруг да около, ища идеальное решение, но с ИИ можно за вечер проверить сразу все варианты и посмотреть какой больше подойдёт. А переделка не будет ужасом потом, с ним и переделаете за другой вечер, если что.
Ну да, для того трансформеры и придумывали, чтобы контекст улавливать. Проблема надуманная поднята, актуальная только если задача по 1 (одному) промпту сделать сразу сложное приложение и менять его запрещено.
Что мешает сразу писать тест кейсы и ничего не будет мстить, код-то всё равно никуда не девается. Разработали, получили желаемое, покрыли тестами.
В каком месте он аналоговый?
Часто постулируется факт, что ни один ИИ никогда не дорастёт своим скудным электронным умишком и не сравнится в гениальности распознавания запросов заказчика так, как это делает программист.
ИИ это уже давно не только про дополнение кода.
Да какая двусмысленность команд, откуда эти надуманные проблемы? Я вот за 25+ лет работы не сталкивался с проектами, которые бы были детально описаны и по этому описанию без изменений реализовывались. Очень давно да, пытались в ТЗ, но те времена уже давно прошли. Проекты - результат постоянного взаимодействия. Для этого и придумали эдайл всякий, спринты. Есть MVP, описанный больше как набор идей, из которых дизайнер или команда будет что-то создавать, есть подгонка под реальность, которая тоже постоянно меняется, есть изменение видения того, как что должно работать и что удобнее после отзывов. Любую задачу можно декомпозировать и описывать по частям, эволюционно. Всё это вполне однозначно описывается человеческим языком. Кроме может дизайна и логотипов каких-то, но для этого есть другие инструменты.
А в чем же проблема поддерживать работу сайта с какими угодно изменениями?
Экспертность иногда полезна, иногда наоборот создаёт зашоренный взгляд на вещи. Но иногда бывает нужно ее остановить от явно ошибочных направлений. А вот чтобы ИИ говорила, что требование не ложится в архитектуру приложения, надо её... спрашивать. Неожиданно, да? :) Но вот именно такой режим мне кажется оптимальным, особенно если вы выходите чуть из вашей предметной области, где точно эксперт. А быть экспертом во всём даже в рамках IT ну никак невозможно. Дайте ей описание того, что вы хотите, чего опасаетесь, какой результат был бы оптимален, что сейчас есть. Переключите в режим планирования, тогда не будет сразу бежать исполнять. Пообщайтесь с моделью, это полезно. И она лучше требования уловит, подтянет правильные куски латентного пространства к контексту, и вы её будете контролировать и много нового узнавать. Когда инструмент уже не код, а речь, нужно и способ общения менять.