Q: What parts of evals can be automated with LLMs? – Hamel’s Blog - Hamel Husain
Хамель Хусейн отвечает на вопрос, какие части работы с оценками (evals) можно автоматизировать с помощью LLM. Главный тезис: LLM ускоряют рабочий процесс, но не заменяют человеческое суждение и экспертизу. Доверять LLM можно черновую осевую кодировку (axial coding) после того, как вы сами разметили 30–50 трейсов, сопоставление аннотаций с режимами отказа, предложения по улучшению промптов и анализ закономерностей в данных. Нельзя делегировать первичную открытую кодировку, валидацию таксономий отказов, разметку эталонных данных (ground truth) для LLM-as-Judge и анализ первопричин — здесь человек ловит то, что LLM пропускает (например, ошибки только при вставке данных из Excel). Итоговый совет: начинайте с ручного изучения данных, а LLM используйте для масштабирования того, что вы уже поняли, а не чтобы избежать просмотра данных.
LLM могут ускорить отдельные части вашего рабочего процесса оценки, но не способны заменить человеческое суждение там, где необходима ваша экспертиза. Например, если поручить LLM весь анализ ошибок (то есть просмотр и разметку трейсов), вы рискуете упустить случаи отказов, важные для вашего продукта. Допустим, пользователи постоянно упоминают «лаги» в отзывах, но LLM сводит их к общим «проблемам с производительностью» вместо того, чтобы создать категорию «задержка» (latency). Тогда вы пропустите повторяющуюся жалобу на медленный отклик и не поставите её исправление в приоритет.
При этом LLM — ценные инструменты для ускорения определённых частей рабочего процесса оценки, когда используются под надзором.
Вот некоторые области, где LLM могут помочь:
Первичная осевая кодировка (axial coding): после того как вы сами провели открытую кодировку 30–50 трейсов, используйте LLM, чтобы упорядочить ваши сырые заметки об ошибках в предлагаемые группы. Это помогает быстро заметить закономерности, но всегда просматривайте и уточняйте кластеры самостоятельно. Примечание: если вы не знакомы с осевой и открытой кодировкой, см. этот faq. Сопоставление аннотаций с режимами отказов: когда вы определили категории отказов, можно попросить LLM предложить, какие категории применимы к каждому новому трейсу (например, «Дана аннотация: [open_annotation] и эти режимы отказов: [list_of_failure_modes], какие применимы?»). Предложения по улучшению промптов: когда вы замечаете повторяющиеся проблемы, попросите LLM предложить конкретные изменения в ваших промптах. Просматривайте эти предложения перед тем, как что-либо внедрять. Анализ данных разметки: используйте LLM или ноутбуки с ИИ, чтобы находить закономерности в ваших метках, например «сообщения о лагах вырастают в 3 раза в часы пиковой нагрузки» или «медленный отклик в основном отмечают пользователи мобильных устройств».
Однако эти действия не стоит передавать LLM:
Первичная открытая кодировка: в самом начале всегда прочитывайте сырые трейсы сами. Именно так вы обнаруживаете новые типы отказов, понимаете болевые точки пользователей и нарабатываете интуицию о своих данных. Никогда не пропускайте этот шаг и не делегируйте его. Валидация таксономий отказов: сгруппированные LLM категории требуют вашей проверки. Например, LLM может объединить и «приложение падает после входа», и «вход занимает слишком много времени» в одну категорию «проблемы со входом», хотя одно — это проблема стабильности, а другое — производительности. Без вашего вмешательства вы упустите, что эти проблемы требуют разных исправлений. Разметка эталонных данных (ground truth): для любых данных, используемых для тестирования/валидации оценщиков LLM-as-Judge, проверяйте каждую метку вручную. LLM могут ошибаться, и это приводит к ненадёжным бенчмаркам. Анализ первопричин: LLM могут указать на очевидные проблемы, но только человеческий просмотр уловит такие закономерности, как ошибки, возникающие в определённых сценариях или граничных случаях, — например, баги, которые случаются только когда пользователи вставляют данные из Excel.
В заключение: начните с ручного изучения данных, чтобы понять, что на самом деле идёт не так. Используйте LLM, чтобы масштабировать то, что вы уже усвоили, а не чтобы избежать просмотра данных.
Эта статья — часть нашего AI Evals FAQ, сборника частых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.