<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://maxim-uvarov.github.io/my-cybegraph/feed.xml" rel="self" type="application/atom+xml" /><link href="https://maxim-uvarov.github.io/my-cybegraph/" rel="alternate" type="text/html" /><updated>2025-10-22T20:21:44+00:00</updated><id>https://maxim-uvarov.github.io/my-cybegraph/feed.xml</id><title type="html">Уваров шарит</title><subtitle>То что я решил пошарить</subtitle><author><name>Максим Уваров</name></author><entry><title type="html">Почему работа с LLM сложнее, чем обещают</title><link href="https://maxim-uvarov.github.io/my-cybegraph/llms/a1-llms-to-change-approach/" rel="alternate" type="text/html" title="Почему работа с LLM сложнее, чем обещают" /><published>2025-10-22T00:00:00+00:00</published><updated>2025-10-22T00:00:00+00:00</updated><id>https://maxim-uvarov.github.io/my-cybegraph/llms/a1-llms-to-change-approach</id><content type="html" xml:base="https://maxim-uvarov.github.io/my-cybegraph/llms/a1-llms-to-change-approach/"><![CDATA[<h2 id="смена-подхода-к-интеллектуальным-задачам">Смена подхода к интеллектуальным задачам</h2>

<h3 id="традиционный-подход-контроль-через-компетенцию">Традиционный подход: контроль через компетенцию</h3>

<p>Раньше возможности ограничены навыками. Развитие идёт медленно — как дерево наращивает годовые кольца, слой за слоем.</p>

<p>Такая работа даёт больше контроля и предсказуемости. Специалист участвует в каждом шаге, встречает препятствия и продумывает решения. Результат понятен и относительно гарантирован.</p>

<h3 id="современный-подход-скорость-через-делегирование">Современный подход: скорость через делегирование</h3>

<p>Появление LLM-агентов изменило ситуацию. Специальные навыки больше не обязательны — задачи можно делегировать модели. Прогресс ускоряется в разы, открывая возможности, которые раньше были недоступны большинству пользователей.</p>

<p>Однако за скорость приходится платить предсказуемостью. Продумывание деталей реализации переходит от человека к модели, и направление развития решения может значительно отклониться от задуманного. Результат зависит от качества постановки задачи для AI — навыка, который нужно приобретать.</p>

<h2 id="почему-ожидания-расходятся-с-реальностью">Почему ожидания расходятся с реальностью</h2>

<h3 id="информационный-шум-и-завышенные-ожидания">Информационный шум и завышенные ожидания</h3>

<p>Любой технологический бум порождает волну профанов, обещающих золотые горы здесь и сейчас. AI-компании, конкурируя за инвестиции и аудиторию, систематически преувеличивают возможности своих продуктов. Это не злой умысел — просто природа рынка и необходимость выживания в конкурентной борьбе.</p>

<p>Социальные сети усугубляют проблему. Они переполнены успешными кейсами: “я за час написал приложение с помощью Claude!” Создаётся искажённая выборка, где видны только победы — реальные или показательные псевдопобеды. Невидимы часы отладки, десятки неудачных попыток, тщательная подготовка промптов экспертами. Пользователь сравнивает свой реальный опыт с этими отретушированными примерами и делает вывод, что проблема в нём, а не в завышенных ожиданиях.</p>

<h3 id="когнитивная-перегрузка">Когнитивная перегрузка</h3>

<p>Современный человек и без того находится на пределе когнитивной нагрузки. Ежедневная жизнь требует постоянного принятия решений, обработки огромных потоков информации, использования десятков сложных технологий.</p>

<p>В этих условиях появляется LLM — технология, которая полностью меняет способ работы. Эффективное использование требует освоения массы новых знаний и навыков. Парадокс ситуации: технология позиционируется как упрощающая жизнь, но требует значительных интеллектуальных инвестиций в период, когда у людей нет свободных когнитивных ресурсов.</p>

<p>Маркетинг обещает мгновенную продуктивность. Реальность требует 2-3 месяцев последовательной практики для освоения базовых навыков работы с LLM [6]. Этот разрыв между обещанием и реальностью создаёт фрустрацию, которая накладывается на технические сложности самой технологии.</p>

<h2 id="технические-причины-сложности">Технические причины сложности</h2>

<h3 id="проблема-очевидного">Проблема “очевидного”</h3>

<p>Главная сложность работы с LLM — асимметрия контекста. Пользователь держит в голове множество деталей своей задачи, включая те, которые кажутся настолько очевидными, что он не озвучивает их.</p>

<p>Для LLM никакого “очевидного” не существует. Модель работает исключительно с явно предоставленной информацией. То, что человек воспринимает как само собой разумеющееся, для модели остается белым пятном, которое она заполняет собственными предположениями.</p>

