Про GraphRAG, RAG, LLM и «умные базы знаний» сейчас говорят много. Но почти всегда разговор начинается не с того места. Люди обсуждают модели, эмбеддинги, графы, вектора — и напрочь забывают про самое важное. Про документы.
А потом начинается классика:
модель отвечает криво, путает разделы, не находит очевидные вещи, выдумывает. И виноват, конечно, GraphRAG, RAG или «эта ваша нейросеть».
Спойлер: в большинстве случаев проблема вообще не в них.
RAG ломается не на моделях, а на входных данных
RAG — это не магия. Он не понимает документы так, как человек. Он работает с текстом, структурой и связями. Если на входе мусор, то на выходе будет умный, уверенный, но всё равно мусор.
Самая частая ошибка — пытаться кормить RAG чем угодно: PDF из сканов, инструкции, где половина смысла на скриншотах, документы без заголовков, где всё просто «абзацами».
GraphRAG сверху только усиливает эту проблему: если связи построены на кривом тексте, граф получится красивый, но бесполезный.
Шаг 1. Привести всё к нормальному формату — Markdown
Первое, что стоит сделать — перевести документы в Markdown.
Почему именно md:
- простой текст, без скрытых стилей
- понятная иерархия заголовков
- легко резать, анализировать и обрабатывать
- идеально ложится в пайплайн RAG
Чем переводить:
- если есть исходный DOCX — MarkItDown от Microsoft
- если DOCX нет, но PDF текстовый — Docling
- если PDF скан — сначала OCR, потом уже конвертация
Важно понимать одну вещь:
PDF почти всегда хуже DOCX. Даже если кажется, что «текст есть». Конвертеры часто теряют структуру, заголовки, смешивают колонтитулы с основным текстом. Поэтому если есть возможность — всегда берите исходники.
Шаг 2. Документ должен быть структурирован, а не просто текстом
Markdown сам по себе ещё не делает документ пригодным для RAG. Ключевое — структура.
Что должно быть:
- заголовки уровней
- разделы и подразделы
- логическая иерархия, а не просто длинное полотно текста
Идеальный документ для RAG — это документ, сделанный для людей:
- нормальные названия разделов
- шаги описаны текстом
- таблицы — таблицами, а не картинками
Если в документе всё выглядит как:
«1. что-то
2. что-то
3. что-то»
но без заголовков — для RAG это почти плоский текст.
Шаг 3. Построить дерево документа
Тут как раз появляется класс инструментов, про которые часто неправильно думают.
Я потестил PageIndex — штука полезная, но важно сразу правильно понимать, что это не RAG и не чат по документам. Он вообще не про ответы, а про структуру: по сути, он разбирает документ и строит иерархию разделов и подразделов.
Из коробки он заточен под OpenAI-совместимый API, но с локальной Ollama тоже можно жить, если эндпоинт совместимый. Очень чувствителен к качеству исходных документов: если инструкция сделана для людей, с нормальными заголовками, логикой и текстовым описанием шагов — всё ок. Если половина информации на скриншотах, а текст — формальность, то он честно вытянет только то, что есть, и дальше начинаются вопросы почему так мало ответов.
Он не делает поиск, не хранит эмбеддинги и сам по себе ни на что не отвечает — это именно подготовительный слой перед RAG. Зато если использовать его правильно, как шаг перед чанкингом и векторизацией, качество RAG заметно растёт. Короче, инструмент не волшебный, но при дисциплинированных документах реально полезный.
Важно: PageIndex не чинит документы. Он лишь показывает, что в них есть.
Шаг 4. Правильный чанкинг — не по токенам, а по смыслу
Одна из самых грубых ошибок — резать текст просто по размеру:
1000 токенов, 2000 токенов, ещё что-нибудь.
Так теряется контекст. Условия отрываются от шагов, определения — от описаний.
Правильный подход:
- сначала структура
- потом чанки строго по разделам и подразделам
- каждый чанк — законченная смысловая единица
Обычно в метаданные чанка стоит класть:
- имя документа
- раздел
- подраздел
- идентификатор узла
И уже эти чанки отправлять в эмбеддинги и в RAG.
Шаг 5. И только потом GraphRAG и умные ответы
GraphRAG начинает работать нормально только тогда, когда:
- документы чистые
- структура ясная
- чанки логичные
- метаданные аккуратные
Иначе он начинает путаться:
- одинаковые сущности из разных инструкций смешиваются
- шаги применяются не к тем документам
- ответы выглядят уверенно, но неверно
Это не баг. Это следствие плохой подготовки.
Итог
Если коротко и честно:
- RAG и GraphRAG не спасают плохие документы
- 70 процентов успеха — это подготовка
- Markdown, структура и осмысленный чанкинг важнее выбора модели
- инструменты вроде PageIndex — это не магия, а увеличительное стекло
- если документы дисциплинированы, RAG начинает реально работать
Хорошая база знаний — это не «подключили LLM»,
а аккуратная работа с текстом ещё до того, как модель вообще увидела данные.
И вот это большинство пропускает.