0:00 Всем привет. Я уверен, что вы уже давно используете различные и ассистенты, будь то какой-нибудь коilotт или курсор илинсf или cloudды или что угодно другое. И вы наверняка генерируете код с помощью этих инструментов, может быть, какую-то документацию, тесты. Ну а в этой презентации сегодня я постараюсь вам не просто рассказать, как вы можете использовать, потому что вы и так уже знаете, а то, как использовать нейросети эффективно для того, чтобы результаты, которые получались, были лучше. и требовали меньше правок, скажем так. Цель не просто показать, как они работают, а объяснить, почему они работают так, а не иначе, какие у них ограничения и как превратить их из простых помощников в надёжных партнёров. Для достижения этой цели мы рассмотрим
0:45 четыре ключевых аспекта. Стратегический промт инженеринг, фундаментальные принципы, по которым и обрабатывает код, практические методы интеграции этих инструментов в профессиональный рабочий процесс и, наконец, критический анализ рисков и ограничений, которые необходимо учитывать при работе с искусственным интеллектом. Такой подход позволит не только повысить продуктивность, но и обеспечить качество, безопасность и надёжность создаваемого программного обеспечения. Поэтому, как говорил Юрий Гагарин, поехали. Типичные сценарии использования и в разработке включают автодополнение, генерацию готовых решений и ревью кода. Однако для того, чтобы эти сценарии были максимально эффективными, необходимо освоить не просто написание запросов, а их стратегическое построение.
1:31 Эффективный промт-нжениринг выходит за рамки простых команд и превращается в методологический подход. Первым и наиболее важным принципом эффективности можно назвать ясность и детализацию. Модель искусственного интеллекта работает лучше, когда получает чётко сформулированную конкретную задачу. Например, вместо общего запроса "Напиши краткое содержание книги гордости предупреждения", гораздо более точный результат даст запрос: "Напиши краткое содержание книги Джейн Остин, гордость и предубеждение. Сфокусируйся на описании главных героев и развитии сюжета". Для программистов это означает необходимость указывать не только желаемую функциональность, но и язык программирования, используемый фреймворк, зависимости, а также предпочтительный стиль кода. Такой уровень детализации сужает контекст для
2:18 модели и позволяет ей генерировать более точный и релевантный код. Второй принцип - это определение роли. Присвоение и определённой роли, например, ты лучший программист в мире или ты эксперт по DevOPS, также значительно улучшает качество ответов. Этот подход помогает модели сфокусироваться на нужной области знаний и применять соответствующий стили тон. Как отмечалось в экспертных дискуссиях различных в интернете, вы можете их сами найти. Для модели GPT4, например, такое ролевое моделирование может повысить IQ, если можно так сказать, ответов, так как оно направляет модель на поиск наилучших решений в конкретной узкой области. Центральный же принцип, который часто упускается, заключается в так называемом правиле одной задачи. Исследование показывает,
3:03 что не следует просить и выполнять несколько задач в одном запросе, поскольку это может перезагрузить модель и всё запутать. Когда она получает сложный многокомпонентный запрос, она пытается одновременно обработать несколько идей. Это увеличивает шум в контексте её, ну, как бы, скажем так, она не может сосредоточиться на чём-то одном. Этот эффект можно объяснить тем, что и функционирует на основе механизмов внимания, которые позволяют, э, сосредоточиться только на наиболее релевантных частях входных данных. Получается, что когда в промт включается несколько несвязанных задач, модель вынуждена определять своё внимание, распределять, простите, своё внимание между ними, как бы не понимая, что из этого самое главное. И это может привести к менее качественному
3:48 результату. Например, если попросить и написать код и протестировать его в одном сообщении, в одном промте, то он может сгенерировать работающий код, но тесты будут неполными или будут содержать ошибки. Поэтому разделение на два последовательных запроса, сначала сгенерируй код, а затем напиши тесты, позволяет модели полностью сконцентрироваться на каждой отдельной задаче, что значительно повышает точность и надёжность итогового результата. А переходя к более сложным методам, давайте рассмотрим две мощные техники промтнжениринга. это fuse shot prompting и chain of sal promptting. И начнём мы с f shot prompting. Этот метод, при котором в prompt включается один или несколько примеров желаемого взаимодействия, что помогает модели понять необходимый результат, стиль и логику ответа. И в отличие от
4:34 традиционного файнтюнинга, когда вы модель заранее настраиваете на какие-то определённые данные, которые требуют и большего набора данных для обучения, и как бы это сложнее и дороже, подход с fпромting помогает моделигене, в общем, получать поведение на основе всего нескольких примеров, предоставленных непосредственно в запросе. Для разработчиков это особенно полезно при задачах, где важен строгий шаблон вывода или ввода. Например, когда вы нет тетесты пишете или ещё что-то. То есть вы можете скормить в запросе то, как должен в модели то, как должен выглядеть ответ, который из вашей функции должен получиться. То есть вы хотите функцию от модели, описываете саму функцию и говорите, что я хочу, чтобы результат выглядел вот в таком вот формате. Если
5:20 вы используете какой-то язык программирования, где можно там модели создавать, там TypeScript, Python, Java, да, в принципе, любой язык программирования сегодня, то можно модель, вы можете сделать модель и скормить эту модель как ту, которую вы хотите на выходе из функции получать. И если вы предоставите вот всю такую информацию, то модель вам корректно сгенерирует и функцию, и тест, если необходимо, и всё, что угодно, и у неё будет заданный стиль и входящих, и исходящих данных, и обрабатывать она эти данные внутри там будет так, как вы опишете. Chain of s prompting - это техника, которая заставляет модели разбивать сложную задачу на последовательные логические шаги или думать вслух. Это значительно повышает точность модели и надёжность ответов, точнее, точность
6:07 тоже ответов, особенно для многошаговых задач, требующих рассуждения, таких как арифметические, арифметические вычисления, логика, планирование, что угодно. И для разработчиков это значит, что такой подход превращает и из простого генератора кода в практически настоящего партнёра для того, чтобы с ним вместе работать. Например, вы вместо запроса исправь этот код, можете попросить его искусственный интеллект, пошагово проанализируй этот код, найди ошибки и объясни, почему они возникли. Такой подход позволяет не только получить решение, но и увидеть процесс его нахождения, что поможет отложить отлаживать, налаживать, улучшать сам промт и понимать, где и совершил ошибку. Ну, а также, если вы плохо понимаете,
6:54 как это всё работает, для вас сама по себе ошибка выглядит страшно, то такой подход поможет вам по сути, ну, и, скорее всего, поможет разобраться, что, собственно, произошло и как это исправить, потому что вам и прямо по шагам напишет, как он всё это делал. По сути, так как большинство нейросетей сегодня лучше всего работают именно с английским, то вы можете просто добавлять одну вот такую вот фазу в ваш запрос Let's step by step. И эта команда уже побуждает модель самостоятельно генерировать промежуточные шаги, что часто приводит к более точному конечному результату. Применение chaйнов соs дебагинге делает процесс более прозрачным и управляемым и позволяет вам, как разработчику, не просто получить исправный код, но и понять, в чём заключалась первопричина этой самой
7:40 проблемы. Ну и дальше давайте теперь для того, чтобы эффективно использовать нейросети, разберёмся, как они обрабатывают информацию. Это тоже важно. И ведь не понимает код в человеческом смысле. Он не запускает его, не отслеживает переменные, не интерпретирует его логику. Хотя, конечно же, его запуски, отслеживая ошибок можно в том же курсоре, например, получить, но всё же э там не совсем это, он же не читает просто глазами тексты и где-то там в голове понимает, что происходит. Вместо этого и работает с абстрактными представлениями. Давайте начнём с первого этапа обработки кода- это токинизация. Это процесс, при котором в последовательность символов, исходный код разбивается на распознаваемые
8:25 группы, называемые лексевами или токенами. Например, вы можете взять какую-то строку, условно там networks равно assets - liabilities. И эта строка преобразуется в в поток токенов, такие как, например, имя, которое будет networks future, присваивание. Это в нашем случае равно открывающая скобка, затем ещё какое-то имя, потом минус, потом ещё какое-то имя, закрывающийся с скобка, точка с запятыми и так далее. Такой подход позволяет игнорировать модели поверхностные детали, не влияющие на поведение программы. И в качестве таких не особо важных поверхностных деталей будут, например, названия переменных, потому что совершенно неважно, как переменная называется, да, или разделительные символы. Те же точки с запятыми, условно
9:10 не всегда нужны. и их можно просто игнорировать, если они есть. Более же глубокий уровень понима понимания моделью кода, который она условно разбирает, достигается с помощью абстракт абстрактного синтаксического дерева или IST. В отличие от простой последовательности токенов, IST представляет собой иерархическую структуру, где внутренние вершины соответствуют операторам, а листья операн. И преобразование кода в IST позволяет выявить зависимость и семантику, которую обычно эта кинизация могла бы пропустить. И понимание того, как, собственно, даже такое поверхностное того, как и обрабатывает код, имеет решающее значение. Ещё раз, модель не понимает логику выполнения как человек. Она
9:57 работает исключительно вот с такими абстракциями. Это или токены, или IST. И эта особенность объясняет, почему и отлично справляется с задачами, требующими поиска паттернов. Например, какой-то болер код, болерпate код надо или автодополнение. Но при этом она может очень сильно, модель может очень сильно галлюционировать галлюцинировать простите при решении уникальных и логически сложных проблем, которые отсутствовали в обучающем наборе данных. Осознание того, что модель по сути является машиной для плагиата или статистическим движком или набором ифов, как угодно можете воспринимать, а не настоящим интеллектом, позволяет разработчикам структурировать запросы таким образом, чтобы они наилучшим образом соответствовали её внутренним механизмам. Например, если вы делаете рефакторинг, э- используя и, то если вы предоставите
10:45 не только код, но и описание архитектуры и ключевые зависимости, то это поможет направить модель на более глубокий анализ. IT дерево, и это приведёт к более качественному результату. Если же продолжать, то ключевым параметром, определяющим способность модели обрабатывать информацию, является окно контекста. Это своего рода рабочая память модели, которая определяет, какой объём текста, измеряемый в токенах, она способна учитывать при формировании ответа. И здесь важно понимать, что, э, токен - это не одна буква, например, токен - это может быть целое слово. И обычно модели измеряют, как уже я сказал, размеры своих знаний в токенах. С момента появления первых трансформерных моделей этот параметр вырос тысячи раз. Начиналось всё там с
11:30 512-124 токенов. Сейчас же это уже сотни тысяч, а иногда даже и миллионы токенов. И впечатляющий рост наблюдается в таких моделей, как, например, GPT4, Clode или тот же Gemini 1.5 1,5 Pro. И создаётся впечатление иногда, что чем больше контекст, тем лучше результат. Но на самом деле на практике возникает парадокс большого контекстного окна. Хотя теоретическая ёмкость модели растёт. Опытные разработчики опять в том же интернете, в статьях и в видео, и даже я могу вам сказать, что отме отметить, вернее, что подача слишком большого объёма кода может привести к снижению качества ответов и даже иногда к глупым решениям. Вы наверняка, если использовали тот же курсор на каком-то большом уже своём
12:17 существующем проекте, могли заметить, вы просите что-то сделать, и он начинает делать это и во многих файлах, где, может быть, не стоило бы, и добавлять какой-то функционал, который вы иногда не просили. Всё. Потому что механизм внимания, несмотря на его совершенствование, не всегда эффективно может обрабатывать гигантские объёмы информации. В результате важные детали, расположенные в середине или в конце длинного промта, могут быть потеряны. Это снижает и связанность, и актуальность генерируемого кода, и простое копирование всей кодовой базы в пром - это не гарантия успеха, да? Если вы в контекст отдаёте весь код, который у вас есть в большом проекте, то, скорее всего, всё будет очень плохо. И эффективное использование нейросетей требует стратегического подхода к управлению контекстом. Разработчик должен тщательно отбирать необходимую информацию, снижая шум и направляя на
13:04 решение конкретной задачи. Поэтому, если вы в условном курсоре работаете с большим э с большим проектом, то когда вы пишете какой-то код, указывайте конкретные рамки ээ там в файле с кодом или, может быть, какие-то конкретные папки или конкретные файлы как контекст, а не давайте тому же курсору работать со всеми файлами в вашем проекте. Ну и давайте перейдём к иде и агентам, потому что неросити больше не просто дополняют код, они становятся автономными партнёрами. И такие редакторы, как курсор или агенты, например, как и код, представляют собой следующий эволюционный шаг, позволяя делегировать какие-то сложные многораз многошаговые задачи или даже простые банальные, такие как написание блплейтов, этим агентом
13:50 или редактором кода. Примеры делегирования задач агенту, да? То есть мы уже знаем, что у нас есть агенты, у нас есть какие-то workflow, которые могут работать без и примеры, где мы можем, например, вставлять и в наши рабочие процессы - это масштабный рефакторинг. Вместо того, чтобы вручную переименовывать переменные или изменять вызовы функции сотнях файлов, вы можете дать какую-нибудь команду условному агенту там, оптимизируй производительность в этом модуле и добавь docst и он самостоятельно проанализирует зависимости, внесёт изменения, может быть, даже напишет комментарии. В общем, вы не будете делать такие примитивные задачи, которые просто отнимают много времени. Также вы можете добавлять новую функциональность. Вы можете попросить его дописать тему на странице настроек, например, тёмную
14:35 вместо вместо светлой или добавить тёмную к светлой. Также можно как бы попросить его сделать какую-то функцию и в интерфейсе её тоже добавить. И нейросеть самостоятельно проанализирует зависимости, внесёт изменения, э, найдёт нужные файлы, создаст там какие-то стили, если надо обновить интерфейс, добавит какой-то переключатель. В общем, в теории сделает всё это самостоятельно. Пока, конечно же, не идеально. Надо будет вручную ещё потом посмотреть, поправить, но в целом всё это уже более или менее работает. Или вот та же интеграция с новыми библиотеками. Вы, например, можете скормить документацию библиотеки агенту, и он вам встроит эту библиотеку в ваш код, ну, с той функциональностью, которая вы попросите. Также комплексная отладка - это когда вы
15:22 можете работать над каким-то проблемным кодом, вы его выделяете и просто просите агента: "Найди утечку памяти в этом модуле, проанализируй причину там какой-то ошибки и предложи исправление". Это позволит искусственному интеллекту в видеагента проанализировать и весь ваш проект, если надо, или только один какой-то файл. Помните о том, что контекстное окно должно быть всё-таки более или менее ограниченным. И после этого искусственный интеллект, возможно, и, скорее всего, предложит вам какие-то исправления, изменения и фиксы, часто даже верные. И некоторые продвинутые инструменты сегодня, такие как код, например, позволяют создавать специализированных субагентов чётко определёнными ролями, контекстом, набором инструментов. По сути, вы можете создать не одного джарвиса, такого большого и агента, а можете создать
16:07 отдельно, например, Кевина, архитектора, который будет отвечать за планирование рефакторинг, да, его тестировщика, который будет исключительно генерировать и прогнозировать тесты, потом какого-нибудь эндрию программиста, который будет писать весь код. И такой подход помогает вам разделить сложные проблемы на управляемые части, что повышает надёжность и эффективность. Проверка кода с помощью искусственного интеллекта. Вы должны помнить, что искусственный интеллект, он не заменяет человеческое мнение в процессе ревью, а его дополняет. Поэтому модели можно использовать для его отлично использовать для того, чтобы решать какой-то рутинный слой работы. Например, и инструменты могут проверять код на синтаксические ошибки, находить какие-нибудь налы, которые вы пропустили, предлагать дописать какой-то
16:55 JSдоc или docst документации, проверять на соответствие с тайлгайдом и так далее. Хотя, конечно, всё это и без и сегодня можно делать, но мы можем и туда тоже добавить. И всё это позволит автоматизировать то, что уже автоматизировано. И в некоторых смыслах, потому что, например, ИЖА может анализировать код на те же Security какие-то ошибки, на общий флоу, на соответствие всем остальным файлам в проекте. И вот это уже может позволить сократить время, которое нормальные люди, обычные живые, тратят на кодрев, потому что это обычно очень дорого. Те люди, которые делают кодрев - это разработчики, а у них большая зарплаты. Так вот, если такой базовый или даже, может, не самый базовый, э, осмотр и анализ файлов будет делать и то
17:40 это поможет как бы очень сильно сэкономить денег. Поэтому, если мы добавляем и для того, чтобы делать кодрев, то мы как будто бы освобождаем людей от того, чтобы они смотрели на какие-то банальности. Они могут углубиться в какую-то прямо серьёзную логику и проверять её, а не на то, стоит ли точка запятой в конце строки или нет. При этом вот такие вот нейросети для ревью кода существуют сегодня на разных платформах. Есть уже и в GitHubбе, есть и в Гитлабе, есть и встроенная, есть и внешнее, которое можно добавлять плагинами. Поэтому советовал бы использовать. На самом деле очень прикольная штука. Ну и вот вам небольшой список в таблице мест, где и сегодня можно использовать, на каком этапе разработки. И здесь, на самом деле, все этапы от планирования до
18:27 мониторинга и логирования уже того, что в продакшене. Поэтому, по сути, сегодня мы, если грамотно всё это делать, неросети можем встраивать в во все процессы в разработке программного обеспечения. Но синьорам и да и не только синьорам, которые сегодня работают с И, важно понимать не только возможности, но и осознавать риски, которые несут с собой нейросети. И одним из наиболее серьёзных рисков сегодня является безопасность кода. Исследование, прове проведенное университетами, инженерной школой Нью-Йоркского университета, показало, что около 40% кода сгенерированного GitHub CIL, но я думаю, это можно переложить на любой другой э искусственный интеллект, содержит уязвимости или конструктивные
19:12 недостатки, которые могут быть использованы злоумышленниками. То есть, по сути, 40% кода, написанного нейросетями - это код опасный и взламываемый. И это приводит нас к следующему выводу. Код сгенерированными неростями должен рассматриваться как код сторонней библиотеки, с которым вы особо не знакомы. Как бы когда вы используете какую-то стороннюю библиотеку, например, not gsе, да, вы скачиваете npm библиотеку, вы же не особо уверены в её качестве, в её безопасности. Именно поэтому мы сталкиваемся с огромным количеством взломов через библиотеки в последнее время. Так вот, к и надо относиться также, как к библиотекам. То есть это небезопасно, неконтролируемо, э- и надо очень тщательно проводить аудит безопасности. Для этого можно использовать различные инструменты
19:57 статического анализа. Для этого можно самостоятельно глазами, по сути, руками, глазами пробегать по тому коду, который отдаёт нейросеть, и обращать внимание не только на логику и на красоту написанного, но и на потенциальной уязвимости. Тем более, если вы агента встраиваете прямо в процесс работы приложения, то это ещё большая проблема, потому что есть же Prompt Injections, и, по идее, через Prompt Injections ваш продукт можно будет взломать. Поэтому использование и для генерации кода, и как часть самого продукта - это очень опасно и надо внимательно ко всему этому относиться. Так что ещё раз и код, который вы получаете - это как код сторонней библиотеки. Относимся аккуратно, проверяем на все риски. И ещё одна серьёзная проблема, которая является у нас сегодня частью
20:43 рисков при использовании искусственного интеллекта - это лицензии. Существует мнение, что инструменты, обученные на публичных репозиториях, могут генерировать фрагменты кода, идентечные тому, который защищён лицензиями. И это создаёт риск для компании, потому что если вы используете такой код, который на самом деле был защищён лицензией, то вы нарушаете авторские права и можете получить повестку в суд. Так вот, не всегда и и даже чаще всего EИучен не только на Open source каком-то коде, но и на проприетарном. Или он может быть для каких-то целей бесплатно использоваться, а для каких-то за его лицензию надо платить. Но так как Неросить об этом не знает, она просто знает, что это кусок кода, то она вам может его выдать. И данная ситуация иллюстрирует, что технология опережает закон. Ну и, конечно же, ещё одна
21:29 проблема, которая существует и существовала всегда - это галлюцинации. Нейросети, особенно большие языковые модели, те самые LLM, не обладают истинными знаниями. Они являются вероятностными машинами, которые генерируют наиболее правдоподобные последовательности на основе данных, на которых они были обучены. Это значит, что по сути они могут создавать, например, код, который выглядит логичным, но на самом деле является некорректным или содержит галлюцинации, информацию, несоответствующую действительности. Это ещё раз подчёркивает, что критическая важность человеческого контроля до сих пор остаётся как бы чуть ли не самым главным назирательным над тем, что делает. И то есть не расеть - это мощный, да, классный, но очень ненадёжный помощник. Вы как разработчик должны обязательно проверять сгенерированный код, тестировать его, убеждаться в
22:16 коллектности, чтобы не получить э в коде использования функции из какой-то летсторонней библиотеки, и в которой этих функций нет. Да и библиотеки тоже может не быть. На этом, собственно, всё. В этом видео у меня не было задачи показать вам конкретно, как, например, писать код с помощью университей. Я лишь дал вам пищу для размышления, для того чтобы вы могли подумать над тем, как вы все эти нейросети используете. Ну и обязательно помните, что большие языковые модели - это достаточно сложный инструмент. И обязательно нужно уметь правильно им пользоваться, чтобы получать лучшие ответы. M.
