Contrastive Round-Robin Voting: выбор лучшего перевода через попарные «дуэли» вариантов

ШАГ 1: Перевод → «улучши предыдущий» ×7 → пул из 8 вариантов
        (в авторской версии в контекст идёт только ПОСЛЕДНИЙ вариант, не вся история)

ШАГ 2: Для каждой пары (i, j) → судья сравнивает «A vs B», называя различия
        → вердикт: 1 (A лучше) / −1 (B лучше) / 0 (ничья)
        → то же с обратным порядком (B vs A)

ШАГ 3: Очки варианта = выигрыши в обоих порядках − проигрыши в обоих порядках
        → победитель = максимум очков

Шаги 1 и 2 — отдельные запросы. Судья должен быть отдельным вызовом, лучше в новом чате.

Задача: Основатель российского SaaS выходит на Product Hunt и переводит на английский первый экран лендинга. Нужен не «нормальный», а лучший вариант: короткий, без калек с русского и с сохранённым тоном.

Промпт (шаг 1, доработка в том же чате):

Переведи на английский заголовок и подзаголовок лендинга. Аудитория: 
основатели стартапов и продуктовые менеджеры в США и Европе. Тон: 
уверенный, без пафоса.

«Принимайте оплату от клиентов из 40 стран без юрлица за границей. 
Подключение за один день, комиссия от 1,9%».

Затем 3–7 раз подряд отправляется одна и та же реплика:

Пересмотри свой предыдущий перевод и улучши его. Верни только новую версию.

Каждую версию сохрани в заметки.

Промпт (шаг 2, новый чат, одна пара):

Ты — строгий редактор-переводчик. Сравни два перевода одного исходника.
Сначала перечисли конкретные различия между ними (смысл, терминология, 
естественность, тон). Затем вынеси вердикт.

Исходник: «Принимайте оплату от клиентов из 40 стран без юрлица за границей. 
Подключение за один день, комиссия от 1,9%».
Требование: уверенный тон, без пафоса, аудитория — основатели стартапов.

Перевод A: {версия 3}
Перевод B: {версия 7}

Ответь JSON: {"differences": "...", "verdict": 1 | -1 | 0}
(1 — A лучше, −1 — B лучше, 0 — равны)

Потом та же пара с переставленными A и B.

Результат: Первые шаги дадут 4–8 версий перевода. Каждая следующая чуть отличается от предыдущей, иногда лучше, иногда нет. Судья на каждой паре выдаст короткий список различий и JSON с вердиктом. После двух порядков у каждой пары будет итог: победа, поражение или ничья. Суммируешь очки и берёшь вариант с максимумом. Если судья по одной паре дал противоположные вердикты в разных порядках, она считается ничьей. Это сигнал, что варианты близки.

Слабость LLM и метрик. Абсолютная оценка («поставь переводу 85 из 100») нестабильна. Метрики вроде COMET-Kiwi плохо различают сильные переводы: все они «хорошие», разница тонкая. Оценка по шкале требует калибровки, а модель каждый раз «плавает» по шкале.

Сильная сторона LLM. Модели гораздо лучше говорят «этот лучше, потому что…», когда видят два текста рядом. Различия видны сразу. Вердикт «A или B» требует только относительного суждения, без привязки к шкале. Поэтому парное сравнение устойчивее поточечной оценки.

Как метод это использует. Турнир «каждый с каждым» превращает много слабых относительных суждений в один устойчивый рейтинг. Двойной прогон с обменом порядка гасит позиционное смещение, когда судья склонен выбирать первый (или последний) вариант. Последовательная доработка даёт пул, где варианты не независимы, а растут из предыдущих. По отчёту авторов, при малом бюджете это эффективнее независимой параллельной генерации.

Рычаги управления: - Число вариантов N → меньше N, меньше пар (2N(N−1) вызовов). Для чата хватит 3–4. - Судья → сильнее модель, меньше ничьих и «перепрыгиваний» при смене порядка. - Режим рассуждения у судьи → прирост мал. Авторы выбрали быстрый режим без рассуждений как лучший по цене/качеству. - Блок инструкции → если у перевода есть специальное требование (тон, глоссарий), добавь его в судью: «также оцени, насколько точно вариант следует этому требованию». Банальное «переведи с X на Y» в судью не включается. - Формат вердикта → JSON с тремя значениями убирает болтовню и упрощает подсчёт.

Дословные тексты промптов в предоставленной статье не приведены (в тексте остались только пересказ и схемы). Ниже реконструкция по описанной механике: структура, формат вердикта и обмен порядка соответствуют статье, формулировки мои.

Шаг 1. Генерация (первый запрос и доработки в одном чате):

Первый запрос:
Переведи с {язык_исходный} на {язык_целевой}.
Контекст и требования: {инструкция}.
Текст: {текст}

Каждый следующий запрос (повторить {число_доработок} раз):
Пересмотри свой предыдущий перевод и улучши его. Верни только новую версию.

Шаг 2. Судья (новый чат, отдельный вызов на каждую пару, дважды с обменом A/B):

Ты — строгий судья качества перевода. Тебе даны исходный текст и два 
перевода. Явно сопоставь их: назови, чем они отличаются, и реши, какой лучше.

Исходный текст: {текст}
Направление: {язык_исходный} → {язык_целевой}
{блок_инструкции}

Перевод A:
{вариант_A}

Перевод B:
{вариант_B}

