Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Из неразмеченного корпоративного корпуса можно собрать оценочный набор, который проверяет разные типы поиска, сложные запросы и корректный отказ от ответа. Команда Scale AI описала CoverSynth в нерецензированном препринте, где все числа получили сами авторы: на RepLiQA человеческие вопросы оказались одинаково простыми для всей панели в 91% случаев, а вопросы CoverSynth — только в 12%. Такой набор помогает выбирать между поисковыми конфигурациями, которые на обычном тесте выглядят равноценными.
Как CoverSynth распределяет вопросы по корпусу
Обычный синтетический набор часто начинается с отдельных фрагментов: модель читает текст и придумывает к нему вопрос. Полученные вопросы могут быть корректными, но концентрироваться на нескольких документах, прямом поиске фактов и формулировках одного типа.
CoverSynth сначала определяет, как интерпретировать корпус, и описывает предполагаемые роли пользователей. Например, роль задаёт профессиональный контекст, знакомство с предметом и характер запросов. Затем система извлекает из документов понятия, ссылки и сокращения, связывает их в граф и группирует близкие области корпуса.
Планировщик выбирает не только тему вопроса, но и структуру подтверждающих фрагментов. Один фрагмент может содержать готовый ответ, несколько независимых фрагментов — части общего ответа, а цепочка — сведения, где каждый найденный элемент помогает отыскать следующий. Отдельные квоты распределяют вопросы между документами, ролями, намерениями пользователя и такими структурами поиска.
Для запросов, на которые нельзя ответить, система изменяет уже проверенный вопрос одним контролируемым способом. Она может удалить необходимое основание, добавить ложную предпосылку, сделать запрос недостаточно определённым или создать неоднозначную ссылку. Так набор проверяет не только извлечение сведений, но и способность агента запросить уточнение либо отказаться от неподтверждённого ответа.
Как проверяют разметку и способность набора различать системы
Для каждого разрешимого вопроса модель предлагает дословные подтверждающие фрагменты. Программная проверка ищет точное совпадение в исходном документе и сохраняет позиции символов. Это не доказывает, что фрагмент действительно отвечает на вопрос, зато исключает ссылки на несуществующий или пересказанный текст.
Смысл проверяют отдельно. Модель-оценщик определяет, достаточно ли приведённых фрагментов, не раскрывает ли вопрос ответ и действительно ли звенья цепочки зависят друг от друга. Для неразрешимых запросов один оценщик подтверждает заданную причину отказа, а другой пытается всё же найти ответ в корпусе. Запрос попадает в набор, только если эта попытка не удалась.
Качество самого набора измеряют по трём направлениям. Покрытие показывает, какие области корпуса, роли, намерения и структуры поиска представлены в вопросах. Надёжность разметки проверяет, хватает ли эталонных фрагментов для ответа и перестаёт ли ответ быть возможным после их удаления. Полезность для сравнения систем оценивают по доле слишком простых вопросов и по тому, повторяются ли различия между конфигурациями в независимых запусках.
На человеческом наборе RepLiQA почти все системы успешно проходили одну и ту же большую группу вопросов, поэтому итоговые оценки сближались. В повторном сравнении на TechQA и RepLiQA интервалы различий лежали выше нуля для 12 из 12 сопоставлений на наборах CoverSynth и только для 4 из 12 на человеческих наборах. Синтетический набор не просто оказался сложнее: он чаще сохранял направление различия между моделями.
Что меняется в планах команд с поисковыми агентами
Работа предлагает перенести контроль покрытия в начало подготовки тестов. Команда сначала фиксирует ожидаемые роли, типы запросов и допустимые причины отказа, затем генерирует вопросы и проверяет, какие части корпуса остались без тестов. Эксперты при этом не исчезают: вместо написания каждого вопроса они проверяют границы рабочей нагрузки, подготовку корпуса и спорные результаты аудита.
Такой подход особенно полезен перед выбором поискового движка, агентной среды или модели. Если текущий набор насыщен прямыми вопросами, новая конфигурация может не показать преимущества на среднем балле. Вопросы с несколькими документами, последовательными зависимостями и неоднозначными запросами создают пространство, где различия становятся видны.
Метод проверяли на TechQA, RepLiQA, EnterpriseRAG-Bench, eCFR и Harvey Firm Knowledge; каждый корпус ограничивали 5000 фрагментами. В генерации использовали GPT-5.4, GPT-5.6 Sol и text-embedding-3-large, поэтому результат пока характеризует конкретную схему и этот масштаб, а не любой внутренний архив. Сравнение охватывало человеческие наборы, MiRAGE и несколько типов разреженного, векторного и агентного поиска.
CoverSynth стоит рассматривать не как замену приёмочным испытаниям на реальных запросах, а как способ обнаружить слепые зоны до них. Практическое изменение плана состоит в том, чтобы оценивать не только ответы системы, но и сам тестовый набор: какие задачи он охватывает, можно ли проверить его эталоны и способен ли он вообще различить рассматриваемые конфигурации.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
