Индексация документов для RAG (PDF, DOCX, HTML, Markdown)

Индексация документов RAG: где теряется качество ответов

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

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

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

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

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

Что даёт управляемая индексация: эффект в измеримых метриках

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

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

Третий эффект — ушедший класс отказов «ответ не по документу». Каждый ответ несёт ссылку на фрагмент-источник, а при низкой близости система честно сообщает, что данных нет, вместо того чтобы достроить формулировку по догадке. Это снимает самый дорогой сценарий: уверенный ответ по отменённой редакции.

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

Сравнение режимов подготовки: PDF, DOCX, HTML и Markdown

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

Основная цена — сканы. Распознавание даёт текст, но не гарантирует порядок чтения на многоколоночных страницах, поэтому проблемные страницы проверяются вручную и помечаются. Иначе в индекс уходит слипшийся фрагмент, и поиск по нему отвечает неточно. В DOCX и HTML сложность не в извлечении, а в очистке: шаблонная навигация и меню создают дубли.

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

Порядок внедрения: от аудита корпуса до передачи

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

1. Аудит корпуса документов. Считаем форматы и объёмы, ищем дубликаты и расхождения версий, отдельно помечаем сканы без текстового слоя, вложенные таблицы, документы на нескольких языках. Результат — карта корпуса со списком мест, где извлечение текста заведомо потеряет смысл.
2. Схема разбиения на фрагменты. Определяем размер фрагмента и перекрытие между соседними, режем по структуре — заголовкам и разделам, а не по фиксированному числу символов. Цель — чтобы фрагмент был самодостаточным и не разрывал таблицу или список посередине.
3. Метаданные и права доступа. На каждый фрагмент вешаем источник, дату, версию, подразделение и гриф доступа. Права наследуются из исходной системы хранения, поэтому сотрудник видит в выдаче только то, что ему разрешено открыть.
4. Настройка извлечения по форматам. PDF берём по текстовому слою, сканы — через распознавание, DOCX разбираем с учётом таблиц и стилей, HTML и Markdown — по структуре заголовков. Для каждого формата настраиваем свою обработку и проверяем её на выборке.
5. Сборка поискового индекса. Совмещаем поиск по смыслу с полнотекстовым по ключевым словам, артикулам и числам — иначе запросы с точными обозначениями проваливаются. Переиндексация запускается по расписанию и по событию изменения документа.
6. Проверка на эталонных вопросах. Собираем набор вопросов с заранее известными ответами и смотрим, долю найденных источников, полноту и точность выдачи, время ответа. По результатам правим схему разбиения и метаданные, а не «крутим настройки наугад».
7. Передача. Отдаём конфигурацию индексации, регламент переиндексации, набор эталонных вопросов и дашборд качества — чтобы команда заказчика могла проверять индекс после каждого обновления корпуса.

Конфигурации, схемы разбора и регламенты обновления

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

• Рабочие конфигурации индексации. Файлы настроек по каждому типу источника: какие поля документа попадают в индекс, как нарезаются длинные разделы, сколько контекста подклеивается к фрагменту. Конфигурации версионируются — изменение разбора не требует пересборки всей базы.
• Схема источников и потоков данных. Карта: откуда приходит документ, через какой разбор он проходит, куда попадает результат, где хранится исходник. С картой видно, что сломается, если отключится сетевая папка или изменится структура выгрузки.
• Схемы разбора по форматам. Отдельные правила для PDF, DOCX, HTML и Markdown: как вытаскиваются заголовки и таблицы, что делать со сканами и вложенными файлами, какие документы уходят в ручную проверку.
• Регламент обновления базы знаний. Частота переиндексации по каждому источнику, условия полной пересборки против точечного добавления, поведение при удалении документа из источника — устаревшие фрагменты уходят из выдачи вместе с ним.
• Правила доступа и разграничения. Кто из сотрудников видит какие разделы, как права источника переносятся в индекс, что происходит при смене роли пользователя.
• Журнал проверок качества. Набор контрольных вопросов, на которых проверяется выдача после каждого обновления: доля верных попаданий, случаи выдачи документа без прав, потери при разборе таблиц. Прогон воспроизводится по кнопке.
• Документация и передача. Инструкция по переиндексации, порядок отката к предыдущему снимку базы, разбор типовых сбоев и точки, куда смотреть в логах.

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

