tgoop.com/max_dot_sh/169
Last Update:
Выпустили первый инженерный лонг рид, активно участвовал в создании и всех экспериментах.
Почитать полный текст можно тут.
На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.
Основная мысль такая. С рассветом агентов и улучшением LLM-ов для кодинга, проблема галлюцинаций или того, что LLM-ка чего то не знает становится менее центральной. Все потому что у агента есть много инструментов найти недостающее знание: 1) посмотреть в исходный код (если работаете с какой-то библиотекой, то агент может просто найти, где она установлена и прочитать код оттуда) 2) поискать в браузере 3) интерактивно повзаимодействовать с библиотекой и в fix-loop парадигме научиться пользоваться библиотекой.
Реальной практической проблемой становится вопрос того, насколько агент эффективно пользуется этой самой библиотекой. Пользуется ли агент ей так, как задумывали авторы? Или вместо использования готового API начинает городить сложные конструкции. Которые формально могут решать задачу. Функционально все будет ок. Функциональная корректность кода – это безумно важно и актуально, никто не отменяет eval-ы про юнит-тесты. Но в реальных приложениях, в продуктовом коде, который пишут разрабы в огромных развитых экосистемах, помимо функциональной корректности нужна еще какая-то валидация на его качество.
Игрушечный пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention механимз в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует F.scaled_dot_product_attention, который делает всё в одну строку.
Такой пример подсвечивает проблемы с идиоматичным использованием фреймворков. Вот в блоге и оценивали масштаб такого эффекта.
* Собрали 270 разных опенсоурсных реп разных лет, от очень старых до новых.
* Нагенерировали на основе исходного кода репозиториев разных coding exercises – задач, в которых агенту нужно было реализовать некоторую логику используя конкретную библиотеку
* Дали разным агентам (cursor, claude code) решать эти задачи
* Оценивали решения с помощью рубрик отдельным агентом-валидатором. Штрафовали за ситуации, когда решение не использовало какой-то метод или паттерн, который ожидался
Посмотрели на результаты в разных разрезах.
Один результат, что лучше модель – лучше качество. Картинка 1 про перформанс разных моделей Антропика.
Другой интересный разрез – это перформанс в зависимости от даты релиза библиотеки. Агенты довольно плохо перформят на старых репах и на супер новых, Картинка 2. По популярности репозитория точно такой же тренд – чем больше форков, тем выше скор. Оно и понятно: такие репы являются основой для трейн данных любой LLM-ки.
Отдельно в блоге еще затронули пункт про то, а как это можно улучшить. Мы предлагаем способ в виде Спек – таких сжатых документов, оптимизированных под то, что они пойдут в контекстное окно модели, чтобы на ходу обучить ее работе с репой. Спеки содержат примеры как работать с API репы, какие best practices и основные детали. Короче по задумке как context7, но построено на других принципах.
Все coding challenges и рубрики для оценки выложили, в блоке есть ссылка.
