Стратегії чанкінгу RAG: 7 методів, ранжовані за даними пошуку (2026)

Стратегії чанкінгу RAG: 7 методів, ранжовані за даними пошуку (2026)

Стратегії чанкінгу RAG визначають, що зможе знайти ваш ретрівер, іще до того, як буде виконано перший запит. У дослідженні Chroma з липня 2024 року 472 запити прогнали на п'яти корпусах із text-embedding-3-large, і вибір сплітера зсуває повноту приблизно на п'ять пунктів: 86,7% для звичайного токенного сплітера проти 91,7% для сплітера на GPT-4o, за п'яти чанків на запит. Точність коливається значно сильніше. У всьому звіті вона сягає від 1,5% до 8,0%, тож вибір розміру чанка є рішенням про витрати, яке лише вдає рішення про якість, а кожен гайд із першої сторінки видачі перелічує ті самі сім методів, не показуючи, який із них шукає краще.

Ключові висновки

• Чанкінг розбиває документи до ембедінгу; точки розбиття визначають, що ваш ретрівер зможе і не зможе знайти.
• У дослідженні Chroma з липня 2024 року на 472 запити повнота виміряних сплітерів становила від 86,7% до 91,7%.
• Точність варіюється в кілька разів сильніше за повноту, тож розмір чанка це передусім рішення про вартість токенів.
• Почніть із 512 токенів і 10% перекриття, потім налаштовуйте під власний eval-набір.

Яку стратегію чанкінгу RAG обрати? (Рейтинг)

Для більшості команд, які працюють із плоским текстом, рекурсивний символьний чанкінг на 512 токенів із 10% перекриття є правильним типовим вибором. Він поважає межі абзаців і речень, не коштує нічого додаткового і в бенчмарку Chroma на 472 запити відстав від LLM-сплітера лише на 3,2 пункту повноти. Відхиляйтеся від нього, лише коли ваші документи мають виражену структуру або ваш eval-набір доводить протилежне.

Наш висновок: починайте з рекурсивного символьного. У даних Chroma він поступається за повнотою лише кластерному та LLM-сплітерам, а точність LLM-сплітера 3,9% означає, що на кожен релевантний токен ви подаєте генератору приблизно вдвічі більше шуму. Більшість команд мають не проблему чанкінгу, а проблему розміру чанка, яку вони ніколи не вимірювали.

Що насправді кажуть дані про розмір чанка?

Єдине публічне пряме порівняння стратегій чанкінгу RAG це технічний звіт Chroma "Evaluating Chunking Strategies for Retrieval" (Брендон Сміт і Антон Тройнніков, опубліковано 3 липня 2024 року). Автори прогнали 472 запити на 5 корпусах (328 208 токенів), перетворили все на ембедінги через OpenAI text-embedding-3-large і діставали 5 чанків на запит. Рядки нижче взяті з таблиці додатка до звіту для всіх корпусів на text-embedding-3-large за 5 отриманих чанків, тож вони безпосередньо порівнянні між собою:

Основна таблиця результатів Chroma, яка звітує про інший режим пошуку, показує найкращу точність кластерного чанкера 8,0% за повноти 87,3% і розтягує діапазон точності всіх сплітерів від 1,5% (KamradtSemanticChunker) до 8,0%. Джерело: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" від Anthropic (опубліковано 19 вересня 2024 року) підходить до проблеми з іншого боку. Їхня базова частота збоїв пошуку top-20 становила 5,7%; самі лише контекстні ембедінги знизили її до 3,7% (зменшення на 35%), контекстний BM25 зверху довів її до 2,9% (49%), а переранжування стиснуло до 1,9% (67%). Anthropic не публікує точний розмір чанка чи перекриття, які використовувала, тож сприймайте це як докази на рівні методу, а не на рівні розміру. Джерело: Anthropic, Contextual Retrieval.

