📊 Оценка LLM

Как известно, LLM придумывали, чтобы воспроизводить максимально правдоподобный ответ по результатам обучения на больших корпусах. Однако не всегда максимально правдоподобный = правильный. Как следствие, в сложных задачах возникает вопрос, как оценивать результаты? Существуют классические системы метрик: например одна из классических работ [1] предлагает систему из 20 метрик, сгруппированных в 4 категории (Accuracy of data, Relevancy of data, Representation of data, Accessibility of data).

😛 Классический лингвистический подход чаще всего сворачивает к рассуждениям на тему лексики/синтаксиса/семантики. Причем это может приобретать различные вариации: например, для программирования и генерации кода лексика может быть привязана к правильно именованным объектам (угадывание API), синтаксис - к компиляции кода, семантика - к решению корректной задачи. Имеются свои сложности (например, не стоит забывать, что у семиотического треугольника больше двух сторон), тем не менее, лингвистический подход работает, но - до определенного предела, когда вариативность задач и их неравномерная встречаемость не перевешивают и тут начинаются проблемы. Например, наши работы показывают, что лингвистические метрики слабо коррелируют и с человеческими оценками [2], и с функциональными тестами кода [3]. Проблемы идут а) от сложного внешнего контекста - ограниченная и смещенная выборка не всегда дает эффективно обобщить знания и обучиться, а тем более корректно оценить работоспособность моделей; б) от сложного внутреннего контекста - оценки от человека (RLHF и все что с ним связано, в частности) сложно собрать в полной полноте и глубине логического вывода явно (а часто - неявно) проводимого человеком).

🧰 В целом, оказывается, что при попытке шагнуть дальше лингвистических метрик существует два пути. Первый, связанный с формированием корпуса предметных задач - от бенчмарков проектного уровня для программирования (нашумевший SWE-bench) до известных историй про экзамены врачей, юристов и пр., которые сдают LLM. Однако, при переходе к практике сказывается ограниченность этих тестов, протекание данных и переобучение. Пример Konwinski Prize (аналог SWE-bench с неизвестными тестами) показал, что что на реально закрытых и неизвестных тестах лучшие результаты не выходят выше нескольких процентов решенных задач.

🙋‍♂️ Второй путь - работа с человеком-оценщиком. Как следствие, метрики дальше лингвистических (см. таблицу - от уровней функциональной пригодности и дальше) до сих пор лучше всего оцениваются человеком: все еще долго, дорого, ограничено. Попытки формирования бенчмарков чаще всего сводятся к фактической оценке более низких уровней, чаще всего, суррогатами на базе поверхностной корректности или функциональной пригодности. Определенная попытка сдвинуться в этом направлении предпринимается в рамках идей LLM-as-a-judge [4]. Однако, возникает вопрос, насколько точно и глубоко воспроизводится человек-оценщик в такой ситуации? Проблема представляется до сих пор открытой. Более того, формируемая информационная обратная связь может вести к увеличению рисков (см. уязвимости), ограниченности, деградации моделей.

Ссылки:
[1] Beyond Accuracy: What Data Quality Means to Data Consumers
[2] Human perceiving behavior modeling in evaluation of code generation models
[3] Test-based and metric-based evaluation of code generation models for practical question answering
[4] A Survey on LLM-as-a-Judge