Evaluating Long-Context Question & Answer Systems
Юджин Ян разбирает, как оценивать Q&A-системы на длинных контекстах — от технической документации до романов и многодокументных сценариев. Ключевые метрики: faithfulness (ответ опирается только на источник, включая умение сказать «не знаю») и helpfulness (релевантность, полнота, краткость), причём они ортогональны и часто конфликтуют. Для построения evaluation-датасета автор советует генерировать вопросы по аннотациям (как в NarrativeQA и QASPER), обеспечивать разнообразие типов (фактоиды, определения, summarization, multi-hop reasoning, «no-info») и варьировать позицию доказательств в тексте. N-gram метрики вроде BLEU и ROUGE плохо коррелируют с человеческими оценками — лучше использовать LLM-as-Judge с разбивкой ответа на атомарные claims. Обзор шести бенчмарков (NarrativeQA, NovelQA, QASPER, L-Eval, HELMET, Loong) показывает: модели деградируют после 100K токенов, а RAG может ухудшать качество на задачах, требующих синтеза по нескольким документам.
Оценка Q&A-систем с длинным контекстом
Если оценка Q&A-систем на коротких абзацах относительно проста, то по мере увеличения объёма документов всё усложняется. Например, в случае с технической документацией, романами и фильмами, а также со сценариями с несколькими документами. Хотя некоторые из этих проблем оценки встречаются и в коротких контекстах, длинный контекст усиливает такие сложности, как:
Информационная перегрузка: нерелевантные детали в больших документах маскируют значимые факты, затрудняя ретриверам и моделям поиск нужных доказательств для ответа. Позиционная вариативность: доказательства могут находиться в начале, середине или конце документов, что становится проблемой для моделей с ограниченным эффективным контекстом или подверженных эффекту «lost in the middle». Многошаговые рассуждения (multi-hop reasoning): правильный ответ требует синтеза нескольких разрозненных фрагментов доказательств, разбросанных по тексту(ам), что испытывает способность модели удерживать и интегрировать информацию, расположенную далеко друг от друга. Галлюцинации в масштабе: увеличение контекста повышает риск того, что модели вернут правдоподобные, но неверные ответы из-за плохого ретривера или ограниченного эффективного контекста. Открытые вопросы: запросы по широким темам или интерпретационным вопросам редко имеют единственный однозначный ответ, особенно для больших документов или корпусов.
В этой статье мы рассмотрим ключевые метрики оценки, как строить evaluation-датасеты и методы оценки качества Q&A через человеческие аннотации и LLM-оценщиков. Мы также разберём несколько бенчмарков для нарративных историй, технических и академических текстов, а также для очень длинного контекста и сценариев с несколькими документами. Наконец, мы завершим советами по оценке Q&A на длинном контексте для ваших конкретных юзкейсов.
Обзор того, что мы охватим в этой статье
Кстати, если вы хотите больше узнать о evals, мои друзья Hamel и Shreya проводят свой последний поток курса «AI Evals for Engineers and PMs» в июле. Вот промокод на скидку 35%.
Ключевые метрики оценки
Оценка Q&A-систем выходит за пределы простой проверки фактической точности. В частности, нам может потребоваться, чтобы ответы основывались только на предоставленном тексте, а не на знаниях модели. Но даже технически правильные ответы не обязательно полезны. Поэтому, чтобы эффективно оценивать Q&A-системы, стоит рассматривать два ортогональных измерения:
Faithfulness (верность источнику): насколько строго ответ опирается только на исходный документ. Helpfulness (полезность): насколько ответ релевантен, полон и полезен для пользователя.
Faithfulness измеряет, опирается ли ответ строго только на исходный документ. Это означает, что модель не должна добавлять внешнюю информацию или выдумывать (так называемые галлюцинации). Faithfulness особенно важна для юридических соглашений, финансовых контрактов или медицинских и страховых форм, где ответы должны основываться исключительно на данном тексте. Faithfulness синонимична groundedness — привязке ответов к оригинальному документу.
Faithfulness также включает способность Q&A-системы сказать «я не знаю». Если в исходном документе нет ответа, идеальный отклик звучит примерно так: «У меня нет этой информации в предоставленном тексте». С этой проблемой связаны два типа ошибок Q&A-систем:
False positives: когда система выдумывает ответ, которого нет в исходном документе (галлюцинации). False negatives: когда система ошибочно утверждает, что в исходном документе нет информации, которая на самом деле там есть, — из-за плохого ретривера или ограничений внимания на больших контекстах.
Важно также отличать faithfulness от корректности. Ответ может быть верным с точки зрения общих знаний, но при этом неверным источнику, если он противоречит документу. Примеры: специфические для пациента медицинские инструкции, отличающиеся от обычных рекомендаций; определения в финансовых или юридических соглашениях, отличающиеся от стандартных; историческая фантастика с альтернативными хронологиями. Пользователи полагаются на Q&A-системы, чтобы получить ответы, верные именно их документам, а не общим истинам.
Для систем, которые предоставляют цитаты, мы также можем оценивать точность цитирования. Это проверяет, поддерживает ли процитированный текст ответ. Бенчмарки вроде QASPER явно оценивают, ссылаются ли модели на правильные подтверждающие доказательства для ответа. Такая совмещённая оценка — проверка и faithfulness, и точности цитирования — даёт более детальные метрики общей faithfulness и качества извлечения доказательств.
Однако верный источнику ответ не всегда полезен. Здесь и появляется необходимость оценивать helpfulness ответов.
Helpfulness измеряет, является ли ответ релевантным, достаточно подробным, но при этом кратким. Релевантность означает, что ответ напрямую отвечает на вопрос пользователя, не уходя в сторону. Полнота гарантирует, что ответ содержит необходимые детали. Краткость уравновешивает полноту, обеспечивая лаконичность ответа без лишних деталей и «воды».
Хотя краткий, в одно предложение, ответ на сложный вопрос может быть верным источнику, он будет недостаточно полезным, если ответу нужны детали. И наоборот, чрезмерно длинные ответы с лишними подробностями могут перегрузить пользователя, затруднив поиск сути. Идеальный ответ должен содержать большую часть, если не всю, релевантной информации из исходного документа в краткой форме, отвечающей нуждам пользователя.
Исследование Xu et al. (2023) показало, что эксперты в таких областях, как биология или экономика, предпочитают ответы, которые одновременно полны и верны источнику, особенно для длинных вопросов. В противоположность, краудворкеры часто акцентируют внимание на поверхностных аспектах — краткости или детализации. Поэтому, если мы строим Q&A-систему для продвинутых пользователей и экспертов, она должна фокусироваться на возврате верных источнику и полных ответов.
Между faithfulness и helpfulness есть напряжение. Ответ может быть идеально верным источнику и при этом совершенно бесполезным. Например, если мы спрашиваем о юридическом контракте: «Что произойдёт, если арендатор пропустит платёж?» — верный, но бесполезный ответ может звучать так: «Пункт 4.2 договора аренды касается пропущенных платежей». Хотя технически это точно, это не полезно, поскольку не сообщает, что именно происходит при пропуске платежа. То же относится к Q&A-системам, которые просто копируют большие куски документа. Полезная система должна синтезировать информацию и выдавать прямой ответ, содержательно отвечающий на вопрос пользователя.
В целом, лучшие ответы достигают и faithfulness, и helpfulness за счёт того, что они:
Остаются привязанными к исходному тексту (faithful) Напрямую отвечают на вопрос пользователя (релевантность) Предоставляют достаточные детали и контекст (полнота) Излагают информацию ясно и сжато (краткость)
Построение evaluation-датасета
Оценка Q&A на длинном контексте начинается с создания надёжного evaluation-датасета. Это означает проверку того, насколько хорошо Q&A-система ориентируется в документах размером с книгу, чтобы отвечать на вопросы.
Для начала создадим разнообразные, реалистичные, контекстно-специфичные вопросы. Хотя люди-аннотаторы прекрасно справляются с составлением хороших вопросов, это трудоёмко и непрактично в масштабе, особенно для длинных документов. Более эффективный подход — использовать языковые модели для черновика вопросов, которые затем аннотаторы принимают или редактируют; так мы дополняем человеческое суждение скоростью и масштабом машины.
Однако одной только масштабируемости языковой моделью недостаточно. Нужно ещё направлять модель к генерации естественных, полезных вопросов. Поэтому вместо размытых промптов вроде «Сгенерируй вопросы по этой главе» можно быть конкретнее, например: «Опиши главных персонажей этой главы. Затем сгенерируй один вопрос о предыстории каждого персонажа на основе того, что мы прочитали к этому моменту». Более точные промпты помогают направлять модели к производству полезных вопросов для нашего evaluation-датасета.
Этот подход опирается на методологию существующих бенчмарков. NarrativeQA намеренно генерирует вопросы на основе аннотаций, а не полных текстов. Это поощряет вопросы, проверяющие понимание нарратива, а не поверхностное запоминание фактов. По той же причине QASPER создаёт вопросы по аннотациям академических статей, на которые модели затем отвечают, опираясь на полную статью. Учась у этих бенчмарков, мы можем строить evaluation-датасеты, эффективно измеряющие осмысленное понимание длинных документов.
При создании вопросов важно обеспечить их разнообразие. Наличие разных типов вопросов помогает оценивать возможности Q&A-системы без переобучения на какой-то один тип вопросов. В зависимости от вашего юзкейса evaluation-датасет может включать смесь:
Воспроизведение фактов: такие вопросы оценивают базовое извлечение фактов, например: «Кто главный герой?», «Когда был подписан договор?» или «Какой юридический пункт упоминается в разделе 2.1?». Хотя простые, они подтверждают, что Q&A-система может надёжно извлекать информацию. Определения: такие вопросы оценивают способность модели объяснять доменно-специфический контент на основе документа. Примеры: «Что означает эта аббревиатура в статье?», «Объясни магическую систему, представленную в главе 7» или «Дайте определение экономической теории, обсуждаемой на странице 203». Это важно для технических документов, чтобы убедиться, что система справляется со специализированной терминологией в контексте. Summarization (краткое изложение): такие вопросы измеряют, может ли система выделить ключевые идеи и связно их изложить. Например: «Кратко изложите основные результаты статьи», «Перескажите, что произошло в книге до сих пор» или «Каковы ключевые темы части 2?». Логический вывод и рассуждение: такие вопросы оценивают способность рассуждать за пределами явно изложенных фактов, интегрируя информацию из разных частей документа в связный ответ. Например: «Почему персонаж сделал этот выбор?» или «Что мы можем сделать вывод об обществе из этих законов?». «No-Info» (нет информации): в отличие от предыдущих категорий, на такие вопросы нельзя ответить по документу. Например: «Что Гэндальф делал в финальной битве в Хогвартсе?» или «Какое наказание за нарушение товарного знака в этом договоре аренды жилья?». Верная источнику Q&A-система должна распознать отсутствие требуемой информации и ответить соответствующим образом, а не выдумывать ответ.
Наши Q&A-evals должны быть устойчивы к положению доказательств в документе. Это обеспечивается вопросами с доказательствами, расположенными в начале, середине или конце, а также созданием multi-hop-вопросов, требующих сведений из нескольких разделов или документов. Бенчмарки вроде HELMET оценивают, как точность модели меняется в зависимости от расположения подтверждающей информации, проверяя способность модели обращать внимание и комбинировать информацию из всего документа, а не полагаться только на ближайший контекст.
Методы оценки качества Q&A
Люди-аннотаторы критичны для построения качественного ground-truth-датасета. Это полезно для калибровки автоматических оценщиков, а при достаточном количестве размеченных примеров мы также можем обучить evaluation-классификаторы или reward-модели. Вот как это может выглядеть для метрик faithfulness и helpfulness:
Разметка faithfulness предполагает оценку того, точно ли ответ отражает исходный текст. Идеально хотелось бы иметь простые бинарные метки — faithful или unfaithful, — но реальность редко так проста. Ответы обычно лежат в спектре. В результате почти правильный ответ, упускающий критическую деталь, должен оцениваться иначе, чем тот, в котором неверно представлена второстепенная информация.
С faithfulness связана разметка «no-info». Она проверяет, корректно ли модель распознаёт случаи, когда предоставленный контекст не содержит информации для ответа. Цель — выявить галлюцинации, когда модель придумывает ответы вместо признания пробела. В рамках этого упражнения можно использовать следующие метки:
Неверный ответ / галлюцинация: модель пытается ответить, несмотря на отсутствие информации, даже если ответ звучит правдоподобно. Ошибочный отказ: модель ошибочно утверждает, что информации нет, — возможно, из-за ошибок ретривера или недостаточного внимания к длинному контексту. Корректный отказ: модель верно распознаёт отсутствие необходимых деталей и обоснованно отказывается отвечать.
Сравнения helpfulness предполагают, что аннотаторы решают, какой из двух faithful-ответов лучше отвечает нуждам пользователя. Вместо абсолютных оценок аннотаторы делают относительные суждения, отвечая на простой вопрос: «Какой ответ полезнее?». Людям проще сравнивать два ответа, чем выставлять абсолютные баллы, что даёт большую согласованность между аннотаторами. При сравнении helpfulness аннотаторы должны учитывать:
Релевантность: один из ответов отвечает на вопрос более прямо и точно? Полнота: один из ответов включает ключевую информацию, которую упускает другой? Краткость: один из ответов лаконичнее и проще для понимания?
Вот несколько практических советов по настройке надёжного процесса разметки:
Начните с чётких гайдлайнов: включайте примеры для каждой категории и поясняйте, как обращаться с пограничными случаями. И будьте лаконичны — так гайд легче прочитать целиком. Итерируйте гайдлайны: первый драфт не будет идеальным. Собирайте обратную связь аннотаторов о неясных или сложных случаях, чтобы улучшать гайдлайны. Используйте квалификационные задания: прежде чем выдавать реальные задачи, дайте аннотаторам тренировочные примеры с известными правильными ответами. Это гарантирует, что они понимают гайдлайны и применяют их единообразно. Измеряйте межаннотаторское согласие: проверяйте согласованность аннотаторов с помощью метрик вроде Cohen's Kappa. Низкое согласие может указывать на нечёткие гайдлайны или неоднозначные сценарии, требующие уточнения. Рассмотрите экспертов-аннотаторов для специализированных доменов: общие задачи разметки обычно по силам краудворкерам, но домены вроде медицины или права часто требуют профильных экспертов для точных и осмысленных оценок.
При этом, хотя человеческая разметка традиционно считается золотым стандартом, она не всегда практична или масштабируема, особенно для больших документов. Здесь могут помочь LLM-оценщики (также называемые «LLM-as-Judge»). При этом подходе мы передаём модели чёткие критерии — или наши гайдлайны разметки — и просим её оценить качество ответов Q&A.
Но сначала важно понять, почему старые автоматические метрики не подходят. Исторически сообщество языкового моделирования полагалось на n-граммные метрики вроде BLEU и ROUGE, измеряющие пересечение слов между сгенерированными ответами и эталонами. Хотя эти метрики кое-как работают для задач вроде машинного перевода, они плохо коррелируют с человеческой оценкой на открытых задачах вроде Q&A.
Например, бенчмарк L-Eval подчеркнул слабую корреляцию между метриками пересечения токенов и человеческой оценкой Q&A-ответов. Корректный ответ, использующий слова, отличные от эталона, может несправедливо получить низкий ROUGE-балл, что даст ложный негативный сигнал. Это особенно заметно, когда ответы модели и эталонные ответы различаются по длине. Без нормализации по длине метрики пересечения токенов могут ошибочно вознаграждать многословные посредственные ответы в ущерб кратким и точным.
Именно поэтому оценка на основе моделей становится всё популярнее — она даёт более надёжные и тонкие evals, чем традиционные метрики. Обычно мы начинаем с калибровки LLM-оценщика на качественном размеченном людьми датасете. Имея ground truth, мы можем оценить нашего LLM-оценщика, измерив его recall и precision по разметке faithfulness, а также его корреляцию с человеческой оценкой при сравнениях helpfulness.
Для оценки faithfulness можно рассматривать ответы как наборы отдельных claims (утверждений), каждое из которых можно проверить как истинное или ложное. Это похоже на подходы, используемые в NLI-based и Q&A-based метриках суммаризации и в генерации и верификации claims. Разложение ответов на атомарные claims помогает выявить, где именно происходят галлюцинации. Вот как это работает:
Извлеките claims: рассмотрим ответ о споре по контракту: «Арендатор нарушил договор аренды, потому что пропустил три платежа, не поддерживал страховое покрытие и сдал квартиру в субаренду без разрешения». Это можно разложить на: Claim 1: Арендатор пропустил три платежа. Claim 2: Арендатор не поддерживал требуемое страховое покрытие. Claim 3: Арендатор сдал квартиру в субаренду без разрешения. Проверьте каждый claim: сверьте каждое утверждение с исходным документом (в данном случае — договором аренды), чтобы подтвердить его точность. Рассчитайте faithfulness: доля claims, подтверждённых документом, даёт общий балл faithfulness.
Этот детальный подход, продемонстрированный такими evaluation-методами, как SummaC, QAFactEval и RefChecker, даёт больше интерпретируемости и нюансов. Вместо того чтобы помечать весь ответ как faithful или нет, мы получаем нюансированное понимание, какие именно claims неверны. Это также позволяет давать частичный балл преимущественно верным ответам с незначительными неточностями.
Можно пойти дальше и потребовать от модели предоставлять цитаты для каждого claim. Это помогает различить два типа сбоев: галлюцинации (выдумывание ответов) и сбои ретривера (неизвлечение релевантной информации).
Чтобы оценить нашего оценщика, мы можем сравнить его суждения с человеческой разметкой по двум ключевым метрикам: (i) recall (из всех unfaithful claims сколько оценщик корректно отметил?) и (ii) precision (из всех claims, отмеченных оценщиком как unfaithful, сколько действительно являются таковыми?).
Оценка helpfulness требует более тонкого подхода, потому что часто нет однозначно «полезного» способа ответить. Разные ситуации могут требовать разной степени детализации или стилей изложения. Вот несколько стратегий, которые можно рассмотреть:
Сравнение с эталоном работает хорошо, когда у нас есть качественные эталонные ответы. LLM-оценщик сравнивает сгенерированные ответы с этими эталонами, оценивая релевантность, детальность и ясность. Однако по мере улучшения моделей их ответы могут превосходить существующие эталоны, делая этот метод со временем менее эффективным. Оценка по критериям оценивает ответы по чётко определённой рубрике. Этот подход позволяет напрямую переиспользовать наши гайдлайны разметки, фокусируясь на таких критериях, как релевантность, полнота и краткость. Попарные сравнения особенно полезны при итеративном улучшении Q&A-систем. Сравнивая вновь сгенерированные ответы с ранее валидированными, мы последовательно поднимаем планку качества. Этот метод также идеален для A/B-тестирования различных конфигураций Q&A-системы.
Для калибровки LLM-оценщика на helpfulness попарные сравнения особенно надёжны. Предъявляя пары ответов аннотаторам и LLM-оценщикам, мы можем измерить их согласованность — как часто они сходятся в выборе более полезного ответа. Корреляционные метрики, например Cohen's Kappa, эффективно количественно оценивают это согласие. Например, L-Eval обнаружил, что попарные сравнения GPT-4 сильно коррелируют с человеческими предпочтениями после надлежащей калибровки.
Что мы можем почерпнуть из существующих бенчмарков
Чтобы заземлить наше обсуждение, посмотрим на несколько бенчмарков для Q&A на длинном контексте. Помимо общего стандарта, эти бенчмарки подсвечивают сложности, с которыми мы можем столкнуться при создании датасета и оценке. Поскольку эти датасеты, вероятно, уже входят в обучающие данные моделей, не стоит полагаться только на них для оценки нашей Q&A-системы. Вместо этого нужно создавать evaluation-датасеты, заточенные под наш юзкейс.
Мы рассмотрим шесть бенчмарков, охватывающих (i) нарративные документы, (ii) технические и академические документы и (iii) очень длинные или многодокументные контексты.
Датасет NarrativeQA, представленный Kočiský et al. в 2017, разработан для проверки настоящего понимания нарратива, а не поверхностного сопоставления паттернов. В отличие от более ранних датасетов, позволявших моделям отвечать, извлекая отдельные предложения, NarrativeQA требует синтеза информации, разбросанной по романам и сценариям фильмов, для генерации ответов.
Сначала авторы собрали более 1500 историй из Project Gutenberg и сайтов сценариев фильмов вместе с соответствующими краткими содержаниями сюжетов из Wikipedia. Затем аннотаторы генерировали пары вопрос-ответ, основываясь только на этих кратких содержаниях, не видя полных текстов. (И наоборот, модели отвечали на вопросы, основываясь на полном тексте, но не на кратких содержаниях.) Этот намеренный подход обеспечил то, что ответы нельзя найти простым сопоставлением текста, сосредоточив оценку на понимании всего текста. Получившийся датасет содержит 46 765 пар вопрос-ответ, сфокусированных на понимании нарратива.
Статистика датасета NarrativeQA
NarrativeQA оценивает, могут ли модели интегрировать информацию, рассеянную по длинным нарративам — целым книгам или фильмам, — чтобы давать связные ответы. Ответы оцениваются n-граммными метриками, такими как BLEU, METEOR и ROUGE, путём сравнения машинно-сгенерированных ответов с двумя эталонными ответами на каждый вопрос.
NarrativeQA подсвечивает важность вопросов, выходящих за рамки простого извлечения и требующих интеграции информации по всему документу. Генерируя вопросы из аннотаций, а не из полных текстов, авторы гарантировали, что вопросы требуют целостного понимания текста, тем самым снижая поверхностные, экстрактивные стратегии ответа.
NovelQA, представленный Wang et al. в 2024, — это бенчмарк, разработанный для оценки понимания чтения на очень длинных текстах, часто превышающих 200 000 токенов. Подобно NarrativeQA, но обновлённый под современные реалии, NovelQA оценивает, насколько хорошо модели понимают и интегрируют нарративы, охватывающие целые романы. Модели оценивались в двух форматах: множественный выбор и открытая генерация.
Два типа ответов в NovelQA
Чтобы построить датасет, авторы выбрали разнообразный набор из 89 английских романов и тесно сотрудничали со студентами английской литературы, знакомыми с этими произведениями. Аннотаторы создали 2305 вопросов в две фазы. Сначала аннотаторы использовали шаблон вопроса и подставляли сущности из романа, чтобы сформировать корректные вопросы (шаблоны ниже).
Шаблоны, использованные для генерации вопросов в NovelQA
Затем, чтобы повысить разнообразие вопросов, аннотаторы также свободно генерировали более сложные вопросы. Все вопросы затем были проверены авторами, которые в итоге приняли 79,4% вопросов. Каждый вопрос сопровождался эталонным ответом и соответствующими подтверждающими доказательствами из романов для заземления оценок.
NovelQA оценивает способность модели синтезировать, интегрировать и вспоминать детальную информацию в очень длинных контекстах. Вопросы делятся на следующие категории:
Ориентированные на детали (22,2%): фокус на тонких подробностях, требующих внимательного припоминания. Single-hop (42,8%): отвечаются по соседним предложениям или близко связанным фрагментам. Multi-hop (35%): требуют синтеза информации по нескольким главам.
Вопросы охватывают различные нарративные аспекты — персонажей, сюжет, сеттинг и более глубокие тематические смыслы. Бенчмарк поддерживает как множественный выбор, так и открытую генеративную оценку, причём GPT-4 выступает оценщиком для генеративных ответов (Cohen's Kappa 89,25% с человеческими оценками).
Распределение данных по сложности и аспекту в NovelQA
Результаты NovelQA — это отход от типичной проблемы «lost in the middle»: они показали, что качество моделей падает, когда доказательства появляются за пределами отметки в 100 000 токенов. Авторы также подчеркнули важность строгого контроля качества, вручную проверяя все вопросы, сгенерированные краудворкерами, и принимая только 79,4% пар вопрос-ответ. Наконец, явная связка каждого ответа с конкретными подтверждающими доказательствами помогает с evals ретривера.
Качество моделей падает, когда доказательства расположены за пределами 100k токенов
Если нарративные тексты представляют один вид сложности, то понимание плотных технических документов вводит совершенно другой набор трудностей.
QASPER, представленный Dasigi et al. (2021), решает эту задачу, тестируя модели на информационно-поисковых вопросах по академическим статьям. В частности, QASPER содержит 5049 вопросов по 1585 NLP-статьям. Подобно NarrativeQA, эти вопросы составлялись NLP-практиками, прочитавшими только заголовки и аннотации статей. Такой подход гарантирует, что вопросы часто требуют синтеза информации из всей статьи, а не простого извлечения текста.
Пример вопроса, ответа и подтверждающего доказательства в QASPER
Сначала 25 NLP-практиков выбрали интересующие их статьи и составили вопросы, основываясь только на заголовках и аннотациях. Затем другая группа из 51 NLP-эксперта отвечала на эти вопросы, используя полные тексты. Задача последней группы включала определение того, можно ли ответить на вопрос, указание конкретных подтверждающих доказательств (например, текстовых фрагментов, рисунков или таблиц) и предоставление чёткого, краткого ответа. (10% вопросов были помечены как не имеющие ответа и потому исключены.) Разделение генерации вопросов и разметки ответов снизило смещения, поскольку авторы вопросов не имели предварительного знания о детальных ответах.
QASPER оценивает модели по двум основным аспектам: точность ответа (Answer-F1) и подбор доказательств (Evidence-F1). Answer-F1 измеряет точность ответов модели, независимо от того, извлекают ли они текст напрямую или создают новые объяснения. Evidence-F1 оценивает способность модели выявлять подтверждающие детали. Это особенно сложно, поскольку более половины вопросов требуют объединения доказательств из нескольких разделов или абзацев.
Результаты Evidence-F1 в QASPER подсвечивают значительный разрыв между генерацией ответа и извлечением доказательств — даже когда модели дают точные ответы, они часто затрудняются указать точные подтверждающие фрагменты. Кроме того, ограничение составителей вопросов только заголовками и аннотациями естественным образом стимулировало вопросы — и ответы, — требующие глубокого понимания всей статьи, выходящего за рамки поверхностного извлечения.
L-Eval от An et al. (2023) охватывает документы длиной от 3000 до 200 000 токенов и включает 20 разнообразных подзадач, 508 объёмных документов и более 2000 размеченных людьми пар вопрос-ответ. В отличие от предыдущих бенчмарков, в основном опиравшихся на метрики сопоставления текста, L-Eval также применял LLM-оценщиков и измерял разницу между подходами.
Для построения L-Eval авторы сначала создали четыре новых датасета: Coursera (образовательный контент), SFiction (научно-фантастические истории), CodeU (Python-кодбейзы) и LongFQA (финансовые отчётности). Они также улучшили пять существующих датасетов, добавив более сложные вопросы, ориентированные на синтез, например, дополнив QuALITY вопросами, требующими более глубокого понимания целых документов. Наконец, они проверили и исправили 12 задач из предыдущих бенчмарков, используя Claude-100k для выявления и удаления неточностей или неотвечаемых вопросов.
Статистика датасетов, типов вопросов и доменов в L-Eval
L-Eval оценивает два типа задач: закрытые (множественный выбор, понимание кода, true/false и математика), акцентирующие точное рассуждение, и открытые (нарративный синтез и summarization), фокусирующиеся на интеграции и обобщении длинного контента.
Закрытые задачи оценивались по точному совпадению, тогда как открытые задачи оценивались людьми-аннотаторами по шкале от 1 (плохо) до 5 (отлично). Дополнительно L-Eval использовал языковые модели вроде GPT-4 и GPT-3.5 как оценщиков через попарные сравнения для открытых задач. Они имели тщательно спроектированные промпты, чтобы снизить смещение в пользу чрезмерно подробных ответов. Традиционные n-граммные метрики, включая ROUGE-L и F1-скоры, также использовались для эффективности, несмотря на их известную чувствительность к длине ответа.
L-Eval показал, что традиционные n-граммные метрики часто не отражают истинное понимание в сценариях с длинным контекстом из-за несовпадения длин ответов. Кроме того, бенчмарк продемонстрировал, что использование LLM в качестве оценщиков в попарных сравнениях даёт превосходное согласие с человеческими оценками по сравнению с традиционными метриками, подсвечивая чёткие различия в сильных сторонах моделей для закрытых и открытых задач.
HELMET (How to Evaluate Long-context Models Effectively and Thoroughly), представленный Yen et al. (2025), решает проблемы более ранних бенчмарков, такие как нереалистичные задачи и непоследовательные метрики, предоставляя фреймворк для оценки long-context языковых моделей.
Для начала авторы выявили недостатки существующих оценок, включая ограниченные длины контекста, ненадёжные методы и недостаточное покрытие моделей без instruction-tuning. Затем они создали бенчмарк с семью категориями задач: RAG, генерация с цитатами, переранжирование пассажей, many-shot in-context learning, Q&A на длинных документах, summarization и синтетический recall. Каждая задача содержит контексты до 128 000 токенов, что позволяет проводить контролируемые и согласованные оценки с тщательно подобранными few-shot промптами и метриками на основе моделей.
Категории задач, датасеты и метрики в HELMET
HELMET конкретно оценивает следующие возможности в long-context моделях:
Извлечение и рассуждение: Natural Questions, TriviaQA и HotpotQA тестируют способность модели находить релевантную информацию в обширных контекстах с дистракторами. Следование инструкциям: задачи генерации с требованием цитат оценивают, могут ли модели следовать точным правилам форматирования, сохраняя точность. Сравнительное рассуждение: переранжирование пассажей оценивает, насколько хорошо модели сравнивают и рассуждают по нескольким фрагментам текста. In-context learning: many-shot-задачи измеряют способность модели быстро адаптироваться и обучаться по множеству примеров, предоставленных в контексте. Понимание длинных форм: задачи Q&A на длинных документах и summarization оценивают способность модели синтезировать и понимать обширные тексты.
HELMET показал, что синтетические задачи вроде Needle In a Haystack менее полезны из-за слабой корреляции с реальными сценариями. Также, за счёт тщательного контроля длин входа, HELMET смог оценить устойчивость моделей к всё более длинным контекстам, приближающимся к пределам предыдущих моделей (≥128K токенов). Подобно предыдущим бенчмаркам, HELMET воспроизвёл недостатки традиционных n-граммных метрик вроде ROUGE, которые могут искажать качество на более длинных выходах. Вместо этого он рекомендует использовать оценку на основе моделей с использованием моделей вроде GPT-4o, что лучше согласуется с человеческой оценкой.
Сравнение результатов бенчмарков по NIAH, Ruler, InfinityBench и HELMET
Loong от Wang et al. (2024) — это бенчмарк, оценивающий понимание длинного контекста по нескольким документам. Если большинство более ранних бенчмарков фокусируются на сценариях с одним документом, Loong представляет реалистичные многодокументные задачи, в которых пропуск любого релевантного документа приводит к неверным ответам.
Loong фокусируется на многодокументных Q&A
Loong состоит из 1600 evals, взятых из финансовых отчётов, юридических дел и академических статей на английском и китайском, в основном за 2024 год. Каждая задача включает доказательства, распределённые по нескольким документам, имитируя реальную сложность. Для генерации вопросов авторы использовали два метода: шаблонную генерацию, при которой пары Q&A конструировались по заданным правилам, и свободную разметку, при которой GPT-4o промптили на создание дополнительных пар Q&A.
Loong оценивает способность модели находить, сравнивать, кластеризовать и рассуждать по доказательствам, распределённым по нескольким документам, обычно от 10 000 до более 250 000 токенов. Бенчмарк охватывает четыре типа задач:
Spotlight: поиск релевантного доказательства в одном конкретном документе среди нескольких. Comparison: сравнение и интеграция нескольких фрагментов информации из разных документов и возврат правильного ответа. Clustering: агрегирование и группировка релевантной информации из нескольких источников по заданным критериям. Chain of Reasoning: интеграция доказательств из разных документов для возврата ответов.
Четыре оценочные задачи в Loong
Для оценки в качестве LLM-оценщика использовался GPT-4, который выставлял баллы выходам моделей по точности, галлюцинациям и полноте, ссылаясь на эталонный ответ и требования задачи. Метрики включали (i) средние баллы (средняя оценка по всем вопросам) и (ii) perfect rate (процент вопросов, получивших идеальный балл).
Интересно, что их анализ retrieval-augmented generation (RAG) показал, что использование RAG снижает качество на бенчмарке Loong. Они предположили, что это связано с тем, что доказательства Loong рассредоточены по нескольким документам. Хотя RAG несколько помогал на spotlight-задачах, он плохо справлялся с задачами, требующими более глубокого синтеза, такими как сравнение, кластеризация и многоступенчатое рассуждение.
Использование RAG ухудшает качество по сравнению с базовой линией
Вот ещё несколько long-context бенчмарков, которые могут оказаться полезными:
A Critical Evaluation of Evaluations for Long-form Question Answering Ada-LEval: Evaluating long-context LLMs with length-adaptable benchmarks BABILong: Testing the Limits of LLMs with Long Context Reasoning-in-a-Haystack BAMBOO: A Comprehensive Benchmark for Evaluating Long Text Modeling Capacities of Large Language Models BizBench: A Quantitative Reasoning Benchmark for Business and Finance ELI5: Long Form Question Answering Frustratingly Hard Evidence Retrieval for QA Over Books InfinityBench: Extending Long Context Evaluation Beyond 100K Tokens LFED: A Literary Fiction Evaluation Dataset for Large Language Models LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-Context Multitasks LongReason: A Synthetic Long-Context Reasoning Benchmark via Context Expansion MultiDoc2Dial: Modeling Dialogues Grounded in Multiple Documents QuALITY: Question Answering with Long Input Texts, Yes!
• • •
Уф, это было много! Вот ключевые выводы:
Faithfulness и helpfulness — ортогональные измерения. Ответ может быть верным источнику, но бесполезным, или полезным, но содержать галлюцинации. Faithfulness также означает умение сказать «я не знаю». Модели должны отказываться отвечать, когда в контексте нет информации, и корректно отвечать, когда она есть. Традиционные n-граммные метрики плохо работают на Q&A. Используйте вместо них LLM-оценщиков. Они лучше оценивают семантическое качество и ближе к человеческой оценке. Расположение доказательств имеет значение. На рассмотренных бенчмарках одни модели страдали от эффекта «lost in the middle», другие показывали плохое качество, когда доказательства были за отметкой в 100 000 токенов. Использование RAG может ухудшить качество, особенно для задач, требующих связного рассуждения по доказательствам, распределённым по одному или нескольким документам.
Что-нибудь важное упустил? Какие ещё метрики, методы или бенчмарки посоветуете изучить? Пожалуйста, дайте знать!
Кстати, если вы хотите больше узнать о evals, мои друзья Hamel и Shreya проводят свой последний поток курса «AI Evals for Engineers and PMs» в июле. Вот промокод на скидку 35%.
Литература
An, Chenxin, Shansan Gong, Ming Zhong, Xingjian Zhao, Mukai Li, Jun Zhang, Lingpeng Kong, and Xipeng Qiu. 2023. «L-Eval: Instituting Standardized Evaluation for Long Context Language Models.» arXiv. https://doi.org/10.48550/arXiv.2307.11088.
Bai, Yushi, Xin Lv, Jiajie Zhang, Hongchang Lyu, Jiankai Tang, Zhidian Huang, Zhengxiao Du, et al. 2024. «LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding.» arXiv. https://doi.org/10.48550/arXiv.2308.14508.
Bai, Yushi, Shangqing Tu, Jiajie Zhang, Hao Peng, Xiaozhi Wang, Xin Lv, Shulin Cao, et al. 2025. «LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-Context Multitasks.» arXiv. https://doi.org/10.48550/arXiv.2412.15204.
Dasigi, Pradeep, Kyle Lo, Iz Beltagy, Arman Cohan, Noah A. Smith, and Matt Gardner. 2021. «A Dataset of Information-Seeking Questions and Answers Anchored in Research Papers.» arXiv. https://doi.org/10.48550/arXiv.2105.03011.
Dong, Zican, Tianyi Tang, Junyi Li, Wayne Xin Zhao, and Ji-Rong Wen. 2024. «BAMBOO: A Comprehensive Benchmark for Evaluating Long Text Modeling Capacities of Large Language Models.» arXiv. https://doi.org/10.48550/arXiv.2309.13345.
Fabbri, Alexander, Chien-Sheng Wu, Wenhao Liu, and Caiming Xiong. 2022. «QAFactEval: Improved QA-Based Factual Consistency Evaluation for Summarization.» In Proceedings of the 2022 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies. Seattle, United States: Association for Computational Linguistics. https://doi.org/10.18653/v1/2022.naacl-main.187.
Fan, Angela, Yacine Jernite, Ethan Perez, David Grangier, Jason Weston, and Michael Auli. 2019. «ELI5: Long Form Question Answering.» arXiv. https://doi.org/10.48550/arXiv.1907.09190.
Feng, Song, Siva Sankalp Patel, Hui Wan, and Sachindra Joshi. 2021. «MultiDoc2Dial: Modeling Dialogues Grounded in Multiple Documents.» In Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing, 6162–76. https://doi.org/10.18653/v1/2021.emnlp-main.498.
Hu, Xiangkun, Dongyu Ru, Lin Qiu, Qipeng Guo, Tianhang Zhang, Yang Xu, Yun Luo, Pengfei Liu, Yue Zhang, and Zheng Zhang. 2024. «RefChecker: Reference-Based Fine-Grained Hallucination Checker and Benchmark for Large Language Models.» arXiv. https://doi.org/10.48550/arXiv.2405.14486.
Kočiský, Tomáš, Jonathan Schwarz, Phil Blunsom, Chris Dyer, Karl Moritz Hermann, Gábor Melis, and Edward Grefenstette. 2017. «The NarrativeQA Reading Comprehension Challenge.» arXiv. https://doi.org/10.48550/arXiv.1712.07040.
Koncel-Kedziorski, Rik, Michael Krumdick, Viet Lai, Varshini Reddy, Charles Lovering, and Chris Tanner. 2024. «BizBench: A Quantitative Reasoning Benchmark for Business and Finance.» arXiv. https://doi.org/10.48550/arXiv.2311.06602.
Kuratov, Yuri, Aydar Bulatov, Petr Anokhin, Ivan Rodkin, Dmitry Sorokin, Artyom Sorokin, and Mikhail Burtsev. 2024. «BABILong: Testing the Limits of LLMs with Long Context Reasoning-in-a-Haystack.» arXiv. https://doi.org/10.48550/arXiv.2406.10149.
Laban, Philippe, Tobias Schnabel, Paul N. Bennett, and Marti A. Hearst. 2021. «SummaC: Re-Visiting NLI-Based Models for Inconsistency Detection in Summarization.» arXiv. https://doi.org/10.48550/arXiv.2111.09525.
Ling, Zhan, Kang Liu, Kai Yan, Yifan Yang, Weijian Lin, Ting-Han Fan, Lingfeng Shen, Zhengyin Du, and Jiecao Chen. 2025. «LongReason: A Synthetic Long-Context Reasoning Benchmark via Context Expansion.» arXiv. https://doi.org/10.48550/arXiv.2501.15089.
Mou, Xiangyang, Mo Yu, Bingsheng Yao, Chenghao Yang, Xiaoxiao Guo, Saloni Potdar, and Hui Su. 2020. «Frustratingly Hard Evidence Retrieval for QA Over Books.» arXiv. https://doi.org/10.48550/arXiv.2007.09878.
Pang, Richard Yuanzhe, Alicia Parrish, Nitish Joshi, Nikita Nangia, Jason Phang, Angelica Chen, Vishakh Padmakumar, et al. 2022. «QuALITY: Question Answering with Long Input Texts, Yes!» arXiv. https://doi.org/10.48550/arXiv.2112.08608.
Wang, Chonghua, Haodong Duan, Songyang Zhang, Dahua Lin, and Kai Chen. 2024. «Ada-LEval: Evaluating Long-Context LLMs with Length-Adaptable Benchmarks.» arXiv. https://doi.org/10.48550/arXiv.2404.06480.
Wang, Cunxiang, Ruoxi Ning, Boqi Pan, Tonghui Wu, Qipeng Guo, Cheng Deng, Guangsheng Bao, et al. 2024. «NovelQA: Benchmarking Question Answering on Documents Exceeding 200K Tokens.» arXiv. https://doi.org/10.48550/arXiv.2403.12766.
Wang, Minzheng, Longze Chen, Cheng Fu, Shengyi Liao, Xinghua Zhang, Bingli Wu, Haiyang Yu, et al. 2024. «Leave No Document Behind: Benchmarking Long-Context LLMs with Extended Multi-Doc QA.» arXiv. https://doi.org/10.48550/arXiv.2406.17419.
Xu, Fangyuan, Yixiao Song, Mohit Iyyer, and Eunsol Choi. 2023. «A Critical Evaluation of Evaluations for Long-Form Question Answering.» arXiv. https://doi.org/10.48550/arXiv.2305.18201.
Yen, Howard, Tianyu Gao, Minmin Hou, Ke Ding, Daniel Fleischer, Peter Izsak, Moshe Wasserblat, and Danqi Chen. 2025. «HELMET: How to Evaluate Long-Context Language Models Effectively and Thoroughly.» arXiv. https://doi.org/10.48550/arXiv.2410.02694.
Yu, Linhao, Qun Liu, and Deyi Xiong. 2024. «LFED: A Literary Fiction Evaluation Dataset for Large Language Models.» arXiv. https://doi.org/10.48550/arXiv.2405.10166.
Zhang, Xinrong, Yingfa Chen, Shengding Hu, Zihang Xu, Junhao Chen, Moo Khai Hao, Xu Han, et al. 2024. «InfinityBench: Extending Long Context Evaluation Beyond 100K Tokens.» arXiv. https://doi.org/10.48550/arXiv.2402.13718.
Если вам это пригодилось, пожалуйста, цитируйте эту статью так:
Yan, Ziyou. (Jun 2025). Evaluating Long-Context Question & Answer Systems. eugeneyan.com. https://eugeneyan.com/writing/qa-evals/.
или
@article{yan2025qa, title = {Evaluating Long-Context Question & Answer Systems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2025}, month = {Jun}, url = {https://eugeneyan.com/writing/qa-evals/} }
Присоединяйтесь к 11 800+ читателям, получающим обновления о machine learning, RecSys, LLM и инженерии.