Стратегії чанкінгу для практичного використання в RAG: фіксований розмір, семантичний підхід та структура батьків-дітей.

Припустимо, співробітник, який обробляє заяви в страховій компанії, запитує внутрішнього асистента: яку затверджувальну процедуру потребує заява на відшкодування збитків від води на суму 40 000 євро, і що потрібно перевірити перед тим, як її оплатити? Асистент керується чинним посібником з обробки заяв. Файли були правильно завантажені, OCR функціонував належним чином, попередня обробка усунула шум, модель ембеддингу знайшла потрібний посібник, а алгоритм ранжування розмістив його близько до верхньої частини списку.

Відповідь все одно надходить неповною.

Досвідчений аджустер не здивується. Це правило не міститься в одному абзаці. У розповідному реченні зазначено, що для заявок, пов’язаних із підозрою на попередні пошкодження, перед виплатою необхідна незалежна перевірка. Під цим реченням наведена таблиця повноважень. На наступній сторінці є діаграма, яка показує, що спочатку також мають бути завершені перевірка на шахрайство та підтвердження права власності. Система документів додає ідентифікатор посібника, його версію та регіон, до якого він застосовується.

Для спеціаліста, який працює з цими документами, це не чотири окремі факти. Це одне бізнес-правило, викладене у чотирьох різних форматах: абзац визначає умову, таблиця — тих, хто може схвалити заявку, діаграма — порядок перевірок, а метадані — яка версія є чинною.

Стандартний розділювач, налаштований на 500 токенів, може помістити абзац у один фрагмент, верхню половину таблиці — у другий, відповідний рядок таблиці — у третій, а витягнутий текст з діаграми — у четвертий. Кожен фрагмент є дійсним. Кожен виклик моделі для генерації ембеддингу успішний. Панель керування залишається у зеленому статусі. Проте знання були фундаментально перерозподілені. Під час запиту система мусить пов’язати тип твердження з діапазоном кількості, віднести його до особи, яка схвалює, знайти вимоги до перевірки та відновити всі необхідні перевірки, причому все це потрібно зробити на основі фрагментів, які самі по собі неможливо прочитати. Модель мови отримує окремі частини та формує неповну відповідь.

Ось чому налагодження систем RAG вводить у оману. Команди змінюють моделі для генерації ембеддингів, збільшують параметр top-k, купують потужніші моделі для переупорядкування даних або переписують запити. Іноді це допомагає. Але частіше це лише компенсує наслідки неправильної сегментації. Погана якість систем RAG часто є наслідком проблем із розділенням даних, які маскуються під проблеми моделей великих мовних моделей.

Більшість обговорень щодо чанкінгу зводиться до однієї цифри: 256 токенів, 512 або 1 000, разом із рівнем перекриття. Це цілком логічні питання щодо реалізації, але архітектурне питання інше:

Що має залишатися разом, щоб це все одно мало той самий сенс при отриманні окремо?

У наступному опису йдеться від найпростіших стратегій до технік, що з’явилися у 2024 та 2025 роках; наводяться моменти, коли кожна з них окуповує себе, а також пропонується проект для практичного використання, здатний працювати із складними корпоративними документами.

Місце чанкінгу у процесі обробки

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

Уявіть собі повний шлях. Джерела такі як PDF, таблиці, зображення, JSON, бази даних, API та код підлягають обробці, аналізу, очищенню та нормалізації. Лише після цього шар розбиття на частини вирішує, як кожен тип контенту стане одиницею пошуку. Для наративного контенту можна використовувати структурне чи семантичне розділення. Жорсткі правила можуть підходити для представлення на рівні тверджень. Таблиці потребують меж, враховуваних їхньою схемою. JSON має відповідати бізнес-об’єктам. Зображення потребують візуальних описів, пов’язаних із оригіналом.

Тож у продакшн-системах рідко використовується єдиний розмір частин для всього. Одне корпус може містити представлення на рівні документа, розділу, абзацу, твердження та токена одночасно. Пари „батьків-дітей“ для пошуку використовують маленькі частини для точності та більші частини для контексту, тоді як пізнє розбиття на частини, контекстуальний пошук та технологія RAPTOR відновлюють інформацію, яку інакше було б видалено під час розбиття.