<p>Например, просьба “создай форму регистрации” кажется однозначной, но подразумевает десятки невысказанных решений: какие поля обязательны? нужна ли валидация email? как обрабатывать ошибки? должна ли форма быть адаптивной? Пользователь считает эти детали “понятными из контекста”, но LLM видит только буквальную инструкцию и заполняет пробелы наиболее вероятными, но не обязательно нужными вариантами.</p>

<p>Масштаб проблемы подтверждён эмпирически: анализ 433 диалогов разработчиков с ChatGPT показал, что отсутствие контекста — причина провала в 42% неэффективных промптов. Общий разрыв в знаниях встречается в 54.7% неудачных случаев против только 13.2% успешных [1].</p>

<h3 id="парадокс-полной-спецификации">Парадокс полной спецификации</h3>

<p>В делегировании задач LLM есть противоречие:</p>

<p><strong>Традиционная работа</strong>: начинаешь с неполного понимания → выполняешь → узнаёшь детали → корректируешь подход → продолжаешь. Неполное знание в начале — это норма.</p>

<p><strong>Работа с LLM</strong>: должен предоставить полную спецификацию в начале → но критичные детали узнаёшь только в процессе работы → которую ты делегировал и не выполняешь сам → поэтому не узнаёшь этих деталей.</p>

<p>Замкнутый круг: чтобы хорошо сформулировать задачу для LLM, нужно уже понимать её решение достаточно глубоко. Но именно это понимание обычно приобретается в процессе решения задачи, который теперь отсутствует.</p>

<p>Конкретный пример: создавая UI компонент вручную, разработчик обнаруживает необходимость обработки edge cases только при интеграции с реальными данными — пустые списки, длинные заголовки, отсутствующие изображения. Эти требования проявляются в процессе, их невозможно сформулировать заранее. При делегировании LLM этот процесс открытия не происходит, и компонент создаётся без учёта случаев, о которых пользователь просто не подумал.</p>

<p>Это объясняет, почему эксперты предметной области получают лучшие результаты от LLM — не потому что они лучше “знают, как разговаривать с AI”, а потому что у них уже есть детальное понимание задачи, накопленное за годы ручной работы.</p>

<h3 id="потеря-обратной-связи-и-инкрементального-обучения">Потеря обратной связи и инкрементального обучения</h3>

<p>Когда специалист работает вручную, он постоянно получает обратную связь от системы. Каждая ошибка корректирует его понимание задачи. Одновременно происходит <strong>инкрементальное накопление информации</strong>: решая задачу, специалист постепенно узнаёт новое о предметной области. Каждый шаг раскрывает новые детали.</p>

<p>Этот процесс опирается на когнитивные механизмы, тренированные десятилетиями — распознавание паттернов, интуитивную оценку сложности, автоматическую декомпозицию, предвосхищение проблем. Они создают петлю обучения от понимания отдельных деталей до развития общих навыков решения подобных задач.</p>

<p>При делегировании задачи LLM петля обратной связи разрывается. Модель получает задание и выдаёт результат, но весь промежуточный процесс остаётся скрытым — какие предположения сделаны, какие пути отвергнуты, где произошло расхождение с ожиданиями. Процесс инкрементального познания коллапсирует.</p>

<p><strong>Следствие</strong>: пользователь не получает обучающей обратной связи. Он не развивает интуицию о том, как правильно формулировать задачи, потому что не понимает механизма, который превратил его инструкцию в конкретный результат. В традиционной работе каждая ошибка объясняет себя сама — код не компилируется, тест падает, UI выглядит не так. С LLM результат просто “не тот”, но почему именно — остаётся неясным.</p>

<p><strong>Дополнительный риск</strong>: петли обратной связи человек-AI усиливают предвзятости в 3 раза сильнее, чем человек-человек. Исследование показало, что начальная предвзятость в 53% превращается в 65% в выводах AI, затем ещё больше увеличивается, когда люди учатся на этих выводах — и часто не осознают этого влияния [2].</p>

<h2 id="психологические-барьеры">Психологические барьеры</h2>

<h3 id="парадокс-скорости">Парадокс скорости</h3>

<p>LLM может выполнить за минуты то, на что у человека ушли бы дни. Казалось бы, это делает итерацию тривиальной: получил неудовлетворительный результат — уточни задачу и запусти заново.</p>

<p>На практике возникает психологический барьер. Когда результат приходит быстро, но оказывается неправильным, это вызывает фрустрацию, блокирующую желание итерировать. Пользователь думает: “Раз это так быстро, почему не получилось с первого раза?”</p>

<p>Эта фрустрация иррациональна, но предсказуема. Быстрый неверный результат психологически воспринимается хуже, чем медленный процесс с постепенной коррекцией. Мозг интерпретирует скорость как признак простоты задачи, а необходимость итераций — как провал системы, а не естественную часть процесса.</p>

