GitHub Copilot - Token Optimization [APAC]

Привет всем. Спасибо, что присоединились к нам на нашем следующем занятии, оптимизация токенов GitHub Copilot. Меня зовут Анна. Я буду вашим продюсером на этом занятии. Я организатор мероприятий для Reactor, присоединяюсь к вам из Редмонда, штат Вашингтон. Прежде чем мы начнем, у меня есть несколько быстрых организационных моментов. Пожалуйста, уделите минуту, чтобы прочитать наш кодекс поведения. Мы стремимся обеспечить уважительную среду как для нашей аудитории, так и для докладчиков. Хотя мы абсолютно поощряем участие в чате, мы просим вас быть внимательными к своим комментариям, оставаться профессиональными и по теме. Следите за чатом. Мы будем публиковать полезные ссылки и проверять вопросы для нашего докладчика. Наше занятие записывается. Оно будет доступно для просмотра по запросу прямо здесь, на канале Reactor. На этом мы передадим слово нашему сегодняшнему спикеру. Спасибо, что присоединились. >> Привет, как дела у всех? Меня зовут Тодд Толлер, и я архитектор облачных решений, или старший архитектор облачных решений, в Microsoft. Я работаю в команде, которую мы называем командой продуктивности разработчиков Tech Success. И поэтому, как часть этого, мы здесь, чтобы помочь вам понять качество агентов и оптимизацию токенов. Так что добро пожаловать. Мы рады видеть вас здесь. Мотивация этого курса заключается в том, что, как вы знаете, это, конечно, связано с переходом GitHub от запросов на премиум-обслуживание к оплате по мере использования. Это огромное изменение, и поэтому оно вызвало много вопросов о потреблении токенов. Поэтому клиенты часто спрашивают нас, как мы можем улучшить наши расходы на токены? Как мы можем понять, насколько оптимизированы наши токены? Какова наша общая экономика токенов. Мы надеемся ответить на некоторые из этих вопросов сегодня и дать вам, знаете, хорошую основу для начала. Итак, мы собираемся, знаете, мы боимся, мы не хотим, чтобы вы обязательно полностью сосредоточились на затратах, потому что есть много разных аспектов, и сосредоточение на затратах может, знаете, уменьшить ценность, которую вы получаете от Copilot. Так что лучший вопрос, который стоит задать: как мы можем получить максимум от токенов, которые мы тратим? И с этим вы начнете, знаете, видеть, как действительно объединить все эти части. Так что с этим, знаете, это на самом деле сводится к, знаете, к оптимизации токенов, как мы узнаем. Так что мы перейдем к этому через мгновение. Перейдем к слайду два. Итак, в этой презентации три части. Часть первая: почему качество агента является лучшим фокусом. Мы рассмотрим, почему оптимизация по качеству превосходит оптимизацию только по стоимости, и как улучшения качества могут естественным образом сократить расходы на токены. Часть вторая будет своего рода фундаментом. Мы рассмотрим основы больших языковых моделей, агентов и контекстных окон. Этот фундамент поможет вам, знаете, получить глубокое понимание оптимизации и качества. Но, знаете, это также поможет вам оценить сотни советов по оптимизации токенов, циркулирующих в Интернете, и сформировать собственное суждение о том, что работает. Информации много. Не вся она полностью точна. Поэтому, чем больше мы, знаете, сможем направить вас по этому пути, тем лучше, мы надеемся, вы будете. Часть третья посвящена контролю качества и токенов, а также практическим советам по оптимизации. Мы углубимся в некоторые практические средства контроля, которые вы можете использовать, от выбора модели до подсказок и конфигураций агентов, с некоторыми практическими советами по оптимизации. Цель здесь — стать лучше с меньшими затратами. Знаете, это своего рода мантра, я полагаю, постковидная эпоха, верно? Делать больше с меньшими затратами. Я всегда говорю это наоборот. Это правильно. На этот раз я сказал правильно. Так что в любом случае, давайте начнем с того, почему качество агента является лучшим фокусом. Чтобы понять это, давайте посмотрим, как индустрия работает сегодня. Каждый из нас, знаете, как каждый из нас, вероятно, действует. Знаете, мы используем агентов в том, что я бы назвал своего рода системой азартных игр. И поэтому, знаете, НАСА, у нас есть эта аналогия с НАСА Артемида: если бы ракеты были дешевыми, НАСА могло бы просто отправить 20 ракет примерно в направлении Луны. Если бы одна из них приземлилась, отлично. Если бы ни одна из них не приземлилась, вы просто отправили бы следующие 20. Это точно соответствует тому, как агенты часто используются и использовались. Итак, вы даете немного контекста. Вы пишете подсказку, но не прилагаете слишком много усилий. А затем вы отправляете агента в путь. Если он возвращает хороший результат, отлично. Если нет, вы просто, знаете, отправляете следующего агента, стреляете в Луну, что угодно, как бы вы на это ни смотрели. Проблема такого подхода к азартным играм в том, что он больше не является устойчивым. Он никогда не был. И это часть того, что мы видим, знаете, теперь, когда код стал дешевым. Вы должны думать о том, как, знаете, как тратятся токены. И поэтому, знаете, это было устойчиво, когда у вас было всего два, три или четыре агента в день. Это больше не устойчиво в направлении, в котором мы движемся, когда десятки, если не сотни агентов отправляются каждым разработчиком каждый день, и это число экспоненциально растет по мере нашего продвижения. Поэтому эти сеансы агентов становятся все длиннее и длиннее, и больше токенов, и больше токенов. Так что, знаете, это не устойчиво с финансовой точки зрения для нас, знаете, для GitHub и Microsoft, потому что мы раньше несли эти расходы, знаете, если использовался PRU, и это было несколько сотен токенов, знаете, мы, как правило,, вероятно, зарабатывали на этом деньги. если это были десятки тысяч токенов, мы, как правило, теряли на этом значительную сумму денег. Вычисления теперь не дешевы в наши дни. Так что, знаете, мы раньше несли эти расходы, и теперь мы переходим на модель оплаты по мере использования. Это больше не устойчиво и для вас как клиента. Так что пора что-то менять, чтобы понять, как двигаться дальше. Если вы смотрите на это исключительно с точки зрения затрат, вопрос становится: как мы можем сделать топливо дешевле? И это действительно просто вопрос: как мы можем продолжать играть в азартные игры, и это не то, что нужно делать. Это не то, что мы хотим видеть. Поэтому я также хочу, чтобы вы подумали о том, чего мы хотим. Знаете, чего это стоит. Я также не думаю, что это то, что вы хотите делать. И поэтому вместо этого мы должны работать над сокращением количества отправляемых ракет. Потому что больше из них действительно попадут в цель. Чем больше, знаете, другими словами, нам нужно увеличить ценность каждого агента и повысить качество агентов, которых мы отправляем, прежде чем мы их отправим, чтобы ни один из них, знаете, или так, чтобы, прежде чем мы их отправим, они все достигли цели. Нам нужно меньше агентов, меньше агентов автоматически означает меньше потраченных токенов, и нам нужно, чтобы это начало работать с лучшей отдачей от инвестиций, отдачей от инвестиций для наших агентов. Это большой сдвиг в нашем мышлении. И поэтому увеличение ценности агента означает, что мы должны повысить его качество. И поэтому, знаете, вы должны заставить ракету приземлиться. И вы думаете о, знаете, всех различных, знаете, НАСА и, я думаю, SpaceX и некоторых других, знаете, как они это делают. Знаете, они не запускают то, что, как они знают, разобьется или взорвется на вылете, и надеются, что если они доберутся до места назначения, они очень усовершенствованы. И они дают много контекста, чтобы добраться точно туда, куда им нужно, и они знают с достаточно высоким процентом, что они доберутся. И поэтому, знаете, оптимизация затрат, потому что когда она, знаете, когда оптимизация затрат при нулевой ценности — это бесполезная работа, как мы можем ясно видеть, глядя на формулу ROI здесь, это стандартная формула ROI, примененная к разработке агентов. Одно предостережение: вы не можете действительно чисто рассчитать это, знаете, как вы количественно оцениваете ценность выходных данных агента? Многие компании борются с этим, и, честно говоря, у нас нет идеальной рекомендации, но только потому, что вы не можете рассчитать формулу, это не означает, что она не верна, и поэтому она по-прежнему полезна в качестве руководства, и это помогает нам, знаете, это своего рода помогает нам в направлении. Но есть еще одна динамика, которая делает этот аргумент еще сильнее. Часто увеличение ценности агента достигается за счет фактического уменьшения количества токенов, за счет увеличения количества токенов. Что мы видим, как многие разработчики делают, это, знаете, набивают релевантную информацию и слишком много текста в контекстные окна, и они позволяют разговорам накапливаться с этой бесполезной информацией, за которую они платят каждый раз. Поэтому сокращение этого контекста является огромным рычагом как для лучшего качества, так и для меньших затрат на токены. Вы получите лучшие ответы быстрее и дешевле. Так что, знаете, это не единственная причина, по которой мы хотим, чтобы качество играло огромную роль в ROI. Есть третья причина, почему фокусировка на качестве более важна. Проблема нарастающей ошибки. Большие языковые модели недетерминированы. У них есть погрешность, и они никогда не будут на 100% точны. Это действительно своего рода модель, знаете, то, как это происходит в многошаговом рабочем процессе агента, создает нарастающие ошибки. Итак, вот некоторая математика. При 99% точности на шаг, что, признаем, оптимистично, 50 шагов снижают вашу общую точность до всего лишь 61%. Вы можете увидеть это на графике здесь. Снижение до 95% на шаг все еще звучит довольно солидно, но в итоге вы получаете 8% точности за 50 шагов, что, знаете, 8% точности — это далеко не то, что я бы считал реальным успехом. Так что это не означает, что каждый агент потерпит неудачу, но это означает, что каждое улучшение качества значительно увеличивает ваши шансы на успех. И поэтому, знаете, мы хотим учитывать стоимость каждого пропущенного агента, каждого пропущенного агента, который тратит эти токены и требует исправлений ошибок, проверок и дополнительных запусков агента. Вы можете даже столкнуться с инцидентами, вызванными низким качеством выходных данных агента. Итак, в классической разработке программного обеспечения мы решаем эту проблему с помощью движения "сдвиг влево". Поэтому тестирование качества, безопасность — все это становится еще более актуальным в системах агентов. Итак, подводя итог, вместо того, чтобы считать токены, мы хотим, чтобы каждый токен имел значение. Так что да, знаете, уменьшите размер токена, но не за счет стоимости. Вы хотите, чтобы это определялось качеством. Поэтому вы хотите отправлять меньше ракет с высокой точностью, что автоматически оптимизирует топливо. Это другой взгляд на вещи, но это способ, которым вы добьетесь лучшего успеха. Итак, чтобы повысить качество агентов, мы сначала должны понять, как все это работает. LLM, агенты, контекстное окно, и как все это связано. Итак, краткое напоминание на высоком уровне. Я уверен, что вы все, вероятно, знаете это на каком-то уровне, LLM и все, что было доступно, но LLM — это машина, которая принимает текст и выдает текст. Под капотом это просто машина вероятности слов, которая, учитывая входные данные и обучающие данные, предсказывает наиболее вероятное следующее слово. Затем следующее, знаете, пока не сформируется предложение. Она просто продолжает делать это до тех пор, пока предложение не будет сформировано. В кодировании она использует ту же механику, просто предсказывая следующую инструкцию или оператор вместо прозы. Знаете, конечно, модели становились все лучше и лучше за последние несколько лет, и было добавлено много дополнительных функций для большей вычислительной мощности, более высокой точности, смещений в сторону разработки программного обеспечения и т. д. Но основной принцип и возможности по-прежнему остаются именно такими. Итак, знаете, когда это соотносится с качеством ответа, основной принцип — это баланс контекста. Предоставляйте как можно меньше контекста, но столько, сколько требуется. Так что это огромное, знаете, вам нужно найти, это, знаете, своего рода эффект Золушки или контекст Золушки. Слишком много контекста, знаете, нерелевантная информация смещает модель в сторону неправильных ответов, и LLM не может отличить релевантные данные от нерелевантных. Поэтому она учитывает все при расчете этих вероятностей. Слишком мало контекста, и она упустит критически важную информацию. Знаете, это смещения, знаете, которые могут сместить модели от правильных знаний. И поэтому, знаете, что еще хуже, модель может галлюцинировать, чтобы заполнить некоторые пробелы. Нет сообщения об ошибке, указывающего на недостаток информации. Она просто заполнит, знаете, заполнит и потенциально приведет вас в неправильном направлении. Так что математика не делает различий между галлюцинацией и фактом. Поэтому инженерия контекста — это фундаментальный навык для работы с агентами. Хорошо. С агентами предыдущее правило имеет еще большее значение. Потому что это больше не один обмен сообщениями туда и обратно, агент общается с LLM от вашего имени. Знаете, это десятки раз, прежде чем он вернется к вам. Он постоянно общается, получая всю информацию, и все это стоит, знаете, немного токенов, немного токенов. Так что агент — это просто приложение. Это какой-то код. Есть, знаете, много оболочек, предлагаемых GitHub. Итак, у вас есть VS Code chat, знаете, где все началось в IDE. У вас есть Copilot CLI, который является отличным инструментом. Copilot cloud agent, который, знаете, это страница github.com, и у вас есть сторонние оболочки, такие как Claude Code и OpenAI CodeX. Так что LLM — это просто модель, знаете, GPT, Claude, Gemini, есть и другие. У нас есть некоторые модели Microsoft. И теперь, знаете, что нам нужно понять здесь, так это то, что способ взаимодействия агента с ним — это не магия, это все еще просто текст. Но критически важно, что это без сохранения состояния, и поэтому у него нет, знаете, состояния, которое вы обычно видите. LLM не хранит разговоры. Ваш разговор на самом деле означает, знаете, повторную отправку всего этого ввода и вывода в каждом повороте. Поэтому токены и контекст накапливаются друг на друге по мере продолжения разговора. Как вы можете видеть, знаете, сама оболочка уже играет большую роль в качестве агента, но у вас все еще есть способы повлиять на нее. Ваши рычаги для влияния на агента — это ваша подсказка, файлы в вашем проекте, конфигурация агента, такая как инструкции, навыки и MCP, и, знаете, и так далее. Так что есть много способов, которыми вы можете управлять им и как бы дать ему этот путь, путь, по которому вы хотите, чтобы он следовал. Понимание потребления токенов — важная часть. Давайте заглянем под капот контекстных окон. На каждом цикле агент отправляет весь разговор в LLM. Опять же, цикл один, это будет системная подсказка и инструменты. Знаете, описание доступных функций, таких как чтение файла, запись файла, а затем ваша подсказка плюс некоторые ссылки на файлы. Все это равно входным токенам. Ответ обратно — это ответ LLM. Это выходные токены, которые, знаете, знаете, немного дешевле, чем входные, или немного дороже, чем входные токены. Цикл два и далее включает все из цикла один, плюс предыдущие ответы, а затем новый ввод. Это равно больше токенов. Так что вы можете видеть, что это просто добавление, это накапливающееся контекстное окно. И один токен равен примерно трем четвертям английского слова. Думайте об одном токене как об одном слове в качестве ментальной модели. И поэтому ограничения контекста варьируются. Меньшие модели могут обрабатывать от 50 до 200 000 токенов, в то время как большие модели, такие как Claude Opus или GPT55, могут обрабатывать миллион токенов. Миллион токенов равен трилогии "Властелин колец" и "Хоббиту". Для некоторого контекста, основанного на этом одном слове, знаете, одно слово равно трем четвертям английского слова, так что не зацикливайтесь на деталях токенизации, это не так критично, как то, что вы хотите, знаете, вам не нужно понимать это на этом уровне, но у вас все равно нет над этим большого контроля. Но думайте об этом на более высоком уровне, как подсказки, файлы, ответы — все это потребляет токены и накапливается на каждом из этих циклов, поэтому вы хотите убедиться, что то, что вы используете, максимально эффективно. Итак, мы перейдем к этому сейчас. Итак, мы перейдем к управлению, но прежде чем перейти к управлению, нам нужно понять две основные проблемы с контекстными окнами. Есть своего рода "потерянное в середине" номер один здесь. Знаете, модель отдает предпочтение контенту в начале и конце контекстного окна. Не в середине. И поэтому обычно это нормально, потому что начало — это ваши инструкции, цели и план. Вы хотите расставить приоритеты. Середина или конец — это ваш текущий рабочий поток. Это тоже важно, но середина — это прошлая работа, и она немного менее релевантна. Проблема возникает, когда вы переключаете задачи в середине сеанса. Итак, вы начинаете с исправления ошибки, а затем в середине разговора говорите: "Теперь давайте реализуем функцию". По мере роста окна модель может внезапно вернуться к исправлению ошибки, потому что она отдает предпочтение первоначальному утверждению перед недавними. И поэтому, знаете, вы хотите использовать новое контекстное окно для каждой отдельной задачи. И поэтому вы хотите, чтобы это было что-то, что вы хотите иметь в виду, когда делаете это. Вы можете использовать команду /clear в Copilot CLI и так далее. Смещение по новизне, знаете, составляет около 50% токенов. Выше 50% емкости модель начинает отдавать предпочтение только концу разговора, и поэтому она забывает ваши системные инструкции, ваши пользовательские инструкции и исходную подсказку, и модель дрейфует, делая то, чего вы не понимаете, основываясь исключительно на недавнем контексте. Поэтому, по мере того, как она отдаляется все дальше и дальше, она видит, знаете, все меньше и меньше того, что вы на самом деле просили ее сделать. Поэтому не позволяйте вашему токену расти за пределы 60-70%, если это абсолютно необходимо, верно? Разделение и завоевание задач с самого начала — лучший способ противостоять этой проблеме, за которым следует потенциальное накопление, знаете, разговора. Так что не воспринимайте это как нечто, что всегда будет происходить. Это не так, знаете, это не так. Смещение не означает, что модель забудет все в середине. Мы не имеем дело с абсолютами, верно? Мы не ситхи. Знаете, есть сценарии, когда вам нужно будет превысить 50% токенного окна, 60, 70, 80, и даже, знаете, потенциально до 100. Все это нормально. Используйте это, знаете, по мере необходимости. Это просто то, что нужно иметь в виду, когда вы начинаете оптимизировать использование. Чем больше вы сможете держать это, чем более целенаправленным будет ваш результат, тем дешевле он будет в целом. Надеюсь, это даст вам хорошее фундаментальное понимание токенов, знаете, контекстных окон и больших языковых моделей и агентов, а также первые идеи о том, как оптимизировать ваше использование. Обладая этими знаниями, давайте теперь рассмотрим практические рекомендации и вещи, которые вы можете сделать уже сегодня, чтобы улучшить качество ваших агентов и ваших токенов. Прежде чем мы углубимся, стоит понять, что в зависимости от вашей зрелости в работе с агентами, вам нужно больше или меньше заботиться об оптимизации. Если вы отправляете всего 10 агентов в день, вы работаете синхронно, вы относитесь к ИИ как к помощнику, а не как к автономной части вашей команды, оптимизация будет иметь меньшее влияние. Но если вы тратите всего 20 долларов в месяц на несколько токенов, экономия 50% на каждой оптимизации в этой презентации принесет вам только 10 долларов. Так что, вероятно, это не стоит огромных усилий, верно? Но сравните это с тем, что мы можем назвать инженером ИИ, оркестратором нескольких асинхронных агентов, десятков, сотен агентов, работающих там. Каждый процент использования токенов, который вы можете сократить, и каждый процент качества, который вы можете добавить, — это хорошо потраченные усилия по накоплению всех этих агентов. Так что, знаете, вы хотите иметь возможность, знаете, делать это по, знаете, когда у вас сотни или тысячи агентов, и вы запускаете его, знаете, как бы как обычный, обычный, знаете, как обычный инженер ИИ. И поэтому оптимизации, которые следуют, упорядочены по рычагу и по их эффекту. Так что, если вы находитесь в левой части спектра зрелости, первые несколько более актуальны, чем последние. Так что я также поделюсь некоторыми советами для продвинутых пользователей в конце. Так что, не волнуйтесь, у нас есть несколько интересных моментов. Итак, уровень один: два самых больших рычага для оптимизации качества и токенов. Да. Уровень один — это выбор модели. Общие шаблоны, знаете, равны дешевым моделям. Все по умолчанию используют, если вы спросите, если вы войдете в комнату из 100 инженеров и спросите их, какая их любимая модель сегодня, это будет Claude Opus 4.6, вероятно, около 99 из 100 человек. Но это не обязательно то, что вам нужно делать для, знаете, скажем, задачи документирования или чего-то в этом роде. Они, знаете, они преуспеют в этом, но вы можете потенциально использовать, знаете, более старую, более дешевую модель, которая, знаете, будет лучше подходить для этого со значительной экономией затрат. Так что, знаете, расточительство может быть значительным, если вы используете, знаете, Opus или GPT55 для простых, знаете, вопросов и вещей, которые могут выйти из-под контроля довольно быстро. Но если вы, знаете, если вы начнете думать об этом по-другому, вы сможете сократить этот разрыв. И поэтому разрыв в стоимости составляет 24 раза, 24-кратная разница между Claude Opus 4.7 и GPT 54 Mini. Так что выбор модели влияет как на стоимость токенов, так и на качество. Так что больше, знаете, больше не всегда лучше. Так что, знаете, вот что я всегда говорю. Так что, знаете, когда вы хотите использовать модели для рассуждений, такие как Claude Opus и подобные, планирование и отладка сложных ошибок, синхронная работа, где вы управляете агентом, и задачи, требующие больших контекстных окон, такие как множество файлов и тому подобное. Когда вы используете меньшие модели, вы можете использовать их для, знаете, для реализации после завершения планирования. Знаете, рассуждения произошли на этапе планирования, теперь вам просто нужна реализация. Так что реализацию может выполнить, знаете, меньшая, меньшая модель, меньшее влияние, модель с меньшим влиянием на стоимость. Влияние на качество, знаете, использование моделей для рассуждений для реализации может фактически повредить качеству, если у вас есть жесткая спецификация. Модель для рассуждений может пересмотреть план и дважды проверить его и выйти из-под контроля. Так что, знаете, вы можете захотеть использовать модель с меньшим количеством рассуждений для реализации, а затем решения. Итак, начиная с июня, я думаю, на самом деле в VS Code, как бы, с прошлой недели, есть автоматический режим, который, знаете, раньше он основывался на, знаете, мы выбираем лучшую модель на основе доступности и, знаете, времени отклика, которое он давал. Теперь он осведомлен о задачах. Он может назначать правильную модель в зависимости от задачи, которую вы пытаетесь выполнить. Он смотрит на ваш контекст и принимает решение о том, куда он пойдет, и вы получаете 10% скидку на это, знаете, 10% скидку на стоимость токенов. Так что это может оказаться очень значительным. Мы видели данные, которые показывают, что, знаете, что люди довольны результатами, которые они получают от автоматического режима. Так что это режим автоматического переключения моделей. Это то, что было очень хорошо принято. Итак, рычаг два, который у нас есть, — это предоставление только релевантного контекста. Так что не набивайте подсказку, потому что, знаете, мне может понадобиться эта информация или мне может понадобиться та. Знаете, позвольте агенту обнаружить, что ему нужно, и он сможет находить файлы и тому подобное самостоятельно. Так что, знаете, вы не хотите прикреплять весь проект. Вы не хотите говорить, знаете, добавить весь код, знаете, для небольшого, для небольшого изменения. Вы можете в некоторых ситуациях, я могу представить некоторые конкретные ситуации, когда вам понадобится, знаете, чтобы все это было, знаете, миллион строк контекста в, знаете, в модель, но, знаете, как правило, вам это не понадобится, и поэтому контекст, инженерия контекста — это основной навык, который нужно развивать. Все последующие советы — это методы инженерии контекста. Итак, вы хотите иметь сжатие, которое может сократить токены, но оно также сопряжено с некоторой потерей информации. Так что потерянная информация, если она была релевантна, создает пропуски агента, а экономия токенов становится потерей качества. Так что будьте очень осторожны с сжатием. Используйте команду /clear. Это, знаете, очистит ваш кэш или ваш контекст довольно свободно. Вы хотите убедиться, что вы хотите начать заново для каждой новой задачи или когда окно становится слишком длинным. И не пытайтесь управлять раздутым сеансом, когда около 80% вашего контекста заполнено. Смещение по новизне, знаете, просто не позволит вам добиться успеха. Так что это то, что вы хотите убедиться, что вы в курсе и имеете все самое свежее, и оно максимально очищено. Токены не накапливаются между сеансами. Так что без колебаний выбрасывайте контекст. Так что, знаете, ваша подсказка — это своего рода всегда включенный контекст. Не оптимизируйте подсказки для меньшего количества токенов. Оптимизируйте. Вы хотите оптимизировать, чтобы правильно направить агента с самого начала. И поэтому подсказки, системы и инструменты всегда находятся в контекстном окне в начале, что дает им непропорциональное влияние. Так что помните, знаете, своего рода смещение "потерянное в середине" из предыдущего. Мы хотим быть точными. Если вы зайдете и скажете, знаете, "исправь ошибку", хорошо, это, знаете, возможно, не приведет вас туда, куда вам нужно. Но если вы скажете, знаете, "проблема номер 45 описывает ошибку, где происходит XY. Исправьте ее". Это даст вам этот контекст. Это всего лишь пара дополнительных токенов, но у вас не будет этих потенциальных пропусков. Если вы скажете "исправь ошибку", он может просто найти, знаете, ошибку, другую ошибку или что-то еще, что вы не, знаете, теперь вам придется вернуться и сделать это. Итак, после исправления ошибки и, знаете, прохождения тестов, остановитесь. Это предотвращает продолжение работы агента с ненужной работой, выполнением всех команд git, коммитов, пушей, связыванием файлов и т. д. И поэтому вы хотите добавить известный контекст. Так что, если вы знаете, где находятся файлы или другой контекст, не позволяйте агенту находить его. Предоставьте его. Вы даете ему этот контекст. Знаете, то же самое касается документации, документирования веб-сайтов и тому подобного, где вы, хотите, чтобы агент получал или вызывал навыки. Все, что вы можете предоставить с самого начала, улучшит опыт и сократит циклы и токены, используемые для того же результата. Особенно, знаете, если вы знаете, что это будет долгий и утомительный сеанс, где вы будете постоянно общаться с Copilot, вы хотите иметь правильное, знаете, правильное количество токенов и тому подобное или правильное количество, правильный контекст на месте в начале, чтобы вы могли, знаете, быть максимально точным. Дайте ему именно то, что вам нужно, но не более того. И поэтому вы хотите работать поэтапно. Итак, вы хотите провести исследование, а затем перейти к планированию, а затем реализовать. И это важно по нескольким причинам. Но, так, исследование — это необязательный пункт. Знаете, вы можете использовать /research в Copilot CLI. Он загружает тонну файлов. Знаете, они не будут релевантны для реализации. Но если вы сделаете все эти этапы в одном сеансе, вы будете переносить, знаете, вы будете переносить нерелевантный контекст через все повороты, и это ухудшит качество и потратит токены, даже некоторые из кэшированных. Так что лучший подход здесь — это создавать новые контекстные окна между этапами. Знаете, будет некоторое дублирование, но улучшенное качество будет частью этого, и вы получите, знаете, большую эффективность токенов. Итак, для планирования вы хотите использовать хорошие модели, знаете, это не всегда должен быть Opus 4.7, как я уже сказал, знаете, вы просто хотите использовать что-то с возможностью рассуждения. Мне нравится смотреть на, знаете, на, на, когда вы разговариваете с моделью, это своего рода отношения, верно? Вы должны создать отношения, где вопросы, которые вы ей задаете, будут определять, что она отвечает. И поэтому создание этих отношений и понимание того, что ее мотивирует, поможет вам получить лучшую реализацию. Это может быть не Opus 4.7 или, знаете, это может быть GPT 5.5. И только потому, что это правильно для вас, это не значит, что это правильно для всех остальных в комнате. Так что, знаете, это просто то, как работают эти вещи. Вы ладите с кем-то лучше, чем с кем-то, знаете, чем с некоторыми людьми лучше, чем с другими. Вы будете ладить с некоторыми моделями лучше, чем с другими. У них есть немного индивидуальности, и у вас должны быть с ними отношения. И поэтому режим планирования — это следующий шаг, верно? Вы хотите использовать его для сложных функций. Знаете, для сложных функций используйте режим планирования с, знаете, с моделями для рассуждений. Они преуспевают в рассмотрении планов со всех сторон и выявлении пробелов. Цель — создать точную спецификацию, подробный список дел, который охватывает все размышления заранее и не оставляет места для вариаций в разделе реализации. Итак, вы хотите, знаете, с четкой спецификацией вы можете развернуть несколько агентов параллельно. Хорошо. Итак, вы разделите по, знаете, по вашему уровню архитектуры, вы хотите определить контракты между компонентами, и каждый агент будет работать эффективно только с, знаете, только с релевантным контекстом. Таким образом, этот подход экономит время и токены, а агенты не несут излишних знаний, знаете, для своей конкретной задачи. Давайте посмотрим, мы укладываемся во время. Итак, хотя это не строго оптимизация контекста, детерминированные элементы управления, такие как тесты, также являются важным контекстом. Итак, существуют инструменты инженерии контекста, которые могут противодействовать недетерминированному поведению LLM. И поэтому, что это означает, знаете, вы хотите писать тесты, иметь тесты, тесты и еще больше тестов. Команда Copilot CLI выпускает около 500 PR в неделю. Их практика номер один в инженерии контекста — это тесты. 50% их кодовой базы — это просто тесты. Почему? Потому что тест — это детерминированный контроль. Он либо проваливается, либо нет. Нет, знаете, нет пространства для маневра. И поэтому агент будет выполнять этот детерминированный контроль, и он сильно противодействует проблемам нарастающих ошибок. Если после 10 шагов вы достигли 50% точности, тест провалится и вернет агента на правильный путь к 99%. Вы, по сути, перезапускаете точность, имея тесты. Так что, знаете, если вы выходите за рамки тестов, это не просто тесты, конечно, знаете, так что вы хотите иметь линтеры, сканеры безопасности и любые другие защитные механизмы, которые вы можете спроектировать с помощью кода. Поэтому любые детерминированные элементы управления, которые вы можете применить к агенту и заставить его выполнить, — это хороший способ сделать это. Визуализация этого в контекстном окне — еще один важный аспект. Вот что мы видим с модульным тестом. Есть ошибочное изменение. Неудачный тест говорит агенту, чтобы он остановился. Вы не можете продолжать. Агент исправляет изменение, а затем строит на его основе, на основе стабильной основы. Он продолжает вносить остальные изменения до тех пор, пока все тесты не пройдут, и агент не закончит. Если у вас нет тестов, агент будет строить ошибочное изменение на ошибочном изменении на ошибочном изменении, и тогда он может, знаете, он может закончить быстрее с меньшим количеством токенов, но то, что у вас есть без этого, — это инцидент, и поэтому, знаете, или ошибка, и эти затраты быстро накапливаются. Да, это могут быть потраченные минуты CI/CD, циклы проверки Copilot, запуски агента, потраченные впустую, человеческое время, необходимое для исправления ошибок, сеанс отладки, который заполняет следующее контекстное окно и т. д. Поэтому накопление токенов гораздо выше, и стоимость гораздо выше, чем если бы у вас просто были тесты с самого начала. Поэтому, если вы потратите некоторое время на тестирование, знаете, сдвиг влево, это то, что мы делали в этой отрасли последние 15 лет, чтобы улучшить наши результаты и повысить ценность. И это гораздо более актуально для агентов, чем раньше. Итак, конфигурации агентов. Давайте рассмотрим эти конфигурации агентов. Когда мы говорим об инженерии контекста, часто это, по сути, один на один с конфигурациями агентов. Конфигурации агентов — это все те файлы Markdown и элементы управления, которые вы можете разместить, которые агенты будут автоматически учитывать. Итак, есть постоянные инструкции — это ваши инструкции Copilot.mmd. У вас есть пользовательские агенты — это ваш, знаете, agent.md. У вас есть навыки, MCP, серверы, под-агенты, ограниченные инструкции, файлы подсказок и память Copilot. Мы рассмотрим некоторые из них более подробно и как вы можете использовать их для улучшения качества и токенов. Первое — это, это, знаете, ваши инструкции Copilot или ваш agent.md. Это всегда включенные руководства для агентов. Во многих случаях я видел действительно огромные. Они помещаются во все контексты, будь то каждый, знаете, в каждом, когда вы запускаете их, запускаете свою подсказку. Эти инструкции предоставляются для каждого сеанса агента и каждого взаимодействия. Требование здесь заключается в том, что вы хотите, чтобы они были очень маленькими. Они должны быть краткими. Они должны быть маленькими. Вам не нужно использовать ИИ для их создания. Не вставляйте полные документации или, знаете, руководства, читаемые человеком, потому что это не ваша целевая аудитория. Вы, знаете, думайте об этом как о вашем проактивном руководстве для каждого агента с участием человека. Знаете, что в них входит: ваши не подлежащие обсуждению пункты. Знаете, журнал, знаете, агент, знаете, так что у вас должны быть ваши не подлежащие обсуждению пункты, которые являются, например, защитными механизмами проекта, которым должен следовать каждый агент. Вам нужно предотвращение ошибок агента. Исправление повторяющихся ошибок, неправильное использование неправильной среды тестирования, неправильная команда сборки и т. д., чтобы он мог избежать таких вещей, и затем некоторые утверждения для, знаете, для обрезки вывода. Будьте краткими, опускайте любезности, возвращайте только код. Выходные токены самые дорогие, поэтому их обрезка имеет значение, знаете, так что вы не хотите, чтобы он говорил "пожалуйста" и "спасибо". Я думаю, Сэм Альтман сказал, что они теряли миллионы долларов, потому что люди были слишком вежливы, верно? Так что, знаете, то же самое касается того, что вы хотите получить от вашей модели. Исследования показывают, что краткость дает почти такие же результаты, как и шкала пещерного человека из 50 строк, просто чтобы все знали. Итак, опять же, лучшие практики: не используйте ИИ для создания инструкций. Это ваш шанс направить агентов. Вы можете, если вам нужно, но, знаете, вы хотите, чтобы инструкции, сгенерированные ИИ, могли быть очень многословными и часто довольно неточными. Так что, знаете, вы хотите писать их сами, основываясь на, знаете, основываясь на реальном поведении агента в вашем проекте и итерировать по ним. Это не обязательно должно быть идеально с самого начала. Вы не получите это идеально с самого начала. И это будет меняться со временем. Так что он может стать длиннее или короче в зависимости от того, что вы собираетесь делать. Добавляйте эти исправления по мере наблюдения за пропусками агента, исправляйте вещи и, знаете, делайте его еще более точным. Воссоздавайте их. Что также помогает, знаете, частое их воссоздание. Модели и, знаете, ваш проект постоянно меняются, и поэтому, знаете, команда CLI выбрасывает все свои инструкции каждые три месяца, потому что они могут устареть, и поэтому, знаете, они больше не актуальны, они могут больше не содержать требуемую информацию или они накапливают бесполезную информацию, так что это своего рода живой документ, который вы хотите держать, знаете, как можно более свежим. Пользовательские агенты — это способ заставить агента принять определенную роль или способ работы. Их лучше всего рассматривать как что-то, вызываемое вручную вами как человеком, когда вы хотите оркестровать рабочий процесс агента и заставить агента вести себя очень специфическим образом. Знаете, в примере, который у нас есть на экране, у нас есть агент разработки, управляемой тестами. Это TDD красный, и даже, знаете, один, который очень специфически ограничен только реализацией красных, то есть, знаете, сбоев тестов. Это то, что агент не сделал бы сам. Это потребовало бы много подсказок. Так что пользовательский агент — это хороший способ один раз написать эту подсказку и использовать ее снова и снова. Как они работают, вы, знаете, вы вызываете их вручную. Их можно вызывать автоматически, но давайте пока оставим это. Для нашей модели-наставника вы вызываете их с помощью команды /. В этом случае вы можете сказать: "Эй, добавь конечную точку API и сначала реализуй тест" или, знаете, "оболочка" или, знаете, "или сначала реализуй тест". Оболочка извлечет файл пользовательского агента и соответствующим образом настроит доступные инструменты. Так что это еще одна интересная вещь, которую вы можете сделать с пользовательскими агентами. Вы можете настроить, к каким инструментам агент имеет доступ. Так что это само по себе также сократит потребление токенов, хотя это не самый актуальный рычаг. Так что входные токены будут кэшироваться, и даже несмотря на то, что инструменты могут составлять большую часть системы и подсказки инструментов, они обычно не являются большим рычагом, когда мы говорим об оптимизации токенов и тому подобном. Реальная выгода — это предотвращение неправильных путей. Так что это предотвратит, предотвратит то, чтобы ваш агент пошел по пути, который вы не намеревались изначально. Например, если вы хотите, чтобы он только читал проблему в GitHub для получения спецификации, а не писал или обновлял ее, вы предотвращаете, чтобы агент пошел по этому пути, просто не давая ему инструмента. Навыки очень близки к пользовательским агентам, знаете, не совсем то же самое, знаете, это навыки. Навыки также показывают вам, также позволяют вам иметь описание в формате Markdown, которое заставляет ваших агентов вести себя очень специфическим образом. Разница в том, что навык — это то, что вы предлагаете своему агенту в зависимости от выполняемой им задачи, и он может быть загружен динамически. Так что это не всегда включенный контекст. Это не всегда часть этого. Знаете, часть этого заключается в том, знаете, оболочка извлекает описание навыка и помещает его в контекстное окно. Знаете, так же, как и с инструментами, но оболочка теперь предлагает навыки LLM. Знаете, один из навыков в некотором лениво закодированном контексте — это, когда LLM обнаруживает задачу, соответствующую навыку, например, работа над API, она сообщает оболочке загрузить этот навык, это отличный способ разгрузить контекст, который не всегда релевантен. Так что стоит иметь в виду, когда мы проходим через это, так что вы можете видеть, что это похоже на сеанс конечной точки API или навык API здесь, который у нас есть. Лучшие практики для навыков, некоторые из вещей, которые мы хотим сделать здесь, это, знаете, не переусердствуйте. Вам не нужно сотни из них. Вам не нужно сотни тысяч навыков. Вам нужно достаточно, правильное количество. Не переусердствуйте. Иногда, в некоторых случаях, меньше значит больше. Будьте осторожны с избыточными навыками. Знаете, действительно ли LLM нужен навык React, когда он уже владеет React? Я не знаю. Так что вы хотите убедиться, знаете, что то, что вы делаете, имеет смысл и не является избыточным. И вы должны использовать навыки только для возможностей, которых у агента иначе не будет. Так что, как, как, как эта вещь с React, вы должны поддерживать их. По мере развития LLM некоторые навыки становятся ненужными. Так что, если вы что-то построили четыре года назад, чего, вероятно, не было, но, знаете, если вы построили что-то год назад или два года назад, или четыре года назад, независимо от истории, это может быть неактуально сегодня из-за достижений в области LM. Это совершенно нормально. Выбросьте это. Давайте, знаете, давайте. Не привязывайтесь ни к одной из этих частей. Вы должны будете постоянно их выбрасывать. ИИ движется так быстро, что всегда есть, знаете, всегда приходится выбрасывать что-то на свалку. Теперь мы перейдем к интеграции со сторонними инструментами, MCP, протокол контекста модели, который добавляет внешние вызовы API и динамические инструменты к вашим агентам. После их активации они возвращают описания инструментов, которые попадают в контекстное окно. GitHub MCP предлагает инструмент для работы с проблемами Git. Так что, знаете, пользователи могут сказать "прочитать проблему номер 45", и LLM распознает инструмент и вызовет его через оболочку. Вы должны быть строгими с MCP и убедиться, что вы понимаете, знаете, что вы можете раздуть описания инструментов, что является большой потерей токенов. Они могут, что более важно, привести агентов к вызову нежелательных инструментов, и вы хотите деактивировать MCP, которые вам не нужны, или поместить их в пользовательские агенты и тому подобное. Например, MCP — это Playwright MCP. Он мощный для работы с веб-интерфейсом. Он может автоматически исправлять и просматривать веб-сайты. Однако это дорого. Скриншоты, чтение страниц потребляют много токенов. Если он всегда включен, он может вызвать ненужную работу и, знаете, например, чтение веб-страницы для простого изменения цвета CSS. Да, используйте его. Лучшая идея — использовать его только в сочетании с пользовательскими агентами, когда это действительно необходимо. Хорошо, мы все еще укладываемся. Надеюсь, все еще бодрствуют. Следующее — это, знаете, разгрузка контекста, специфичного для задачи. Под-агенты открывают второе контекстное окно для конкретных задач, таких как, знаете, исследование или некоторые из них, предотвращая заполнение основного сеанса нерелевантной информацией. Под-агент обрабатывает документы, знаете, создает сводку и возвращает только релевантную информацию в основной сеанс. Это улучшает качество основного сеанса, но сопряжено с компромиссом в виде потраченных токенов в под-агенте. Так что, знаете, когда вы хотите использовать под-агенты, это, знаете, если агент часто решает автоматически сделать это, или вы можете явно вызвать их для исследовательских задач. Так что используйте с осторожностью. Это своего рода условная оптимизация. Это то, что, когда вам нужно их использовать, они отлично подходят, но вы не хотите использовать их всегда. Что еще? Эти другие конфигурации агентов оказывают меньшее влияние на токены и качество. Они просто, знаете, они все еще полезны, чтобы знать о них. Вы хотите иметь, знаете, ограниченные инструкции, верно? Они полезны для монолитов и с отдельными разделами кода, но очень условны. Знаете,