Наш висновок: з арифметики випливають три речі. По-перше, вибір сплітера вартий реальної повноти, і Chroma каже це прямо: деякі стратегії перевершують інші на величину до 9% повноти. У її основній таблиці результатів повнота сягає від 83,6% (KamradtSemanticChunker) до 91,9% (LLMSemanticChunker), а в наведених вище рядках із 5 чанками вона досі простягається від 86,7% до 91,7%. Точність на тих самих даних рухається в кілька разів далі: від 1,5% до 8,0%, розкид 5,3x проти 1,1x у повноти. Тож повнота це там, де ви виграєте кілька пунктів, а точність і вартість токенів це там, де вибір справді кусається. По-друге, LLM-сплітер купує найвищу повноту за найгіршої точності: ви платите виклик LLM за кожен документ і подаєте генератору більше шуму. По-третє, цифри Anthropic показують, що збагачення чанків контекстом (з 5,7% до 3,7%) зсунуло частоту збоїв сильніше, ніж будь-який вибір сплітера в таблиці Chroma. Збагачуйте чанки, перш ніж заново налаштовувати сплітер. Переранжування рятує чанки, які ваш сплітер понівечив, а гібридний пошук поєднує BM25 із векторним пошуком з тієї самої причини.

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

Чому розмір чанка визначає якість пошуку?

Розмір чанка задає гранулярність вашого пошукового ключа. Чанк у 400 токенів дає сфокусований ембедінг, який збігається з конкретними запитами; чанк у 4 000 токенів усереднює багато тем і не збігається точно ні з чим. Малі чанки дістають точний уривок, але можуть розфрагментувати відповідь між результатами. Великі чанки тримають контекст разом, але послаблюють сигнал ембедінгу.

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

Тепер бік генератора. Лю та ін. показали у "Lost in the Middle" (arXiv 2307.03172, 2023), що точність LLM падає понад 20%, коли релевантний документ лежить у середині довгого контексту. Отримання п'яти чанків по 1 000 токенів вкидає 5 000 токенів у промпт, і потрібна вам відповідь може опинитися в позиції, яку модель читає найгірше. Менші чанки тримають релевантний уривок ближче до позиції, з якою модель добре працює.

Уявіть це як картковий каталог бібліотеки. Картка з написом "Розділ 4.2, абзац 3: політика повернення" приводить вас до сторінки. Картка з написом "усе про торгівлю XX століття" приводить вас до будівлі. Ваш ембедінг це картка. Побудуйте RAG-застосунок від початку до кінця, щоб побачити, де чанкінг сидить у конвеєрі, і прочитайте наш гайд з інженерії контексту про те, як отримані чанки стають токенами промпта. Гайд Pinecone з чанкінгу окреслює той самий компроміс із боку векторної бази даних.

Фіксований і рекурсивний чанкінг (починайте звідси)

Фіксований розмір це базова лінія, з якою ви порівнюєте все; рекурсивний це те, що ви насправді відправляєте в продакшн.

Токен-чанкінг фіксованого розміру

Розбивайте кожні N токенів, незалежно від вмісту.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Правильна відповідь для: плоского тексту без структури заголовків, швидких прототипів і будь-якого базового порівняння. Це не дурість. Це контрольна група.

Рекурсивний символьний чанкінг

RecursiveCharacterTextSplitter від LangChain розбиває за ієрархією роздільників: спершу \n\n (абзаци), потім \n (рядки), потім . (речення), потім (слова). Кожен чанк лишається меншим за chunk_size, поважаючи найбільшу природну межу, яка вміщується.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Список роздільників це та частина, яку оминає кожен конкурент. Сплітер спершу пробує \n\n і переходить до . , лише коли абзац перевищує chunk_size. Якщо ваш Markdown має заголовки, додайте "## " перед "\n\n", щоб секції лишалися цілими.

Арифметика перекриття чанків: за 512 токенів із 50-токенним перекриттям крок становить 462. Документ у 10 000 токенів дає ceil(10000 / 462) = 22 чанки. Усього ембедиться токенів: 22 x 512 = 11 264, тобто ви повторно ембедите приблизно 12,6% корпусу як перекриття. Такою є ціна сховища й API за те, щоб прикордонні речення не лишалися сиротами.

Як працює семантичний чанкінг і чи вартий він своїх грошей?

