Когда речь заходит о RAG, обычно представляют простую схему: разбить документы на фрагменты, посчитать эмбеддинги, загрузить в векторную базу и подключить LLM. На демо это работает. Иногда срабатывает и в корпоративной среде. Но с нормативными документами такой подход быстро даёт сбой.

Мы столкнулись с этим на практике, создавая систему для работы с нормативной базой. Сначала задача казалась стандартной: есть документы, есть вопросы — нужен RAG. Но вскоре стало ясно: главная проблема не в генерации. Она в представлении документа так, чтобы retrieval не разрушал его структуру и смысл.

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

• Нормативные документы плохо ложатся в модель «плоский набор чанков».
• Слишком маленькие фрагменты теряют контекст, слишком большие — дают шумный retrieval.
• Одного семантического поиска недостаточно: нужны точечный поиск по пунктам, работа с таблицами, терминами и кросс-ссылками.
• Один вопрос может требовать нескольких разных поисковых стратегий.
• Найденный пункт — это не всегда ответ: к нему нужно подтянуть связанные нормы.
• Поэтому документ пришлось моделировать не как текст, а как иерархический граф узлов и связей.

Где ломается обычный RAG

Сначала мы шли по привычному пути: разбивали документ на элементы, каждый делали единицей хранения, строили поверх векторный поиск.

Логика была проста: чем меньше фрагмент, тем точнее ссылка и меньше мусора в ответе. Но вскоре выяснилось, что минимальная единица хранения и минимальная единица смысла в нормативных документах часто не совпадают.

Проблема проявлялась так:

• пользователь спрашивает о конкретном требовании;
• semantic search находит похожий по формулировке пункт;
• но рядом есть подпункт, примечание или ссылка, без которых ответ становится некорректным;
• модель видит только один фрагмент и строит ответ, как будто этого достаточно.

На простых вопросах система справлялась. На сложных — где нужна доказуемая цепочка из нескольких норм — начинались сбои. Retrieval находил релевантный фрагмент, но не подтягивал обязательный контекст.

Тогда стало ясно: проблема не в «недоумной» модели. Проблема в слишком плоском представлении документа.

Первый поворот: документ перестал быть просто текстом

Вместо «документ = длинная строка» мы начали строить структурную модель. Основная идея: документ состоит не из абзацев, а из адресуемых элементов.

В нашей модели появились:

• документ как корневая сущность;
• узлы: разделы, пункты, подпункты;
• таблицы как отдельные элементы;
• формулы как отдельные элементы;
• связи между узлами;
• термины и их определения.

Сначала документ превращается в иерархию, а потом уже индексируется.

Это был первый важный шаг. Мы перестали индексировать «результат парсинга» и начали работать с нормализованной моделью документа.

Почему одного узла оказалось недостаточно

Даже с иерархией retrieval не стал автоматически хорошим.

Сначала мы рассматривали каждый элемент — пункт, подпункт, таблицу — как отдельный блок. Но оказалось, что одного фрагмента часто недостаточно. Он слишком узкий и теряет локальный контекст.

Например, вопрос не «где про эвакуацию», а «какими должны быть минимальные эвакуационные выходы». Семантический поиск может найти релевантный пункт, но для полного ответа нужно:

• увидеть соседний подпункт;
• подтянуть примечание;
• учесть таблицу;
• проверить ссылки на другие документы или пункты.

Retrieval должен возвращать не просто близкий фрагмент, а минимально достаточный контекст.

Мы не стали делать generic chunking по токенам. Вместо этого группировали соседние элементы с общим родителем и уровнем вложенности. Так система понимала, что это логически связанные пункты в одном разделе.

Размер фрагментов мы подбирали экспериментально. Идеального числа нет: слишком маленькие группы теряют смысл, слишком большие — снижают точность. Поэтому лучше использовать структурную группировку с настраиваемым лимитом по размеру.

Эффект был заметен: меньше стало ответов, где модель цеплялась за один «почти правильный» пункт и упускала окружение. В индекс попадали не только атомарные узлы, но и устойчивые смысловые блоки.

Почему семантического поиска оказалось недостаточно

Для свободных вопросов векторный поиск помогает. Но в нормативной сфере пользователи часто спрашивают конкретику:

• покажи пункт 6.2.2;
• найди таблицу 7.1;
• что означает термин «X»;
• где описан параметр Y;
• какие нормы связаны с этим пунктом.

Для этого одного vector search недостаточно. Нужны разные режимы retrieval:

• точечный поиск по номеру пункта;
• поиск по таблице;
• лексический поиск;
• гибридный поиск;
• терминологический поиск;
• поиск по кросс-ссылкам.

