Прибуток:
- Чисельно оцініть розмір блоку, перекривання та семантичні компроміси блокування
- Вибір відповідної стратегії фрагментації для різних типів документів (PDF, таблиця, код, журнал чату)
- Покращте якість пошуку та фільтрації, додавши метадані до кожного блоку
Це найбільш забутий, але найбільш вирішальний крок у RAG: як ви розбиваєте документ. Це називається поділом. Навіть якщо ви надасте той самий документ тій самій моделі, через погане поділ на фрагменти пошук повертає неправильний фрагмент, і модель ніколи не дасть чудової відповіді. У цьому розділі ми розглядаємо стратегії фрагментації, як адаптувати їх відповідно до типу документа та як додати значимі метадані до кожного фрагменту.
Чому ми подрібнюємо?
Є три причини. По-перше, моделі вбудовування перетворюють текст певної довжини на значущий вектор; Якщо цілу 40-сторінкову главу втиснути в один вектор, сенс стає «розмитим». По-друге, ми хочемо надати моделі лише ту частину, яка потрібна як контекст; передавати весь документ дорого і відволікати. По-третє, щоб пошук був точним, одиниця пошуку має бути невеликою та цілеспрямованою.
Таким чином, блок є найменшою одиницею пошуку. Він не повинен бути ні занадто великим, ні занадто маленьким - в самий раз.
Розмір шматка та баланс перекриття
Є два основних параметри: розмір блоку (скільки маркерів/слів буде у фрагменті) і перекриття (частка, яка використовується сусідніми блоками).
Дуже маленькі фрагменти (наприклад, 100 токенів): зосереджені, але відключені від контексту. Він каже «на 14 днів», але що таке 14 днів, залишилося в попередньому реченні. Дуже великі фрагменти (наприклад, 2000 токенів): зберігає контекст, але змішується багато потоків; вбудовування заплутується, і нерелевантні теми об’єднуються.
Перекриття вирішує граничну проблему. Якщо речення потрапляє точно на межу двох частин, воно ділиться на дві без накладення і втрачає сенс. Перекриття 50-100 токенів гарантує, що інформація, яка потрапляє в ліміт, залишається недоторканою принаймні в одній частині.
Розмір шматка
Перевага
Недолік
відповідний зміст
Малий (100-250 жетонів)
Висока чутливість, цілеспрямованість
Контекст може порушитися
FAQ, короткі статті, визначення
Середній (300-600 жетонів)
Баланс; більшість сценаріїв
—
Процедури, тексти політики
Великий (800-1500 жетонів)
Цілісність контексту
розмите вбудовування
Розповідь, довгі пояснення
Порада: якщо ви не знаєте, з чого почати, почніть з блоку 400-500 токенів і 50-80 перекриття токенів; потім виміряйте та відкоригуйте власні дані. «Правильний» розмір не є універсальним, він залежить від контексту.
Стратегії чанкінгу
Фіксований розмір: обрізає текст кожні N маркерів. Це просто і швидко, але можна переривати на середині речення.
На основі роздільників (рекурсивний/роздільник): Розділяє відповідно до меж абзацу, а потім речення; Це краще зберігає цілісність сенсу. Більшість виробничих систем починаються з цього.
Семантичне поділ: аналізує вкладення речень і розділяє їх там, де відбувається зміна теми. Це найякісніший, але найдорожчий метод; При великих обсягах транзакційні витрати зростають.
З урахуванням структури: використовує структуру документа, наприклад заголовки, розділи, таблиці. Наприклад, розділення документа Markdown за заголовками гарантує, що кожна частина має свій власний заголовок.
Адаптація за типом документа
Не кожен документ однаковий. Стратегія залежить від типу:
- PDF/текст політики: на основі закладок, середнього розміру. Очистити верхню/нижню частину сторінки (верхній/нижній колонтитул).
- Таблиці: не виривайте рядок із контексту; зберігайте кожен рядок із інформацією заголовка ("Пункт: X, Ціна: Y, Акція: Z"). Перетворення необробленої таблиці на звичайний текст часто є важливим.
- Код: розділити за межами функції/класу; Не вирізайте функцію зі шляху.
- Запис чату/квитка: розділити за раундом повідомлення або розмови; Зберігайте знання про те, хто що сказав.
# блокування на основі дужок (концептуальні) chunks = bol( text, target_size=450, # token overlap=70, # token brackets=["\n\n", "\n", ". ", " "] # перший абзац, останнє слово)
Додайте метадані до кожного треку
Чанкінг – це не просто «розподілити»; полягає в тому, щоб збагатити кожну частину. Кожен тег, який ви додаєте до треку, на вагу золота для майбутнього фільтрування та посилання на джерело.
# Enriched chunk (conceptual){ "text": "Щорічна оплачувана відпустка становить 14 днів із 1-5 роками служби...", "metadata": { "source": "ik_el_kitabi_v7.pdf", "section": "5.2 Щорічна відпустка", "page": 23, "date": "2025-06", "department": "IK", "privacy": "внутрішній" }}
Інший потужний прийом — додавання контекстного заголовка: написання назви розділу, до якого він належить, на початку кожного твору. Таким чином, навіть такий роз’єднаний твір, як «На 14 днів», і краще вписується, і має більше значення, ніж «Щорічна відпустка – 14 днів».
Слабке чанкінг / сильне чанкінг
Слабкий (сліпа жорстка версія, без метаданих):
Скорочувати текст кожні 1000 символів. Зберігати лише текст.# Результат: таблиці розділені посередині, «14 днів» залишається без контексту,# невідомо, з якого документа воно взято, не можна зробити фільтр.
Потужний (з урахуванням структури + заголовок + метадані):
Розбити документ за заголовками; додайте назву розділу до кожної частини; додайте джерело, сторінку, дату та метадані конфіденційності; перетворювати рядки таблиці на звичайний текст із їхніми заголовками.# Результат: сфокусований, контекстний, з можливістю фільтрації, джерелами.
Три міні-чохли
Кейс 1 — Фарбування. Команда фінансів розділила 200-сторінковий прайс-лист за допомогою сліпого жорсткого різання; рядки таблиці були розділені випадковим чином. "Яка ціна товару X?" Модель прочитала неправильний рядок і вказала неправильну ціну (9 з 12 випадків неправильні). Коли я перетворив рядки таблиці на звичайний текст у форматі "Продукт: … | Ціна: … | Одиниця: …", помилка зменшилася до 0 із 12.
Випадок 2 — Надзвичайно великий шматок. У вікі кожна сторінка складається з однієї частини (дехто каже, що 3000 токенів). Вбудовування розмите, оскільки на одній сторінці є «відпустка», «понаднормові» та «нарахування заробітної плати»; Розділ про робочі години також став важливим для питання про відпустку. Коли сторінки були розділені на частини середнього розміру за назвою, recall@5 збільшився з 64% до 91%.
Випадок 3 — скорочене речення без накладання. 250 токенів виправлено для команди юристів, без перекриття. Критичне визначення впало прямо на межу двох частин і розкололося надвоє; Ні те, ні інше не містить повної відповіді. Коли було додано перекриття 60 токенів, те саме визначення залишилося незмінним і була повернута правильна відповідь.
Поширені помилки
- Сліпий фіксований розріз: Розділяє речення та таблиці посередині; сенс втрачається.
- Залишення перекриття на нульовому рівні: інформація, яка потрапляє на межу, розділяється та втрачається.
- Недодавання метаданих: фільтрація та відображення джерела стають неможливими.
- Залишення таблиць необробленими: модель не може вирішити структуру таблиці; Перетворення рядків на звичайний текст.
- Накладення однієї стратегії: PDF, код і таблиця не розділяються одним методом; Адаптація до жанру.
Застереження: не встановлюйте Chunking один раз і не забудьте. Повторно вимірюйте якість пошуку, коли надходять нові типи документів (квитки з нової системи, відскановані PDF-файли). Погані вхідні дані означають погану відповідь ("сміття входить, сміття виходить").
Підсумовуючи
- Чанк — найменша одиниця пошуку; Ні занадто великий, ні занадто малий – він повинен бути збалансований відповідно до вмісту.
- Розмір фрагмента вказує на баланс фокус-контекст; Перекриття керує втратою меж.
- Розбиття на фрагменти на основі дужок і з урахуванням структури є відправною точкою більшості систем генерації; семантичне фрагментування якісне, але дороге.
- Такі типи, як table, script і chat, вимагають власних стратегій; Перетворення таблиць у звичайний текст.
- Додайте метадані джерела/дати/розділу/конфіденційності та назву розділу до кожної доріжки; Це основа фільтрації та цитування.
Аплікаційне завдання
Розбийте вибраний вами розділ документа трьома різними способами: (1) маленькі частини по 200 токенів, (2) середні частини по 500 токенів (70 токенів перекриваються), (3) окремі великі частини. Поставте ті самі 3 запитання для кожної стратегії, вручну позначте, який фрагмент додати, і запишіть міркування, яка стратегія найкраще підходить для цього документа. Потім додайте принаймні чотири поля метаданих і «заголовок розділу» до кожного треку. Якщо документ містить таблицю, перетворіть рядок таблиці на звичайний текст у форматі «поле:значення».
контрольний список
- [ ] Я можу сказати, що блок — це найменша одиниця пошуку, а розмір — це баланс фокус-контекст.
- [ ] Я знаю, чому Overlap запобігає втраті меж.
- [ ] Я можу розрізняти блокування на основі дужок, семантичне та з урахуванням структури.
- [ ] Я можу адаптувати стратегію для столу, коду та чату.
- [ ] Я посилю пошук, додаючи метадані та назву розділу до кожного треку.