Семантичний чанкінг перетворює кожне речення на ембедінг, вимірює косинусну відстань між ембедінгами сусідніх речень і розбиває там, де ця відстань перевищує перцентильний поріг (зазвичай 95-й). Чанки розриваються на зміні теми, а не на довільній кількості токенів. Ноутбук Ґреґа Камрада "5 Levels of Text Splitting" започаткував цей підхід із перцентильною точкою розриву, і дослідження Chroma бенчить його чанкери на ім'я.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Математика витрат це та частина, яку ніхто не викладає одразу. Семантичний чанкінг ембедить ваш корпус двічі: один раз, щоб обчислити відстані між реченнями і знайти точки розриву, і вдруге, щоб перетворити на ембедінги отримані чанки для індексації. За ціни OpenAI text-embedding-3-large у $0,13 за 1 млн токенів корпус у 10 млн токенів коштує $1,30 за звичайної індексації та $2,60 із семантичним чанкінгом. Ви платите вдвічі більше, перш ніж виконається хоч один запит.

Що це купує? У рядках Chroma з 5 чанками кластерний семантичний чанкер досяг повноти 89,0% і точності 6,7% проти 88,5% і 7,0% у рекурсивного за того самого розміру 200 токенів. В основній таблиці результатів той самий чанкер показує найкращу точність дослідження, 8,0%, за повноти 87,3%. Пів пункту повноти в той чи інший бік і результат точності, який змінює знак залежно від того, який режим пошуку ви читаєте, за подвійний рахунок за ембедінги. Наш вердикт: семантичний чанкінг окупається на різноманітних за темами корпусах (архіви новин, збірки статей), де фіксовані межі регулярно розрізають тему посередині. Для однорідних корпусів (продуктова документація, одна база знань) рекурсивний дає 95% якості за половину ціни. Якщо ви запускаєте моделі ембедінгів локально з Ollama, вартість подвійного ембедінгу зводиться до часу обчислень.

Чанкінг із урахуванням документа: Markdown, HTML і код

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

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

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

Конкретно для кодового RAG: розбиття за межами AST, імпорти на початку, 256-512 токенів на функцію, нульове перекриття.

А як щодо пізнього, ієрархічного та агентного чанкінгу?

Це просунуті стратегії чанкінгу RAG, які стоять за галасом навколо "RAG 2.0", і всі три мають покриття SERP 1/10.

Пізній чанкінг

Пізній чанкінг, запропонований Ґюнтером та ін. у "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, вересень 2024), спершу ембедить увесь документ моделлю з довгим контекстом, потім агрегує токенні ембедінги у вектори чанків, тож кожен чанк несе контекст усього документа і фраза "це коштує $40 на місяць" знає, на що вказує "це". Анотація заявляє кращий пошук на різних завданнях, але не публікує жодного головного числа, яке ми могли б перевірити. Стаття Weaviate пояснює механіку і теж зупиняється за крок до контрольованого порівняння. Стан доказів: перспективно, без кількісної оцінки.

Ієрархічний (батьківсько-дочірній) чанкінг

Індексуйте малі чанки (256 токенів) для пошуку; повертайте генератору батьківський (1 024 токени). Ретрівер знаходить голку; генератор отримує навколишній стіг сіна. Ви підтримуєте два рівні індексу та батьківсько-дочірнє відображення. Жоден публічний бенчмарк не виділяє цей ефект окремо.

Чанкінг на основі LLM / агентний чанкінг

LLMSemanticChunker із дослідження Chroma використовує GPT-4o для визначення точок розбиття в кожному документі: повнота 91,7% (найвища) і точність 3,9% (найнижча). Ви платите виклик LLM за кожен документ під час індексації (близько $100 за корпус із 10 000 документів) і подаєте генератору більше шуму. Прибережіть його для справді нерегулярних корпусів: юридичні документи, скановані PDF без заголовків, які можна витягти.

Який розмір чанка підходить вашій моделі ембедінгів?

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

Джерела: гайд OpenAI з ембедінгів, документація Cohere embed, документація Voyage embeddings, картка моделі BGE.

