TL;DR
Исследование показало, что предварительное структурирование документа с метаданными улучшает точность ответов LLM на 9-12% по сравнению с прямой загрузкой текста. Суть: перед тем как задавать вопросы по большому документу, попроси LLM создать структурированный индекс, где для каждой секции указан тип контента (процедура/концепция/справка), ключевые слова, краткий summary и какие вопросы этот раздел отвечает. Потом используй этот индекс для поиска нужных частей.
LLM хуже ищет информацию в больших документах при прямых вопросах — модель видит текст как единый поток без понимания структуры. При вопросе "как настроить X" может выдать теоретическое описание вместо пошаговой инструкции, потому что не различает где процедуры, а где концепции. В документации на 6000+ страниц модель "теряется в середине", пропуская релевантные части.
Решение — трёхслойное структурирование: для каждой секции документа LLM генерирует (1) метаданные контента (тип раздела, ключевые термины, есть ли код/примеры), (2) технические метки (категории, упомянутые сервисы/инструменты), (3) семантические аннотации (краткое содержание, потенциальные вопросы пользователя). Этот индекс становится "картой местности" — при вопросе модель сначала смотрит в индекс, находит релевантные секции, потом даёт ответ. Исследование на документации AWS S3 показало: рекурсивная разбивка по структуре документа + метаданные дают 82.5% точность против 73.3% без структурирования.
Схема применения
ШАГ 1: Создание индекса
→ LLM читает документ и создаёт таблицу метаданных
ШАГ 2: Ответы на вопросы
→ LLM использует индекс для поиска релевантных секций
→ Даёт ответ на основе найденных частей
Оба шага в одном чате, но индекс создаётся один раз в начале работы с документом.
Пример применения
⚠️ Ограничение метода: Эффект заметен на больших технических документах (100+ страниц) с разнородным контентом. На коротких текстах (до 20 страниц) или художественных текстах разница незначительна.
Задача: Ты получил 150-страничную документацию по корпоративной CRM-системе (инструкции, API reference, примеры интеграций, FAQ) и тебе нужно быстро находить ответы для команды: как настроить, где API метод, что делать при ошибке.
Промпт:
Прочитай эту документацию и создай структурированный индекс в виде таблицы:
Для каждого раздела укажи:
1. Номер и название раздела
2. Тип контента: Процедура (как сделать) / Концепция (что это) / Справка (параметры, API) / Пример / Решение проблемы
3. Ключевые термины (5-7 слов)
4. Краткое содержание (1-2 предложения)
5. Какие вопросы пользователя отвечает этот раздел (2-3 типичных вопроса)
После создания индекса я буду задавать вопросы. Используй индекс чтобы быстро находить релевантные разделы, потом давай точный ответ со ссылкой на номер раздела.
[вставить документацию]
Результат:
Модель создаст таблицу с метаданными для каждой секции документа. При последующих вопросах ты увидишь: модель сначала называет релевантные разделы из индекса ("раздел 4.2 Настройка веб-хуков, тип: Процедура"), потом даёт конкретный ответ на основе этих секций. Вместо общего пересказа всей документации — точное попадание в нужную часть.
Почему это работает
Слабость LLM: При работе с большими документами модель не видит внутреннюю структуру текста. Для неё 150 страниц — это последовательность токенов без явного разделения на типы контента. При вопросе "как настроить X" модель может начать отвечать с теоретического описания, потому что оно идёт первым в тексте, хотя практическая инструкция есть дальше. "Lost in the Middle" эффект — модель хуже всего находит информацию в средней части длинного контекста, фокусируясь на начале и конце.
Сильная сторона LLM: Модель отлично работает со структурированными данными и может создавать метаданные, которые потом сама использует для навигации. Когда есть явная карта документа с типами секций и ключевыми словами, модель может быстро определить где искать ответ — не перебирая весь текст, а просматривая индекс.
Как метод использует сильную сторону: Явный индекс с метаданными превращает аморфный текст в структурированную базу знаний. Модель сначала смотрит в индекс (компактный, легко просканировать), определяет релевантные секции по типу контента и ключевым словам, потом фокусируется только на этих частях. Это как оглавление книги — вместо чтения всех глав ищешь по названиям.
Рычаги управления:
- Детальность индекса → уменьши количество полей метаданных для простых документов (оставь только тип контента + краткое содержание), сэкономишь токены
- Типы контента → адаптируй под свой домен: для бизнес-документов добавь "Стратегия/Тактика/Данные", для учебных материалов "Теория/Практика/Тест"
- "Потенциальные вопросы" → замени на "Для кого этот раздел" (роли пользователей), если документ для разных команд
- Частота обновления индекса → пересоздавай индекс если документ изменился больше чем на 20%, иначе используй старый
Шаблон промпта
Прочитай документ и создай структурированный индекс:
Для каждого раздела/секции укажи:
1. Идентификатор: {номер или название раздела}
2. Тип контента: {типы релевантные твоему домену}
Примеры типов:
- Техдокументация: Процедура / Концепция / API Reference / Пример / Troubleshooting
- Бизнес-документ: Стратегия / Тактика / Данные / Процесс / Решение
- Учебный материал: Теория / Практика / Кейс / Проверка знаний
3. Ключевые термины: {5-7 главных слов/фраз из раздела}
4. Краткое содержание: {1-2 предложения — ЧТО в разделе}
5. Отвечает на вопросы: {2-3 типичных вопроса пользователя}
Выведи в виде таблицы или структурированного списка.
После создания индекса я буду задавать вопросы. Алгоритм ответа:
1. Просмотри индекс — найди релевантные разделы по типу контента, ключевым словам и вопросам
2. Назови номера найденных разделов
3. Дай ответ на основе этих секций со ссылками на разделы
{твой_документ}
Что подставлять:
- {типы релевантные твоему домену} — выбери или придумай типы контента для своих документов, примеры в шаблоне
- {твой_документ} — вставь текст документа или загрузи файл в чат
🚀 Быстрый старт — вставь в чат:
Вот шаблон для структурирования документа с метаданными. Адаптируй под мой документ: [опиши тип документа и зачем он нужен].
Задавай вопросы чтобы правильно определить типы контента и структуру индекса.
[вставить шаблон выше]
LLM спросит какой у тебя документ (техдокументация, бизнес-процессы, учебный материал) и предложит подходящие типы контента для индекса. Модель возьмёт паттерн из шаблона и адаптирует под специфику твоего документа — тебе не нужно разбираться в структуре вручную.
Ограничения
⚠️ Размер документа: Эффект заметен на больших документах (100+ страниц, 30,000+ токенов). На коротких текстах (до 20 страниц) создание индекса съедает токены без значительного выигрыша в точности — модель и так видит весь контекст.
⚠️ Тип контента: Работает для технической документации, бизнес-процессов, справочных материалов где есть разнородные типы информации (инструкции + концепции + примеры). Для художественных текстов или нарративов метод неэффективен — там важна последовательность повествования, не типы секций.
⚠️ Токены: Создание индекса требует дополнительного прохода по документу и занимает 10-15% от объёма оригинального текста. Для очень больших документов (200+ страниц) может потребоваться разбить на части и создавать индекс частями.
⚠️ Динамические документы: Если документ часто обновляется, индекс устаревает. Нужно пересоздавать индекс при изменениях больше ~20% контента, что добавляет накладные расходы.
Как исследовали
Исследователи из University of Illinois Chicago взяли документацию AWS S3 (6,287 страниц: User Guide, API Reference, Glacier, Outposts) — реальный пример сложной технической документации с разными типами контента. Задача: проверить, как добавление метаданных влияет на точность поиска ответов.
Дизайн эксперимента: Сравнили три способа разбивки документа на части: 1. Naive chunking — фиксированные куски по 1024 токена (режем где попало) 2. Recursive chunking — рекурсивная разбивка по структуре: сначала по параграфам, потом по предложениям, сохраняя контекст 3. Semantic chunking — группировка по смыслу через векторные embeddings (умная кластеризация)
Для каждой стратегии разбивки протестировали три способа использования метаданных:
- Content-only (baseline) — только текст секции
- TF-IDF weighted — комбинация текста (70%) и метаданных (30%) с весами по частоте терминов
- Prefix-fusion — метаданные как префикс перед текстом секции
Получилось 9 конфигураций (3×3 матрица). На каждой прогнали тестовый набор технических вопросов, измерили точность через Hit Rate@10 (нашли ли релевантную секцию в топ-10), MRR (на какой позиции первый правильный ответ), NDCG (качество ранжирования), Precision (доля правильных в топ-10).
Неожиданный результат: Самая "умная" семантическая разбивка проиграла простым методам! Naive chunking + TF-IDF дал лучший Hit Rate (92.5%), а recursive chunking + TF-IDF — лучшую точность (82.5% vs 73.3% у content-only semantic).
Почему так получилось: Semantic chunking создал слишком много мелких кусков (5,706 против 4,099 у recursive), размыв контекст. Recursive chunking нашёл золотую середину — сохранил структуру документа (заголовки, параграфы), но не усложнял. Добавление метаданных через TF-IDF weights работает лучше чем prefix-fusion, потому что взвешивает важность терминов, а не просто склеивает текст.
Инсайт для практики: Не усложняй разбивку документа. Простая структурная разбивка (по заголовкам, параграфам, разделам) + явные метаданные (тип контента, ключевые слова) работают лучше чем умные семантические алгоритмы. Важнее не КАК разбить, а ЧТО добавить к каждой части.
Ресурсы
A Systematic Framework for Enterprise Knowledge Retrieval: Leveraging LLM-Generated Metadata to Enhance RAG Systems _Pranav Pushkar Mishra, Kranti Prakash Yeole, Ramyashree Keshavamurthy, Mokshit Bharat Surana, Fatemeh Sarayloo_ University of Illinois Chicago, 2024
Исследование ссылается на: - RAG fundamentals (Lewis et al., 2020) - Dense embeddings для поиска (Karpukhin et al.) - FAIRMetaText framework (Sundaram & Musen) — выравнивание метаданных с онтологиями через GPT - Snowflake Arctic-Embed model — embedding модель для технической документации