Factored Verification

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

Factored Verification особенно полезен там, где:

• reasoning длинный;
• решение можно разложить на шаги;
• важна локализация ошибки;
• partial correctness имеет значение.

Типичные случаи:

• математика;
• логические задачи;
• сложный data analysis;
• code reasoning;
• plan validation.

Factored Verification нужен не для "ещё одной оценки", а для более точного debug signal по самому процессу.

Почему answer-only verification часто слишком груб

Если вы оцениваете только итог, то теряете много информации:

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

Factored Verification даёт более богатый debug signal и лучше подходит для repair loops.

Это особенно важно в системах, где reasoning длинный и дорогостоящий. Если шаги 1-4 корректны, а ломается только шаг 5, нет смысла выбрасывать всё решение целиком.

Как обычно выглядит факторизация

Важен не только сам verdict, но и граница надёжности. Хорошая система должна понимать:

• какие шаги можно оставить;
• какие надо пересчитать;
• какие downstream conclusions уже contaminated.

Где техника реально полезна в 2026

Сегодня Factored Verification особенно уместна в:

• reasoning-model evals;
• judge pipelines;
• coding agents, где решение можно разбить на subgoals;
• math / logic benchmarks;
• enterprise workflows с многошаговыми policy decisions.

В обычном потребительском чате техника почти всегда слишком тяжёлая. Но в системах, где важно понимать причину ошибки, она очень ценна.

Почему factored signal полезнее одного общего verdict

Главное преимущество техники не только в "большей детализации". Оно в том, что она превращает verification из бинарной кнопки в рабочий diagnostic layer:

• можно увидеть point of failure;
• можно отделить healthy prefix от broken suffix;
• можно repair only affected branch;
• можно строить более дешёвые re-run loops.

Именно поэтому техника особенно ценна в длинных reasoning workflows, а не в задачах, где есть только один короткий ответ.

Когда локальная починка действительно возможна

Не каждый неправильный шаг можно починить изолированно. Factored Verification особенно полезна там, где между шагами есть относительно ясная зависимость и можно отделить healthy prefix от broken suffix.

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

• в вычислении ошибка на шаге 4 действительно позволяет оставить шаги 1-3 без изменений;
• в policy reasoning ранняя неверная интерпретация правила может отравить почти все последующие выводы;
• в агентном плане один неверный subgoal иногда требует перепроверить весь downstream branch, а не только один пункт.

То есть factorization полезна не сама по себе, а в связке с пониманием dependency graph между шагами.

Что такое хорошая granularity

Factored Verification зависит от того, как вы выбрали шаги.

Слишком крупные шаги:

• скрывают точное место ошибки;
• сводят факторизацию к "псевдодетализации".

Слишком мелкие шаги:

• резко повышают cost;
• дают много шумных verdict-ов;
• усложняют repair orchestration.

Как выбрать granularity на практике

Полезно выбирать шаги так, чтобы каждый из них:

• имел явный input/output;
• мог получить отдельный verdict;
• влиял на downstream conclusion;
• не требовал перепроверять весь ответ целиком.

Если шаг не даёт отдельного проверяемого сигнала, он, скорее всего, выбран слишком крупно или слишком формально.

Примеры

Пошаговая проверка вычисления

Разбей решение на шаги. Затем оцени каждый шаг как correct / uncertain / wrong. Если есть ошибка, укажи, с какого шага решение нужно пересчитать.

Проверка аналитического вывода

Разбей вывод аналитика на subclaims и проверь каждый: подтверждён данными, частично подтверждён или не подтверждён.

Проверка плана агента

Разбей план агента на subgoals. Проверь для каждого: feasible, blocked, risky.

Почему техника хорошо стыкуется с repair

Factored Verification особенно полезна не как verdict layer сама по себе, а как вход в repair pipeline:

1. локализуем first failing step;
2. переписываем только его;
3. пересчитываем downstream steps;
4. повторно проверяем только affected branch.

Это намного экономичнее и понятнее, чем генерировать решение заново с нуля.

Где factorization особенно полезна вне математики

Технику стоит рассматривать шире, чем math reasoning. Она часто полезна и для:

• chain-of-claims в аналитике;
• plan validation у агентов;
• multi-step policy decisions;
• code reasoning, где можно проверять подцели отдельно.

То есть factorization полезна везде, где решение естественно распадается на зависимые subclaims.

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

steps = decompose_reasoning(candidate_answer)
verdicts = [verify_step(step) for step in steps]
first_bad = first_incorrect(verdicts)

Вариант verdict schema

verdict = {
    "status": "correct | uncertain | wrong",
    "why": "...",
    "repair_needed": True,
}

Finding the first failing point

def first_incorrect(verdicts):
    for i, verdict in enumerate(verdicts):
        if verdict["status"] == "wrong":
            return i
    return None

Это простой, но очень полезный артефакт. Он определяет, с какого момента reasoning уже нельзя считать trustworthy.

Local repair

def local_repair(steps, first_bad_idx, repair_fn):
    repaired = steps[:first_bad_idx]
    repaired.append(repair_fn(steps[first_bad_idx]))
    return repaired

Это упрощённая схема, но она хорошо показывает основной смысл factorization: чинить не всё, а проблемный сегмент.

Чем техника полезна для repair

Factored Verification хорошо стыкуется с Self-Refine и repair-loops:

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

Частая ошибка

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

• путать step verification с final-answer verification;
• не хранить dependency graph между шагами;
• использовать технику там, где reasoning почти не декомпозируется;
• не разделять uncertain и wrong.

Полезный production-паттерн

Если шаги дорогие, кешируйте уже проверенный корректный prefix и перезапускайте только affected suffix. Тогда Factored Verification становится не просто диагностикой, а механизмом экономии на repair loops.

Когда лучше взять более простой verification route

Если задача:

• короткая;
• плохо декомпозируется;
• не требует local repair;
• или verdict нужен просто как pass/fail,

то чаще выгоднее использовать CoVe, Self-Consistency или even answer-only checks.

Что полезно мерить

Для этой техники особенно важны:

• first-failing-step accuracy;
• repair success rate;
• verification cost per candidate;
• difference between uncertain and wrong usage.

Именно эти метрики показывают, даёт ли factorization реальный operational выигрыш, а не только более красивую диагностику.