Transcription
Привет, это Кэтрин из Lang. Один из самых распространенных вариантов использования, которые мы видим с LMS, — это генерация кода. Но вот вопрос: как улучшить точность и производительность кода, генерируемого вашим кодовым агентом? Один из ответов — статический анализ, проверка кода на ошибки или несоответствия без его выполнения. Именно здесь пригодятся такие инструменты, как Pyre или MyPy.
Теперь вы можете фактически встроить такую проверку в цикл вашего агента. Это то, что мы называем шагом рефлексии — моментом в цикле, когда агент оглядывается на то, что он только что сгенерировал, и проверяет или улучшает его, прежде чем продолжить. Мы покажем вам пример того, как вы можете создать такой шаг рефлексии в своей архитектуре, оценивая свой собственный вывод, прежде чем возвращать результат.
Вместо того, чтобы создавать логику оценки с нуля, мы покажем вам, как вы можете использовать OpenEval — пакет с открытым исходным кодом, который предоставляет вам готовые инструменты для таких задач, как проверка типов и изолированное выполнение. OpenEval включает в себя ряд полезных готовых оценщиков. Это включает в себя оценщики от таких как, a judge, Rack и code evaluation. Сегодня мы сосредоточимся на разделе оценщика кода.
OpenEval предоставляет вам несколько предварительно созданных оценщиков для сгенерированного кода, таких как проверка типов сгенерированного кода, проверка типов в песочнице и оценщики выполнения, и, наконец, использование LM в качестве судьи для оценки качества кода. Поскольку выходные данные LM часто содержат как код, так и некодовый текст, оценщики OpenEval также включают в себя гибкие утилиты извлечения кода. Вы можете использовать LLM для извлечения соответствующих фрагментов или просто извлечь блоки кода Markdown напрямую.
Теперь давайте углубимся в несколько методов, которые мы можем использовать для проверки кода. Во-первых, вы можете проверить тип сгенерированного кода с помощью Pyre и MyPy. Это лёгкие подходы к проверке типов кода Python, но они не будут устанавливать или проверять отсутствующие зависимости. Для TypeScript существует аналогичный оценщик для проверки типов.
Во-вторых, вы можете использовать LM в качестве судьи, чтобы предложить LM дать отзыв о вашем коде. Оценщик LM в качестве судьи здесь по умолчанию использует стратегию без извлечения кода, но он дает возможность включить извлечение кода, что может быть полезно для уменьшения шума или отвлечения внимания, особенно при использовании меньших моделей.
Наконец, OpenEval интегрируется с E2B для запуска некоторых оценщиков кода в изолированных песочницах. Статический анализ — полезный инструмент для выявления ошибок в сгенерированном коде. OpenEval позволяет вам выполнять это полностью локально. Иногда сгенерированный код может содержать и неправильно использовать сторонние библиотеки. Поэтому вместо того, чтобы устанавливать или выполнять эти произвольные зависимости локально, вы можете использовать среду песочницы для эффективного выполнения проверки типов.
Существует два основных оценщика песочницы. Первый — это оценщики типизации в песочнице. Один из примеров — это песочница Pyre. Этот оценщик анализирует необходимые зависимости, устанавливает их в песочнице и запускает Pyre. Он возвращает все найденные ошибки проверки типов. Для TypeScript аналогично существует оценщик проверки типов в песочнице.
Второй тип оценщика песочницы — это оценщик выполнения в песочнице. Этот оценщик идет на шаг дальше, устанавливая зависимости, фактически выполняя код внутри песочницы и проверяя ошибки времени выполнения.
Теперь давайте взглянем на пример, который мы видели ранее, чтобы увидеть, как он применяется на практике. Теперь вернемся к примеру, который мы видели в начале. Базовый агент имеет простую реализацию архитектуры React, где он работает с текстовым файлом, встроенным в системный запрос, и имеет инструменты для извлечения дополнительной информации для повышения правильности сгенерированного кода. Цепочка мини-чатов включает в себя набор рефлексии, который проверяет сгенерированный код с помощью оценщика типизации в песочнице в цикле.
Давайте посмотрим, как он построен. Итак, это наш узел рефлексии в нашем шаге рефлексии. Сначала мы создаем ко-оценщик песочницы Pyre, где оценщик извлекает сгенерированный код из вывода агента через Markdown и отправляет его в песочницу E2B для запуска Pyre над ним. Мы получили результат выполнения оценщика, и теперь есть две ситуации, когда мы будем хотеть напрямую вывести ответ конечному пользователю.
Первый сценарий — если сгенерированный код не имеет никаких проблем с проверкой типов, то есть в поле результата score он выводит true, поэтому не потребуется повторная генерация кода. Второй сценарий — если исходный ответ агента вообще не содержал кода. Мы можем проверить это, проверив метаданные результата, чтобы увидеть, был ли выполнен шаг извлечения кода в поле evaluator. В этом случае мы также хотим напрямую вывести ответ нашего агента.
Теперь, переходя к этому коду, в случае, если ответ нашего агента содержит код и находит ложные результаты оценщика, мы хотим передать сообщение об ошибке обратно агенту для повторной генерации кода. Мы делаем это, прикрепляя пользовательское сообщение к LM, предоставляя контекст найденных ошибок и указания по повторной генерации кода с этой информацией в запросе. Затем агент должен сообщить контекст для повторной генерации и модификации на основе ошибки.
Давайте попробуем это. Я могу передать пример входных данных нашему агенту, попросив создать агента в стиле роя. Запрос направляется к нашему узлу агента, который генерирует свой ответ, вызывая набор инструментов. Как только генерация ответа завершена, он передается узлу рефлексии для создания результатов. Похоже, узел рефлексии обнаружил некоторые ошибки, которые теперь побуждают агента к повторной генерации кода.
Теперь наш агент повторно генерирует ответ, который теперь проходит тест оценщика, и его вывод — наш окончательный ответ. Мы также можем проверить trace в Lang, чтобы подробно изучить поведение запуска. Во-первых, мы видим, что базовый агент вызвал инструмент get_langraph_docs_content. Он извлекает соответствующий контент из соответствующих документов, а затем вызывает LLM для генерации ответа. Затем ответ передается на шаг рефлексии, где запускается оценщик.
Присмотревшись к результатам оценщика, он прошел со счетом false, и, судя по сообщению об ошибке, несколько необходимых аргументов, кажется, отсутствуют. Это включает в себя model_name, timeout и stop. Это затем передается как часть сообщения человека. Если мы прокрутим вниз, где мы включили найденную ошибку и попросили агента попытаться исправить ее. Теперь, имея контекст сообщения об ошибке, агент генерирует еще один раунд вывода.
Сгенерированный вывод затем передается на шаг рефлексии, и во второй раз выполнения оценщика мы видим, что ошибок не обнаружено, возвращая true, и оттуда окончательный ответ передается клиенту. Добавление этого шага рефлексии в нашу архитектуру помогает исправить некоторые ошибки проверки типов, которые допускаются LM, и это может обеспечить лучшее качество кода для нашего агента. Спасибо за просмотр.