Процес чанкінгу також не закінчується з наявністю векторів. Метадані чанків, версії документів, посилання типу «батьківський-дочірній», механізми контролю доступу та посилання на джерела мають зберігатися під час індексування, пошуку, переранжування, формування контексту та генерації результатів. Оцінка завершує цей цикл: випадки невдалих пошуків, дубльований контекст, неправильні цитати та зміни у шаблонах запитів мають повертатися для урахування під час прийняття рішень щодо чанкінгу. У практичному застосуванні чанкінг — це не стільки розбиття документів, скільки проектування одиниць пошуку, на яких буде ґрунтуватися вся решта процесів.

Основний компроміс

Розгляньмо короткий уривок з політики:

High-risk corporate customers must complete Enhanced Due Diligence.

Facilities above EUR 10 million require Group Credit Committee approval.

Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.

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

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

Прості базові підходи

Розділення фіксованого розміру

Розділення фіксованого розміру розбиває текст на фрагменти певної довжини, зазвичай за допомогою токенів, з можливістю перекриття. Цей підхід є простим, детермінованим та економічно ефективним.

Підрахунок токенів зазвичай кращий за підрахунок символів, оскільки моделі з вбудованими ембеддингами сприймають токени. П’ятсот символів німецькою чи китайською мовою можуть містити значно менше змістовних одиниць, ніж така ж кількість символів англійською мовою. Метод кодує текст у токени, працює з ними з фіксованими інтервалами та декодує кожне вікно. Накладення означає, що кожне вікно починається до завершення попереднього.

• Добре підходить для: однорідного прозового тексту, базових тестів, ситуацій, де найважливішою є операційна простота, та ранніх прототипів, яким спочатку потрібна функціональна система.
• Не ефективний, коли: зміст залежить від структури. Умова може закінчуватися на токені 499, тоді як її виняток починається на токені 501, і межа нічого не знає про бізнес-логіку.

Що означає накладення

Перекриття є захистом від проблем із межами. Без нього речення може бути розділене на дві частини, і жодна з них не буде цілісною. З ним кожна частина містить трохи інформації від сусідньої, тож обидві залишаються зрозумілими.

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

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

Рекурсивне розділення

Корпоративні документи вже містять корисні межі у заголовках, розділах, абзацах, реченнях та списках. Рекурсивне розділення використовує ці межі перед тим, як звернутися до довільних точок розрізу. Наприклад, рекурсивний розділювач символів LangChain спочатку пробує використати подвійні переноси рядків, які зазвичай позначають абзаци. Якщо фрагмент все ще занадто великий, він пробує використати одинарні переноси рядків, потім пунктуацію речень, потім пробіли та нарешті окремі символи. Ліміт розміру — це поріг, який запускає кожен з варіантів розділення.

Порядок використання роздільників має більше значення, ніж саме число розміру. Для добре організованих політик, процедур, посібників та технічної документації це часто є ефективним стандартним варіантом.

Одна порада щодо обробки: якщо під час збору даних вже була видобута ієрархія, не викидайте її та не просіть інструмент розділення знаходити її заново. Розділ під номером 7.4 у розділі про позики вже вказує, які тексти належать до одного цілого. Зберігайте цю структуру в метаданих та використовуйте її для обмеження процесу розділення. Простіше кажучи, не руйнуйте структуру під час формування частин, а потім не намагайтеся її відновити під час отримання даних.

Рекурсивне розділення передбачає, що структура приблизно відповідає змісту, але це не завжди так. Один абзац може містити три непов’язані правила, а п’ять абзаців можуть описувати один процес. Саме тут на допомогу приходять методи, засновані на змісті.

Елементи речення та абзаців

Інструменти на кшталт spaCy та NLTK пропонують навчені детектори речень, які ефективно справляються з проблемами, що виникають під час простого розділення на речення: скорочення, десяткові числа, заголовки та трьохтирадкові дефіси. Розділення на абзаци є простішим та часто ефективнішим, оскільки абзац — це групування, яке автор навмисно обрав. Для чистих документів розділення на абзаци та об’єднання коротких сусідніх фрагментів до певного мінімального розміру є розумним компромісом між підходами з фіксованим розміром та семантичними підходами.

