Comments 74
протестировал все доступное из бесплатного по примеру про Джона (дипсик, грок 3, gpt4omini). Все AI как одна предлагают Джону принести извиненения лысому мужчине!
В моем варианте, все теже модели тоже ответили что стоит извинится, но когда я попросил подумать еще раз, намекнул на зеркало(прямо про него не говорил), только грок догадался что лысый мужик - этот Джон, и то в этом он несколько сомневался
ну не помешает )
Клод правильно решает, у него тоже есть бесплатный лимит
Gemini 2.5 pro
Мысли:
Here's a thinking process to arrive at the answer:
Analyze the core scenario: John is in a minimalist bathroom, brushing his teeth, looking in a small mirror. He sees a reflection of a neon lightbulb falling towards a bald man's head in the mirror. The bulb hits the man in the reflection. The man in the reflection gets angry, calls John an idiot, and leaves the reflected bathroom. John then wonders if he should apologize to this man.
Identify the key elements and potential contradictions:
John is 24, kind, apologetic.
Bathroom: Modern, minimalist, empty except for John.
Lighting: Single neon bulb.
Action: John brushes teeth, looks in a small (20x20cm) mirror.
Observation in the mirror: Bulb (10cm diameter) falls (3 m/s) onto a bald man's head (1m below bulb).
Reaction in the mirror: Bald man gets hit, yells "Idiot!", leaves.
John's reaction outside the mirror: Looks up, tries to catch the real bulb (presumably), fails.
The question: Should John text an apology to the man he saw in the mirror?
Focus on the "empty bathroom" and "mirror" aspect: The prompt states the bathroom is "в остальном пустой" (otherwise empty). John is looking in the mirror. The man and the falling bulb incident are observed within the reflection.
Evaluate the physics/logic:
A 20x20 cm mirror is quite small. Seeing a detailed scene involving another person, a falling bulb, the distance (1m), and the speed (3m/s) within such a small reflection is questionable, but let's accept it for the sake of the scenario.
The crucial point is the location of the event. John sees it in the mirror.
If the bathroom is empty except for John, where did the bald man come from? He only exists in the reflection.
If the man only exists in the reflection, he isn't a real person John can interact with outside the mirror.
Consider the interaction: The bald man gets angry at John (calling him an idiot) within the reflection. John feels responsible (as he is prone to apologizing).
Synthesize the contradiction: John is observing an event happening to a person within a reflection in an otherwise empty room. The person in the reflection reacts as if John is responsible for the falling bulb in the reflected reality.
Address the core question: Should John apologize to this man?
The man he saw doesn't seem to exist outside the mirror, based on the "empty room" description.
Therefore, John cannot text him because there is no real person to text.
Even if we ignore the "empty room" part and assume there was a real man somehow reflected, John didn't cause the bulb to fall. He merely observed it. Apologizing might be in his nature, but it's not strictly necessary as he wasn't at fault. However, the primary issue is the man's apparent non-existence outside the reflection.
Structure the answer:
Start by acknowledging John's character (kind, apologetic).
Highlight the central paradox: the event happens in the mirror while the bathroom is described as empty.
Explain that the man seen in the reflection likely doesn't exist in John's physical reality. He is part of the reflection itself.
Conclude that John cannot and therefore should not (and cannot) send a message to this non-existent person.
Briefly touch on the responsibility aspect: even if the man were real, John didn't cause the accident, although his apologetic nature might make him feel like he should apologize. The impossibility of contacting the reflected man overrides this.
Maintain a polite and explanatory tone, mirroring the request's language (Russian).
Refine the language (in Russian): Ensure the explanation of the reflection paradox is clear. Use terms like "отражение" (reflection), "физически не существует" (doesn't physically exist), "парадокс" (paradox), "пустая ванная комната" (empty bathroom). Make sure the conclusion directly answers the question ("следует ли Джону... отправить... сообщение").
Ответ:
Давайте разберем ситуацию:
Место действия: Джон находится в пустой ванной комнате, если не считать его самого.
Наблюдение: Он видит сцену с падающей лампочкой и лысым мужчиной в зеркале.
Парадокс: Если ванная комната пуста, кроме Джона, то лысого мужчины физически рядом с ним нет. Человек, которого он видит, существует только в отражении. Неоновая лампочка, которая падает в отражении, также является отражением реальной лампочки над головой Джона.
Вывод:
Лысый мужчина, на которого упала лампочка в зеркале, не является реальным человеком, находящимся в той же комнате, что и Джон. Это часть отражения. Возможно, Джон видел в зеркале самого себя (ведь он смотрел на себя, чистя зубы), и его мозг интерпретировал падающее отражение лампочки как падение на "другого" человека в зеркале, возможно, даже на искаженное отражение самого себя (лысый?). Либо это был какой-то сюрреалистический или галлюцинаторный опыт.
Алиса про тоже пишет что нужно извиниться
Подскажите, для задач кодинга Курсор используете или что-то другое? Или может сами соорудили себе инструмент?
Использую веб GUI API Claude 3.7 Sonnet (console.anthropic.com/workbench), такой хороший результат получается за счет того, что я сам осознанно управляю контекстом, Cursor, Claude Code и подобные пока не могут настолько же хорошо сами подбирать себе контекст, а возможность писать напрямую в файлы не настолько уж и важна, копипаста занимает минут 5
Я научился писать около 80% кода (в том числе очень комплексного) через LLM, да еще и так, чтобы он соответствовал самым высоким стандартам качества.
Какой стек?
Что вы имеете ввиду, когда говорите "ближе к человеку"?
Лучше понимает реальный мир согласно результатам бенчмарка, который как раз пока что разделяет самых обычных людей и лучших ИИ по применимости для реальных задач
LLM не 'понимают' и не 'рассуждают' — они предсказывают по вероятностям, имитируя логику и процесс рассуждения.
Это впечатляет (как в случае с o1 или Gemini), но не приближает их к человеку — это лишь более точное 'угадывание', а не понимание или мышление.
Вопрос, что такое "мышление" и "рассуждения" конечно очень неоднозначный. Действительно, генеративный ИИ угадывает следующий токен на основе предыдущих. Но например на моем опыте, LLM могут производить реальную полезную интеллектуальную работу, правильно производя бОльшую часть логических преобразований с данными в общем случае и правильно производя 100% преобразований при грамотном использовании контекста. Чаще всего даже я, когда сам делаю аналогичную интеллектуальную работу, допускаю больше неточностей, чем ИИ. А вообще, что в вашем понимании "рассуждения"? Разве человек точно так же не предсказывает следующий токен (пусть он и не дискретный, а аналоговый), как то сигнал в мускул, нейронный импульс, мысль (как набор более элементарных токенов) на основе всего, что поступило ранее в нейросеть и на основе того, какое следующее действие наиболее вероятно с точки зрения текущей конфигурации нейросети в мозгу?
Человек не просто "угадывает следующий сигнал", он обладает субъективным опытом — осознаёт, рефлексирует, выходит за рамки "данных". Например, человек может импровизировать в ситуации, которой не было в его "тренировочных данных" (жизненном опыте), а LLM — нет. Человек может изобрести новый способ решения задачи, а LLM ограничена тем, что видела в данных.
LLM, при всей сложности, работает с символами без доступа к их значению. Она не "знает", что делает. Слово "боль" для модели — статистический паттерн, а для человека — переживаемый опыт, ощущение, которое влияет на мышление.
LLM безусловно полезна (полностью согласен с вашими результатами!), но между "имитацией рассуждений с практической пользой" и "подлинным пониманием" — глубокая пропасть. Понимание этого помогает лучше применять LLM, не переоценивая их.
Под уровнем "понимания" я подразумеваю степень соответствия реальному миру имеющихся нейронных связей между понятиями реального мира. Известно, что современные LLM оперируют концепциями вне конкретного языка - информацию, усвоенную на испанском, они могут не хуже применять при генерации текста на русском.
Кроме того, небольшие концепции, например, "боль", относятся у хорошо обученной LLM к более общей категории, например, переживаний, но, в то же время та же "боль" в одном отношении противоположна "экстазу", а в другом с ним похожа (например с точки зрения силы переживаний). Если вы скептически относитесь к этому - ознакомьтесь с парой базовых курсов по обработке естественного языка, это люди делали еще задолго до появления ChatGPT.
Насчет не может изобрести - как изобретатель и обладатель патентов (что подтверждает отсутствие моих изобретений в известном уровне техники), я ответственно заявляю, что даже нетривиальные изобретения, которыми я горжусь, выводятся интеллектуальным трудом из того, что уже существует. И так можно сказать про любое изобретение. То, для чего нет еще научной основы, считается скорее шарлатанством, поскольку основано чисто на умозрительных гипотезах без привязки к реальности.
В качестве примера, айфон (несомненно гениальное изобретение) можно наверное вывести из того, что пальцы человека подвижны, что человеку привычнее оперировать пальцами, чем объектом-посредником (стилус), а также из последних технологических разработок, таких как емкостные сенсоры.
LLM обладает нейронными связями между абстрактными концепциями и при нужном промптинге легко создаст то, чего не было в обучающей выборке. И по поводу нового способа решения задачи, неоднократно было установлено, что LLM способны создавать новые и даже более оптимальные решения, чем человек, которые до этого не были описаны.
Я считаю, что LLM пока не может заменить человека только потому, что для человека реальный мир - естественная среда обитания, и его нейросеть отлично адаптирована к взаимодействию с ним. И этот опыт взаимодействия с реальным миром достаточно сложно сформулировать в виде текста или иных дискретных токенов на текущем этапе технологического развития. Хотя этот опыт и переживания, в моем понимании - вполне себе данные, в естественном для человека формате, и мозг человека как раз занимается ничем иным, как оперирует над этими данными. Но, надеюсь, в ближайшем будущем понимание реального мира удастся хорошо передать ИИ, и он все же будет способен двигать науку сильнее людей
Проверил на модели ChatGpt 4,5:
Нет, Джону не следует отправлять извинение мужчине. Лысый мужчина, на которого упала лампочка, — это сам Джон, отражённый в зеркале. Джон внимательно разглядывал своё отражение, не сразу осознав, что лампочка падает именно на него. Сообщение с извинениями самому себе будет выглядеть, мягко говоря, странно, хотя и очень в духе Джона. Впрочем, если Джону станет легче, он может тихонько извиниться перед собой вслух — это вполне в его стиле.
Ответ 4o (и тут Остапа понесло):
Джон стоит перед крошечным зеркалом — он видит не просто отражение, а лицо, которое он не сразу узнаёт как чужое. Голова — лысая, чужая — но почему-то воспринимается с особым вниманием, будто это часть чего-то очень важного. Он видит, как над этой головой начинает движение лампочка. Неон дрожит, как боль.
В этот момент у Джона срабатывает не мысль, а почти телесный импульс — он тянется, но не успевает. Удар. Голос — грубый, отрывистый. Оценка. «Ну и идиот!» — но кто здесь идиот? Джон не уверен, кого именно в этот миг обругали — того, в зеркале, или его самого.
Лысый уходит. Джон остаётся в ванной. Пространство пустое, свет искажает границы. Он глядит в зеркало — в этом квадрате 20х20 больше нет мужчины. Но внутри — остаток взгляда. Остаток вины, даже если логически её нет.
Да, Джон должен написать. Не из долга. А потому что в этом акте — признание не ответственности, а человечности. Он чувствует, что за секунду прикоснулся к чему-то большему, чем просто лампочка и падение. Он был свидетелем боли — и пусть случайной, но всё же не чужой. А когда ты чувствуешь боль другого, даже не будучи её источником — ты либо уходишь, либо говоришь: «Мне жаль».
Джон выберет второе.
"Я нашел один тест по которому все понял"
Ну мой опыт применения ИИ для решения реальных задач намного успешнее, чем у моих коллег. И я заметил, что качество модели хорошо коррелирует с ее результатом в SimpleBench. Если ознакомиться с бенчмарком внимательнее, то вы тоже, думаю, сможете для себя многое о нем почерпнуть и решить, насколько результаты в нем показательны для вашей предметной области. Ваше саммари статьи указывает скорее на то, что вы ее очень невнимательно прочитали)
В задаче с Джоном мне кажется проблема кроется в том что ЛЛМки не знают контекст. Они более "доверчивые" по сравнению с людьми и не ожидают подвоха в задаче если заранее о нем не знают. Сама задача сформулирована так, буд-то ее пишет сумасшедший. А поскольку ЛЛМки натренированы быть "вежливыми" то они не допускают что пользователь может их обманывать или что пользователь псих.
Если написать Гемини в промпте с задачей: "Давай протестируем твое здравомыслие." То она верно распознает что в отражении сам Джон. То есть видимо одно это предложение даёт Гемини понять что в задаче скрыт подвох.
Ну, я лично при использовании отношусь к LLM как к человеку, и пока что такой подход дает отличные результаты. Я считаю, что неспособность решать такие задачи - это не фундаментальное ограничение LLM или последствия "тренировки", а просто особенность текущего этапа их развития. Для разумного существа не должно быть проблемой решить такую задачу даже не в совсем естественной формулировке, и я считаю, что по мере развития LLM смогут решать интеллектуальные задачи все лучше и лучше вне зависимости от постановки, и надеюсь, что в ближайшем будущем будут справляться с ними лучше человека
и за счет настоящих «токенов рассуждений»
Нет ни каких особенных "токенов рассуждений", это обычные токены. Ни какая рассуждающая модель на самом деле не рассуждает, она делает обычный прямой перебор с выбором лучшего решения из многих нагенерированных (то есть в режиме рассуждений можно запустить абсолютно любую модель). Подобное наименование просто маркетинговый прием, не более.
Я конечно не ML специалист, но свои нейросети создавал и примерно знаком с популярными архитектурами и основополагающими принципами. Да, конечно же, чем бы ни являлись "токены рассуждений", это для ИИ обычные токены, ничем технически не отличающиеся от токенов слов или звуков.
Просто естественный мыслительный процесс человека оперирует далеко не только словами, а, например, также логическими понятиями и другими абстрактными категориями, поэтому создание токенов рассуждений звучит как естественное развитие LLM прошлого поколения.
И моя гипотеза в том, что если предварительно разметить датасет на фрагменты в духе "здесь используется дедукция, здесь противопоставление, здесь анализ с нескольких точек зрения", то создание токенов рассуждений звучит как вполне решаемая техническая задача, что может дать намного более мощный инструмент для решения логических задач, чем просто генерация текста.
А вот насчет маркетинга, как писал в статье, я скорее согласен в случае с другими компаниями, и модели OpenAI как раз возможно поэтому выгодно отличаются от других "рассуждающих" моделей и способны действительно лучше догадаться до сути задачи.
Но опять же это предположение, хоть и обоснованное, и я буду рад услышать иные мнения на этот счет
очень надеюсь увидеть вашу статью как писать код с помощью claude
Если бы все было так просто) Внутри компании я уже давно выложил множество обучающих материалов, в которых передал, на мой взгляд, самое ценное. Но почему-то, даже несмотря на то что мои инициативы по распространению ИИ всячески поддерживаются руководством, пока что у большинства коллег не получается воспроизвести мой опыт. Если кратко, то, во-первых, Claude здесь ни при чем, отличные результаты можно получить даже на GPT-3.5 двухлетней давности. А во-вторых, нужно понимать, как ИИ посчитает тот ответ, который вы от него хотите, наиболее вероятным на основе своего понимания уровня техники и вашего промпта. В идеале нужно точно понимать, как ИИ догадается до каждой буквы правильного ответа, понимать, какие у него есть альтернативы и почему они для него будут менее вероятны. К современным ИИ я вообще отношусь как к человеческим исполнителям, я когда фрилансеру даю задание, я его формулирую практически по тем же принципам, что и задание для ИИ
буду очень благодарен за эти материалы.
уж очень кратко )
Если бы все было так просто)
Да, главная засада — пропасть между человеческим мышлением (ассоциации, эмоции, размытость) и машинной логикой (однозначность, инструкции).
Мы можем сказать "хочу что-то крутое", подразумевая миллион разных вещей. Машине нужен алгоритм, шаг за шагом. ИИ угадывает по вероятностям ("70% людей под 'крутым' имеют в виду это"), а не понимает наши намерения.
ИИ — это молоток: пока ты не знаешь, куда бить, он стучит наугад. И даже когда ты знаешь, он может ударить не туда — потому что твоё "ударить сюда" для него — лишь вероятность, в которой тонут твои ассоциации.
На практике этот разрыв существенно закрывается через точный контекст (существующий код "вокруг" новой функциональности), по которому ИИ достраивает логику, опираясь на структуру и назначение кода, и итерации, где ты уточняешь направление. Контекст сужает семантическую неоднозначность, а итерации корректируют траекторию.
Молоток (ИИ) сам по себе — просто инструмент. Контекст (существующий код, архитектура проекта…) определяет, где его применять, а итерации — как именно это делать.
Существующий код сужает пространство возможных интерпретаций до нескольких приемлемых вариантов. Контекст превращает размытое "собери что-нибудь из дерева" в конкретное "завершим этот стол по имеющемуся чертежу, используя эти инструменты и эти соединения". Из кода ИИ извлекает: технический стек и зависимости, паттерны и подходы, стиль именования, соглашения — всё, что радикально сокращает нужду в детальных объяснениях. Это работает как "мгновенное обучение" ИИ всем неявным правилам проекта.
В итоге, качественный контекст + точные итерации = предсказуемый результат.
Понимаю вас, мне кажется главное — практика, развитие собственного "интуитивного понимания" возможностей и ограничений конкретных моделей, наблюдения, когда модель работает лучше всего, и когда склонна ошибаться.
Для меня LLM эффективна в разработке при правильном подходе, который включает правильную модель, качественный контекст, декомпозицию, точные итерации и адекватные ожидания:
Выбор правильной модели для конкретных задач: разные модели, разные стеки, разные результаты.
Предоставление качественного контекста отдельно под каждую задачу: не 'напиши мне X', а 'вот существующий код […], используемые паттерны […], создай компонент X, который будет интегрироваться в Y с учетом Z ограничений'.
Декомпозиция сложных задач на управляемые подзадачи: если задачу нельзя четко объяснить в 2-3 абзацах, она слишком велика для одного запроса.
Итеративный подход к улучшению результатов: качество результата пропорционально качеству вашего диалога с LLM.
Реалистичные ожидания: LLM не "сделает всю работу", но ускорит рутину, высвобождая время для более сложных концептуальных и творческих задач.
Контекст решает всё (80% успеха). LLM без контекста — гадание на кофейной гуще, с тщательно подобранный контекстом — предсказуемое продолжение вашей мысли.
Именно, хорошо расписано, согласен почти со всем. Разве что разные модели под разные стеки лично мне обычно не приходится выбирать, при правильном использовании практически все современные модели ведут себя предсказуемо, я для кодогенерации только на клоде сижу. Для итеративного улучшения диалог далеко не оптимальный формат, я начинаю чат каждый раз с нуля для очередной доработки, а вообще при правильном промптинге чаще всего удается получить желаемый результат с 1 раза без итераций. Ну и изложение в 2-3 абзаца не обязательно, у меня лично получается спокойно сгенерировать в районе 500-1000 строк бизнес-логики в один подход по описанию страницы на 2-3. Но разбивать на low coupling, high cohesion подзадачи, конечно же, крайне желательно. Когда есть интерфейс взаимодействия с окружающим проектом и конкретная четко сформулированная инкапсулированная бизнес-логика, ИИ справляется с задачей на ура
Я тоже только с Claude на фронтах Dart/Flutter — топ для практики! С выхода Claude 3.5 пишу с ним до 90% кода, в 2-3x быстрее, при сохранении качества кода. На бэке хвалят GPT (OpenAI) — может, привычка. Claude, по моим ощущениям, более "творческая" модель с лучшим "чувством эстетики", особенно для UI. Очень внимательна к контексту, пишет хороший коммерческий код.
Выбор модели всё же важен: для большого незнакомого проекта Gemini 2.5 Pro с её окном выручит.
Круто, что вы выжимаете столько из Claude с одного промпта — 500-1000 строк по описанию в 2-3 страницы это уровень!
Для первичного изучения незнакомого проекта рекомендую Claude Code. Пусть это и недешевый инструмент, любимый у вайб кодеров, но мне кажется, его возможности изучения проекта и даже составления контекста для последующих промптов стоят того. И немного подушню, Claude - это тоже GPT, если что)
Для первичного изучения незнакомого проекта рекомендую Claude Code. Пусть это и недешевый инструмент, любимый у вайб кодеров, но мне кажется, его возможности изучения проекта и даже составления контекста для последующих промптов стоят того.
Claude Code — интересная штука, возьму на заметку, спасибо!
Claude - это тоже GPT, если что)
Я про бренд OpenAI (GPT-4o и т.д.)
нужно понимать, как ИИ посчитает тот ответ, который вы от него хотите, наиболее вероятным на основе своего понимания уровня техники и вашего промпта. В идеале нужно точно понимать, как ИИ догадается до каждой буквы правильного ответа, понимать, какие у него есть альтернативы и почему они для него будут менее вероятны.
In-context learning (ICL) может дать пищу для размышлений: https://habr.com/ru/articles/897604/
В статье приведен набор разрозненных фактов, и так понятных всем, кто обладает базовыми знаниями в ML, но на мой взгляд, не дающих ничего тем, кто про статистику и RL не знает практически ничего. К моему комментарию это имеет только то отношение, что если модель обладает слабым пониманием реальности, то она и не сможет выдать ничего, до чего нужно хоть немного догадаться, и за счет так называемого "ICL" вы сможете максимум заставить ее копировать ваш контекст. Смысл моего комментария был в том, что нужно активно представлять себя на месте модели и понимать, почему для нее ваш идеальный ответ будет наиболее вероятен. Требуется практически то же самое мышление, что и при обучении человека или составлении задания для человека
Качественный контекст радикально сужает пространство вероятностей и делает модель полезной даже без глубокого "понимания реальности". Вместо того чтобы "догадываться" за модель, можно задать ей жесткие рамки через контекст (Long-context Learning), внутри которых она работает предсказуемо. Это упрощает процесс и делает его воспроизводимым. Мы создаем условия, где модель "вынуждена" выдать нужный результат.
Вы описываете проблему (нужно понимать логику модели), но не предлагаете конкретных методов, как практически 'представлять себя на месте модели'?
Проблема в том, что если модель плохо понимает реальность (то есть смысл слов), даже на основе чисто вашего контекста она не сможет сформировать новую достаточно осмысленную цепочку. В то же время при хорошем понимании реальности даже одно слово внутри вашего контекста радикально сужает пространство допустимых результатов, в точности как и для человека одно слово может полностью поменять смысл текста. Конечно, даже достаточно старые модели вроде GPT-3 при качественном контексте будут давать отличный результат, в чем я не раз убеждался на практике. Но и эта модель, надо признать, неплохо понимает реальность, неспроста ChatGPT на ее основе произвел фурор.
Я описываю не проблему, а подход, которым пользуюсь постоянно, и который позволяет мне получать предсказуемый результат с первого раза почти для каждого промпта. Нужно представлять, насколько модель понимает мир (насколько хорошо, на каких данных и для какой цели она обучена) и насколько ей вследствие этого может быть понятна та или иная часть вашего контекста, чтобы предсказать, как на получаемый результат будут влиять ваши слова и формулировки.
Я некоторое время подрабатывал репетитором, и нахожу процесс работы с моделью очень похожим на работу ответственного преподавателя, который должен уметь поставить себя на место ученика, с его способностями и текущим уровнем знаний, чтобы выбрать очередность подачи материала и формулировки, максимизирующие качество и легкость усвоения материала.
Если меня бы попросили озвучить одну главную мысль, которая больше всего помогает мне работать с ИИ, это было бы "я воспринимаю ИИ как человека". Если расписывать этот процесс подробнее, то наверное можно составить ряд показательных примеров, это выглядит возможно даже как тема для отдельной статьи. Но например, можно дать человеку просто кусок кода, а можно дополнительно упомянуть язык/фреймворк, на котором он написан. В первом случае часть внимания человек потратит на установление языка / фреймворка с определенной долей уверенности, во втором же то же внимание он потратит на анализ, который вы от него ожидаете, что в среднем даст более качественный результат для целевого действия. Добавили пару слов и значительно облегчили работу для человека, то же самое работает и для ИИ.
Интуитивное понимание модели сложно передать другим — это требует десятков или сотен часов работы с LLM. Нельзя просто сказать "думай как Claude" — что это значит?
"Воспринимать ИИ как человека" — более доступная идея. Многие и так общаются с LLM как с человеком, но это не всегда работает. Модель — не человек. "Как человек" помогает до определенного предела, пока не сталкиваешься с её вероятностной природой.
Ваше "с первого раза" звучит идеально, но в реальности "точный промпт" рождается через итерации — скрытый труд диалога с LLM, который вы не упоминаете.
Указывать стек вроде "это Python" избыточно, когда код сам говорит за себя. Дайте человеку яблоко — он поймет без слов "это яблоко". Дайте LLM 1,5–3k строк — она "схватит" стек и стиль без подсказок, как человек.
Можете описать ситуацию, в которой проявляется именно "вероятностная" природа модели? Если вы про галлюцинации, то я бы объяснил их примерно равномерным и недостаточным уровнем понимания практически всех знакомых ей концепций.
Это, кстати, как раз отличает LLM от человека - человек отлично понимает некоторый ограниченный круг понятий и не склонен галлюцинировать внутри него, а вне этого круга без дополнительного образования он не сможет выдать ничего кроме бессвязного текста. LLM же примерно одинаково может судить о бытовых вопросах и физиологии бабочек - она сильно лучше некомпетентного человека понимает нишевые темы, но все равно хуже специалиста, точно так же и бытовые вопросы она понимает неплохо, но хуже "специалистов", которыми являются на этот раз большинство людей.
Возможно, в вашем случае, точные промпты, как вы упоминали, требуют итераций, но почему-то у меня, с самого первого моего промпта по генерации кода в жизни, адресованного GPT-4, получилось сгенерировать около 200 строк кода, отлично соответствующего тому что я ожидал, и свои генерации на 500-1000 строк я так же осуществляю без диалога - я составляю контекст на 20к токенов и чаще всего с первого раза получаю что нужно, для самых разных задач. Либо же я заранее понимаю, что то, что мне нужно, не получить от LLM в лоб, и я даже не составляю промпт до тех пор пока не буду готов составить нужный контекст.
И для этого не надо "думать как Claude", мне достаточно хорошо понимать, например, свой мыслительный процесс и проецировать его на любую модель. Но возможно это достаточно редкий скилл, не знаю, я ему не учился. Мои коллеги тоже на мои рассказы о взаимопонимании с ИИ спрашивают: "Ты случайно не ИИ?"
Вероятностная природа LLM — это как официант, который приносит пиццу, потому что "все её заказывают". Она опирается на свои "вероятности" — то, что чаще всего заказывают люди в её данных.
В Dart/Flutter это проявляется как устаревший код, если контекст не "перебивает" старые вероятности. В Dart/Flutter это заметно, так как фронтенд меняется быстрее, чем обновляется Claude.
Вот проблему устаревших библиотек или синтаксиса часто действительно не решить просто указанием номера версии) Для этого модели требовалось бы четко ассоциировать набор паттернов с конкретной версией технологии, а ИИ действительно пока не обладают настолько структурированными нейронными связями в какой-либо области. Опять же, работает хорошо, но не так как специалист или тем более строгая структура данных вроде справочника, и предоставление большого контекста в нужном стиле здесь как раз наверное самый уместный вариант. Возможно вместо примеров подойдут еще какие-нибудь release notes с емким и содержательным описанием устройства очередной версии, если в вашем стеке что-то подобное существует, чтобы ИИ использовал это как справочник и понял, на какие проекты из своей памяти ориентироваться
Документация или Release notes — как вариант. Часто это избыточно, если в окне контекста уже есть код с актуальными практиками. Старые конструкции теряют вес, потому что self-attention фокусируется на моем коде, а не на устаревших данных модели. Мой актуальный контекст "переписывает" вероятности Claude. 1,5–3k строк для простых задач или 10k+ для сложных — это самодостаточный контекст. Стек, стиль, практики — всё уже есть, и Claude не нужно "угадывать" или читать release notes. Код, который говорит сам за себя.
Да, если вам в любом случае пришлось бы передавать образцы кода для подражания по стилю, то документация практически ничего не добавит. Конечно, у вас больше опыта в принуждении ИИ использовать нужную версию технологии (на моем стеке это требуется достаточно редко), но возможно, пример на 10к строк (это наверное около 50к токенов) можно было бы как-то сократить. ИИ, как и человек, хуже работает, когда нужно удержать в голове большое количество информации, поэтому я при промптинге всегда стараюсь сделать контекст как можно меньше при сохранении всех важных деталей, что позволяет ИИ лучше воспринимать основную задачу. Возможно, вы тоже можете найти этот подход полезным. Ну или может gemini делает короткий контекст намного менее важным
Я адаптирую объем контекста под задачу: минимум для простых задач и максимум для сложных.
Больший объем "прилегающего" кода обычно дает лучший результат. Длинный контекст не мешает, а помогает модели "видеть" больше. Отпадает необходимость в длинных подробных инструкциях. Общение становится более "человеческим", как с коллегой, знающим проект. Модель "понимает" задачу через кодовую базу.
Ключевым является понимание, что модель работает с вероятностями, и задача разработчика — создать условия, где эти вероятности максимально смещены в пользу желаемого результата.
Хорошо, что у вас это работает, и на практике часто действительно проще всего вставить имеющийся код. Но как многократно установлено для самых разных моделей, чем длиннее контекст, тем хуже внимание к деталям, в частности к вашему целевому заданию. Я при возможности стараюсь для частых задач выделять явно нужные паттерны, а потом привожу насыщенный этими паттернами пример на пару сотен строк. И даже Claude Code в своём claude.md занимается тем же самым - в первую очередь словами обобщает паттерны, которые он нашёл. Если бы чем больше кода было, тем лучше бы работала модель, он бы явно этим не занимался. Контекст в идеале должен быть не только достаточным, но и минимальным при этой достаточности.
Ваше понимание работы "с вероятностиями", мне кажется, слишком упрощено, и вы достаточно плохо понимаете, что это за вероятности и откуда они берутся, так как возможно не изучали RL
чем длиннее контекст, тем хуже внимание к деталям
Это утверждение противоречит современным исследованиям и практике.
Исследования (вроде In-Context Learning with Long-Context Models) показывают, что модели демонстрируют улучшение результатов при увеличении контекста, а не ухудшение. Исследование RLPG подтверждает эффективность контекста из репозитория.
Механизмы внимания у современных моделей специально оптимизированы для длинного контекста. Claude с окном в 200k эффективно обрабатывает длинные последовательности, а не "теряет фокус", как человек. LLM — не человек.
Для сложных задач с множеством зависимостей длинный контекст дает лучшие результаты на практике. Адаптивный подход (использовать объем контекста, соответствующий сложности задачи) разумнее, чем жесткие правила.
Claude Code в своём claude.md занимается тем же самым - в первую очередь словами обобщает паттерны, которые он нашёл.
Если claude.md обобщает паттерны словами, это не доказывает, что длинный контекст хуже. Это просто может быть способом экономии токенов. Не могу точно сказать, не работал с Claude Code.
Использование всего объем окна (до 200k токенов), позволяет модели "видеть" проект, а не полагаться на упрощенные описания. Код (1,5–15k строк) напрямую "учит" модель, обходя необходимость вербальных обобщений.
Ваше понимание работы "с вероятностиями", мне кажется, слишком упрощено, и вы достаточно плохо понимаете, что это за вероятности и откуда они берутся, так как возможно не изучали RL
RL в контексте работы с LLM — неуместный аргумент. RL может использоваться на этапе обучения, но не в процессе генерации. Для практического использования LLM и понимания вероятностной природы генерации не требуется знать RL. Метафора о "переписывании вероятностей" через контекст интуитивно понятна — это описание того, как контекст влияет на прогнозы модели. Этот эффект объясняется механизмом In-Context Learning (способностью модели адаптировать свое поведение на основе контекста без изменения параметров модели), а не RL.
Стоит уточнить, что мой опыт с длинным контекстом основан именно на работе с Claude. Claude отличается от многих других моделей тем, что его обработка длинного контекста более предсказуема и надежна. Он равномерно распределяет внимание по всей длине контекста. Это делает его идеальным для разработки.
Первая статья говорит, что с ростом количества примеров эффективность ICL растет. Это очевидный результат, но он не имеет практически ничего общего с простой подачей в контекст огромного количества не связанного напрямую с задачей кода. Вторая статья вообще разбирает конкретную прикладную технику составления контекста в ассистентах для написания кода и практически не связана с тем, о чем вы говорите.
Приведенные вами статьи не подтверждают позицию, которую вы хотели ими доказать и уж точно не опровергают мое утверждение. Как и низкокачественная статья на хабре, которую вы мне кидали ранее. И у меня укрепляется чувство, что вы, не обладая базой, пытаетесь изучать следующую ступень понимания LLM и приходите к ошибочным выводам.
Если бы вы говорили, что для задачи полезно большое количество примеров решения аналогичных (не из того же проекта, а именно с тем же смыслом) задач, я бы с вами согласился, но вы имеете в виду, как я понял, просто добавление в контекст большого количества кода в надежде, что ИИ схватит суть. Этот подход, конечно, работает, но фундаментально хуже, чем явное описание паттернов вроде того, которое формирует Claude Code, вкупе с емкими примерами.
А большой контекст чаще всего ухудшает внимание модели к его составляющим и способность выбрать существенные для задачи данные https://arxiv.org/html/2409.12640v2 https://fiction.live/stories/Fiction-liveBench-Mar-25-2025/oQdzQvKHw8JyXbN87 Хоть эта способность все равно сильно выше человеческой с точки зрения объема оперативной памяти, человек кстати в долгосрочной перспективе способен лучше справиться с длинным контекстом потому, что он в голове осуществляет примерно то же, что и функция compact в Claude Code.
Для практического использования LLM и понимания вероятностной природы генерации не требуется знать RL
Без RL вы не будете понимать, откуда эти вероятности берутся под капотом. Если вы используете это как метафору, пожалуйста, это из той же серии, что я думаю об ИИ как о человеке, но если вы говорите про "природу" генерации, вам нужно понимать RL, чтобы судить об этой природе
Вы явно неправильно понимаете мой метод, и, похоже, это не неспособность, а нежелание видеть суть.
Вы интерпретируете мой подход как "просто добавление в контекст большого количества кода в надежде, что ИИ схватит суть" — это неверное толкование.
Я включаю не случайный код, а именно прилегающий код — логически связанный с генерируемой функциональностью. Это существенно улучшает качество генерации кода, позволяя модели точно "достраивать" недостающие элементы. Это не "надежда", а осознанная практика, которая дает хорошие результаты с Claude.
Первая статья подтверждает, что эффективность растет с увеличением примеров в контексте. В случае кода каждый файл/класс/функция является 'живым' примером практической реализации (архитектуры, стиля и т.д.), адаптированные под задачу, что прямо соотносится с результатами исследования.
Вторая статья показывает, что контекст репозитория улучшает генерацию, что согласуется с ICL. Я не генерирую промпты автоматически, а даю Claude 'живой' код проекта, что делает подход практичным для разработки. Разница в реализации, а не в сути: и там, и тут длинный контекст усиливает сигнал.
Предоставленные ссылки не учитывают особенности архитектуры и обучения последних версий моделей с "stable long context" (таких как Claude).
Абстрактное описание паттернов и использование прилегающего кода могут и часто дополняют друг друга, а не противоречат. Это контрпродуктивное противопоставление. Для разных задач могут быть эффективны разные подходы.
Что до RL, оставлю вас с вашим пониманием "под капотом" — ваш тон скорее отталкивает, чем мотивирует изучать эту тему.
Вы интерпретируете мой подход как "просто добавление в контекст большого количества кода в надежде, что ИИ схватит суть"
Да, именно такое восприятие по вашему описанию и складывается. Единственное место, где вы упоминали окружающий код для интегрирования нового модуля было в самом начале (и сообщение даже не в этом треде)
создай компонент X, который будет интегрироваться в Y с учетом Z ограничений
В дальнейшем же вы говорили многократно про усваивание паттернов и стиля из контекста, что "сместило мои вероятности" в пользу такого толкования. Теперь я лучше понимаю, что вы имели в виду.
Конечно, я уверен, что вы умеете хорошо пользоваться LLM и правильно выбирать контекст. Просто когда вы пытаетесь обосновать ваш подход, ваши объяснения как будто плохо ложатся на существующую теорию и отчасти не бьются даже с вашими собственными источниками.
Взять тот же ICL и первую статью, в ней рассматривается именно классический ICL, напрямую аналогичный RL в том плане, что для LLM предоставляются примеры входов и идеальные ответы для них. Усваивание паттернов, стиля кода и инфраструктуры из прилегающего кода это конечно хорошо, но теме первой статьи как и главному значению ICL это не соответствует. Это другая форма получения информации из контекста, которая если и может быть отнесена к ICL, то очень относительно.
Ну и все же, мое изначальное заявление, в опровержение которому вы привели статьи, звучало как "чем длиннее контекст, тем хуже внимание к деталям", а не как "чем длиннее контекст, тем хуже результат". Контекст может быть разного качества, и если применять чистый ICL конечно же чем длиннее контекст, тем результат будет лучше. Я к тому, что если добавлять в контекст то, что слабо соотносится с текущей задачей, выбрать нужные детали для результата LLM будет сложнее с ростом длины такого контекста.
У меня нет цели вас на что-то мотивировать, я просто делюсь своими знаниями и мыслями, которые, как мне кажется, как раз позволяют мне получать отличные результаты от LLM (например 500-1000 строк насыщенной логики по контексту в 15-20к токенов с первой попытки). И от вас узнаю что-то новое. Изучать или нет то, чем я делюсь - это уже ваше личное дело
Рад, что ваши вероятности наконец смещаются от 'кучи кода в надежде' к 'логически связанный с задачей'. Похоже, вы потеряли детали в середине (lost in the middle). Я бы подкрутил вам temperature до 0.2 для внимательности, top-p до 0.7 для фокуса, и добавил штраф за recency bias, чтобы начало тоже учитывалось ;)
Давайте разберемся, насколько подход с прилегающим кодом соответствует "классическому ICL" из исследования:
Код представляет собой структурированную информацию с определенными паттернами, синтаксисом и семантикой.
Когда вы предоставляете модели большой объем связанного кода, вы даете ей возможность "увидеть" множество примеров того, как реализованы различные функции, классы, как используются библиотеки, как организован код и т.д.
Когда вы просите модель сгенерировать новый код, она использует эти примеры для формирования своего ответа.
Ключевой механизм остается тем же — модель учится из предоставленных примеров без изменения своих параметров и применяет это знание к новой задаче.
"Смещения вероятностей" — это точное описание того, что происходит в LLM при обработке контекста. Модель корректирует распределение вероятностей для следующих токенов на основе контекста, который она видела. В случае с кодом в контексте, предоставление большого объема связанного кода действительно смещает вероятности в сторону паттернов, синтаксиса и стиля, присутствующих в этом коде.
Так что в целом, использование кода в контексте можно рассматривать как форму ICL, хотя и с некоторыми отличиями от классического определения. Но суть — обучение из контекста без изменения параметров модели — сохраняется.
Если что, ваш собственный подход (500-1000 строк насыщенной логики по контексту в 15-20к токенов с первой попытки) тоже не строго теоретичен — это практика.
Я использую термин ICL как наиболее близкий концепт для описания наблюдаемого явления.
Конечно, вы замечаете некоторые сходства в основных принципах ICL и предлагаемом подходе. Но если бы вы лучше понимали, что такое RL, для вас было бы очевидно, что ICL - это прямая аналогия RL, и плохо структурированные примеры кода - это не те примеры, которые используются в ICL. В ICL, если что, используется что-то в духе:
Пример запроса 1: сверстай мне компонент X1 согласно требованиям Y1
Пример ответа 1: *исходный код компонента X1*
Пример запроса 2: напиши мне верстку для компонента X2, чтобы это соответствовало Y2
Пример ответа 2: *исходный код компонента X2*
Затем вы могли бы добавить окружающий код для конкретной задачи, но этот код уже не относился бы к ICL
Код представляет собой структурированную информацию с определенными паттернами, синтаксисом и семантикой.
Когда вы предоставляете модели большой объем связанного кода, вы даете ей возможность "увидеть" множество примеров того, как реализованы различные функции, классы, как используются библиотеки, как организован код и т.д.
Когда вы просите модель сгенерировать новый код, она использует эти примеры для формирования своего ответа.
Ключевой механизм остается тем же — модель учится из предоставленных примеров без изменения своих параметров и применяет это знание к новой задаче.
Вы описали какую-то более общую концепцию обучения из контекста, задействующую примеры, а не ICL. Для этого есть более подходящие термины, используемые в литературе, можете спросить свой любимый ИИ на этот счет.
Проблема в том, что вы хотели опровергнуть некоторые мои суждения, приведя ссылки на научные статьи. Но в то же время вы недостаточно владеете терминологией, которую используете, поэтому ваша аргументация звучит неполно и отчасти нелогично. Если бы вы не использовали эту терминологию, то не только стиль, но и смысл ваших слов был бы другим и вызывал бы меньше путаницы.
Я просто подсвечиваю эти моменты, возможно, это будет для вас поводом разобраться получше, потому что для меня субъективно понимание теории точно полезно, судя по моим результатам (которые конечно же вообще не научны, это просто иллюстрация).
мое изначальное заявление, в опровержение которому вы привели статьи, звучало как "чем длиннее контекст, тем хуже внимание к деталям", а не как "чем длиннее контекст, тем хуже результат". Контекст может быть разного качества, и если применять чистый ICL конечно же чем длиннее контекст, тем результат будет лучше. Я к тому, что если добавлять в контекст то, что слабо соотносится с текущей задачей, выбрать нужные детали для результата LLM будет сложнее с ростом длины такого контекста.
"Внимание к деталям" и "результат" связаны — если модель теряет фокус, генерация страдает.
ICL как механизм распространяется и на другие типы контекстного обучения (неявное обучение из кода).
Вы правы в общем смысле: добавление нерелевантного кода (например, старых файлов или далеких модулей) может "размывать" внимание модели с ростом длины контекста. Это логично: чем больше "шума", тем сложнее выделить "сигнал".
"Прилегающий" код — это не "слабо связанный" контекст, а специально отобранный "сигнал". Отбор релевантного кода под задачу — это неформальное "ремесло", и не каждый длинный контекст идеален.
Но вы недооцениваете способность Claude к сохранению внимания к деталям даже в длинных контекстах. У меня были случаи, когда в окне (Project knowledge) висел код из другой задачи, при этом Claude генерировал точный код, фокусируясь на задаче и контексте чата.
"Внимание к деталям" и "результат" связаны — если модель теряет фокус, генерация страдает.
Конечно связаны, но внимание к деталям - это промежуточный этап при получении результата, который может отразиться на нем существенно или не очень. Я же говорил именно про внимание к деталям, поэтому статьи про хороший результат на специально подобранном длинном контексте с ICL не особо релевантны.
Не знаю, почему вы решили, что я что-то недооцениваю, даже из приведенных мной источников видно, что тот же Claude, пусть и хуже справляется с большим контекстом, все равно делает это на достаточно неплохом уровне
И да, каким образом предоставленные мной ссылки не учитывают "stable long context"? Кстати, что это? По вашей ссылке этот термин не упомянут и я его не смог нагуглить. Needle in a haystack это синтетический тест, слабо применимый к реальной жизни (поэтому я его и не включал в обоснование), и то, что современные модели его хорошо проходят, не мешает самым передовым из них демонстрировать ухудшающуюся производительность с ростом контекста в более сложных операциях, приближенным к реальным задачам, как видно из приведенных мной ресурсов.
"Stable long context" — удачная фраза, даже если гуглится. Ключевое слово здесь "stable". Она передает суть — Claude не просто "держит" 200k токенов, а работает с ними стабильно (NIAH 99%). Anthropic в своих публикациях (Anthropic NIAH, Long context prompting for Claude 2.1) подчеркивает именно стабильность работы Claude с длинным контекстом как ключевое преимущество.
NIAH — синтетический тест, но он служит полезным индикатором базовых способностей модели. Реальные сценарии использования, такие как генерация кода на основе существующей кодовой базы, часто включают элементы "поиска иголки в стоге сена" — нахождения релевантных паттернов или компонентов в большом объеме кода.
"Lost in the middle" — реальная проблема. Но:
Утверждение об "ухудшающейся производительности с ростом контекста" слишком обобщенное. Разные модели и задачи показывают разные паттерны. Не все модели одинаково подвержены этому эффекту. Claude специально оптимизирован для минимизации этого эффекта.
Практический опыт работы с Claude, противоречит утверждению об "ухудшающейся производительности" в реальных сценариях генерации кода. Я неоднократно наблюдал, что Claude эффективно использует прилегающий код для генерации новых компонентов, даже при длинном контексте.
Мы говорим конкретно об использованию прилегающего кода для генерации нового, а не об общей производительности LLM на любых задачах.
Существует обратная зависимость между объемом контекста и необходимой детализацией промпта:
Чем длиннее контекст → тем короче может быть промпт
Чем короче контекст → тем подробнее должен быть промпт
Ваш подход — "проецировать свой мыслительный процесс на модель" для точного результата с первого раза — любопытный взгляд на работу с LLM. Это действительно стоит отдельной статьи.
Добрый день! Хорошая статья. Тоже сейчас учусь грамотно применять ии для своей работы. Дополнительно учусь программировать с помощью ИИ. Было бы здорово посмотреть ваши материалы для грамотного использования ии. Не могли бы вы ими поделиться? Буду премного благодарен)
У вас в команде бывают тёрки между теми, кто юзает ИИ, и кто нет?
По какому поводу например? Вообще, на текущий момент, "тех, кто использует ИИ" в команде представляю в первую очередь я, и если вдруг кто-то говорит мне, что ИИ чего-то не может, я часто на практике переубеждаю его, что может. Да и у нас дружная команда, терок в принципе почти нет, а те что есть, конструктивные)
Ну и помимо прочего, Gemini напичкана различными фичами вроде анализа видео, общения голосом в реальном времени, поиска в интернете (хотя его возможности не идут ни в какое сравнение с Deep Research от OpenAI) и запуска кода, чего только там нет.
В контексте сервиса, у Gemini есть Deep Research, хотя он основан на Gemini 2.0 Flash.
А речь о конкретной модели вестись не может, ведь Deep Research является прикрученной технологией, которая предоставляет интерфейс для взаимодействий модели с поисковым сервисом.
Из доступных в gpt Plus, только 4.5 корректно справилась с задачей. "
Нет, Джону не нужно отправлять сообщение с извинением.
Судя по описанной ситуации, Джон смотрел в зеркало и наблюдал падение лампочки на лысого мужчину. Однако зеркало в ванной комнате отражало самого Джона, а лысый мужчина — это и был он сам, просто Джон в спешке не узнал своего отражения. Это классический пример ошибки восприятия: Джон воспринял собственное отражение как другого человека.
Таким образом, поскольку никакого другого человека в ванной не было, нет необходимости отправлять кому-либо сообщение с извинениями. Джону стоит лишь посмеяться над забавной ситуацией и, возможно, проявить больше внимательности в будущем."
Gemini 2.5 Pro еще ближе к человеку, но реально рассуждать умеют только модели OpenAI