<h3 id="проблема-калибровки-ожиданий">Проблема калибровки ожиданий</h3>

<p>В традиционной работе человек заранее знает, что задача займёт, например, неделю. Он морально готов к этому временному горизонту. С LLM задача “должна” решиться быстро, и каждая дополнительная итерация воспринимается как провал, хотя даже несколько итераций (каждая от минут до часов в зависимости от объёма и сложности) — это всё равно гораздо быстрее недели.</p>

<p>Отсутствует калибровка: сколько итераций “нормально” для задачи определённой сложности? Простая задача (форматирование кода) — 1-2 итерации. Средняя задача (новый компонент с чёткими требованиями) — 3-5 итераций. Сложная задача (рефакторинг архитектуры) — 7-15 итераций. Этот опыт ещё не накоплен интуитивно ни индивидуально, ни коллективно, поэтому любая итерация вызывает вопрос “а должно ли так быть?”</p>

<p>Исследование на 560 участниках выявило контринтуитивный метод ускорения калибровки: <strong>демонстрация границ ошибок AI</strong> (где и почему модель проваливается) улучшает решения о делегировании эффективнее, чем показ только успешных результатов [3]. Это сокращает время калибровки с недель до дней. Парадоксально, но знание ограничений инструмента оказывается важнее знания его возможностей.</p>

<h3 id="конструктивное-vs-деструктивное-взаимодействие">Конструктивное vs деструктивное взаимодействие</h3>

<p>Когнитивные процессы, которые мы тренировали десятилетиями, остаются невостребованными или используются неправильно. Исследования различают два типа взаимодействия с AI:</p>

<p><strong>Конструктивное взаимодействие:</strong></p>
<ul>
  <li>Задавать зондирующие вопросы к предложениям AI</li>
  <li>Оспаривать предположения</li>
  <li>Синтезировать вывод с независимыми знаниями</li>
  <li>Использовать AI как партнёра по мышлению</li>
  <li>Итерировать на несовершенных результатах</li>
</ul>

<p><strong>Деструктивное взаимодействие:</strong></p>
<ul>
  <li>Пассивное потребление ответов</li>
  <li>Принятие первого вывода без оценки</li>
  <li>Аутсорсинг мышления вместо его усиления</li>
  <li>Избегание итераций из-за воспринимаемого “провала”</li>
</ul>

<p>Простое внедрение “челлендж-промптов” после ответов AI (“Какие предположения здесь могут быть неверны?”) снижает пассивное принятие на 40% [4].</p>

<h2 id="инверсия-метрик-и-навыков">Инверсия метрик и навыков</h2>

<h3 id="невидимые-vs-видимые-итерации">Невидимые vs видимые итерации</h3>

<p>Правильный вопрос не “Почему LLM не сделал идеально с первого раза?”, а “Какое время до результата приемлемого качества?”</p>

<p><strong>Традиционный подход:</strong></p>
<ul>
  <li>Время до первого результата: дни/недели</li>
  <li>Количество итераций: встроены в процесс (невидимы)</li>
  <li>Качество: высокое (при наличии навыков)</li>
  <li>Барьер входа: высокий (нужны навыки)</li>
</ul>

<p><strong>LLM-подход:</strong></p>
<ul>
  <li>Время до первого результата: минуты</li>
  <li>Количество итераций: 3-7 для средних задач (видимы и вызывают фрустрацию)</li>
  <li>Качество: от базово работающего до высокого (зависит от постановки задачи)</li>
  <li>Барьер входа: низкий (специальные навыки не обязательны)</li>
</ul>

<h3 id="сдвиг-от-выполнения-к-формулированию">Сдвиг от выполнения к формулированию</h3>

<p>Возникает новая специализация: не “как сделать задачу”, а “как описать задачу так, чтобы LLM её сделал”. Это отдельный навык, требующий понимания:</p>
<ul>
  <li>Как модель интерпретирует инструкции</li>
  <li>Какие детали критичны для указания</li>
  <li>Как структурировать контекст</li>
  <li>Когда разбивать задачу на подзадачи</li>
</ul>

<p>Парадокс: теперь нужно учиться не столько делать, сколько объяснять. При этом качество результата по-прежнему зависит от глубины понимания предметной области — эксперты получают отличные результаты за 1-2 итерации, новички тратят 5-7 итераций на тот же результат. Это не проблема технологии, а естественное следствие того, что любой инструмент эффективнее в умелых руках.</p>

<p>Развитие этого навыка требует <strong>2-3 месяца последовательного использования</strong> [6], а не интуитивного освоения, как обещает маркетинг. Это реальная кривая обучения, требующая целенаправленной практики.</p>

