Печалби:
- Числено оценявайте размера на парчетата, припокриването и семантичните компромиси при групирането
- Избор на подходяща стратегия за групиране за различни типове документи (PDF, таблица, код, дневник на чат)
- Подобрете качеството на извличане и филтрирането чрез добавяне на метаданни към всяка част
Това е най-пренебрегваната, но най-решаваща стъпка в RAG: как разбивате документа. Това се нарича накъсване. Дори ако дадете един и същ документ на един и същ модел, поради лошо разбиване на части извличането връща грешната част и моделът никога няма да даде страхотен отговор. В тази част разглеждаме стратегиите за фрагментиране, как да ги адаптираме според типа документ и как да добавяме значими метаданни към всеки фрагмент.
Защо раздробяваме?
Причините са три. Първо, моделите за вграждане преобразуват текст до определена дължина в смислен вектор; Ако цяла глава от 40 страници е натъпкана в един вектор, значението става „размито“. Второ, искаме да дадем на модела само частта, която е необходима като контекст; предаването на целия документ е скъпо и разсейващо. Трето, за да бъде извличането прецизно, търсещата единица трябва да е малка и фокусирана.
Така че парчето е най-малката единица за извличане. Не трябва да е твърде голямо или твърде малко – точно както трябва.
Размер на парчета и баланс на припокриване
Има две основни настройки: размер на парчето (колко токени/думи ще има в парче) и припокриване (частта, споделена от съседни парчета).
Много малки парчета (напр. 100 токена): фокусирани, но отделени от контекста. Той казва "за 14 дни", но какво са 14 дни, е останало в предното изречение. Много големи парчета (напр. 2000 токена): запазва контекста, но много нишки са смесени; вграждането се обърква и неуместни теми се събират.
Припокриването решава проблема с границите. Ако едно изречение попадне точно на границата на две части, то се разделя на две без застъпване и смисълът му се губи. Припокриването на 50-100 токена гарантира, че информацията, попадаща в лимита, остава непокътната поне в една част.
Размер на парчето
Предимство
Недостатък
подходящо съдържание
Малък (100-250 токена)
Висока чувствителност, фокусиран
Контекстът може да се счупи
ЧЗВ, кратки статии, дефиниции
Среден (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", ". ", " "] # първи параграф, последна дума)
Добавете метаданни към всяка песен
Разкъсването не е просто "разделяне"; е да обогатите всяко парче. Всеки таг, който прикрепите към песента, струва теглото си в злато за бъдещо филтриране и цитиране на източник.
# Обогатена част (концептуална){ "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 — Изключително голямо парче. В wiki всяка страница е направена от едно парче (някои казват 3000 токена). Вграждането е размазано, защото на една страница има "отпуск", "извънреден труд" и "заплата"; Разделът за работното време също влезе в действие по отношение на въпроса за отпуска. Когато страниците бяха разделени на среден размер по заглавие, recall@5 се увеличи от 64% на 91%.
Случай 3 — Скъсено изречение без припокриване. 250 токена фиксирано изрязване за правен екип, без припокриване. Една критична дефиниция падна точно на границата на две части и се раздели на две; Нито едното, нито другото съдържат пълния отговор. Когато беше добавено припокриване на 60 токена, същата дефиниция остана непокътната в едно цяло и се върна правилният отговор.
Често срещани грешки
- Сляпо фиксирано изрязване: Разделя изречения и таблици по средата; смисълът се губи.
- Оставяне на припокриването на нула: Информацията, която попада на границата, се разделя и губи.
- Без добавяне на метаданни: Филтрирането и показването на източника стават невъзможни.
- Оставяне на таблиците необработени: Моделът не може да разреши структурата на таблицата; Преобразуване на редове в обикновен текст.
- Налагане на една стратегия: PDF, код и таблица не се разделят по един и същ метод; Адаптиране към жанра.
Внимание: Не задавайте Chunking веднъж и го забравете. Измерете отново качеството на извличане при пристигането на нови типове документи (билети от нова система, сканирани PDF файлове). Лошите входни данни означават лош отговор („боклук вътре, боклук вън“).
В обобщение
- Чънкът е най-малката единица за извличане; Нито много голям, нито твърде малък – трябва да е балансиран според съдържанието.
- Размерът на парчето показва баланса фокус-контекст; Припокриването управлява загубата на граници.
- Базираното на скоби и съобразено със структурата разчленяване е отправната точка на повечето системи за генериране; семантичното разделяне е добро качество, но скъпо.
- Типове като маса, скрипт и чат изискват свои собствени стратегии; Преобразувайте таблици в обикновен текст.
- Добавяне на източник/дата/глава/метаданни за поверителност и заглавие на раздел към всяка песен; Това е основата на филтрирането и цитирането.
Задача за приложение
Разделете избрания от вас раздел на документа на три различни начина: (1) малки части от 200 жетона, (2) средни части от 500 жетона (70 жетона се припокриват), (3) единични големи парчета. Задайте едни и същи 3 въпроса за всяка стратегия, маркирайте ръчно коя част да внесете и запишете мотивите коя стратегия работи най-добре за този документ. След това добавете поне четири полета с метаданни и „заглавие на глава“ към всяка песен. Ако документът съдържа таблица, преобразувайте ред от таблица в обикновен текст във формат „поле:стойност“.
контролен списък
- [ ] Мога да кажа, че парчето е най-малката единица за извличане, а размерът е балансът фокус-контекст.
- [ ] Знам защо припокриването предотвратява загубата на граници.
- [ ] Мога да правя разлика между базирано на скоби, семантично и съобразено със структурата разкъсване.
- [ ] Мога да адаптирам стратегията за маса, код и чат.
- [ ] Подсилвам извличането, като добавям метаданни и заглавие на глава към всяка песен.