Кейс: база знаний поддержки до и после пересборки

Что было до пересборки

Поддержка выросла до базы в несколько десятков тысяч документов: регламенты в PDF, инструкции в DOCX, статьи портала в HTML и Markdown. Индексатор резал их фиксированным окном по символам, без оглядки на структуру: заголовок попадал в один фрагмент, таблица условий — в другой, вложение в индекс не попадало вовсе.

Ответы ассистента опирались на устаревшие ревизии и куски соседних разделов: доля ответов по актуальному разделу держалась около 60%, поиск нужного фрагмента занимал до 10 секунд, а каждое пятое обращение оператор закрывал вручную — открывал документ и искал глазами.

Что изменили

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

Через месяц замеров после пересборки:

• доля ответов по актуальному разделу — с 60 до 94%;
• время поиска нужного фрагмента — с 10 до 1,5 секунды;
• обращения с ручным разбором — с 20 до 4%;
• документы с корректно разобранными таблицами — с 55 до 97%.

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

Чем отличается разбиение по структуре от разбиения по смыслу?

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

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

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

Перекрытие фрагментов сглаживает стыки: хвост предыдущего куска дублируется в начале следующего, обычно на 10–20%. Спасает ответы, лежащие на границе, но раздувает индекс и добавляет почти одинаковые результаты — их приходится отсеивать по схожести.

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

Частые технические сомнения перед стартом проекта

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

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

Можно ли обновлять базу без полной пересборки?

Да. Индексация идёт по версиям: пересобираются только изменившиеся документы, остальное берётся из предыдущего индекса. Предыдущая версия сохраняется, поэтому откат к прежнему состоянию поиска занимает минуты, а не сутки.

Как права доступа попадают в результаты поиска?

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

Что делать с противоречивыми документами?

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

Как убедиться, что поиск находит нужное?

Собираем набор контрольных вопросов с эталонными фрагментами и замеряем долю попаданий до и после каждого изменения схемы. Без такого набора любая правка индексации — это правка наугад.

Обсудим задачу: что понадобится для оценки объёма работ

Чтобы вернуться с оценкой объёма корпуса и планом внедрения, доступ ко всей инфраструктуре не нужен — достаточно описать задачу в терминах документов, вопросов и прав. Чем конкретнее исходные данные, тем меньше допущений в оценке и тем раньше стартует пилот на одном разделе: одна тема, живые вопросы сотрудников, проверка качества ответов до масштабирования на весь массив.

• Состав корпуса: сколько файлов и разделов, где они лежат — файловое хранилище, внутренний портал, почтовый архив, база знаний.
• Форматы и их качество: PDF со сканами без текстового слоя, DOCX с отслеживаемыми правками, HTML, Markdown в репозитории. Сканы меняют объём работ — им нужен отдельный шаг распознавания.
• Динамика: сколько документов добавляется за месяц, есть ли устаревшие редакции, которые нельзя показывать в ответах.
• Частые вопросы пользователей: 20–30 реальных формулировок. По ним мы собираем проверочный набор и до внедрения видим, каких данных в корпусе не хватает.
• Текущая схема прав доступа: какие группы что видят. От неё зависит разграничение на уровне фрагментов и то, как индексируются документы с ограничениями.
• Точки возврата ответа: внутренний портал, мессенджер, рабочее место оператора — от этого зависит формат выдачи и ссылок на источник.
• Ограничения: где запрещены внешние сервисы, нужны ли журналы обращений и хранение истории запросов.

Опишите задачу и пришлите то, что уже есть, — вернёмся с оценкой объёма, планом внедрения и предложением по пилотному разделу.