Retrieval перестаёт быть одной функцией и превращается в набор специализированных инструментов.

Почему один вопрос может запускать несколько поисков

Система не обязана ограничиваться одним способом поиска. Наоборот, один запрос может содержать несколько намерений:

• упоминание конкретного пункта;
• ссылка на таблицу;
• часть запроса в свободной форме;
• использование термина, требующего проверки в терминологическом слое.

В этом случае retrieval может:

• выполнить точечный поиск по пункту;
• параллельно проверить таблицу;
• запустить keyword search;
• обратиться к терминологическому слою;
• объединить результаты в единый контекст.

Это делает поисковый агент: он распознаёт намерения, приоритизирует их, запускает несколько поисков и собирает результаты.

Эта композиция резко повышает шанс найти не просто «что-то похожее», а действительно полезную комбинацию источников.

Зачем понадобился слой терминов

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

Мы добавили отдельную обработку терминов:

• извлекаем термины из документа;
• привязываем к каждому определение;
• индексируем термины отдельно;
• используем их как дополнительный сигнал в retrieval.

Это особенно важно, когда пользователь спрашивает не по номеру пункта, а по понятию из предметной области.

Момент, когда стало ясно, что без графа не обойтись

Даже иерархия и термины не решили всех проблем.

Некоторые ответы зависят от жёсткой цепочки связей. Например:

• пункт требует учёта другого пункта;
• ссылка на внешний документ;
• таблица актуальна только с описывающим её разделом;
• ограничение находится не в основном тезисе.

Семантический поиск может найти основной фрагмент, но не гарантирует подтягивание обязательного контекста. Иногда он слишком далёк по смыслу, чтобы попасть в top-k. Иногда формально не релевантен, но без него ответ ошибочен.

Поэтому нам понадобился граф связей.

В нём у узлов есть отношения:

• mandatory — узел обязательно учитывается вместе с другим;
• cross — кросс-ссылка на другой фрагмент или документ;
• связи документ → узел;
• связи узел → таблица;
• связи между документами.

Эти связи участвуют в retrieval. Если найден релевантный узел, система проверяет, нужно ли принудительно подтянуть связанные элементы.

В этот момент система перестаёт быть «чатом поверх документов» и становится инженерным инструментом.

Что это изменило на практике

Главное изменение — не в «умности» ответов, а в их устойчивости.

Система стала лучше справляться с задачами, где нужно:

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

Для нормативных документов это важнее, чем «красивая» генерация. Даже убедительный ответ без обязательного контекста — плохой ответ.

Что мы из этого вынесли

Главный урок: в сложных документных доменах качество определяется не моделью и не промптом, а представлением данных.

В нашем случае это означало:

• документ нельзя рассматривать как плоский текст — нужна адресуемая структура;
• chunking должен учитывать смысловую иерархию, а не только длину;
• retrieval должен быть многослойным: vector search полезен, но не заменяет точечный поиск, лексические сигналы, термины, связи и композицию стратегий;
• обязательные связанные нормы должны быть выражены в данных явно — нельзя надеяться, что модель «сама догадается».

Мы начинали с идеи «построим RAG по документам». Но стало ясно: для нормативки этого недостаточно.

Чтобы система работала, пришлось пройти несколько этапов:

• от плоских фрагментов к иерархическим узлам;
• от одиночных чанков к структурным группам;
• от одного векторного поиска к гибридному retrieval;
• от простого индекса к терминологическому слою;
• от «похожего текста» к графу обязательных и кросс-ссылок.

В какой-то момент это перестаёт быть «LLM поверх базы» и становится полноценной инженерной системой, где retrieval — не вспомогательная деталь, а ядро качества.

Именно это, как нам кажется, и отделяет демонстрационный RAG от рабочего инструмента по нормативным документам.

Когда говорят про RAG, обычно имеют в виду довольно прямую схему: взять документы, нарезать их на фрагменты, посчитать эмбеддинги, сложить всё в векторную базу и поверх этого подключить LLM. На демо это часто работает. Иногда работает и на корпоративных данных. Но на нормативных документах такой подход очень быстро начинает сыпаться.

Мы увидели это на практике, когда строили систему для работы с нормативкой. Сначала задача выглядела стандартно: есть документы, есть вопросы пользователей, есть поиск по смыслу. Значит, нужен обычный RAG. Но довольно быстро стало ясно, что главная проблема здесь не генерация. Главная проблема в том, как представить документ так, чтобы retrieval не разрушал его структуру и смысл.

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

