Баланс токенов: как GitHub Copilot повышает эффективность без потери качества кода
Эффективность в работе с генеративным ИИ часто оценивают неправильно, фокусируясь лишь на количестве токенов в одном ответе. В новом обзоре GitHub объясняет, как платформа оптимизирует общие затраты на выполнение задач (агентское кодирование), сокращая неэффективные вызовы, убирая лишний форматированный мусор и сжимая промпты без потери критической инструкции для модели. Цель проста: дать агенту нужный контекст, но не заставлять его тратиться на повторную работу из-за избыточных данных.
# Как оптимизировать стоимость ИИ-программирования, не жертвуя качеством задач
«Мы не стремимся к минимальному количеству токенов в одном ответе. Наша цель — получить необходимый контекст для продвижения задачи вперед и избежать лишних шагов восстановления.»
Использование агентского программирования с помощью ИИ, такого как GitHub Copilot, открывает новые возможности, но также создает сложные вызовы в части оптимизации ресурсов. Многие разработчики интуитивно предполагают, что сокращение длины ответа модели автоматически снижает стоимость вычислений. Однако недавний анализ показывает, что чрезмерное упрощение отдельных шагов может привести к увеличению общего времени выполнения задачи и росту итоговой стоимости.
В этой статье мы рассмотрим четыре ключевых изменения в архитектуре GitHub Copilot, направленные на то, чтобы сделать процесс кодирования более экономичным. Эти улучшения были протестированы с помощью строгих офлайн-бенчмарков и подтверждены в контролируемых онлайн-экспериментах, прежде чем быть выпущенными пользователям.
Ловушка локальных метрик и важность целостной задачи
Часто можно встретить подход, называемый RTK (Rust Token Killer), целью которого является сокращение вывода оболочки перед тем, как агент его прочитает. Идея звучит логично: меньше текста — меньше токенов — меньше денег. Однако эксперименты с GitHub Copilot показали обратный эффект.
Когда система RTK удаляла важные детали из вывода команд, модели иногда были вынуждены повторно читать исходный текст или перезапускать команды, чтобы восстановить пропущенную информацию. Хотя сам ответ инструмента становился короче, общее количество токенов, затраченных на завершение задачи, возрастало из-за необходимых шагов восстановления.
Ключевой вывод: Сокращение ответа инструмента не равно эффективности. Оптимизация должна оцениваться в контексте всей цепочки действий: от запроса пользователя до финального результата.
Для разработчиков важно понимать, что «время жизни токена» — это не всегда показатель качества. Если агент тратит время на то, чтобы «отыскать» информацию, которую можно было просто включить в первый же ответ, итоговая стоимость задачи растет.
Сжатие шума: сохранение контекста при устранении повторов
Одной из основных проблем в автоматизированном кодировании является избыточность. Выводы от команд установки, сборки, тестирования и линтинга (linter) часто содержат повторяющиеся сообщения о прогрессе, которые не несут новой информации для принятия решений агентом.
GitHub внедрил избирательный сжимающий алгоритм вывода, который работает по трем принципам:
1. Сохранение исходного кода и произвольных выводов: Команды типа cat, git diff, git show и результаты произвольных скриптов возвращаются без изменений, так как они содержат критические данные. 2. Оптимизация списков результатов: Результаты поиска (например, от grep) могут быть сгруппированы более эффективно, при этом сохраняется полнота набора найденных файлов. 3. Сжатие повторяющегося шума: Выводы от npm install, cargo build и аналогичных процессов сжимаются только там, где это дает существенную экономию, не затрагивая важные метаданные.
Важно отметить, что система всегда сохраняет путь к полному оригинальному выводу. Если агент обнаружит, что какой-то фрагмент информации был скрыт сжатием, он сможет восстановить его по прямой ссылке. В ходе тестов было показано, что агенты крайне редко прибегали к этому механизму восстановления, что свидетельствует о том, что сжатие удаляло лишь действительно избыточную информацию.
Удаление формата, не несущего смысловой нагрузки
Кажется, что каждая деталь в выводе имеет значение. Однако внимательный анализ выявил проблему с неочевидным форматированием. Ранее инструмент view, используемый агентами для чтения содержимого файлов, добавлял нумерацию строк перед каждым символом текста.
Хотя нумерация строк полезна при диффах (diff) или работе с короткими фрагментами, в текущем рабочем процессе редактирования файлы уже не требуют такой нумерации — современные инструменты находят изменения по контексту кода, а не по номерам строк. Тем не менее, префиксы с номерами строк сохранялись, добавляя лишние токены к каждому вхождению файла.
Факт: Удаление нумерации строк из содержимого файлов, читаемых агентом, снизило затраты на инференс модели примерно на 5% в офлайн-тестах и на 3% в онлайн-экспериментах, не повлияв на процент успешных редактирований.
Это решение является идеальным примером оптимизации: оно не требует новых инструкций для модели, не удаляет информацию, необходимую для задачи, и не создает необходимости в дополнительных решения со стороны модели. Файлы теперь поступают к нейтральному потребителю (модели) в чистом виде.
Сжатие промптов без потери намерений
Инструкции (промпты), сформированные для управления агентами, отправляются в модель на каждом шаге. Если эти промпты слишком длинные, это увеличивает стоимость. Но если их слишком сильно сократить, можно unintentionally (беспозвольно) изменить поведение агента.
В GitHub Copilot используется инструмент task, запускающий специализированных агентов параллельно. Изначальные инструкции для этого инструмента накапливались в разных описаниях, схемах и системных подсказках. Команда применила метод «мета-промптинга», позволив Copilot самому итеративно сокращать свои инструкции.
Первая попытка привести к ошибке: мета-промпт изменил гибкую политику параллельного запуска на жесткое правило, заставляя независимых агентов работать по очереди. Это привело к регрессии производительности, которую офлайн-тесты не уловили.
Финальное решение заключалось в замене сложных разрешительных списков на одну четкую фразу: *«Независимые агенты могут работать параллельно; учитывать побочные эффекты»*. Эта фраза передала выбор стратегии модели, а не жестко прописала её. Результатом стало сохранение нужного поведения при снижении количества токенов промпта примерно на 1,8% за сессию и экономии около 2,9% в час активной работы.
Этот случай подчеркивает необходимость тщательного тестирования поведения. Без проверки изменений в промптах, сокращение текста может удалить важные нюансы, незаметные для людей, но критичные для алгоритма.