GeopoliticalQA: bge-m3 обошёл коммерческие эмбеддинги на 5 525 вопросах по отчётам

Группа исследователей опубликовала на arXiv GeopoliticalQA — бенчмарк для RAG-систем, которые отвечают на вопросы по геополитическим и стратегическим аналитическим отчётам. В наборе 415 открытых отчётов и 5 525 пар «вопрос — ответ», каждая привязана к конкретному документу. Это примерно 13 вопросов на отчёт. Главный результат такой: на уровне чанков качество поиска не растёт с размером эмбеддинг-модели. Среднеразмерная открытая bge-m3 сравнялась с моделями на порядок крупнее и опередила коммерческие embedding API. Генерация при этом остаётся трудной даже тогда, когда модель получает правильные фрагменты.

Что внутри бенчмарка

Аналитические отчёты плохо подходят для стандартного RAG. Форматы у них разные, структура неоднородная, а ценные выводы часто растянуты на несколько разделов и не лежат в одном абзаце. Авторы разделили вопросы на четыре типа: фактологические, на вывод (inferential), сравнительные и ориентированные на риски.

Вопросы строил document-aware пайплайн. Сначала он профилирует отчёт, то есть выясняет, о чём документ и как устроен, и только потом генерирует вопросы. Так вопросы меньше зависят от случайного фрагмента текста. Качество набора проверили двумя способами: экспертной разметкой и протоколом LLM-as-judge, где оценку выставляет языковая модель.

• Корпус: 415 открытых геополитических и стратегических отчётов
• Разметка: 5 525 вопросов с привязкой к документам
• Типы вопросов: фактологические, на вывод, сравнительные, рисковые
• Поиск: 15 систем
• Генерация: шесть open-weight LLM
• Проверка качества: эксперты и LLM-as-judge

Поиск: масштаб не решает

На уровне документов, то есть при выборе нужного отчёта, системы показывают близкие результаты. Различия появляются на уровне чанков, где нужно найти конкретный фрагмент внутри длинного текста. Здесь, по словам авторов, качество не определяется масштабом эмбеддера. bge-m3 держится на уровне моделей, которые на порядок больше, и превосходит коммерческие embedding API.

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

Генерация: потолок ниже ожидаемого

Для генерации авторы дали шести открытым LLM эталонные фрагменты, то есть убрали ошибки поиска. Модели всё равно справляются плохо, особенно с вопросами на вывод и на оценку рисков. Фактологические вопросы проще: ответ лежит в тексте. Выводы и риски требуют сопоставить утверждения, взвесить аргументы и сформулировать суждение, которого в отчёте может не быть дословно. Именно ради таких ответов аналитические отчёты и читают.

Если ответ плох при идеальном контексте, дело не в ретривере. Тюнинг поиска такую проблему не закроет.

Что делать командам, которые строят RAG

Первое: не выбирайте эмбеддер по размеру или цене. Прогоните на своём корпусе несколько моделей, включая bge-m3 как self-hosted базовую линию. Данные при этом остаются внутри контура, что важно для чувствительных документов.

Второе: оценивайте поиск и генерацию раздельно. Режим с эталонными фрагментами показывает потолок генератора и помогает понять, где именно ломается система.

Третье: разбивайте метрики по типам вопросов. Среднее по всем скроет провал на рисковых и выводных запросах. Для них стоит оставлять проверку человеком.

Ограничения тоже есть. Корпус состоит из открытых отчётов, а не закрытых материалов, и часть валидации опирается на LLM-as-judge с присущими ей смещениями. Как бенчмарк для сравнения подходов к RAG на аналитических текстах он всё равно полезен.