• Нормативные документы плохо ложатся в модель «плоский набор чанков».
• Слишком маленькие фрагменты теряют контекст, слишком большие дают шумный retrieval.
• Одного семантического поиска недостаточно: нужны точечный поиск по пунктам, работа с таблицами, терминами и кросс-ссылками.
• Для одного пользовательского вопроса система может запускать несколько разных поисков и потом объединять результаты.
• Если найден пункт, этого часто мало: в ответ нужно подтянуть ещё и обязательные связанные нормы.
• Поэтому документ пришлось моделировать не как текст, а как иерархический граф узлов и связей.

Где ломается обычный RAG

На старте мы шли по привычному пути. Документ разбивается на элементы, каждый элемент становится отдельной единицей хранения, дальше поверх этого строится векторный поиск.

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

Проблема выглядела так:

• пользователь задаёт вопрос по конкретному требованию;
• semantic search находит похожий по формулировке пункт;
• но рядом есть подпункт, примечание или ссылка на другой документ, без которых ответ уже не совсем корректен;
• модель видит только один «подходящий» кусок текста и строит ответ так, будто этого достаточно.

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

Именно в этот момент стало ясно: проблема не в том, что модель «недоумна». Проблема в том, что документ представлен слишком плоско.

Первый поворот: документ перестал быть просто текстом

Вместо «документ = длинная строка» мы начали строить структурную модель. Базовая идея была такой: документ состоит не из абзацев, а из адресуемых элементов.

В нашей модели появились:

• документ как корневая сущность;
• узлы документа: разделы, пункты, подпункты;
• таблицы как отдельные элементы;
• формулы как отдельные элементы;
• связи между узлами;
• термины и их определения.

То есть сначала документ превращается в иерархию, и только потом эта иерархия индексируется.

Внутри проекта это выглядит примерно так:

Это был первый важный поворот. Мы перестали индексировать «что получилось после парсинга» и начали индексировать нормализованную модель документа.

Почему одного узла оказалось недостаточно

Следующая проблема была чуть менее очевидной. Даже если у вас уже есть иерархия, это ещё не означает, что retrieval автоматически станет хорошим.

Сначала мы воспринимали каждый элемент документа как отдельный блок. Например, один пункт, один подпункт, одна таблица. Но выяснилось, что для многих вопросов этого слишком мало. Один фрагмент оказывается слишком узким и теряет локальный контекст.

Характерный пример: пользователь спрашивает не просто «где написано про эвакуацию», а «какими должны быть минимальные эвакуационные выходы». Формально релевантный пункт можно найти семантическим поиском. Но для корректного ответа нередко нужно:

• увидеть соседний подпункт того же раздела;
• подтянуть примечание;
• учесть таблицу;
• проверить, нет ли обязательной ссылки на другой документ или на другой пункт.

То есть retrieval должен приносить не просто близкий фрагмент, а минимально достаточный контекст.

Но не как попало. Важный момент был в том, что мы не делали generic chunking по предложениям или просто по токенам. Мы группировали соседние элементы, у которых общий родитель и общий уровень вложенности. Проще говоря, система понимала, что это не просто несколько строк подряд, а логически родственные пункты внутри одного раздела.

Мы экспериментировали с размером фрагментов и довольно быстро поняли, что одного «идеального» числа нет. Слишком маленькие группы теряют смысл, слишком большие ухудшают точность retrieval. Поэтому вместо жёсткой универсальной нарезки полезнее иметь структурную группировку с ограничением по размеру, которое можно подстраивать под домен и качество документов.

Практический эффект был заметный. Меньше стало ответов, где модель цеплялась за один «почти правильный» пункт и не видела его окружение. А в индекс начали попадать не только атомарные узлы, но и более устойчивые смысловые блоки.

Почему семантического поиска оказалось недостаточно

Если пользователь задаёт вопрос в свободной форме, векторный поиск действительно помогает. Но в нормативке пользователь часто спрашивает не «смысл в общем», а что-то очень конкретное:

• покажи пункт 6.2.2;
• найди таблицу 7.1;
• что означает такой-то термин;
• где в документе описан конкретный параметр;
• какие связанные нормы нужно учитывать вместе с этим пунктом.

Для таких вопросов одного vector search недостаточно. Нужны разные режимы retrieval:

• точечный поиск по пункту;
• поиск по таблице;
• лексический поиск;
• гибридный поиск;
• терминологический поиск;
• поиск связанных элементов по ссылкам.

Иными словами, retrieval здесь перестаёт быть одной функцией и превращается в набор специализированных инструментов.

