Когда разработчик впервые применяет языковую модель, ошибка часто возникает ещё до первого ответа. Он переносит на модель собственный способ работы и ожидает, что она будет действовать как человек: запоминать информацию «в голове», уставать, понимать интерфейс и спорить. Это некорректный перенос.
Языковая модель — не человек. Это инструмент, порождающий код на основе статистических связей. Данная статья родилась как небольшая помощь моим юным коллегам, позволяющая получить набор эргономичных правил для взаимодействия с нейросетевой моделью и организации труда с целью получить максимальную выгоду для себя и не навредить проекту.
Содержание:
Когнитивная нагрузка
Глубина контекста, а не его охват
Поведенческие ограничения и вероятностная природа ответа
Рутина — главное место, где модель полезна
Итог
Об авторе и контексте
Добрый день, меня зовут Семён. Я занимаю должность руководителя лаборатории опытно-конструкторских разработок в области систем медицинских ускорителей, систем протонной терапии и дозиметрии ООО «Натшелл».
Разработка ПО является частью нашей внутренней рутины, и технология нейросетей не обошла нас стороной. Мы активно применяем её для повседневных задач и хотим поделиться набором наблюдений. Описание касается преимущественно больших языковых моделей в контексте программирования, но представленные суждения могут быть расширены и на общий случай.
1. Когнитивная нагрузка
Когнитивная нагрузка — это «загрузка процессора» вашего мозга. Чем больше информации нужно одновременно удерживать и обрабатывать, тем выше нагрузка и тем быстрее наступает усталость от удержания или обработки этих сведений.
У нейросети нет человеческой усталости. Если дать ей доступ к фрагментам кода, она механически сопоставит имена и шаблоны, не затратив на это сколько-нибудь усилий в привычном для нас понимании. При всём при этом, она создаст такой уровень вложенности и горизонтальных связей между сущностями кода, что в нём можно будет потеряться как в лабиринте минотавра. Это нормально для машины, но плохо для человека.
Когда мы говорим о разработке, в подавляющем большинстве случаев конечным пользователем и тем, кто будет поддерживать код, является не нейросеть, а человек. Если мы применяем модель без ограничений, мы даём ей карт-бланш на создание кода со значительно более широкими горизонтальными связями. В результате разработчик, входящий в такой код, испытывает критический стресс — порой превышающий стресс от разбора даже легаси кода.
Первое правило – упрощайте как только можете.
Чтобы сберечь нервные клетки, мы должны целенаправленно снижать когнитивную нагрузку на самих себя. Создаваемый совместно с нейросетью код обязан быть в первую очередь понятным и линейным — даже ценой многословности. И только потом — красивым и коротким.
2. Глубина контекста, а не его охват
Человек растёт и развивается в языковых, слуховых, визуальных, тактильных раздражителях. Нейросети же, если они не мультимодальные, узконаправленны. Они развиваются в рамках ограниченного набора данных и дополнительно «затачиваются» на производительность: урезаются параметры, слои, используется квантование, снижается точность, накладываются ограничения. Поэтому в работе с любой моделью всегда необходимо давать ей «фору» — намеренно снижать сложность и объём входных данных, давая поправку на отсутствие у неё связей высших размерностей, которыми обладает человек. Одной из задач программиста, работающего с такой моделью, будет корректное определение правил работы (стартовый промпт). Такие правила следует минимизировать в своём объёме, следует избегать «простыней» с текстом.
Вы можете спросить, а почему не использовать superskills на 8 тысяч строк, которыми сейчас принято пользоваться, ведь таким образом я жёстко задаю рамки работы модели? Причина, по которой «простыни» правил не работают лежит на дне нейросетевого омута. Даже современные «монстры», технически способные проглотить гигантский объём текста, страдают от эффекта «lost in the middle» («потерянное в середине»).
Исследования в целом и непосредственно наш опыт использования моделей, локально запускаемых на ПК, показывают, что все они хорошо извлекают информацию из начала и конца промпта, и речь сейчас не про всё контекстное окно модели, а именно про единичный промпт. Инструкции, находящиеся в середине какого-либо сообщения, не игнорируются полностью, но их вес и точность выполнения снижаются — внимание модели размывается по всем токенам (элементам слов и предложений). Именно по этой причине расширение списка требований не даёт того эффекта, на который изначально рассчитывает программист.
Второе правило — стремитесь к сокращению объёма правил, передаваемых в модель при генерации.
Запросы должны быть краткими и самодостаточными. Один запрос — одна конкретная задача. Для маленьких десктопных моделей практически только так. Попытка скормить модели «простыню» требований даже высокого уровня ведёт к деградации результата. Расширение списка правил и объёма стартового промпта, по обычаю, не приводит к улучшению генерации, а порой даёт обратный эффект: в длинном перечне правила теряются между началом и концом промпта.
3. Поведенческие ограничения и вероятностная природа ответа
Любая модель обучена не только порождать вероятный ответ, но и следовать определённым правилам поведения, встроенным разработчиками (обратная связь от людей, идеологические принципы и пр.). Эти надстройки вы не видите снаружи, но они неявно ограничивают спектр ответов. Кроме того, языковая модель — стохастически-статистическая система: один и тот же запрос не обязан давать одинаковый код. Исследования генерации текста показывают, что даже способ выбора исходного фрагмента одного и того же текста влияет на качество и форму результата.
Не ждите от модели идентичных ответов на повторный запрос, а если не ждёте, то помните, рефакторинг без учёта стабильности ответов модели может превратиться в путешествие по замкнутому кругу в болоте.
Если вам нужен контролируемый результат, вам придётся задавать не просто явные интерфейсы, структуры данных, типы, но и накладывать ограничения на саму логику процесса генерации и кода. Нужно формировать поток работы модели - её поведение явными правилами.
Если вы используете самодельные «фреймворки» при работе с моделью или личную библиотеку, будьте уверены, модель сочтёт их как лишнее сопротивление своей работе. Причина тому - сама конструкция модели, заложенный порядок и направление «мышления». И модель всегда будет тяготеть к заученной последовательности. Именно по этой причине она будет стараться избегать применение нетиповых конструкций в коде и переделывать их в пользу типовых решений, заложенных на стадии своего создания и обучения.
Третье правило – явно специфицируйте логику генерации и используйте типовые решения вместо самодельных фреймворков.
4. Человек глубже модели по слоям восприятия
Опыт человека заземлён в физическом мире: зрение, слух, тактильные ощущения, пространственные связи. Текстовая модель этого лишена. Например инженер, по фотографии платы, может понять, что разъём физически не встанет в неправильно изготовленный корпус.
Большая часть моделей, с помощью которых ведут программную разработку ограничены именно текстом. Текстовая модель, созданная для выполнения задач программирования не обученная на изображениях, звуке или тактильной связи, будет не в состоянии реализовать графический интерфейс по одной причине – у неё нет «опыта» и знаний в этой области. Единственным выходом может быть транспонирование графических и логических представлений в область текстовых абстракций или новых сущностей, но то будет равносильно попытке объяснить слепому, как вы воспринимаете цвет, посредством вкуса.
Модель, без подробного описания, не имевшая канала восприятия или набора данных формирующих ландшафт её весовых коэффициентов, заполнит пробел правдоподобной информацией, наиболее близко соответствующей её пространству понятий.
Если для решения задачи нужно понимание физического мира, интерфейса или состояния системы, вы обязаны явно описать это текстом или посредством новых абстракций, связанных логически, что не просто. Это касается графических интерфейсов в первую очередь.
Правило номер четыре – не опирайтесь на невысказанный контекст и передавайте модели абстракции и определения непосредственным примером.
Если вам необходим нестандартный функционал приложения или механизмы, которых не существует в стандартном исполнении, то вы обязаны в явном виде, кодом, передать желаемый вами формат.
5. Рутина — главное место, где модель полезна
Нейросеть не должна и не заменит инженера полностью. Это производительный инструмент для работы с однотипными, объёмными, проверяемыми задачами — с тем, что человеку долго и неприятно делать вручную.
История языков программирования высокого уровня хорошо показывает эту логику. Их смысл был не в том, чтобы машина стала умнее человека или приблизилась к нему в работе с текстом, а в том, чтобы человек перестал вручную выполнять низкоуровневые повторяющиеся действия. Объектно-ориентированное программирование решало похожую задачу: изолировать состояние и поведение, поднять уровень описания, убрать часть рутины в абстракции.
Но здесь есть известная ловушка. Абстракция может не только упростить работу, но и притащить за собой лишний слой окружения. Джо Армстронг критиковал объектно-ориентированный подход через образ, где вместе с нужным объектом приходится тащить слишком много связанного окружения. Но именно данная абстракция, эти самые джунгли это и есть тот багаж, который был призван убить рутину низкого уровня через шаблоны объектов (классы) – это то, к чему всё и шло.
Поэтому если задаться вопросом «объектно-ориентированное программирование оправдало ожидания или нет?» хорошо выражается фразой: «Да, но фактически нет».
Смысл не в том, что объектный подход плох. Смысл в том, что абстракция полезна только тогда, когда она действительно изолирует рутину, а не создаёт новые джунгли с обезьяной ради банана, за которыми потом приходиться ухаживать в режиме рутины.
С нейросетями та же картина.
Когда разработчик пытается передать модели собственное инженерное мышление и ответственность за архитектуру, он неизбежно начинает подстраиваться под модель. Возникает эффект подмены и разворот парадигмы вашей работы. И вот вы уже тратите силы не на управление инструментом, а на рутину исправления всего направления работы.
Пятое правило – модель это станок для рутины.
Отдавайте нейросети рутинные операции, но не ответственность за смысл. Требуйте от модели простого для понимания кода, избегая неочевидных состояний и сильной связности – объём сам по себе не страшен, страшна сложность, превращающая использование модели в новую рутину.
Перечисленные правила призваны направить ваше мышление в правильном направлении: перестаньте видеть в нейросети джуниора, человека или искусственный интеллект, и смотрите на него как на мощный, ручной и многофункциональный инструмент. Он идеально выполняет повторяющуюся, формально проверяемую работу, но не принимает инженерных решений и не способен думать за вас. И прошу помнить, что мы не говорим про лабораторные модели, разворачиваемые на суперкомпьютерах для моделирования свойств нашей вселенной и имеющих самую сложную архитектуру, мы говорим про то, что доступно большинству.
Итог
1. Код — для человека. Снижайте собственную когнитивную нагрузку. Код должен быть понятным и линейным — многословность допустима, непрозрачность нет.
2. Атомарность запросов: одна задача — один короткий запрос. Длинные «простыни» ухудшают результат.
3. Контролируйте через рамки: стабильность достигается не удачей, а жёсткими ограничениями с вашей стороны (типы, интерфейсы, явные контракты, логика работы).
4. Описывайте реальность: у модели нет глаз и тела. Весь неявный контекст физического мира и интерфейса должен быть передан текстом.
5. Модель — инструмент: отдавайте ей рутину, а не архитектурные решения и не ответственность за смысл.
Придерживаясь данных правил, вы превращаете языковую модель из непредсказуемого «напарника» в мощный инструмент, который ускоряет разработку, не разрушая при этом вашу кодовую базу и нервную систему.
Ниже приведён список источников, из которых можно почерпнуть немного информации по основам утверждений данной статьи:
1. Nelson Cowan - The magical number 4 in short-term memory: A reconsideration of mental storage capacity
2. John Sweller - Cognitive Load During Problem Solving: Effects on Learning
3. Nelson F. Liu - Lost in the Middle: How Language Models Use Long Contexts
4. Kelly Hong - Context Rot: How Increasing Input Tokens Impacts LLM Performance
5. Long Ouyang, Jeff Wu - Training language models to follow instructions with human feedback
6. Jiashuo Liu - Towards Out-Of-Distribution Generalization: A Survey
7. Sida Peng - The Impact of AI