Вы вы вы только должны соответствовать определенным условиям, чтобы использовать ограниченные инструкции. Вы начнете со статических инструкций и, знаете, перейдете к ограниченным инструкциям только в том случае, если они станут слишком длинными. Файлы подсказок, э, знаете, многоразовые подсказки, вызываемые вручную, не поддерживаются в Copilot CLI, но, знаете, обычно навыки или пользовательские агенты являются лучшим выбором, чем файлы подсказок в наши дни, что отчасти объясняет, почему я думаю о том, чтобы выбросить в мусорную кучу файлы подсказок, которые начинают выходить из употребления, поскольку, знаете, они движутся в сторону навыков или пользовательских агентов, а затем память Copilot, э, она автоматически учится на вашем поведении и командных шаблонах, вы создаете инструкции, которые со временем улучшают качество агента. Итак, это работает в фоновом режиме. Это, знаете, не так уж много, что вы можете проактивно оптимизировать в любом случае, но это, знаете, может стоить периодической проверки. Э, так что у нас осталось всего несколько слайдов, и тогда мы закончим эту секцию. Э, так что некоторые рекомендации для опытных пользователей, которые мы хотели здесь привести. Они требуют больше знаний и тестирования. э, знаете, они иногда жертвуют качеством ради экономии токенов, но э, знаете, вы хотите, чтобы это были некоторые вещи, которые вы хотите делать, думать в коде, поэтому вы хотите создавать скрипты для фильтрации выходных данных перед анализом, знаете, например, фильтрация GitHub REST API только по релевантным полям или э, знаете, использование CLIs вместо или следующая вещь, которую вы хотите сделать, это использовать CLIs вместо MCPS. Так что инструменты CLI немного более оптимальны. Они могут, знаете, продолжающиеся дебаты о том, что инструменты CLI, такие как GH, уже известны моделям и, возможно, более легкие, чем их эквиваленты MCP. Оптимизация вывода оболочки. Так что инструменты, такие как RTK, обрезают вывод оболочки, они инструменты, такие как RTK, могут обрезать вывод оболочки до информации, релевантной только агенту. U есть также инструмент Chronicle. Вы хотите использовать команду /chronicle. э, которая анализирует журналы сеансов Copilot CLI, чтобы предложить оптимизацию подсказок, что-то, что вы захотите, знаете, использовать в значительной степени на протяжении всего процесса, а затем свертывание вызовов инструментов. э, знаете, вы хотите объединить несколько вызовов инструментов в один, чтобы уменьшить, уменьшить количество ходов. э, последнее — оптимизация контекста, специфичного для модели. Так что это будет только для э, для для опытных пользователей в основном, но э, вы бы, знаете, только с опытными пользователями с тысячами агентов не рекомендуется из-за, знаете, своего рода быстрых изменений моделей, но это то, чем опытные пользователи могут заняться и начать думать о важных будущих чертах. Итак, мы закончим эту сессию более дальновидным долгосрочным взглядом на то, на чем стоит сосредоточиться, чтобы быть по-настоящему успешным в разработке агентов. Итак, одно, вы хотите развивать свои аналитические навыки. Аналитические навыки, знаете, что отличает разработчиков, никогда не было просто написанием кода. Это были аналитические навыки, аналитические навыки, быстрое накопление знаний в предметной области, понимание потребностей клиентов и перевод требований в технологии. Это ваша сильная сторона как разработчика. Это то, в чем вы должны быть, знаете, действительно хороши. Это очень востребовано в будущем. э, агенты не могут этого сделать. У них еще нет этой возможности. Так что они не будут понимать клиентов или принимать высокоуровневые решения о том, что важно в, знаете, в их приложении. Они будут выполнять, но не будут разрабатывать стратегию. Итак, э, второе, что мы всегда говорим, это применять хорошую архитектуру. Это важнее, чем когда-либо, хорошая архитектура. Она уменьшает промахи агентов, обеспечивает навигационные ограждения. Она предотвратит размещение агентами кода в неправильных местах и поможет поддерживать качество кода. э, знаете, так что некоторые из рекомендуемых подходов — это предметно-ориентированный дизайн, шестиугольная архитектура, CQRS и событийно-ориентированный дизайн, знаете, эти архитектуры четко отличают низкоуровневые технологии, такие как REST API, от дифференцирующего доменного ядра, предоставляя агентам отличные ограждения, так что дебаты о пятистрочных функциях, комментариях или точках с запятой больше не актуальны, здесь важна архитектура, и затем, наконец, в этой части. э, мы хотим итерировать по подсказкам и конфигурациям агентов. Так что теперь вы контекстный инженер. Это не разовая работа. Это не то, что не установлено и забыто. Знаете, это непрерывное проектирование. Вы должны учитывать это все время и делать это как можно лучше, потому что это может быстро выйти из-под контроля. Подходите к этому с инженерным мышлением. Последовательно настраивайте агентов на успех. Знаете, такие инструменты, как Chronicle, знаете, могут помочь анализировать и оптимизировать ваши подсказки с течением времени. Так что это то, что вы хотите продолжать оттачивать свои навыки, но также оттачивать, знаете, навыки внутри ваших, э, ваших агентов и так далее. И так, э, давайте, мы будем завершать. Я понимаю, что это много информации для усвоения. Так что, в качестве напоминания, вот пять самых важных, э, советов, которые мы можем дать вам, чтобы улучшить качество ваших агентов и расход токенов сегодня. э, они не, знаете, надеюсь, не потребуют от вас слишком больших усилий. Это просто повторение того, что мы узнали ранее. Так что э, знаете, вы хотите выбрать правильную модель для задачи. Вы хотите предоставить четкие указания в своих подсказках. Используйте, знаете, разделите свои задачи. Используйте этот план исследования и реализации, чтобы использовать его в своих интересах для уменьшения размера контекста. Вы хотите предоставить детерминированные ограждения, так что у вас есть тесты, линтеры, сканеры безопасности и т. д., и поддерживать краткий файл инструкций Copilot, написанный человеком, в дальнейшем. Так что э, знаете, это поможет вам обрезать выходные данные и поможет вам, знаете, использовать его как ваш своего рода журнал ошибок агента. Так что, если вы вынесете что-то из этого выступления, это, знаете, пишите как можно меньше контекста, как требуется, и как можно больше, как необходимо. Это самая большая, знаете, самая большая сквозная линия на протяжении всей презентации. Реализуйте эти пять советов, и вы уже будете в довольно хорошем положении. Так что тогда это просто рост и созревание в эту новую эпоху, и тогда мы все будем счастливы. Мы создадим больше ценности и избежим траты такого количества токенов на, знаете, некоторые бесполезные авантюры. Еще раз, я Тодд Толлер, Microsoft CSA. Я рад, что вы здесь. Мы ценим ваше время. Большое спасибо, что вы здесь. Большое спасибо, что вы пользователи GitHub и GitHub Copilot, и, надеюсь, также клиенты Microsoft. Мы искренне ценим вас и, э, ценим ваше время.