Self-Consistency

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

Self-Consistency особенно полезна там, где:

• задача имеет один чёткий ответ;
• reasoning может идти разными путями;
• ошибка одного прогона слишком дорога;
• extra latency и cost оправданы.

Типичные кейсы:

• математика;
• логика;
• численные задачи;
• классификация со строгим итогом;
• judge-пайплайны с bounded outputs.

Реши задачу 5 раз разными путями. Верни только итоговый ответ каждого прогона и потом majority answer.

Если цена выросла со 100 до 120, а затем упала на 20%, сколько стало?

Self-Consistency не делает модель умнее сама по себе. Она снижает зависимость от одного неудачного sampled path и превращает устойчивость результата в отдельный сигнал качества.

Почему Self-Consistency работает

Обычный single-pass reasoning опирается на один sampled path. Если модель на раннем шаге выбрала неудачный ход, ошибка тянется до конца. Self-Consistency пытается компенсировать это за счёт diversity:

1. Модель генерирует несколько reasoning trajectories.
2. Каждая траектория приходит к финальному выводу.
3. Выигрывает ответ, который устойчиво повторяется.

На практике это означает: мы меньше верим одному "красивому" рассуждению и больше смотрим на устойчивость финального результата.

Техника особенно сильна тогда, когда существует один канонический или хотя бы хорошо нормализуемый финальный answer. Если такой answer есть, расхождение между траекториями становится полезным operational signal, а не просто "ещё одной вариацией текста".

Когда техника действительно помогает

Лучшие сценарии:

• арифметические word problems;
• multiple-choice reasoning;
• extraction с конечным набором labels;
• routing decisions, где итог можно свести к enum;
• judge-задачи с ограниченным verdict set.

Слабее всего техника работает там, где в ответе слишком много stylistic freedom и нет ясного критерия нормализации.

Когда она не нужна

Self-Consistency часто переоценивают. Она почти не даёт пользы, если:

• задача тривиальна и single-pass уже стабилен;
• downstream tolerates small noise;
• ответ идёт в chat UX, где extra latency раздражает сильнее, чем occasional error;
• модель уже routed в более сильный reasoning-tier, и проблема не в sampling variance.

То есть это не "улучшатель всего", а дорогой, но полезный режим для узкого класса задач.

Что считать "голосом"

Классическая версия техники предполагает majority voting по финальному answer. Но в реальности почти всегда нужен дополнительный слой нормализации:

• для чисел: привести к числу;
• для меток: привести к label set;
• для yes/no: нормализовать до булева значения;
• для multiple choice: привести к букве варианта.

Без этого пять одинаковых по смыслу ответов могут выглядеть как пять разных строк.

Production-паттерн 2026

В продакшене техника редко применяется глобально. Гораздо разумнее выглядит такой маршрут:

Такой подход обычно даёт лучший cost/quality balance, чем тупое n=5 на каждый запрос.

Что делать с disagreement

Высокий disagreement между прогонами — это не просто "плохая статистика", а конкретный routing signal. Он может означать:

• задача неоднозначна;
• prompt слишком расплывчат;
• модель колеблется между несколькими reasoning paths;
• данные неполны;
• нужен более сильный reasoning route.

Практические реакции:

• reroute на более сильную модель;
• попросить дополнительные данные;
• запустить tool-backed verification;
• вернуть low-confidence verdict;
• отправить кейс в human review.

Когда majority answer всё ещё недостаточно хорош

Majority vote помогает против случайной path variance, но не решает проблему correlated errors. Если все траектории идут по одному и тому же ошибочному шаблону, Self-Consistency даст уверенное, но системно неверное большинство.

Практический пример:

• задача формально арифметическая, но prompt задаёт двусмысленную нормализацию;
• модель стабильно неверно интерпретирует условие;
• все пять прогонов сходятся к одному wrong answer;
• disagreement низкий, но confidence ложный.

Поэтому low disagreement нужно трактовать как сигнал устойчивости, а не как доказательство истинности.

Сравнение с близкими техниками

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

Простой паттерн

def self_consistency(sample_fn, task, n=5):
    answers = [sample_fn(task) for _ in range(n)]
    normalized = [normalize(a) for a in answers]
    return majority_vote(normalized), answers

Disagreement как confidence signal

def disagreement_rate(normalized_answers):
    majority = majority_vote(normalized_answers)
    disagreements = sum(a != majority for a in normalized_answers)
    return disagreements / len(normalized_answers)

Если disagreement высокий, это полезный operational signal:

• escalate to stronger model;
• ask follow-up question;
• switch to tool-backed verification;
• mark low confidence.

Хорошая нормализация

def normalize(answer: str):
    answer = answer.strip().lower()
    answer = answer.replace(",", ".")
    return answer

В реальных системах нормализация почти всегда domain-specific. Для triage label, multiple-choice, price extraction и boolean verdict это будут разные функции.

Stop rules

def should_run_self_consistency(task_risk: str, baseline_confidence: float) -> bool:
    return task_risk == "high" or baseline_confidence < 0.7

Это полезнее, чем глобально включать n=5 на весь трафик.

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

Другие типовые ошибки:

• считать голоса по сырому тексту без нормализации;
• применять технику к free-form summaries;
• не логировать disagreement;
• не ограничивать её hard-case routing-ом;
• принимать majority answer как абсолютную истину.

Практический tuning-совет

Если sampling почти не даёт разнообразия, self-consistency теряет смысл. Важно подобрать decoding так, чтобы траектории реально могли расходиться, но не превращались в хаотический шум. Иначе вы платите за пять почти одинаковых прогонов без нового сигнала.

Где техника особенно сильна

• математические word problems;
• logic puzzles;
• classification with strict labels;
• extraction tasks с жёстким набором финальных значений;
• judge prompts, где надо снизить path dependence.

Где обычно лучше выбрать другое

• длинные memo и summaries -> USC;
• фактологические claim-heavy ответы -> CoVe;
• step-by-step reasoning with local repair -> Factored Verification;
• writing / code polishing -> Self-Refine.