🧩 RAG работает хуже не из-за модели, а из-за того, как вы режете документы
В системах с поиском по базе знаний качество ответа зависит не только от модели. Не менее важно, как именно документ делят на части перед загрузкой в поиск. Если разделить текст неудачно, система найдёт только половину ответа — и ошибётся даже при хорошей модели.
📚 Речь о так называемом семантическом разбиении. Это подход, при котором текст делят не по фиксированной длине, а по смыслу: где заканчивается одна тема и начинается другая. Например, короткое определение можно оставить в одном небольшом фрагменте, а длинное объяснение процесса — сохранить целиком.
Хороший фрагмент должен быть понятен сам по себе и содержать достаточно контекста для ответа.
⚖️ У каждого способа есть свои плюсы и минусы. Фиксированное разбиение быстрое и простое, но легко ломает абзацы и мысли пополам. Разбиение по структуре документа лучше подходит для справки по API, базы знаний и инструкций. А семантическое разбиение особенно полезно для неструктурированных текстов, но требует больше вычислений и усложняет настройку.
Авторы отдельно подчёркивают: не стоит искать «идеальный размер» фрагмента. Универсального числа нет. Важнее другое — может ли найденный кусок текста сам по себе ответить на вопрос пользователя без потери важных деталей.
Разбиение — это не подготовительный этап “один раз и навсегда”, а часть архитектуры поиска.
🛠 n8n предлагает собирать такие цепочки визуально: загружать документы из разных источников, направлять разные типы файлов в разные блоки разбиения, сохранять векторные представления текста и смотреть историю выполнения. Это позволяет проверять, какие границы фрагментов реально улучшают поиск, а какие только добавляют сложность.
При этом даже исследователи спорят, всегда ли сложное семантическое разбиение оправдано. Для структурированных документов простые подходы нередко дают почти такой же результат. Поэтому лучший совет — начинать с базового варианта, тестировать на реальных запросах и улучшать по мере необходимости.
🎯 Почему это важно: при запуске помощников на документах, внутренних баз знаний и службах поддержки ошибка часто кроется не в модели, а в структуре данных. Для бизнеса это значит меньше неточных ответов, ниже расходы на обработку текста и более предсказуемый результат.