Недоліком є змінний розмір частин. Деякі абзаци містять 50 токенів, а інші — 800, що ускладнює об’єднання в пакети, збільшує затримку під час створення ембеддингів та ускладнює прогнозування розміру індексу. Чи виправдовують кращі межі такі труднощі, залежить від корпусу даних.

Слайдуючі вікна як інструмент для покращення точності

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

Більше перекриття підвищує точність пошуку, але призводить до зайвості інформації. При рівні перекриття понад 30–40 відсотків списки типу top-k заповнюються майже однаковими даними, які витрачають ресурси на контекст, не додаючи нової інформації; 10–25 відсотків є оптимальними для більшості корпусів. Оцінюйте рівень перекриття, вимірюючи частку дублікатів, поряд із показником Recall@k, адже підвищення Recall@5 при подвоєнні кількості дублікатів може не покращити якість відповідей.

Стратегії, з орієнтацією на значення

Семантичне розділення на частини

Семантичне членування замінює правило підрахунку токенів на запитання: чи змінилося тематичне напрямок достатньо, щоб почати нову одиницю? Уявіть розділ, у перших двох реченнях якого йдеться про вимоги до перевірки, у третьому — про ліміти оплати, а у четвертому — про правила боротьби з шахрайством. Фіксований інструмент для розділення тексту не може помітити цих змін, тоді як добре налаштований семантичний членувач може.

Звичайний підхід складається з трьох етапів. Спочатку за допомогою лінгвістичної моделі розділяють текст на речення. Кожне речення або невеликий проміжок сусідніх речень інтегрують за допомогою моделі sentence-transformer. Потім обчислюється косинусова відстань між сусідніми ембеддингами, і встановлюється межа там, де ця відстань перевищує певний процентиль, зазвичай між 85-м та 95-м процентилями відстаней у цьому документі.

Цей поріг є критичним параметром. Якщо він занадто високий, пов’язані ідеї розпадаються на дрібні, беззмістовні фрагменти. Якщо ж він занадто низький, окремі теми залишаються об’єднаними, що повертає шум, який ви намагалися усунути.

Це також збільшує витрати, адже перед визначенням меж необхідно провести повний процес вбудовування даних. Для коротких, структурованих документів ця витрата майже не має значення. Однак для довгих текстів з непослідовною форматуванням виявлення справжніх змін тем може значно покращити ефективність пошуку. Є одна важлива обмеження: метод передбачає, що теми поступово та помітно змінюються між реченнями. У щільному юридичному чи регуляторному тексті, де одне речення може містити три умови та два винятки, відстані на рівні речень створюють шумливі сигнали.

Розділення на батьківські та дочірні фрагменти

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

Візьмемо фрагмент довжиною 2 000 токенів, який охоплює обмеження, винятки, механізми керування та процедури ескалації. Його повне вбудовування зберігає контекст, але створює нечіткий вектор. Розділення на фрагменти по 200 токенів покращує точність пошуку, проте знайдений фрагмент може бути позбавленим того, що потрібно моделі для правильного міркування.

Метод розділення на батьківські та дочірні фрагменти розділяє ці дві задачі. Батьківський фрагмент — це більша, послідовна частина тексту, наприклад цілий речення, процедура чи підрозділ. Дочірні фрагменти — це менші, спеціалізовані частини, отримані з нього: окремі умови, порогові значення чи винятки. Лише дочірні фрагменти вбудовуються та піддаються пошуку. Коли знаходиться дочірній фрагмент, його ідентифікатор батьківського фрагмента завантажує більший вихідний текст, і саме його модель насправді читає.

LlamaIndex та LangChain пропонують версії цього підходу через ієрархічні вузли, пошук від дрібних до великих об’єктів та пошук батьківських документів. Кожен дочірній об’єкт зберігає ID батька у метаданих, а після пошуку відбувається розширення результатів до їхніх батьків перед формуванням контексту.

У регульованих середовищах ідентифікатори потребують чіткої ланцюгової структури. Читабельний ID, який поєднує документ, версію та розділ, є безпечнішим за випадковий UUID, оскільки дочірній об’єкт версії 7.2, який посилається на батьківський об’єкт версії 7.1, створює контекст, який здається правдоподібним, але є операційно неправильним. Ця схема також працює у різних форматах: дочірнім об’єктом може бути рядок серіалізованої таблиці, візуальний опис діаграми чи твердження — усі вони мають спільного батька, який представляє один логічний розділ.

