Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Правильный ответ на многошаговую задачу оказался слабым доказательством того, что LLM действительно связала все нужные факты. В препринте, который не прошёл рецензирование и приводит замеры самих авторов, REALHOP поднял долю ответов, зависящих от каждого заданного шага, с 27,4% до 94,4%. Командам, которые сравнивают модели для поиска по документам и длинным контекстам, теперь имеет смысл проверять не только точность, но и необходимость каждого фрагмента доказательства.
Почему правильный ответ не доказывает рассуждение
Обычный тестовый набор задаёт вопрос, размечает цепочку фактов и считает правильный ответ подтверждением того, что модель прошла всю цепочку. Но разметка описывает путь, который задумал составитель, а не путь, от которого фактически зависел ответ.
Модель может обойти цепочку несколькими способами. Она вспоминает ответ из обучающих данных, находит более короткую связь между сущностями, использует неразмеченный фрагмент контекста или угадывает по поверхностной подсказке. Во всех случаях итог будет правильным, хотя один или несколько заявленных шагов не сыграли роли.
Эту проблему не решает простое усложнение вопроса. Дополнительные отвлекающие документы могут снизить точность из-за шума, но падение результата ещё не показывает, что модель стала последовательно соединять факты. Нужна проверка причинной зависимости: сохранится ли правильный ответ, если убрать доказательство для конкретного шага.
REALHOP измеряет именно наблюдаемое поведение, а не внутренний ход вычислений модели. Если после удаления фрагмента ответ меняется, это показывает зависимость от фрагмента, но не раскрывает, как модель представила связь внутри себя.
Как измеряли необходимость отдельного шага
Авторы ввели долю поведенческой необходимости, BNR. Сначала модель отвечает с полным контекстом. Затем из контекста по очереди удаляют доказательства для каждого шага и считают, как часто модель перестаёт давать верный ответ среди задач, которые она исходно решила правильно.
Отдельная контрольная проверка удаляет сопоставимый по длине фоновый текст. Она нужна, чтобы отличить потерю важного факта от общей чувствительности к сокращению контекста. Если удаление фона почти не влияет на ответ, а удаление размеченного доказательства ломает его, тест фиксирует адресную зависимость.
Одного аудита существующих наборов оказалось недостаточно, поэтому REALHOP перестраивает сами задачи. Имена и другие сущности заменяют вымышленными аналогами, чтобы ослабить влияние запомненных связей. Отношения раскладывают на факты, которые приходится соединять, а рядом добавляют полный конкурирующий путь к другому ответу.
Конкурирующий путь отличается критическим отношением, но выглядит правдоподобно и содержит последующие факты. Поэтому модель не может выбрать ответ по одному совпавшему имени или упоминанию конечной сущности. Каждый созданный факт привязывают к точному месту в тексте, а вопросы проверяют на неоднозначность, пропущенные связи и незапланированные правильные ответы.
Основная парная проверка охватила 790 вопросов MuSiQue. Тот же принцип применили к выбранной части FRAMES, где цепочки пришлось восстановить по исходным ссылкам, и к заданиям LongBench с контекстами вплоть до 575 тысяч токенов. Таким образом, работа покрывает обычные вопросы по нескольким документам и поиск связанных фактов в длинном контексте, но использует сконструированные сущности и заранее спланированные цепочки.
Меняет ли REALHOP планы продуктовых команд
На перестроенных вопросах MuSiQue точность с полным контекстом оставалась в диапазоне 68,5–83,5%. Значит, рост зависимости от отдельных шагов нельзя свести к тому, что задачи стали почти нерешаемыми: модели продолжали находить ответы, но уже не могли так часто обходить заданные доказательства.
На длинных контекстах различия между моделями стали заметнее. Разброс точности среди 16 моделей вырос с 13,9 до 59,2 процентного пункта и сохранился при повторных ответах без готовых вариантов. Одинаковый формат с выбором ответа дал сходный эффект, поэтому разрыв объясняется не только способом ввода результата.
Работа меняет прежде всего план оценки, а не выбор архитектуры продукта. Средняя точность на готовом наборе может скрыть модель, которая отвечает по памяти или использует короткие обходные связи. Для системы, которая должна обосновывать вывод несколькими документами, такой результат создаёт ложное ощущение надёжности.
Практическая проверка может повторять схему REALHOP на собственных данных: сохранить задачи, решённые с полным контекстом, удалить доказательство для каждого обязательного шага и отдельно удалить сопоставимый фоновый фрагмент. Ещё полезнее добавить правдоподобный конкурирующий путь, который ведёт к другому ответу и расходится с верным путём в одном существенном отношении.
Такой аудит не заменяет проверку качества ответа, стоимости и задержки. Он добавляет отдельный критерий для продуктов, где ошибка возникает не только из-за неверного финального вывода, но и из-за того, что модель проигнорировала обязательный документ, правило или связь между ними.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
