Як готувати дані для RAG: чанкінг і очищення

Якість RAG-застосунку на 80% визначається не моделлю, а тим, як підготовлені дані. Найкраща LLM дасть слабкі відповіді, якщо їй підсунути погано нарізаний і брудний текст. Розберемо, як готувати дані правильно.

Чому підготовка даних вирішує все

RAG працює так: система знаходить релевантні фрагменти з ваших документів і передає їх моделі як контекст. Якщо фрагменти нерелевантні, обрізані посеред думки чи засмічені — модель отримає погану основу й дасть погану відповідь. Тому підготовка даних — не рутина, а ключовий етап.

Що таке чанкінг

Документи не можна передавати моделі цілком — вони завеликі. Їх розбивають на фрагменти (chunks), кожен з яких перетворюється на ембединг і зберігається. Питання «як саме різати» — центральне. Занадто великі чанки розмивають зміст і містять зайве; занадто малі — втрачають контекст і сенс.

Як обрати розмір фрагментів

Універсального числа немає, але є орієнтири. Занадто дрібно (окремі речення) — фрагмент втрачає контекст; занадто велико (цілі розділи) — у нього потрапляє багато нерелевантного. Розумний старт — фрагменти в кілька абзаців, розбиті за логічними межами (заголовки, розділи), а не механічно за кількістю символів. Розбивайте за змістом, а не посеред речення.

Перекриття фрагментів

Корисний прийом — робити фрагменти з невеликим перекриттям (overlap): кінець одного чанка частково повторюється на початку наступного. Це запобігає втраті думки, яка опинилася на межі двох фрагментів. Помірне перекриття суттєво покращує якість пошуку.

Очищення тексту

Перед чанкінгом текст варто очистити: прибрати навігаційні елементи, повторювані колонтитули, рекламу, службові символи й «сміття» з PDF чи веб-сторінок. Кожен зайвий фрагмент засмічує пошук і знижує релевантність. Також корисно зберігати метадані (джерело, розділ, дату) — вони допомагають фільтрувати й посилатися на джерело у відповіді.

Типові помилки

• Механічна нарізка за символами без урахування змісту.
• Ігнорування структури документа (заголовків, списків, таблиць).
• Брудні дані — весь HTML- чи PDF-шум потрапляє в базу.
• Занадто великі фрагменти, у яких корисне тоне серед зайвого.
• Втрата метаданих, через що неможливо послатися на джерело.

Практичний підхід

Почніть просто: очистіть текст, розбийте за логічними межами з невеликим перекриттям, збережіть метадані — і протестуйте на реальних запитах. Далі ітеруйте: якщо відповіді неточні, найчастіше проблема саме в чанкінгу чи чистоті даних, а не в моделі. Гарні дані — це найдешевший спосіб зробити RAG якісним.