Чанкування тверджень

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

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

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

• Пропозиція не є джерелом істини. Це представлення, створене за допомогою моделі. У регульованій роботі спочатку отримують пропозицію, а потім повертаються до авторитетного тексту для підтвердження, обґрунтування та цитування. Пропозиція — це запис у індексі, а не твердження.
• Витрати різко зростають. Один документ із 10 000 токенів може створити сотні пропозицій, кожна з яких потребує виклику функції імбеддингу, тому індекс швидко зростає.

Відновлення втраченого контексту

Пізнє чанкінгування

Традиційне чанкінгування спочатку розділяє текст та імбеддить кожну частину окремо. Пізнє чанкінгування, запроваджене Jina AI у 2024 році, змінює частину цього порядку.

Метод пізнього розділення спочатку пропускає весь документ через модель ембеддингу з довгим контекстом для отримання репрезентацій на рівні токенів з урахуванням контексту. Після цього встановлюються межі частин, об’єднуючи вектори токенів, які знаходяться всередині кожного вікна. Відмінність від простого використання більших частин полягає у тому, що одиниця пошуку залишається невеликою. Текст все ще залишається сфокусованим, але його вектор відображає середовище, у якому він з’явився. Займенники, скорочення, прямі посилання та терміни, визначені раніше, інтегруються у ембеддинг, а не залишаються на розсуд моделі під час генерації.

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

Контекстуальне пошукове забезпечення

Система контекстуального пошукового забезпечення від Anthropic, опублікована у 2024 році, підходить до вирішення тієї ж проблеми ізоляції по-іншому. Вона не змінює архітектуру ембеддингу. Вона покращує текст для пошуку кожного фрагмента під час створення індексу.

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

Згідно з оцінкою Anthropic, поєднання контекстуальних ембеддингів із контекстуальним алгоритмом BM25 зменшило кількість невдалих пошуків у топ-20 на 49 відсотків, а додавання функції переранжування — ще на 67 відсотків. Ці цифри базуються на власних корпусах даних Anthropic та не є гарантіями. Фактична ефективність залежить від ваших документів, запитів, моделі ембеддингів та налаштувань пошуку. Важливим не є саме число, а те, що додавання контексту, специфічного для кожного документа, до окремих фрагментів може суттєво допомогти, коли важливий зміст знаходиться поза межами цих фрагментів.

Це найбільше допомагає з неоднозначними фрагментами: відокремленими рядками таблиць, підписами до зображень, згадками про визначені терміни та частинами, межі яких походили з батьківського розділу, до якого вони більше не належать. Воно також природним чином поєднується зі знаходженням інформації на рівні батьківських та дочірніх елементів. Існує одне правило: генерований контекст є допоміжним засобом для пошуку, а не джерелом інформації. Якщо для кожного фрагмента використовувати однаковий загальний опис, вектори стануть занадто схожими, що ускладнить пошук. Хороша контекстуалізація додає лише те, що необхідно для розуміння фрагмента без його сусідів.

RAPTOR: кілька рівнів абстракції

RAPTOR, скорочення від Recursive Abstractive Processing for Tree-Organized Retrieval, усуває обмеження, притаманне пошуковим системам одного рівня: дрібні фрагменти добре відповідають на конкретні фактичні запитання, але мають труднощі з питаннями, що вимагають синтезу інформації з різних частин. Порівняйте запит про те, хто схвалює певне твердження, з запитом про всю систему контролю організації для цього типу тверджень. Для першого запиту існує одна авторитетна відповідь у таблиці. Для другого потрібні докази з правил перевірки, делегованих повноважень, політик підтримки чи відновлення, процедур перегляду та шляхів ескалації, ймовірно, з різних розділів та документів.

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

Основною проблемою під час створення контенту є походження інформації. Анотації є інтерпретаціями, а інтерпретації можуть спотворювати критерії, межові випадки та винятки — саме ці деталі мають найбільше значення у регульованій роботі. Використовуйте вищорівневі вузли для пошуку відповідних частин корпусу, а потім повертайтеся до оригінальних уривків перед генерацією. Анотація допомагає знаходити докази, а оригінальний текст є основою для міркувань моделі. RAPTOR окуповує свою вартість у випадках довгих політик, регуляторних рамок та великих посібників, де користувачі ставлять як детальні, так і синтезуючі запитання в одному застосунку. Для коротких збірок чи однотипних типів запитів складність рідко виправдовує себе.

