Claude Code رفع Legal RAG إلى 0.791، لكن نهائيات ARLC 2026 اصطدمت بقيود التوسع

Кейс ARLC 2026 хорошо показывает, насколько хрупким может быть RAG в реальных задачах. За пять дней автор вместе с Claude Code поднял результат юридического пайплайна с 0.034 до 0.791 на warmup, а затем столкнулся с жёсткой стеной масштабирования в финале.

От бага к рывку

Челлендж требовал не просто отвечать на вопросы по судебным решениям и законам, а точно указывать страницы-источники. Из-за этого grounding становился множителем всей итоговой оценки: даже при сильных ответах слабые ссылки почти обнуляли score. Именно так случилось на старте: первая версия показала 0.

034, хотя точность по части ответов уже была высокой. Проблема оказалась не в модели и не в retrieval, а в формате выдачи. Автор потратил три попытки, прежде чем заметил простую ошибку: в поле doc_id отправлялось имя файла вместе с .

pdf, хотя система ожидала идентификатор без расширения. Один фикс поднял grounding с 0.05 до 0.

55, а общий результат — с 0.034 до 0.438.

Дальше пайплайн дошёл до 0.791 на warmup за 17 итераций. Отдельно помогла математика F-beta с β=2.

5: она показала, что лишние страницы вредят сильнее, чем кажется, и каждая лишняя ссылка может стоить 10–22% качества grounding.

Архитектура и приёмы

Лучший результат дал пайплайн, который индексировал не чанки, а целые страницы PDF. Это важный выбор для legal RAG: если метрика проверяет попадание в конкретную страницу, chunking усложняет обратную привязку и плодит шум. Для поиска использовалась гибридная схема BM25 плюс эмбеддинги с объединением через RRF, а для сканов добавлялся OCR. Поверх этого автор ограничивал число страниц в выдаче и отдельно маршрутизировал comparison-вопросы, где нужно сопоставлять два документа.

• Page-level retrieval вместо чанков BM25 + embeddings + Reciprocal Rank Fusion OCR fallback для пустых или сканированных страниц Ограничение числа страниц в ответе по типу вопроса Быстрые детерминированные ветки для простых кейсов > «Сначала валидируй формат вывода. Потом улучшай качество». Отдельная линия кейса — роль Claude Code. С его помощью автор собрал около 3000 строк кода в семи модулях за пять дней и успел сделать 17 версий вместо условных 3–5 вручную. Агент ускорял правки, рефакторинг, прогон сабмишенов и проверку диффов перед отправкой. Но стратегические решения всё равно оставались за человеком: какие метрики чинить первыми, как интерпретировать регрессии и когда не трогать уже настроенный промпт.

Где всё сломалось

На warmup корпус состоял из 30 документов и 100 вопросов, а в финале — уже из 303 документов, 4244 страниц и 900 вопросов. Здесь и выяснилось, что пайплайн, хорошо ведущий себя на маленьком наборе, не обязан переноситься на большой. Сначала всплыл баг с кешем: система по ошибке индексировала 30 warmup-документов вместо 303 финальных, из-за чего число null-ответов подскочило до 37.

После очистки кеша проблема ушла, но основной провал остался: итоговый score просел на 42%, до 0.457. Корневые причины оказались уже архитектурными.

Огромный документ DIFC Courts Rules начал загрязнять выдачу по многим юридическим запросам, consultation papers с одинаковыми номерами, но разными годами ломали дизамбигуацию, а регулярка для law number подменяла ответы про штрафы номерами законов. Попытка быстро накатить пакет из восьми исправлений выглядела разумно, но в сумме ухудшила баланс метрик: часть детерминированной точности выросла, зато grounding и общий score просели ещё сильнее. Этот разбор ценен тем, что не продаёт магию AI-ассистента.

Claude Code дал скорость, но не снял главную инженерную работу: валидировать формат, считать метрику, тестировать по одному изменению и проверять систему на масштабе, близком к продакшену. Главный вывод автора жёсткий: если eval-сет в разы меньше боевого корпуса, то ты тестируешь не retrieval, а удачу.

Что это значит Для команд, которые строят RAG-продукты, это хороший холодный душ.

Побеждает не самый сложный стек, а дисциплина: точный формат вывода, понятная метрика, минимальный шум в ссылках и проверка на реальном масштабе. А AI-кодинг-ассистенты уже дают серьёзное ускорение, но пока не заменяют инженерное мышление и ответственность за архитектурные решения.