От 0.034 до 0.791 и обратно: Legal RAG, 17 итераций и стена масштабирования

[General_Grievous]

Интересно, что пайплайн так сильно просел при масштабировании. Как думаешь, иерархический ретривал решил бы проблему, или там фундаментально другой подход нужен?

[tagir_analyzes]

Спасибо! Да, иерархический ретривал скорее всего помог бы – основная проблема была в том, что flat BM25 по всем 4000+ страницам возвращал шум из нерелевантных документов (один только DIFC Courts Rules на 537 страниц забивал результаты). Сначала определить документ по title match / type classification, потом искать страницы внутри – я бы так пошел. По сути document routing index в моем пайплайне делал это для case references, но для законов и consultation papers маршрутизация была слишком слабой

[not-allowed-here]

самое интересное - это вместо попыток увеличения результативности - попытки нарастить подгонку ответа под ожидание - с тз соревновательности то всё верно, но вот с тз эффективности много вопросов....

чисто дилетантские вопросы:

1. каждый вопрос был к новому сету документов или для всей или общей группы группы вопросов был общий сет?

2. были ли заранее известны варианты вопросов или только "Answer types"?

3. не разумнее было бы провести какую-то предварительную классификацию документов с формированием некой структуры которая бы сократила зоны поиска? номера документов, типы, разделение статей.

4. формализация обработки документов - не разумнее было бы сформировать сразу некие формальные признаки привязывающие документы к типу/классу? опять же сокращение зон поиска

5. классификация внутренних частей документа - например выделить абзацы проработать их, сделать их разбор с предварительным выделением "смысловых токенов" для опять же упрощения поиска - хотя тут нужно хоть какое-то понимание вариантов вопросов - чтобы сформировать смысловые токены по ним.

[tagir_analyzes]

Привет! Спасибо за такую пачку вопросов

Про подгонку – справедливо, но с нюансом. Большинство итераций – это не «подкрутить ответ на вопрос №37», а найти системный баг в пайплайне. Например, regex для номеров законов случайно ловил вопросы про штрафы – 27 ответов мимо. Или BM25 заливал контекст страницами из одного 537-страничного документа. Такие фиксы переносятся на новые данные – из warmup (30 доков) на final (300 доков) большинство сработало. 

Один сет или разные? Один корпус на фазу. Warmup – ~30 PDF / 100 вопросов, final – ~300 PDF / 900 вопросов. Скачиваешь всё, индексируешь, прогоняешь все вопросы, отправляешь JSON. 

Вопросы заранее? При запуске – да, скачиваются вместе с корпусом. При проектировании пайплайна – нет. Известны только answer_types (number, boolean, name, date, free_text) и общие категории. 

Классификация документов – делалась, просто встроена в retrieval. Вопрос про «Article 12 of Law No. 2» маршрутизируется на конкретный закон. Вопрос про стороны дела – ищет только на первой странице case law. Consultation papers различаются по заголовкам. Можно было формализовать сильнее – на 300 документах это уже ощутимо не хватало. 

Формализация признаков / смысловые токены – по сути это и есть embeddings + BM25, просто на уровне страниц (не абзацев), потому что grounding оценивается по физическим страницам PDF. Более тонкая гранулярность точнее, но рискуешь потерять контекст. Для прода с другой метрикой – chunking с overlap разумнее.

[SenDog3]

ничего непонятно но оч.интересно

[SenDog3]

ушёл Карьерник проходить