Структурований та нетекстовий контент

Таблиці: структура — це значення

Поверніться до таблиці авторитетів. Вона містить прямі зв’язки: тип претензії — пошкодження від води, діапазон суми понад 25 000 євро, особа, яка схвалює — регіональний менеджер претензій. Якщо перетворити це на послідовність слів, зв’язки між стовпцями, які надають значенню кожному елементу, зникають, тому таблиці потребують спеціального оброблення.

У випадку невеликих таблиць часто краще зберігати їх цілісністю, особливо коли запити порівнюють рядки або потребують повного набору умов. Необхідно записати їх так, щоб зв’язки між стовпцями та рядками залишилися, наприклад, перетворивши кожен рядок на пари «мітка-значення», які позначають кожен стовпець. У великих таблицях рядки утворюють більш точні частини, але кожен рядок має містити свої заголовки, адже три простих значення без міток самі по собі нічого не означають.

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

JSON та структуровані записи

Той самий принцип застосовується й до JSON. Запис із полями segment, rating, region, amount, approver та прапорцем review вже показує, які поля належать разом, тому використання інструменту розділення на токени для серіалізованого JSON ігнорує це. Невеликі записи повинні залишатися цілими, з читабельною формою пошуку, яка відображає кожне поле разом із його позначкою. Для великих об’ємів даних потрібно знайти природні бізнес-ентитети, такі як клієнти, рахунки, транзакції, події перевірки чи рішення щодо справ, та розділити дані навколо них.

Усередині запису необхідно розділити семантичні поля від тих, які можна фільтрувати. Поля, до яких стосуються запитання мовою природи, повинні входити до ембеддингу. Поля на кшталт region, version, business unit та effective date зазвичай краще використовуються як фільтри метаданих у індексі, ніж як частина вектора. Попередній фільтрації метаданих є швидшою та точнішою для категоріальних обмежень, а також допомагає зберегти ембеддинг, орієнтований на сенс.

Код: синтаксис є межею

Код створює таку саму проблему в іншій сфері. Універсальний розділювач, який розрізає файл на Python на 500-му токені, може відокремити функцію від її оператора повернення або клас від його методів. Для пошуку коду межі повинні відповідати синтаксису: функції, методи, класи та модулі. Модуль ast у Python може парсити вихідний код у деревоподібну структуру та виділяти кожну функцію, асинхронну функцію та клас як цілісну одиницю, тож фрагменти коду відповідають семантиці мови, а не просто орієнтуються на кількість символів. Для репозиторіїв багатьох мов інструмент tree-sitter пропонує єдиний інтерфейс парсингу для десятків з них та вирішує крайні випадки, які залишаються поза увагою регулярних виразів. Взаємозв’язок між батьківськими та дочірніми елементами є природним: спочатку точно отримується метод, а потім, коли моделі потрібен ширший контекст, відбувається розгортання до його класу чи файлу.

Діаграми та зображення

Не вважайте текст, отриманий за допомогою OCR, повноцінним відображенням зображення. Діаграма потоку передає значення за допомогою стрілок, послідовності, розгалужень, групування та просторового розташування, що OCR не може зафіксувати. Використовуйте модель, здатну розпізнавати зображення, щоб створити опис того, що передає зображення, а не лише слів, які в ньому є. Зберігайте посилання на оригінал. Створений опис є записом у індексі, тоді як вихідне зображення є доказом, який система відображає. У регульованих системах посилання має вказувати на оригінальне зображення, а не на його опис.

Маршрутизація за типом контенту

Справжні документи є змішаними. Один мануал може містити описові правила, таблицю авторитетів, діаграму процесу, метадані у форматі JSON та вбудовані посилання. Немає жодних обґрунтованих причин застосовувати один інструмент розділення до всіх чотирьох типів документів, адже кожен з них несе інше значення: абзац — через лінгвістичну послідовність, таблиця — через перетини рядків та стовпців, діаграма — через положення, напрямок та групування, а JSON — через чітко визначені ключі.

