Universal Self-Consistency

Суть в двух словах

USC особенно полезна для:

• суммаризации;
• аналитических заметок;
• code suggestions;
• свободных объяснений;
• любых free-form outputs без одного канонического answer.

Сгенерируй 4 кратких executive summary по отчёту. Затем выбери лучший по критериям: точность, краткость, coverage ключевых рисков.

USC нужна там, где устойчивость важна, но свести ответ к одному числу или label уже нельзя.

Почему обычная Self-Consistency ломается на free-form задачах

На математике и классификации всё просто: ответ можно нормализовать до числа, метки или буквы. На свободных задачах этого нет:

• пять summaries не будут текстово одинаковыми;
• пять вариантов кода могут отличаться синтаксисом, но решать одну задачу;
• пять аналитических memo могут по-разному расставлять акценты.

Поэтому вместо majority voting нужен слой, который оценивает качество, а не текстовое совпадение.

Именно здесь USC превращает consistency из "голосования по строкам" в "отбор лучших кандидатов по rubric".

Типичный pipeline USC

На практике есть два режима USC:

1. Select: выбрать один лучший кандидат.
2. Select + merge: выбрать лучшие элементы нескольких кандидатов и собрать финальную версию.

Первый режим проще и надёжнее. Второй мощнее, но уже требует осторожности, чтобы merge не разрушил удачные части.

Где USC даёт реальную пользу

Сильные сценарии:

• executive summaries;
• product/market memos;
• code review comments;
• rewrite tasks;
• explainer answers;
• candidate generation в IDE assistants.

Слабые сценарии:

• задачи с легко нормализуемым answer;
• high-stakes factual QA без retrieval;
• automation-пайплайны, где нужен strict schema output, а не просто "лучший по качеству вариант".

USC и judge models

В 2026 USC естественно стыкуется с eval tooling:

• rubric-based graders;
• pairwise ranking;
• reference-free judging;
• domain-specific scorecards.

То есть USC — это уже не просто "сэмплинг", а мини-ранжирующая система поверх нескольких кандидатов.

Как проектировать rubric

USC резко усиливается, если rubric конкретный. Хороший rubric:

• разделяет factual accuracy и style;
• учитывает coverage;
• учитывает adherence to constraints;
• не награждает лишнюю длину сама по себе;
• допускает "не уверен", если это релевантно задаче.

Плохой rubric:

• расплывчатый;
• слишком общий;
• смешивает 10 критериев без приоритетов;
• толкает judge к preference for polish over truth.

Практические примеры

USC для суммаризации

Сгенерируй 3 summary по отчёту. Затем оцени их по rubric:
1. Не выдумывает факты
2. Покрывает риск churn
3. Укладывается в 120 слов

Выбери лучший.

USC для code suggestion

Предложи 4 варианта исправления race condition. Затем выбери лучший по критериям: correctness, simplicity, minimal behavioral change.

USC для product memo

Сгенерируй 3 варианта memo о запуске новой цены. Выбери лучший по критериям: clarity, commercial risk, next action.

Select против select-plus-merge

На практике USC почти всегда стоит начинать с режима select one winner.

Он лучше, когда:

• ответ должен быть publish-ready без дополнительной редактуры;
• rubric достаточно понятный и judge уже откалиброван;
• downstream pipeline предпочитает один стабильный output;
• вы хотите легко измерять win rate against baseline.

Режим select + merge имеет смысл, только если разные кандидаты действительно приносят разные сильные стороны: один лучше покрывает риски, другой короче, третий аккуратнее формулирует вывод. Тогда merge-слой должен быть очень ограничен: сохранить лучший каркас, подтянуть только недостающие фрагменты, не перепридумывать весь ответ заново.

Если merge превращается в ещё один свободный generation step, USC быстро теряет смысл и становится просто дорогим rewrite-loop.

Как понять, что USC окупается

Минимальный production-набор метрик обычно такой:

• win rate vs single-pass;
• judge-human agreement на небольшом размеченном срезе;
• cost per accepted output;
• edit distance after human review;
• failure mode distribution, где judge выбрал polished but wrong candidate.

USC особенно оправдана там, где single-pass уже "почти хороший", но human reviewer всё ещё часто выбирает другой вариант из нескольких кандидатов. Если же разница между кандидатами слабая или judge не коррелирует с human preference, техника начинает просто сжигать токены.

Техническая реализация

def usc(generate_fn, judge_fn, task, k=4):
    candidates = [generate_fn(task) for _ in range(k)]
    scores = [judge_fn(task, candidate) for candidate in candidates]
    best_idx = max(range(len(scores)), key=lambda i: scores[i])
    return candidates[best_idx], scores

Что должен уметь judge

Judge для USC должен быть:

• откалиброван под rubric;
• устойчив к длине и стилю;
• не слишком чувствителен к cosmetic differences;
• проверен на human-labeled subset.

Pairwise judge

def pairwise_select(candidates, compare_fn):
    best = candidates[0]
    for candidate in candidates[1:]:
        if compare_fn(candidate, best) == "candidate":
            best = candidate
    return best

Pairwise ranking часто устойчивее, чем попытка сразу выставить абсолютные баллы всем кандидатам.

Merge after select

def merge_top_candidates(best, second_best, merge_fn):
    return merge_fn(best=best, second_best=second_best)

Такой режим полезен только если merge явно ограничен rubric-ом. Иначе он легко превращается в новый noisy generation step.

Частые ошибки

Другие ошибки:

• использовать одного и того же biased judge без калибровки;
• сравнивать кандидатов без чётких критериев;
• не логировать причину выбора;
• сразу запускать k=8 без понимания, зачем;
• применять USC там, где хватило бы обычного single-pass plus light editing.

Когда USC лучше не использовать

• если ответ легко нормализуется до one canonical answer -> обычная Self-Consistency;
• если задача high-stakes factual -> лучше добавить CoVe, citations или external verification;
• если output пойдёт в automation -> нужен ещё и schema / semantic validation layer.