LLM-судье нельзя верить на слово: как построить надёжный гейт и проверить сами тесты

[sixxio]

Не рассматривали вариант использовать строгую json схему для выходных данных?
Кажется, сильно бы упростило жизнь, но есть интуиция, что это может вносить смещение в сам скор..

[b_ernis]

да, для живого ллм адаптера строгая json-ка была бы полезна, тот же equivalent, extracted,reason с фикс типами и энамчиком. В текущем виде в репо намернно не вызывается, просто используются записанные json ответы.
Но вот что сразу можно заметить:
1. json схема решает ведь только синтаксическую часть. Моделька все еще может вернуть совершенно валидный json с выдуманным "extracted=3/4" для ответа "не знаю" (это если в контексте описанных в статье примера). Поэтому json -схему я бы рассматривал как входной фильтр перед гейтом, а не как замену детерминированной проверки
2. Насчет смещения интуция дельная. Я бы проверял это на аб тестах на одном калибров.сете, где свободный ответ противопоставлял бы строгой схеме, а затем сравнил бы конфужн матрицу, каппу и долю ручной проверки. Кстати, я скорей всего, так и сделаю и результаты опубликацию как продолжение статьи, спасибо!

[GDDaoshi]

Интересная статья. Я еще в процессе опиливания её целиком, но интересная тема.
Я сейчас занимаюсь созданием обвязки из циклов, сделал свой нодовый редактор для циклических задач. Вот теперь подумываю сделать ноду судьи, который бы возвращал задачу на доработку

[b_ernis]

ну нода судьи для циклических задач выглядит естественно, но я бы не давал ей напрямую управлять бесконечным возвратом задачки. Судья ведь может вернуть типизированный результат. Вы можете добавить что то типа Контроллера самого цикла, который будет обязан хранить чисто попыток, лимиты бюдета и репорты слать. Иначе 2 вероятностных агента могут долго возвращать работу друг другу, каждый раз немного меняя формулировку, но не устраняя сам дефект.

[andreyilin]

Ваша таблица маршрутов почти дословно совпала с той, что мы рисовали для текстов, и самой полезной оказалась графа «ручная проверка»: пока её нет как явного исхода, все расхождения молча уезжают в «принять».

У нас арбитр считает статистику текста и отдаёт exit 0 или 1. На чистом финале ноль, на фикстуре с задранной плотностью одного маркера (845 на 1000) единица, и судья этот вердикт не оспаривает.

Вопрос по вашей схеме: что вы делаете с ростом очереди на ручную проверку? У нас часть инвариантов детерминизму не поддаётся вообще, например «описанный случай действительно был у автора», и эта очередь растёт вместе с системой. Пока считаем её честной ценой, но чувствую, что есть решение получше.