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 используйте для масштабирования того, что вы уже поняли, а не чтобы избежать просмотра данных.
LLMs can speed up parts of your eval workflow, but they can’t replace human judgment where your expertise is essential. For example, if you let an LLM handle all of error analysis (i.e., reviewing and annotating traces), you might overlook failure cases that matter for your product. Suppose users keep mentioning “lag” in feedback, but the LLM lumps these under generic “performance issues” instead of creating a “latency” category. You’d miss a recurring complaint about slow response times and fail to prioritize a fix.
LLM могут ускорить отдельные части вашего рабочего процесса оценки, но не способны заменить человеческое суждение там, где необходима ваша экспертиза. Например, если поручить LLM весь анализ ошибок (то есть просмотр и разметку трейсов), вы рискуете упустить случаи отказов, важные для вашего продукта. Допустим, пользователи постоянно упоминают «лаги» в отзывах, но LLM сводит их к общим «проблемам с производительностью» вместо того, чтобы создать категорию «задержка» (latency). Тогда вы пропустите повторяющуюся жалобу на медленный отклик и не поставите её исправление в приоритет.
That said, LLMs are valuable tools for accelerating certain parts of the evaluation workflow when used with oversight.
При этом LLM — ценные инструменты для ускорения определённых частей рабочего процесса оценки, когда используются под надзором.
Here are some areas where LLMs can help:
Вот некоторые области, где LLM могут помочь:
Первичная осевая кодировка (axial coding): после того как вы сами провели открытую кодировку 30–50 трейсов, используйте LLM, чтобы упорядочить ваши сырые заметки об ошибках в предлагаемые группы. Это помогает быстро заметить закономерности, но всегда просматривайте и уточняйте кластеры самостоятельно. Примечание: если вы не знакомы с осевой и открытой кодировкой, см. этот faq. Сопоставление аннотаций с режимами отказов: когда вы определили категории отказов, можно попросить LLM предложить, какие категории применимы к каждому новому трейсу (например, «Дана аннотация: [open_annotation] и эти режимы отказов: [list_of_failure_modes], какие применимы?»). Предложения по улучшению промптов: когда вы замечаете повторяющиеся проблемы, попросите LLM предложить конкретные изменения в ваших промптах. Просматривайте эти предложения перед тем, как что-либо внедрять. Анализ данных разметки: используйте LLM или ноутбуки с ИИ, чтобы находить закономерности в ваших метках, например «сообщения о лагах вырастают в 3 раза в часы пиковой нагрузки» или «медленный отклик в основном отмечают пользователи мобильных устройств».
However, you shouldn’t outsource these activities to an LLM:
Однако эти действия не стоит передавать LLM:
Первичная открытая кодировка: в самом начале всегда прочитывайте сырые трейсы сами. Именно так вы обнаруживаете новые типы отказов, понимаете болевые точки пользователей и нарабатываете интуицию о своих данных. Никогда не пропускайте этот шаг и не делегируйте его. Валидация таксономий отказов: сгруппированные LLM категории требуют вашей проверки. Например, LLM может объединить и «приложение падает после входа», и «вход занимает слишком много времени» в одну категорию «проблемы со входом», хотя одно — это проблема стабильности, а другое — производительности. Без вашего вмешательства вы упустите, что эти проблемы требуют разных исправлений. Разметка эталонных данных (ground truth): для любых данных, используемых для тестирования/валидации оценщиков LLM-as-Judge, проверяйте каждую метку вручную. LLM могут ошибаться, и это приводит к ненадёжным бенчмаркам. Анализ первопричин: LLM могут указать на очевидные проблемы, но только человеческий просмотр уловит такие закономерности, как ошибки, возникающие в определённых сценариях или граничных случаях, — например, баги, которые случаются только когда пользователи вставляют данные из Excel.
In conclusion, start by examining data manually to understand what’s actually going wrong. Use LLMs to scale what you’ve learned, not to avoid looking at data.
В заключение: начните с ручного изучения данных, чтобы понять, что на самом деле идёт не так. Используйте LLM, чтобы масштабировать то, что вы уже усвоили, а не чтобы избежать просмотра данных.
This article is part of our AI Evals FAQ, a collection of common questions (and answers) about LLM evaluation. View all FAQs or return to the homepage.
Эта статья — часть нашего AI Evals FAQ, сборника частых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.