Почему один вопрос может запускать несколько поисков

Когда пользователь задаёт вопрос, система не обязана выбирать ровно один способ поиска. Наоборот, в реальном сценарии она может решить, что один и тот же запрос лучше проверить несколькими стратегиями одновременно.

Например, в одном вопросе могут смешиваться сразу несколько намерений:

• пользователь упоминает конкретный пункт;
• одновременно ссылается на таблицу;
• формулирует часть запроса как свободный текст;
• использует термин, который полезно проверить через отдельный терминологический слой.

В этом случае хороший retrieval не должен искусственно сужать задачу до одного запроса. Он может:

• сначала попробовать точечный поиск по пункту;
• параллельно проверить таблицу;
• отдельно сходить в keyword search;
• а затем объединить результаты и передать их в context builder.

Схематично это выглядит так:

В текущей реализации это и делает поисковый агент: он получает набор распознанных намерений, приоритизирует их, выполняет несколько поисковых функций и собирает результаты в единый пул.

Со стороны это может выглядеть как мелочь, но именно такая композиция резко повышает шанс, что система найдёт не просто «что-то похожее», а действительно полезную комбинацию источников.

Зачем понадобился слой терминов

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

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

Поэтому мы добавили отдельную обработку терминов:

• из документа извлекаются термины;
• к каждому термину привязывается определение;
• термины индексируются отдельно;
• retrieval может использовать терминологический слой как дополнительный сигнал.

Это особенно полезно в случаях, когда пользователь спрашивает не номер пункта, а понятие из предметной области.

Момент, когда стало ясно, что без графа не обойтись

Но даже иерархии и терминов оказалось недостаточно.

Проблема была в том, что некоторые ответы зависят не от одного найденного пункта, а от жёсткой цепочки связей. Например:

• найденный пункт требует учитывать ещё один пункт;
• пункт ссылается на другой документ;
• таблица релевантна только вместе с описывающим её разделом;
• ограничение находится не там, где основной тезис.

Семантический поиск может найти основной фрагмент. Но он не гарантирует, что подтянется обязательный связанный контекст. Иногда этот контекст находится слишком далеко по смыслу, чтобы попасть в top-k. Иногда он формально не очень похож на запрос пользователя, но без него ответ будет неполным или даже ошибочным.

Именно поэтому нам понадобился граф связей.

В нём у узлов есть не только положение в иерархии, но и отношения типа:

• mandatory— этот узел нужно обязательно учитывать вместе с другим;
• cross— кросс-ссылка на другой фрагмент или документ;
• связи документ → узел;
• связи узел → таблица;
• связи между документами.

А дальше эти связи уже участвуют в retrieval. Если найден релевантный узел, система не просто радуется попаданию. Она проверяет, не нужно ли принудительно подтянуть ещё связанные элементы.

Вот здесь система и перестаёт быть «чатом поверх документов». Она начинает становиться инженерным инструментом.

Что это изменило на практике

Самое важное изменение было не в том, что ответы стали «более умными». Они стали более устойчивыми.

Система стала лучше справляться с вопросами, где нужно:

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

Для нормативных документов это намного важнее, чем «красота» генерации. Если система уверенно отвечает, но не показывает обязательный контекст — это плохая система, даже если текст звучит убедительно.

Что мы из этого вынесли

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

В нашем случае это означало несколько вещей.

Во-первых, документ нельзя рассматривать как плоский текст. Нужна адресуемая структура.

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

В-третьих, retrieval должен быть многослойным. Vector search полезен, но он не заменяет точечный поиск, lexical-сигналы, термины, связи и композицию нескольких поисковых стратегий на один вопрос.

В-четвёртых, если для правильного ответа нужны обязательные связанные нормы, они должны быть выражены в данных явно. Надеяться, что модель «сама догадается», в таких сценариях нельзя.

Мы начинали как многие: с идеи «построим RAG по документам». Но по мере работы стало ясно, что для нормативки этого недостаточно.

Чтобы система действительно работала, пришлось пройти несколько этапов:

• от плоских кусков текста к иерархическим узлам;
• от одиночных фрагментов к структурным группам;
• от одного поиска по эмбеддингам к гибридному retrieval;
• от просто индекса документов к терминологическому слою;
• от «похожего текста» к графу обязательных и кросс-ссылок.

В какой-то момент это перестаёт быть «LLM поверх базы» и становится полноценной инженерной системой, где retrieval — уже не вспомогательная деталь, а ядро качества.

Именно это, как нам кажется, и отделяет демонстрационный RAG от рабочего инструмента по нормативным документам.