С подобными задачами у меня нет особо опыта, но чисто умозрительно могу предположить, что не стоит ожидать, что вы дадите LLM первый документ, второй и третий, и она все сама сделает без ошибок даже когда документы длинные. Нейросети все равно не на уровне машин обрабатывают кучу информации, у некоторых даже возникает сопротивление, когда вывод достаточно длинный.
Можете попробовать опытным путем подобрать длину фрагментов, с которой ошибок минимум и попробовать декомпозировать задачу на сопоставимые по сложности подзадачи. Например, в исходных документах выделить разделы, сильно связанные по смыслу внутри и слабо между собой, либо если изложение последовательное, просто разделить на части, не знаю.
В любом случае при работе с нейросетью очень полезно понимать, на какие интеллектуальные подзадачи, обрабатывающие ограниченный объем контекста, разбивается основная задача. Что-то более конкретное сложно сказать, так как нужно смотреть задачу подробнее. Вообще, из того что слышал, писатели до сих пор не могут довериться нейросетям как раз в том числе из-за большой длины текстов.
В данном случае претензия к аналитику была не в том, что он что-то упустил (хотя и это имело место), а просто в том, что он невнятно сформулировал алгоритм.
UserStory - хорошее дополнение для основной постановки, позволяющее лучше ее понять, но не всегда достаточное само по себе. На проекте принято писать постановки в терминах бд сущностей, почему - не могу подсказать, но такие постановки часто напоминают псевдокод и ввиду детальности могут уже служить достаточно четким описанием нужного алгоритма.
В принципе можно поэкспериментировать и с постановками в другой форме - я думаю, что они тоже могут дать хороший результат, если глобально при работе с ИИ соблюдаются описанные в статье правила. Вообще, при дальнейшем движении в сторону автоматизации работы аналитика стоит рассмотреть самые разные формы спецификации требований, и возможно, найдется объективно оптимальная для работы с ИИ.
В моем случае верификация идёт полностью вручную, так как я хотел получить не просто достаточно хороший, а идеальный результат (то есть лучше которого я бы сам не сделал), поэтому мне нужно было убедиться, что он хорош во всех моментах, а не выборочно.
Постановка задачи в примере у вас не очень понятная. Статья по мотивам модуля (учитывая, что в модуле есть функции, значит это наверное модуль ПО) - это типа неформальной документации? Отождествлять то что обычно отождествляют - тоже достаточно расплывчатая формулировка.
Непонятно, что значит игнорирует фрагменты документов в контексте данной задачи. Не совсем понятно как длина контекста исправляет ненадежность верификации.
В целом, использовать LLM для верификации - нормальный подход. Из быстрых советов, которые могу дать даже не углубляясь в детали вашей проблемы - используйте о3 (отрабатывает для чуть ли не на 100% при простой проверке текстов вроде упомянутой вплоть до 100к слов) или Gemini 2.5 Pro (отрабатывает хорошо даже для 500к слов). Но если у вас настолько длинные тексты, я бы скорее всего не стал работать с ними целиком, а попробовал декомпозировать задачу. На первый взгляд, напоминает попытки загрузить в контекст весь исходный код проекта, когда можно этого не делать
Звучит здраво, хотя мне до сих пор не требовалось как-то особо усиливать промпты, так как при грамотной постановке у модели в любом случае проявляются лучшие качества, а без нее даже эксперт не будет знать что делать, но с использованием системного промпта не просто при генерации текста (где роль является по сути частью постановки), а при решении формализованных задач, можно также поэкспериментировать👍
Хотя опять же, при решении технических задач это больше как микрооптимизация, не заменяющая фундаментальные принципы
В 4 я скорее имею в виду, что от того, что я человеку скажу, что он эксперт, квалификации у него особо не прибавится) Просто инструктирую как абстрактного разумного ассистента, прикидывая уровень его знаний и интеллектуальных способностей, без каких-либо фишек, предназначенных специально для "железного друга"
В 1 у вас получается классический chain of thought? Если задача комплексная, и вы не уверены, что у вас есть достаточно точный контекст, тогда да, поэтапная генерация рабочий вариант, тоже иногда пользуюсь. В общем же случае мне удается получить от LLM все что нужно без всяких "think step by step", тем более, что у рассуждающих llm аналогичный механизм уже встроен и оптимизирован, а современные не рассуждающие каждый токен в любом случае генерируют не независимо, а внутри планируют решение на много шагов вперёд. Но в целом, chain of thought рабочая техника и не повредит.
По поводу 4, в целом, такой промпт не помешает, но я пока как-то принципиально стараюсь инструктировать LLM так, как инструктировал бы человека, и пока что такого подхода хватает для отличных результатов. Но если вдруг что-то никак не будет получаться, такие приемы конечно доступны)
Не совсем представляю ваш воркфлоу с такими приемами, но применительно к коду и моему подходу, прокомментирую пункты:
1) Это возможно удобно для проверки, почему модель делает не то что ожидалось - заставить ее объяснить, как она что получила. При этом в рабочих промптах излишние комментарии как будто только засоряют выход, не влияя при этом на качество результата.
2) Да, только я включаю интеллектуальные операции не в примеры, а в постановку задачи. Примеры же добавляю отдельно для демонстрации этих операций (опять же отчасти чтобы у модели не возникало желания писать обоснование в выходе, но это не принципиальный момент, и его думаю можно обойти).
3) Можно, но на моем опыте, это признак недоработанного промпта. Как правило, надёжные и стабилизировавшиеся промпты не содержат указаний "как не надо".
4) Может быть, но если имеется в виду мотивация в духе "это вопрос жизни и смерти", по мне это уже шаманство) По-хорошему, код нужно уметь писать без этого, я даже системный промпт не пишу и роли всякие не задаю. Но если "важно по такой-то причине" добавляет понимания о сути задачи, тогда звучит нормально.
Мнение, что лучшее ТЗ для программиста - это пример программы, неверно. Перед программистом в таком случае должен как минимум плотно поработать системный аналитик. Конечно, я не раз задумывался о том, чтобы автоматизировать работу аналитика, но это в любом случае качественно иная задача, чем написание исходного кода.
Дискуссии о замене программистов ИИ конечно идут, но это ведь только дискуссии. Если бы это было возможно уже сейчас, никто бы не дискутировал. На данный момент ИИ точно не может заменить программиста, но уже способен делать существенную часть интеллектуальной работы, которая еще недавно входила в его основные трудовые обязанности.
Проблема не праздная конечно)) По хорошему, она должна решаться семантической индексацией проекта (как описано в статье под написанием саммари вместо кода) или проще говоря составлением документации. Некоторым из нашей команды было удивительно даже не только что я тут ИИ раскочегарил, но что я ему внятно объяснил как устроен наш проект. Сейчас к тому же есть Claude Code, который может интеллектуально поползать по репо и написать неплохой черновик архитектуры, Gemini с его огромным контекстом, MCP для доступа к бд, так что в целом-то, инструменты, как минимум, для облегчения связывания рандомных частей проекта вместе и документирования есть. Хотя фокус статьи конечно в первую очередь на генерации нового кода
У вас, на первый взгляд, два принципиально разных кейса, отвечу по очереди.
Есть множество средств для добавления в контекст файлов в интернете, вы даже сами можете создать такой инструмент для своих нужд. Вопрос механики добавления чего-либо в контекст все же второстепенный по сравнению с сутью требуемой интеллектуальной работы над этим контекстом, его формой и содержанием.
В случае файлов Excel я бы лично использовал ИИ для создания скрипта, который будет надёжно считать строки для сколь угодно длинных файлов, если задача повторяющаяся. Либо можно посмотреть в сторону о3 - она вроде как умеет пользоваться питоном в процессе своих размышлений, чтобы как раз добиться точности в таких вычислениях без необходимости разрабатывать скрипт под задачу, если она разовая. Понадеяться на точный подсчет строк силами самой LLM конечно тоже можно, но я бы не стал, я бы и своим собственным подсчётам на пальцах не доверял в такой задаче.
Задача с бинарным файлом конечно не "чуть" сложнее. Смотря что за бинарный файл и как бы его анализировал человек. LLM в любом случае пока практически не способны делать того, что недоступно человеку. В общем случае, я бы отбросил идею, что ИИ вам сделает полноценный реверс-инжиниринг в красивый исходник по бинарнику
Я из лагеря вот этих вот сторонников замены, несмотря на то, что первые полгода конечно же у меня тоже возникали подобные экзистенциальные беспокойства. Но мне кажется, такие антиутопические суждения не очень дальновидны и не учитывают некоторые важные вопросы.
Зачем супер ИИ использовать людей? Что они могут дать такого уникального, что их выгодно использовать?
Зачем нужны деньги (людям или бизнесу) в мире, где люди, которым мы этими деньгами платим, не производят ценность?
Вполне возможно, будет борьба, но не за деньги, а за ресурсы. При этом если удастся сделать ИИ служащим не просто группе злонамеренных людей, а всему человечеству, то перед таким ИИ мы все будем равны. Возможно, мы будем только и заняты тем, чтобы сознательно жить, и конкурировать между собой будем не ресурсами, а например моральными и интеллектуальными качествами (пусть и нужными в таком мире только для красоты). Главная задача при замене людей же не обеспечить господство хозяев ИИ, а создать условия, при которых ИИ заменит прямо всех, что даже эти хозяева не смогут уже его контролировать. При этом заменить так, чтобы он максимально соответствовал интересам всего человечества. И как бы по крайней мере публичный образ разработчиков ИИ транслирует именно эту идею, и мне кажется, морально она близка достаточно большому количеству людей у власти, чтобы ей служить. Фриков, желающих поработить и уничтожить весь мир (просто потому что могут, иную цель сложно придумать), в обществе не так много
Если заменят этих, заменят и других. То, за что платили раньше, потому что это делали люди, будет практически бесплатным из-за отсутствия платежеспособного спроса и людских издержек на производство. Деньги, как средство распределения результатов человеческого труда, может уже даже потеряют свою актуальность
Как минимум, продолжительность жизни и ее качество выросло, стало больше выбора чем заниматься, меньше рутины, которую неизбежно пришлось бы делать 200 лет назад всем кроме самых состоятельных, через полсвета можно перелететь чтобы увидеть что-нибудь интересное, по тыку на экран ознакомиться с лучшими творениями мировых гениев. Не думаю, что хотя бы в какой-то мере тех прогресс не способствует повышению удовольствия от жизни))
Распространенное мнение, но я с ним не согласен)) зачем дергать мощную нейросеть для выключения лампочки при нажатии на сенсорный выключатель, для рендеринга текста, который вы сейчас читаете, для работы сетевого оборудования, оптимизированной не на уровне софта даже, а на уровне железа. Софт в миллионы раз производительнее ИИ, и грех тому же ИИ не пользоваться этой оптимизацией
Я про эту фразу (незаменимость - не самое точное слово с моей стороны)
Не в физическом труде (ни в коем случае, это оставят людям)
Ну и как бы мы интеллектуальным трудом далеко не только создаем контент, а люди не только занимаются его потреблением. Я больше про более практичный интеллектуальный труд - инновационные технологические разработки, научные открытия, программная автоматизация та же самая. В общем то, что вас окружает и дарит глубокое душевное удовольствие от взаимодействия, упрощает ненужную рутину или например, делает вас здоровее, продляя ваш счастливый век.
Да и когда ИИ заменит человека в плане контента - это будет означать, что он сможет писать произведения не менее гениальные, чем мировая классика. Не думаю, что вы были бы против того, чтобы вам по вашему желанию составили произведение, наполненное глубоким смыслом, чтобы вы получили от него настоящее интеллектуальное удовольствие.
И да, ИИ создают в том числе для того, чтобы он решал наши проблемы более эффективно и результативно, чем мы. Приведет ли это к личностной деградации? Это будет зависеть только от вас - чем вы будете заполнять свою голову. Да и не думаю, что супер-ИИ не сможет решить проблему того, что человеку нечем заняться, и ему не нравится деградировать. Я бы лично лучше жил вечно, чем, пусть и занимательно, участвовал в заранее предрешенной гонке со смертью
Я лично почему-то с самого начала в этом вопросе на стороне бизнеса - действительно, зачем достигать полезного результата ценой намного большего количества ресурсов, если можно использовать блага технического прогресса.
Про незаменимость физического труда вы зря - он подлежит тем же самым трендам, просто конечности управляются все равно мозгом, поэтому для замены физического труда первым логичным шагом в любом случае является замена труда интеллектуального. Пусть физическая работа требует его меньше, но если решить проблему полноценного управления конечностями, параллельно вполне возможно удастся решить проблему выполнения намного более сложных интеллектуальных операций.
Можно конечно рассматривать (и это много раз было сделано) различные антиутопические сценарии, но по большому счету, если не считать, что мы работаем чисто ради удовольствия, разве плохо, что полезный результат будет получаться быстрее, дешевле, а значит и в большем объеме, что приведет к значительному росту уровня жизни человечества?
Полностью согласен с тезисами статьи - для полноценной разработки ПО конечно же нужно обладать широким жизненным кругозором и пониманием реальности, до которого ИИ в принципе пока не дотянуть.
Но с другой стороны я мечтаю о том дне, когда программистов заменит ИИ. Сейчас разработка качественного и полезного ПО требует кучи ограниченных ресурсов, таких как квалифицированные разработчики, время и деньги. Если создание ПО будет под силу ИИ, оно станет значительно дешевле, его будет больше, и ИИ уже примется и за другие специальности. От общего изобилия, вызванного ускорением производительности, все только выиграют. В конечном счете, мы ведь работаем не для того, чтобы зарабатывать больше соседа, а чтобы позволить себе уровень жизни, способствующий счастью. При господстве ИИ уровень жизни за счет технического прогресса у всех значительно вырастет.
"Внимание к деталям" и "результат" связаны — если модель теряет фокус, генерация страдает.
Конечно связаны, но внимание к деталям - это промежуточный этап при получении результата, который может отразиться на нем существенно или не очень. Я же говорил именно про внимание к деталям, поэтому статьи про хороший результат на специально подобранном длинном контексте с ICL не особо релевантны.
Не знаю, почему вы решили, что я что-то недооцениваю, даже из приведенных мной источников видно, что тот же Claude, пусть и хуже справляется с большим контекстом, все равно делает это на достаточно неплохом уровне
Конечно, вы замечаете некоторые сходства в основных принципах ICL и предлагаемом подходе. Но если бы вы лучше понимали, что такое RL, для вас было бы очевидно, что ICL - это прямая аналогия RL, и плохо структурированные примеры кода - это не те примеры, которые используются в ICL. В ICL, если что, используется что-то в духе:
Пример запроса 1: сверстай мне компонент X1 согласно требованиям Y1
Пример ответа 1: *исходный код компонента X1*
Пример запроса 2: напиши мне верстку для компонента X2, чтобы это соответствовало Y2
Пример ответа 2: *исходный код компонента X2*
Затем вы могли бы добавить окружающий код для конкретной задачи, но этот код уже не относился бы к ICL
Код представляет собой структурированную информацию с определенными паттернами, синтаксисом и семантикой.
Когда вы предоставляете модели большой объем связанного кода, вы даете ей возможность "увидеть" множество примеров того, как реализованы различные функции, классы, как используются библиотеки, как организован код и т.д.
Когда вы просите модель сгенерировать новый код, она использует эти примеры для формирования своего ответа.
Ключевой механизм остается тем же — модель учится из предоставленных примеров без изменения своих параметров и применяет это знание к новой задаче.
Вы описали какую-то более общую концепцию обучения из контекста, задействующую примеры, а не ICL. Для этого есть более подходящие термины, используемые в литературе, можете спросить свой любимый ИИ на этот счет.
Проблема в том, что вы хотели опровергнуть некоторые мои суждения, приведя ссылки на научные статьи. Но в то же время вы недостаточно владеете терминологией, которую используете, поэтому ваша аргументация звучит неполно и отчасти нелогично. Если бы вы не использовали эту терминологию, то не только стиль, но и смысл ваших слов был бы другим и вызывал бы меньше путаницы.
Я просто подсвечиваю эти моменты, возможно, это будет для вас поводом разобраться получше, потому что для меня субъективно понимание теории точно полезно, судя по моим результатам (которые конечно же вообще не научны, это просто иллюстрация).
Ну просто те, кто так пишут, чаще всего имеют достаточно поверхностное представление о нейросетях и LLM в частности
С подобными задачами у меня нет особо опыта, но чисто умозрительно могу предположить, что не стоит ожидать, что вы дадите LLM первый документ, второй и третий, и она все сама сделает без ошибок даже когда документы длинные. Нейросети все равно не на уровне машин обрабатывают кучу информации, у некоторых даже возникает сопротивление, когда вывод достаточно длинный.
Можете попробовать опытным путем подобрать длину фрагментов, с которой ошибок минимум и попробовать декомпозировать задачу на сопоставимые по сложности подзадачи. Например, в исходных документах выделить разделы, сильно связанные по смыслу внутри и слабо между собой, либо если изложение последовательное, просто разделить на части, не знаю.
В любом случае при работе с нейросетью очень полезно понимать, на какие интеллектуальные подзадачи, обрабатывающие ограниченный объем контекста, разбивается основная задача. Что-то более конкретное сложно сказать, так как нужно смотреть задачу подробнее. Вообще, из того что слышал, писатели до сих пор не могут довериться нейросетям как раз в том числе из-за большой длины текстов.
В данном случае претензия к аналитику была не в том, что он что-то упустил (хотя и это имело место), а просто в том, что он невнятно сформулировал алгоритм.
UserStory - хорошее дополнение для основной постановки, позволяющее лучше ее понять, но не всегда достаточное само по себе. На проекте принято писать постановки в терминах бд сущностей, почему - не могу подсказать, но такие постановки часто напоминают псевдокод и ввиду детальности могут уже служить достаточно четким описанием нужного алгоритма.
В принципе можно поэкспериментировать и с постановками в другой форме - я думаю, что они тоже могут дать хороший результат, если глобально при работе с ИИ соблюдаются описанные в статье правила. Вообще, при дальнейшем движении в сторону автоматизации работы аналитика стоит рассмотреть самые разные формы спецификации требований, и возможно, найдется объективно оптимальная для работы с ИИ.
В моем случае верификация идёт полностью вручную, так как я хотел получить не просто достаточно хороший, а идеальный результат (то есть лучше которого я бы сам не сделал), поэтому мне нужно было убедиться, что он хорош во всех моментах, а не выборочно.
Постановка задачи в примере у вас не очень понятная. Статья по мотивам модуля (учитывая, что в модуле есть функции, значит это наверное модуль ПО) - это типа неформальной документации? Отождествлять то что обычно отождествляют - тоже достаточно расплывчатая формулировка.
Непонятно, что значит игнорирует фрагменты документов в контексте данной задачи. Не совсем понятно как длина контекста исправляет ненадежность верификации.
В целом, использовать LLM для верификации - нормальный подход. Из быстрых советов, которые могу дать даже не углубляясь в детали вашей проблемы - используйте о3 (отрабатывает для чуть ли не на 100% при простой проверке текстов вроде упомянутой вплоть до 100к слов) или Gemini 2.5 Pro (отрабатывает хорошо даже для 500к слов). Но если у вас настолько длинные тексты, я бы скорее всего не стал работать с ними целиком, а попробовал декомпозировать задачу. На первый взгляд, напоминает попытки загрузить в контекст весь исходный код проекта, когда можно этого не делать
Звучит здраво, хотя мне до сих пор не требовалось как-то особо усиливать промпты, так как при грамотной постановке у модели в любом случае проявляются лучшие качества, а без нее даже эксперт не будет знать что делать, но с использованием системного промпта не просто при генерации текста (где роль является по сути частью постановки), а при решении формализованных задач, можно также поэкспериментировать👍
Хотя опять же, при решении технических задач это больше как микрооптимизация, не заменяющая фундаментальные принципы
В 4 я скорее имею в виду, что от того, что я человеку скажу, что он эксперт, квалификации у него особо не прибавится) Просто инструктирую как абстрактного разумного ассистента, прикидывая уровень его знаний и интеллектуальных способностей, без каких-либо фишек, предназначенных специально для "железного друга"
В 1 у вас получается классический chain of thought? Если задача комплексная, и вы не уверены, что у вас есть достаточно точный контекст, тогда да, поэтапная генерация рабочий вариант, тоже иногда пользуюсь. В общем же случае мне удается получить от LLM все что нужно без всяких "think step by step", тем более, что у рассуждающих llm аналогичный механизм уже встроен и оптимизирован, а современные не рассуждающие каждый токен в любом случае генерируют не независимо, а внутри планируют решение на много шагов вперёд. Но в целом, chain of thought рабочая техника и не повредит.
По поводу 4, в целом, такой промпт не помешает, но я пока как-то принципиально стараюсь инструктировать LLM так, как инструктировал бы человека, и пока что такого подхода хватает для отличных результатов. Но если вдруг что-то никак не будет получаться, такие приемы конечно доступны)
Не совсем представляю ваш воркфлоу с такими приемами, но применительно к коду и моему подходу, прокомментирую пункты:
1) Это возможно удобно для проверки, почему модель делает не то что ожидалось - заставить ее объяснить, как она что получила. При этом в рабочих промптах излишние комментарии как будто только засоряют выход, не влияя при этом на качество результата.
2) Да, только я включаю интеллектуальные операции не в примеры, а в постановку задачи. Примеры же добавляю отдельно для демонстрации этих операций (опять же отчасти чтобы у модели не возникало желания писать обоснование в выходе, но это не принципиальный момент, и его думаю можно обойти).
3) Можно, но на моем опыте, это признак недоработанного промпта. Как правило, надёжные и стабилизировавшиеся промпты не содержат указаний "как не надо".
4) Может быть, но если имеется в виду мотивация в духе "это вопрос жизни и смерти", по мне это уже шаманство) По-хорошему, код нужно уметь писать без этого, я даже системный промпт не пишу и роли всякие не задаю. Но если "важно по такой-то причине" добавляет понимания о сути задачи, тогда звучит нормально.
Круто, что у вас получается, я тоже тащусь)
Мнение, что лучшее ТЗ для программиста - это пример программы, неверно. Перед программистом в таком случае должен как минимум плотно поработать системный аналитик. Конечно, я не раз задумывался о том, чтобы автоматизировать работу аналитика, но это в любом случае качественно иная задача, чем написание исходного кода.
Дискуссии о замене программистов ИИ конечно идут, но это ведь только дискуссии. Если бы это было возможно уже сейчас, никто бы не дискутировал. На данный момент ИИ точно не может заменить программиста, но уже способен делать существенную часть интеллектуальной работы, которая еще недавно входила в его основные трудовые обязанности.
Проблема не праздная конечно)) По хорошему, она должна решаться семантической индексацией проекта (как описано в статье под написанием саммари вместо кода) или проще говоря составлением документации. Некоторым из нашей команды было удивительно даже не только что я тут ИИ раскочегарил, но что я ему внятно объяснил как устроен наш проект. Сейчас к тому же есть Claude Code, который может интеллектуально поползать по репо и написать неплохой черновик архитектуры, Gemini с его огромным контекстом, MCP для доступа к бд, так что в целом-то, инструменты, как минимум, для облегчения связывания рандомных частей проекта вместе и документирования есть. Хотя фокус статьи конечно в первую очередь на генерации нового кода
У вас, на первый взгляд, два принципиально разных кейса, отвечу по очереди.
Есть множество средств для добавления в контекст файлов в интернете, вы даже сами можете создать такой инструмент для своих нужд. Вопрос механики добавления чего-либо в контекст все же второстепенный по сравнению с сутью требуемой интеллектуальной работы над этим контекстом, его формой и содержанием.
В случае файлов Excel я бы лично использовал ИИ для создания скрипта, который будет надёжно считать строки для сколь угодно длинных файлов, если задача повторяющаяся. Либо можно посмотреть в сторону о3 - она вроде как умеет пользоваться питоном в процессе своих размышлений, чтобы как раз добиться точности в таких вычислениях без необходимости разрабатывать скрипт под задачу, если она разовая. Понадеяться на точный подсчет строк силами самой LLM конечно тоже можно, но я бы не стал, я бы и своим собственным подсчётам на пальцах не доверял в такой задаче.
Задача с бинарным файлом конечно не "чуть" сложнее. Смотря что за бинарный файл и как бы его анализировал человек. LLM в любом случае пока практически не способны делать того, что недоступно человеку. В общем случае, я бы отбросил идею, что ИИ вам сделает полноценный реверс-инжиниринг в красивый исходник по бинарнику
Я из лагеря вот этих вот сторонников замены, несмотря на то, что первые полгода конечно же у меня тоже возникали подобные экзистенциальные беспокойства. Но мне кажется, такие антиутопические суждения не очень дальновидны и не учитывают некоторые важные вопросы.
Зачем супер ИИ использовать людей? Что они могут дать такого уникального, что их выгодно использовать?
Зачем нужны деньги (людям или бизнесу) в мире, где люди, которым мы этими деньгами платим, не производят ценность?
Вполне возможно, будет борьба, но не за деньги, а за ресурсы. При этом если удастся сделать ИИ служащим не просто группе злонамеренных людей, а всему человечеству, то перед таким ИИ мы все будем равны. Возможно, мы будем только и заняты тем, чтобы сознательно жить, и конкурировать между собой будем не ресурсами, а например моральными и интеллектуальными качествами (пусть и нужными в таком мире только для красоты). Главная задача при замене людей же не обеспечить господство хозяев ИИ, а создать условия, при которых ИИ заменит прямо всех, что даже эти хозяева не смогут уже его контролировать. При этом заменить так, чтобы он максимально соответствовал интересам всего человечества. И как бы по крайней мере публичный образ разработчиков ИИ транслирует именно эту идею, и мне кажется, морально она близка достаточно большому количеству людей у власти, чтобы ей служить. Фриков, желающих поработить и уничтожить весь мир (просто потому что могут, иную цель сложно придумать), в обществе не так много
Если заменят этих, заменят и других. То, за что платили раньше, потому что это делали люди, будет практически бесплатным из-за отсутствия платежеспособного спроса и людских издержек на производство. Деньги, как средство распределения результатов человеческого труда, может уже даже потеряют свою актуальность
Как минимум, продолжительность жизни и ее качество выросло, стало больше выбора чем заниматься, меньше рутины, которую неизбежно пришлось бы делать 200 лет назад всем кроме самых состоятельных, через полсвета можно перелететь чтобы увидеть что-нибудь интересное, по тыку на экран ознакомиться с лучшими творениями мировых гениев. Не думаю, что хотя бы в какой-то мере тех прогресс не способствует повышению удовольствия от жизни))
Распространенное мнение, но я с ним не согласен)) зачем дергать мощную нейросеть для выключения лампочки при нажатии на сенсорный выключатель, для рендеринга текста, который вы сейчас читаете, для работы сетевого оборудования, оптимизированной не на уровне софта даже, а на уровне железа. Софт в миллионы раз производительнее ИИ, и грех тому же ИИ не пользоваться этой оптимизацией
Я про эту фразу (незаменимость - не самое точное слово с моей стороны)
Ну и как бы мы интеллектуальным трудом далеко не только создаем контент, а люди не только занимаются его потреблением. Я больше про более практичный интеллектуальный труд - инновационные технологические разработки, научные открытия, программная автоматизация та же самая. В общем то, что вас окружает и дарит глубокое душевное удовольствие от взаимодействия, упрощает ненужную рутину или например, делает вас здоровее, продляя ваш счастливый век.
Да и когда ИИ заменит человека в плане контента - это будет означать, что он сможет писать произведения не менее гениальные, чем мировая классика. Не думаю, что вы были бы против того, чтобы вам по вашему желанию составили произведение, наполненное глубоким смыслом, чтобы вы получили от него настоящее интеллектуальное удовольствие.
И да, ИИ создают в том числе для того, чтобы он решал наши проблемы более эффективно и результативно, чем мы. Приведет ли это к личностной деградации? Это будет зависеть только от вас - чем вы будете заполнять свою голову. Да и не думаю, что супер-ИИ не сможет решить проблему того, что человеку нечем заняться, и ему не нравится деградировать. Я бы лично лучше жил вечно, чем, пусть и занимательно, участвовал в заранее предрешенной гонке со смертью
Я лично почему-то с самого начала в этом вопросе на стороне бизнеса - действительно, зачем достигать полезного результата ценой намного большего количества ресурсов, если можно использовать блага технического прогресса.
Про незаменимость физического труда вы зря - он подлежит тем же самым трендам, просто конечности управляются все равно мозгом, поэтому для замены физического труда первым логичным шагом в любом случае является замена труда интеллектуального. Пусть физическая работа требует его меньше, но если решить проблему полноценного управления конечностями, параллельно вполне возможно удастся решить проблему выполнения намного более сложных интеллектуальных операций.
Можно конечно рассматривать (и это много раз было сделано) различные антиутопические сценарии, но по большому счету, если не считать, что мы работаем чисто ради удовольствия, разве плохо, что полезный результат будет получаться быстрее, дешевле, а значит и в большем объеме, что приведет к значительному росту уровня жизни человечества?
Полностью согласен с тезисами статьи - для полноценной разработки ПО конечно же нужно обладать широким жизненным кругозором и пониманием реальности, до которого ИИ в принципе пока не дотянуть.
Но с другой стороны я мечтаю о том дне, когда программистов заменит ИИ. Сейчас разработка качественного и полезного ПО требует кучи ограниченных ресурсов, таких как квалифицированные разработчики, время и деньги. Если создание ПО будет под силу ИИ, оно станет значительно дешевле, его будет больше, и ИИ уже примется и за другие специальности. От общего изобилия, вызванного ускорением производительности, все только выиграют. В конечном счете, мы ведь работаем не для того, чтобы зарабатывать больше соседа, а чтобы позволить себе уровень жизни, способствующий счастью. При господстве ИИ уровень жизни за счет технического прогресса у всех значительно вырастет.
Конечно связаны, но внимание к деталям - это промежуточный этап при получении результата, который может отразиться на нем существенно или не очень. Я же говорил именно про внимание к деталям, поэтому статьи про хороший результат на специально подобранном длинном контексте с ICL не особо релевантны.
Не знаю, почему вы решили, что я что-то недооцениваю, даже из приведенных мной источников видно, что тот же Claude, пусть и хуже справляется с большим контекстом, все равно делает это на достаточно неплохом уровне
Конечно, вы замечаете некоторые сходства в основных принципах ICL и предлагаемом подходе. Но если бы вы лучше понимали, что такое RL, для вас было бы очевидно, что ICL - это прямая аналогия RL, и плохо структурированные примеры кода - это не те примеры, которые используются в ICL. В ICL, если что, используется что-то в духе:
Пример запроса 1: сверстай мне компонент X1 согласно требованиям Y1
Пример ответа 1: *исходный код компонента X1*
Пример запроса 2: напиши мне верстку для компонента X2, чтобы это соответствовало Y2
Пример ответа 2: *исходный код компонента X2*
Затем вы могли бы добавить окружающий код для конкретной задачи, но этот код уже не относился бы к ICL
Вы описали какую-то более общую концепцию обучения из контекста, задействующую примеры, а не ICL. Для этого есть более подходящие термины, используемые в литературе, можете спросить свой любимый ИИ на этот счет.
Проблема в том, что вы хотели опровергнуть некоторые мои суждения, приведя ссылки на научные статьи. Но в то же время вы недостаточно владеете терминологией, которую используете, поэтому ваша аргументация звучит неполно и отчасти нелогично. Если бы вы не использовали эту терминологию, то не только стиль, но и смысл ваших слов был бы другим и вызывал бы меньше путаницы.
Я просто подсвечиваю эти моменты, возможно, это будет для вас поводом разобраться получше, потому что для меня субъективно понимание теории точно полезно, судя по моим результатам (которые конечно же вообще не научны, это просто иллюстрация).