<h2 id="как-адаптироваться">Как адаптироваться</h2>

<p>Переход от ручной работы к делегированию LLM — это обмен контроля на скорость. Мы получаем низкий барьер входа и многократное ускорение, но теряем непрерывную обратную связь и автоматическое обучение через практику.</p>

<p>Адаптация требует:</p>

<ol>
  <li>
    <p><strong>Принять итеративность как норму</strong>: итерации могут занимать от минут до часов в зависимости от объёма и сложности, но это всё равно быстрее, чем делать руками</p>
  </li>
  <li>
    <p><strong>Развивать навык вербализации контекста</strong>: явно указывать стиль кода, паттерны проектирования, требования к обработке ошибок</p>
  </li>
  <li>
    <p><strong>Калибровать ожидания реалистично</strong>: сложные задачи требуют 7-15 итераций даже с LLM. Это нормально</p>
  </li>
  <li>
    <p><strong>Строить обратную связь искусственно</strong>: после каждой неудачной итерации анализировать, какая информация не была передана модели. Вести лог типичных упущений</p>
  </li>
  <li>
    <p><strong>Понимать границы применимости</strong>: задачи с глубокой интеграцией часто эффективнее решать традиционно с точечным использованием LLM для подзадач</p>
  </li>
  <li>
    <p><strong>Разбивать задачи на наблюдаемые цепочки</strong>: вместо “проанализируй датасет и создай визуализацию” использовать пошаговый подход с видимыми промежуточными результатами. Исследования показывают, что 9 из 10 пользователей естественно принимают такой подход, и он сохраняет возможности обучения при использовании возможностей AI [5]</p>
  </li>
  <li>
    <p><strong>Практиковать конструктивное взаимодействие</strong>: задавать вопросы к предложениям AI, оспаривать предположения, использовать модель как партнёра по мышлению, а не как оракула</p>
  </li>
</ol>

<p>Ключ к эффективной работе — принять другую логику взаимодействия с инструментом, который работает через описание, а не через прямое управление. Не пытаться воспроизвести старую модель контроля, а построить новые навыки работы с качественно иным типом инструмента.</p>

<hr />

<h2 id="источники">Источники</h2>

<p>[1] ArXiv (2025). Анализ диалогов разработчиков с ChatGPT на GitHub. Исследование выявило разрыв в знаниях как основную причину неэффективных промптов.</p>

<p>[2] Glickman, M., &amp; Sharot, T. (2025). How human–AI feedback loops alter human perceptual, emotional and social judgements. <em>Nature Human Behaviour</em>, 9(2). https://www.nature.com/articles/s41562-024-02077-2</p>

<p>[3] Taudien, S., et al. (2022). Calibrating Users’ Mental Models for Delegation to AI. <em>Proceedings of ICIS 2022</em>. https://aisel.aisnet.org/icis2022/user_behaivor/user_behaivor/16/</p>

<p>[4] ArXiv (2025). From Consumption to Collaboration: Measuring Interaction Patterns to Augment Human Cognition in Open-Ended Tasks. https://arxiv.org/html/2504.02780</p>

<p>[5] Wu, T., et al. (2022). AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts. <em>Proceedings of ACM CHI 2022</em>. https://dl.acm.org/doi/fullHtml/10.1145/3491102.3517582</p>

<p>[6] Синтез исследований и практических наблюдений экспертов (Yan, E., Willison, S., et al.) о кривой обучения работе с LLM показывает необходимость 2-3 месяцев последовательной практики для достижения базовой компетентности в делегировании задач AI.</p>

<h3 id="дополнительная-литература">Дополнительная литература</h3>

<ul>
  <li>
    <p>De Freitas, J., et al. (2023). Psychological barriers to the adoption of AI. <em>Nature Human Behaviour</em>. https://www.hbs.edu/ris/Publication%20Files/DeFreitas%20-%20Nature%20Human%20Behavior%20-%20Psychological%20Barriers%20to%20AI_b802852e-5cfb-4dca-8e68-d45af0b7d818.pdf</p>
  </li>
  <li>
    <p>Yan, E. (2023). Patterns for Building LLM-based Systems &amp; Products. https://eugeneyan.com/writing/llm-patterns/</p>
  </li>
  <li>
    <p>Weng, L. (2023). LLM Powered Autonomous Agents. https://lilianweng.github.io/posts/2023-06-23-agent/</p>
  </li>
  <li>
    <p>Anthropic. (2025). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents</p>
  </li>
</ul>]]></content><author><name>Максим Уваров</name></author><category term="llms" /><category term="Maxim Uvarov" /><summary type="html"><![CDATA[С мая месяца я использую claude code ежедневно. И даже немножко учу других. Вот важное, чего я испытал на своей шкуре.]]></summary></entry></feed>