Agentic Legal RAG Challenge 2026: как Sparks of intelligence проверила пределы agentic RAG
Команда Sparks of intelligence опубликовала разбор участия в Agentic Legal RAG Challenge 2026 — хакатоне по ответам на документах судов DIFC. Авторы собрали две

Команда Sparks of intelligence опубликовала подробный разбор участия в Agentic Legal RAG Challenge 2026 — международном хакатоне по legal RAG. Это не история про громкую победу, а полезный инженерный отчёт о том, почему системы поиска по документам чаще ломаются на подготовке контекста, чем на выборе самой LLM.
Как устроили хакатон Соревнование проводила компания EORA AI Applications and Services.
Участникам нужно было построить систему, которая отвечает на вопросы по документам судов Международного финансового центра Дубая — DIFC. Хакатон шёл в два этапа: с 11 по 19 марта 2026 года участники работали с 30 документами и 100 вопросами, а в финале, который прошёл с 20 по 22 марта 2026 года, объём вырос до 300 документов и 900 вопросов. Призовой фонд составил 32 000 долларов, а всего в соревновании участвовало более 300 человек.
Сложность была не только в объёме. Организаторы заранее заложили разные типы ответов: boolean, name, date, number и free text. То есть одной модели генерации было мало — системе приходилось и точно извлекать факт, и удерживать контекст, и не тратить слишком много времени и токенов.
Для свободных текстовых ответов использовалась LLM-оценка, а среди ключевых критериев были точность, скорость и стоимость обработки. По сути, участников проверяли не на умение «подключить чат-бота», а на зрелость всего retrieval-контура.
Две версии системы
Команда собрала две архитектуры на одном стеке: Qdrant как векторную базу, LlamaIndex для работы с индексами и LLM-абстракциями, а Unstructured — для извлечения текста из PDF с сохранением структуры. Дальше пути разошлись. Первая версия была максимально практичной: чанкинг по страницам с перекрытием, гибридный поиск, фильтрация по метаданным и регулярным выражениям. Вторая версия была заметно амбициознее: иерархический чанкинг, предварительный анализ структуры через LLM и агент-роутер, который выбирает подходящий инструмент поиска под конкретный вопрос.
- Простая версия делила документы по страницам и сразу давала понятный grounding.
- Поиск там строился на смеси векторов, метаданных и regex-фильтров.
- Агентная версия использовала роутер и четыре инструмента: поиск по метаданным, точное совпадение, сравнение документов и гибридный поиск.
- В обеих схемах применяли реранкер, чтобы перетасовать top-k кандидатов и поднять релевантность. На практике простая архитектура оказалась устойчивее. Её можно было быстро собрать, поведение было предсказуемым, а источник ответа легче отследить. Агентная схема выглядела сильнее на бумаге, но оказалась дороже по времени: два вызова LLM, нестабильный чанкинг и больше точек отказа. Даже после исправления части ошибок команда не успела полноценно прогнать и настроить весь пайплайн. Для хакатона с жёстким дедлайном это критично: лишняя сложность быстро съедает выигрыш от «умной» архитектуры.
Где всё ломалось Главной проблемой оказался чанкинг.
Один и тот же шаблон разбиения по-разному работал на разных страницах, а мелкие фрагменты без смысла приходилось просто приклеивать к соседним кускам. В простой схеме мешали и regex: они ускоряли поиск по паттернам, но легко пропускали нужные случаи или давали ложные срабатывания. Отдельно всплыл вопрос grounding: сначала нужные ссылки и метаданные не загружались как надо, потом это исправили, но вместе с ростом grounding просела точность. Хорошая иллюстрация того, что retrieval-система редко оптимизируется по одной метрике без побочных эффектов.
«В такие сжатые сроки построить подобную систему практически невозможно без кодовых агентов».
Финальные результаты это только подтвердили. Простое решение добралось до точности 0.79 при grounding 0.63 и показало стабильное, хоть и не идеальное поведение. Более сложная агентная версия на предварительном этапе проигрывала по точности и работала медленнее, а в финале её вообще не успели сдать из-за API-ошибок перед дедлайном. Авторы отдельно предупреждают и о другой ловушке: кодовые агенты полезны для обвязки и рутинных задач, но при сложной постановке могут подменять реальные шаги заглушками, «магическими числами» или узкими regex-хаками, которые выглядят как решение, но не выдерживают реальной проверки.
Что это значит Разбор хорошо показывает реальный статус agentic RAG в 2026 году.
В задачах по юридическим документам выигрывает не самая эффектная схема, а та, где контролируются чанкинг, grounding, метаданные и тестирование. Для команд, которые строят AI-поиск по внутренним базам знаний, вывод простой: сначала нужно сделать надёжный retrieval и измеримость, а уже потом добавлять роутеры, агентов и сложную оркестрацию.