Оптимальним рішенням є маршрутизатор з частковим розділенням, який визначає тип контенту кожного виділеного блоку та надсилає його до відповідної стратегії обробки. Цей маршрутизатор не повинен бути складним у функціонуванні. Його цінність полягає у тому, що він робить вибір маршрутизації за типом контенту свідомим елементом проектування, а не наслідком використання якогось універсального розділювача. Для довідника тверджень текст буде переданий для структурного чи семантичного розділення, таблиця авторитетності — для серіалізації з урахуванням структури таблиць, діаграма потоку — до моделі візуалізації для опису, а JSON-метадані — до розділення з урахуванням особливостей об’єктів.

Кожен отриманий блок має містити однакові основні метадані, такі як ідентифікатор документа, версія, ідентифікатор батьківського елемента, розділ та область. Ця спільна структура дозволяє наступним етапам розуміти, що рядок у таблиці, абзац та опис діаграми є взаємопов’язаними елементами одного розділу.

Коли перевагу мають більші одиниці

Більша частина описаного вище прогресу спрямована на досягнення більш високої деталізації, що може створити хибне враження про те, що менше завжди краще. Дослідження LongRAG розглядали протилежний напрямок, перевіряючи, чи можуть значно більші одиниці отримання інформації — у деяких експериментах аж до приблизно 4 000 токенів — перевершити деталізоване отримання інформації при розв’язанні складних багатоетапних запитань. Висновок полягав не у тому, що великі фрагменти є універсально кращими, а у тому, що рівень деталізації отримання інформації має відповідати рівню деталізації запиту.

Запит про те, як часто потрібно переглядати певний тип облікового запису, має відповідь розміром з окрему тезу. Щоб отримати повну інформацію про систему керування для певного типу тверджень, потрібні дані з кількох сфер, а деталізоване отримання інформації може змусити систему скласти широку відповідь з багатьох окремих фрагментів, тож помилки у формуванні відповіді з’являються навіть тоді, коли кожен фрагмент є правильним.

Вибір та оцінка

Як обрати стратегію

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

Орієнтовний посібник:

• Однорідний текст, ранній прототип: фіксований розмір з невеликим перекриттям.
• Добре структуровані посібники та інструкції: рекурсивне або структурно-орієнтоване розділення, при цьому ієрархія зберігається у метаданих.
• Довгий наратив із непослідовним форматуванням: семантичний чанкінг, якщо додаткові витрати приносять помітну користь.

Питання, які вимагають як точності, так і контексту: батьківсько-дочірні взаємозв’язки.

Інтенсивні формулювання правил та вузькі запити на факти: пропозиції з збереженням батьківських елементів.

Фрагменти, які втрачають значення при ізоляції: пошук у контексті або пізнє формування фрагментів.

Змішані типи запитів у довгих документах: ієрархічні методи, такі як RAPTOR.

Таблиці, JSON, код та діаграми: специфічна обробка за типом через маршрутизатор.

Бенчмарк замість здогадок

Огляд кількох фрагментів та висновок про їхню прийнятність допомагає під час виправлення помилок, але це не є оцінкою. Справжнє питання полягає у тому, чи допомагає стратегія знаходити необхідні докази для запитів, які насправді надсилають користувачі.

Складіть набір для оцінки, який охоплюватиме різні потреби: вузький факт, пов’язаний із окремим рядком таблиці, запит із кількома доказами, який вимагає наявності оповідного речення та опису процесу, умовний запит щодо винятку та синтетичний запит, що охоплює кілька розділів. Під’єднайте кожен запит до ID одиниць даних, які слід знайти.

Метрики пошуку самі по собі недостатні. Запишіть, наскільки великий індекс у порівнянні з базовим значенням фіксованого розміру, які витрати на вбудовування даних на один документ, час індексації та пошуку, кількість контекстних токенів на запит, частку дублікатів, правильність відповіді та правильність посилань. Три додаткові бали за Recall@5 є малоцінними, якщо розмір індексу зростає в чотири рази, а результати наповнюються майже ідентичними копіями.

У типовому корпусі політик рекурсивне розділення перевершує розділення фіксованого розміру на кілька пунктів при однакових витратах на індексацію; семантичне членування додає ще трохи при незначних додаткових витратах; підхід «батьків-дітей» підвищує рівень відтворення ще більше з помітним зростанням кількості індексів; а комбінація пропозицій з їхніми «батьками» досягає найвищого рівня відтворення, але за значно більшої вартості та складності. Контекстуальне пошукове забезпечення може досягти подібного рівня відтворення з меншим зростанням кількості індексів, що може обґрунтувати використання цього підходу під час індексації, тоді як RAPTOR може поступатися підходу «батьків-дітей» у випадку вузьких фактів, але перевершувати його у синтезі. Розглядайте це як ілюстрацію характеру компромісів, а не як точний результат. Оптимальна точка роботи залежить від вимог до точності, обмежень щодо затримки, бюджету на індексацію та від того, чи обґрунтовує кожне покращення свою складність.

Не оптимізуйте лише процес пошуку

Припустимо, що сильне перекриття покращує показник Recall@5, але топ-п’ять результатів тепер містить чотири майже ідентичні уривки з одного речення, що виштовхує інший релевантний фрагмент за межі дозволеного обсягу контексту. Одна метрика покращилась, але система стала гіршою. Необхідно оцінити весь процес — від пошуку та переранжування до формування контексту та генерації відповіді, на кожному етапі перевіряючи, чи збереглися необхідні докази, чи дублікати не займають корисний простір, чи є відповідь правильною та обґрунтованою, а також чи посилання веде до правильного джерела та версії.

У регульованих системах правильність посилань — це не дрібниця. Відповідь може бути фактично правильною, але ґрунтуватися на неправильній версії правил. Це все одно є порушенням вимог, і воно залишається непоміченим, якщо не перевіряти походження посилань.

Архітектура продакшну

Основна зміна у підході полягає у тому, що зріла система обробки контенту майже ніколи не потребує єдиного інструменту для розбиття на частини. Їй потрібний шар маршрутизації, який надсилає кожен блок контенту до відповідної стратегії обробки, зберігає спільну метадану про походження у всіх отриманих частинах та містить прямі посилання на авторитетне джерело.

Для посібника з формулювання претензій доцільна така структура: наративні розділи піддаються структурному чи семантичному розділенню; щільні клози правил перетворюються на пропозиції з збереженням батьківського елемента; невеликі таблиці серіалізуються цілком; великі таблиці розділяються на блоки рядків із урахуванням заголовків; діаграми отримують описи у вигляді моделей розпізнавання зображень; а записи у форматі JSON розділяються об’єктами. Кожен блок, незалежно від типу, містить однакові ідентифікатори: ID документа, версія, ID батьківського елемента, розділ, регіон та посилання на вихідний документ. Ця спільна ієрархія має таке ж значення, як і самі блоки, адже вона дозволяє пов’язати рядок таблиці, клоз та опис процесу як докази з одного розділу певної версії.

Повернення до претензії щодо пошкодження від води

Питання ніколи не полягало у тому, чи є 500 чи 800 токенів правильним розміром. У джерелі були різні види доказів. У параграфі йшлося про необхідність незалежної перевірки. У таблиці було вказано, хто схвалює діапазон кількості. У діаграмі були показані перевірки, які передують оплаті. У метаданих було визначено, яка версія та регіон застосовуються.

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

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

Останній перелік перевірок перед індексуванням

Перш ніж фрагменти потраплять у процес ембеддингу, кожен з них має відповідати трьом вимогам:

• Здатний до пошуку. Достатньо конкретний, щоб відповідати важливим запитам, але не настільки широкий, щоб відповідати всьому поверхнево.
• Інтерпретований. Містить достатньо контексту, щоб сам по собі мати зміст, або має надійний спосіб відновлення цього контексту через пошук у батьківських елементах.

Простежуваність. Посилання на авторитетне джерело: саме документ, версія, розділ, сторінка, таблиця, зображення чи запис, з яких взято інформацію.

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

Перед розгортанням також необхідно спланувати обробку журналів подій, секретних даних та конфігурацій, використання детерміністичних ідентифікаторів, версіонування моделей та запитів, відстеження походження частин даних, контроль доступу, набори даних для оцінки, управління життєвим циклом індексів та моніторинг якості пошуку, затримки та витрат.