Закономірність: моделі з жорсткою стелею 512 токенів (Cohere v3, BGE) вимагають чанків значно менших за 512, бо усікання мовчазне. Подайте такій 600 токенів, і останні 88 зникнуть з ембедінгу без жодної помилки в лозі. Моделі з великими стелями (OpenAI, Voyage, Cohere v4) терплять більші чанки, але не винагороджують за них. Максимальна вхідна довжина моделі це ліміт усікання, а не рекомендація.

Поєднайте це з нашим оглядом найкращих моделей ембедінгів для RAG, зі статтею про те, що насправді вимірює оцінка MTEB, і з ембедінгами Voyage, OpenAI і Cohere пліч-о-пліч, перш ніж зупинитися на моделі.

Як чанкувати документи не англійською?

Токенізатори не є мовно-нейтральними. Петров та ін. показали у "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023), що той самий текст у перекладі різними мовами може відрізнятися за токенізованою довжиною на величину до 15x. Навіть символьні та байтові моделі показують різницю понад 4x для деяких мовних пар. Чанк у 512 токенів містить набагато менше сенсу турецькою, арабською чи японською, ніж англійською.

Ось те саме речення, токенізоване кодуванням tiktoken cl100k_base (токенізатор GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Підрахунки згенеровано tiktoken cl100k_base, 30 липня 2026 року.

Практична порада: за фіксованого розміру чанка 512 токенів ваші турецькі та японські чанки вміщують приблизно 37% сенсу ваших англійських чанків, а ваші арабські чанки приблизно 26%. Чанкуйте за кількістю символів або речень для кожної мови або пропорційно збільшуйте токенний бюджет (близько 1 400 для турецької, 2 000 для арабської). Мови CJK не мають пробільних меж слів, тож символьні сплітери поводяться інакше. Морфологія арабської пакує кілька граматичних маркерів в один токен, ще більше роздуваючи підрахунки.

Дерево рішень для вибору стратегії чанкінгу

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

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

Інструменти: LangChain проти LlamaIndex проти Chonkie

Ми не продаємо жодного з них; три найвищі сторінки в рейтингу за цим ключовим словом це блоги вендорів із продуктовими CTA.

Джерела: документація LangChain, NodeParsers LlamaIndex, документація Chonkie.

Усі три реалізують ті самі базові алгоритми, тож обирайте залежно від того, що вже використовує ваш конвеєр. Для ширшого стека RAG-інструментів понад сплітери та порівняння Qdrant, Chroma і pgvector для сховища дивіться наші кластерні гайди.

Як Techsy підходить до чанкінгу

У клієнтських RAG-проєктах команда Techsy починає з 512 токенів і 10% перекриття та не чіпає сплітер, поки ми не побудуємо eval-набір із 20-50 питань зі справжніх тикетів підтримки клієнта. Eval-набір іде першим; потім ми змінюємо одну змінну за раз: розмір, перекриття, стратегію. Жодної заміни сплітера без цифри "до і після" на тих самих питаннях. Отримайте безплатну консультацію, щоб свіжий погляд оцінив ваш конвеєр пошуку.

Про автора

Мерт Батур співзасновник Techsy.io, де команда постачає AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек LLM-інструментів, який команда Techsy реально використовує в продакшні, зокрема про роботу з RAG і пошуком, що стоїть за побудовою клієнтських баз знань. Підключайтеся у LinkedIn.

Часті запитання

Що таке чанкінг у RAG?

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

Яка найкраща стратегія чанкінгу для RAG?

Для більшості продакшн-систем на загальних документах рекурсивний символьний чанкінг на 512 токенів із 10% перекриття є найсильнішим типовим вибором. У дослідженні Chroma на 472 запити (липень 2024) він показав повноту 88,5%, у межах 3,2 пункту від найдорожчого методу на основі LLM, без жодних додаткових витрат.

Який оптимальний розмір чанка для RAG?

Почніть із 512 токенів. Зменшіть до 256, якщо ваша модель ембедінгів обмежена 512 вхідними токенами (Cohere v3, BGE) або якщо ваші запити очікують відповідей в одне речення. Збільшіть до 1 024, лише якщо ваш eval-набір показує, що багатоабзацні відповіді фрагментуються. Завжди вимірюйте на власних питаннях.

Яке перекриття чанків використовувати?

10-20% розміру чанка (50-100 токенів за 512). Перекриття не дає прикордонним реченням лишатися сиротами: факт, розрізаний між двома чанками, з'являється повністю принаймні в одному. Понад 20% ви повторно ембедите забагато корпусу за спадної віддачі. Більшість команд зупиняються на 10% і ніколи до цього не повертаються.

Чи кращий семантичний чанкінг за фіксований?

Незначно, і за подвійної вартості ембедінгу. Бенчмарк Chroma з липня 2024 показав кластерний семантичний чанкер із повнотою 89,0% і точністю 6,7% проти повноти 88,5% і точності 7,0% у рекурсивного за того самого розміру токенів, а його найкращий результат точності 8,0% походить з іншого режиму пошуку. Варто для різноманітних за темами корпусів; важко виправдати для однорідних наборів документів.

Чи залежить розмір чанка від моделі ембедінгів?

Так. Моделі зі стелею в 512 вхідних токенів (BGE, Cohere v3) вимагають чанків значно менших за 512, бо усікання мовчазне. Моделі зі стелями 8 192+ терплять більші чанки, але не винагороджують за них; якість ембедінгу деградує від розведення ще до стелі. Дивіться таблицю парувань вище для початкових точок під кожну модель.

Як чанкувати код для RAG-системи?

Розбивайте за межами AST (визначення функцій і класів), а не за кількістю токенів. Тримайте кожен чанк у межах 256-512 токенів на функцію, додавайте на початок блок імпортів файлу і сигнатуру зовнішнього класу та використовуйте нульове перекриття, оскільки функції є самодостатніми одиницями. CodeSplitter від LlamaIndex і мовно-обізнані сплітери LangChain обидва це роблять.

Що таке пізній чанкінг?

Пізній чанкінг спершу ембедить увесь документ моделлю з довгим контекстом, потім агрегує токенні ембедінги у вектори чанків. Кожен ембедінг чанка несе контекст усього документа, розв'язуючи проблему "на що вказує 'це'?". Запропонований Ґюнтером та ін. (arXiv 2409.04701, вересень 2024). Жоден публічний прямий бенчмарк поки не виміряв виграш кількісно.

Як чанкувати документи іншими мовами, окрім англійської?

Кількість токенів не є мовно-нейтральною. Те саме речення потребувало у 2,7x більше токенів турецькою та японською, ніж англійською, і у 3,9x арабською (tiktoken cl100k_base). Фіксований бюджет у 512 токенів мовчки дає неангломовним чанкам менше сенсу. Чанкуйте за кількістю символів або речень для кожної мови або пропорційно збільшуйте бюджет.

Як зрозуміти, що чанкінг справді працює?

Побудуйте eval-набір із 20-50 питань зі справжніх запитів користувачів, перш ніж чіпати сплітер. Оцініть hit@5 і MRR на ваших поточних чанках. Змініть одну змінну (розмір, перекриття, стратегію), проженіть знову, порівняйте. Без eval-набору ви налаштовуєте навмання. Двадцяти питань достатньо, щоб почати.

Підсумок

• Почніть із рекурсивного символьного чанкінгу на 512 токенів, 10% перекриття. Правильний типовий вибір для плоского тексту.
• Серед чотирьох родин сплітерів, які хтось вимірював, 472 запити Chroma зсувають повноту приблизно на 5 пунктів, а точність у кілька разів більше. Спершу налаштовуйте точність і вартість.
• Узгоджуйте розмір чанка зі стелею вхідних токенів вашої моделі ембедінгів. Модель зі стелею 512 токенів вимагає чанків, менших за 512.
• Збагачуйте чанки контекстом (падіння частоти збоїв Anthropic з 5,7% до 3,7%), перш ніж заново налаштовувати сплітер.
• Спочатку побудуйте eval-набір. Кожне рішення про сплітер без цифри "до і після" є здогадкою.

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