Ответь строго JSON:
{"differences": "<кратко, по пунктам>", "verdict": 1 | -1 | 0}
1 = A лучше, -1 = B лучше, 0 = равны.

Шаг 3. Подсчёт:

score[i] = (победы i в роли A и в роли B) − (поражения i в обоих ролях)
Победитель = вариант с максимальным score.

{блок_инструкции} — вставляй только если у перевода есть особое требование. Формулировка из статьи: «Переводы были выполнены по такой инструкции; также оцени, насколько точно каждый вариант ей следует: {инструкция}».

🚀 Быстрый старт — вставь в чат:

Вот шаблон «контрастный турнир для выбора лучшего варианта». 
Адаптируй под мою задачу: {твоя задача}. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про язык и аудиторию, особые требования к тексту и количество вариантов. Эти данные нужны, чтобы заполнить {инструкция} и {блок_инструкции} и подобрать число пар под ваш бюджет. Она возьмёт структуру из шаблона (генерация → попарное сравнение → обмен порядка → подсчёт) и подстроит под вашу задачу.

⚠️ Шаблоны не даны: в предоставленном тексте нет дословных промптов. Структуру можно воспроизвести, но точные формулировки авторов неизвестны.

⚠️ Нет прямого сравнения с поточечным LLM-судьёй: «очень чёткое улучшение» показано против автоматических метрик (COMET-Kiwi, MetricX), а не против оценки «поставь балл» той же моделью. Что даёт именно парность, а что сама сила модели, статья не разделяет.

⚠️ Слабый судья вредит: модели послабее часто дают «ничья» или меняют вердикт при перестановке. Это шум, а не рейтинг. Слабую модель в судьи ставить не стоит.

⚠️ Точность всё ещё скромная: даже у лучших судей угадывание «лучшего из 8» составляет примерно 20–37%. Метод заметно лучше случайности, но не заменяет редактора.

⚠️ Дорого по числу вызовов: на 8 вариантов полный турнир с двойным порядком — 112 вызовов, на финальный ансамбль двух моделей — 142. Для длинных текстов или массовой работы нужна автоматизация.

⚠️ Узкая проверка: судью проверяли на английско-китайском и английско-русском. Эффект последовательной доработки взят из соседней работы и показан на одной модели.

Команда из Амстердама участвовала в соревновании по машинному переводу WMT26 на 23 направлениях. Идея: что можно выжать из «обычных» LLM только за счёт приёмов на этапе запроса, без дообучения. Для проверки судьи взяли данные WMT25: 198 абзацев EN→ZH и 200 EN→RU. Для каждого берут 8 случайных вариантов перевода от разных систем (GPT-4.1, Claude-4, Qwen3 и др.) с оценками людей-экспертов. Сравнивали, насколько ранжирование судьи совпадает с человеческим (корреляция Кендалла), и как часто он находит лучший вариант.

Что вышло: автометрики показали корреляцию около 5–9 из 100 и угадывали лучший вариант на уровне жребия. Попарные LLM-судьи дали 20–30. Сильные модели (GPT-5.4, Gemini-3.5-Flash) заметно лучше слабых: ничьих меньше, а при смене порядка вердикт реже «прыгает» (12,6% против 51,4% у Gemini-2.5-Flash на китайском).

Что удивило: включение режима рассуждений почти ничего не дало. Gemini-3.5-Flash с рассуждением лишь немного обогнал свою «прямую» версию, а по части метрик даже проиграл. Поэтому в финале взяли быстрый и дешёвый «прямой» режим. Практический вывод: для судьи важнее сила модели, чем длинная цепочка рассуждений.

🔧 Техника: убрать «рассуждение» у судьи → быстрее и дешевле

Авторы брали минимальное reasoning effort и температуру 0. В чате это значит: просить только JSON с вердиктом, без длинного обоснования. Для скорости оставь в differences одну-две строки.

🔧 Техника: добавить критерий в блок инструкции → судья учитывает ваше требование

Для текстов с жёстким брифом вставь: «Оцени также, насколько вариант следует требованию: без англицизмов, до 12 слов в заголовке, тон как у Stripe». Именно так авторы подмешивают специальные инструкции.

Экстраполяция: двойной порядок для любых выборов из двух. Статья показывает, что позиционный сдвиг — большая проблема. Для сравнения заголовков, тем писем или ответов поддержки: прогоняй пару в двух порядках. Если вердикты противоречат, считай ничьей.

Сравни два заголовка для рассылки. Сначала назови различия, потом дай 
вердикт JSON {"verdict": 1|-1|0}.
Заголовок A: {…}
Заголовок B: {…}
Критерий: {открываемость у B2B-аудитории}

Повтори с обратным порядком. Победитель — тот, кто выиграл в обоих.

• UvA-MT's Participation in the WMT26 General Translation Shared Task — Di Wu, Sergey Troshin, Wafaa Mohammed, Seth Aycock, Evgeniia Tokarchuk, Vlad Niculae, Christof Monz; Language Technology Lab, University of Amsterdam
• Wu et al., 2026. Ladders in chaos: When, how, (and perhaps why) does test-time scaling improve LLM machine translation — основа последовательной доработки
• Wu et al., 2025a. Please translate again — промпт доработки
• Wang et al., 2024. Large language models are not fair evaluators — позиционное смещение судей
• Бенчмарк: WMT25 General MT Human Evaluation (github.com/wmt-conference/wmt25-general-mt)