Обновить

Комментарии 5

Универсального RAG не существует. Чанкинг, который работает на коротких статьях, ломается на 537-страничном своде правил. Промпт, который извлекает даты, путает “апелляция подана” и “в апелляции отказано”.

Интересно, есть ли уже какое-то движение в сторону "meta-RAG" - пайплайна, который сначала анализирует данные заранее неизвестной структуры и содержания и исходя из этого анализа собирает оптимальный для них RAG.

У меня интерес практический - давно мечтаю о решении типовой задачки для юридической фирмы - "проанализировать первоначально полученные от клиента документы по делу". А от клиента по новому проекту обычно прилетает архив на гигабайты - десятки гигабайт, в котором может быть всякое: фото материалов дела в JPEG паршивого качества; тысячи банковских выписок; 30 версий одного и того же договора в Word (неплохо бы угадать, какая оказалась последней); архивы внутри архивов с кривой кодировкой имён файлов и т.д и т.п. И вот хочется волшебную кнопку, которая за разумное время (скажем, за сутки) все эти авгиевы конюшни разгребёт, построит по ним RAG и начнёт более или менее осмысленно отвечать на вопросы по содержимому. Пока моих скромных талантов и опыта не хватает даже чтобы подступиться к этой задаче...

Я бы ещё добавил, что когда неопределенность и неуниверсальность, то как раз агенты. "Так, первый пункт плана. Что это перед нами? Фото? Давайте прочитаем, вызываем qwen3.5-9b." И т.п.

RAG собранный на агентах, по наблюдению ещё одного участника соревы (https://www.linkedin.com/posts/ayelmagambetov_i-spent-the-last-2-weeks-on-an-ai-competition-activity-7442151483950919680-enX2) - это лучше всего ("If you care about accuracy without latency constraints, just use an agent loop. Give it grep, file search, maybe FTS. It will outperform any embedding + reranker pipeline. Use an existing harness (Claude Code, Codex, OpenCode), don’t build your own agent. These are universal enough.")

В соревновании уже столкнулись с этим на минималках: сначала смотрим на документ, потом выбираем стратегию.

Ваша задача посложнее, до RAG нужно понять что перед нами. Очень похоже что требуется какой-то подход, который будет постепенно из этих конюшень чистить по одной проблеме. Сначала разберет документы, из них найдет последние версии. Потом разберется с JPEG, а там может и до архивов доберется. Но начать с одного типа документов, реализовывать и расширять дальше. Именно так мы и делали )

Дальше, адаптивный пайплайн RAG: выписки парсить структурно, договоры семантически, фото через Vision LLM.

Думаю Meta-RAG - это именно то, к чему все хотят прийти, в том числе и мы )

Наш код опубликован на github но пока он ориентирован больше на PDF, MD и базы знаний Confluence + jira.

Крутой разбор, особенно про grounding metric - что без правильной атрибуции даже идеальный ответ проваливается.

Столкнулся с похожей проблемой в другом контексте: делаю AI-компаньон с persistent памятью. Flat RAG не справлялся - факт “Маша обещала позвонить” без эмоционального контекста момента (она была расстроена) превращается в мёртвые данные.

Перешёл на 7-мерный граф с somatic markers (Damasio) - каждый факт хранит valence (эмоциональный заряд при записи). Spreading activation вместо cosine similarity — граф знает что person X связан с promise Y через episode Z, а не просто “похожие эмбеддинги”.

Hybrid подход (BM25 + semantic) как у вас, но с добавлением temporal proximity boost - факты близкие по ВРЕМЕНИ к текущему моменту получают gaussian boost. Решает проблему “вспомни что было час назад” где keyword match и семантика не помогают.

Интересно было бы сравнить grounding metrics на графовом retrieval vs flat. Формального бенчмарка пока нет, но субъективно - граф реже “галлюцинирует” источник, потому что edge type = явная связь.

Да, графовые подходы на мой взгляд очень крутые! Они позволяют делать явные связи между сущностями, причем на мета-уровне, над документами. А еще они позволяют оперировать транзитивными зависимостями между сущностями. Что если А->B, а В->С, то с легкостью использовать то, что А->C. В обычном RAG с этим гораздо сложнее. Граф значительно сложнее построить, хранить и поддерживать, делать дедупликацию сущностей. На больших документациях они могут получиться очень шумными. Но согласен, сравнить было бы очень интересно!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации