Роблю RAG по внутрішній документації (Confluence, близько 3000 сторінок, багато таблиць і прикладів коду). Зараз ріжу текст по 1000 символів з перекриттям 200 — і відповіді часто «майже правильні»: модель бачить шматок інструкції без потрібного контексту.
Чи є якесь правило для розміру чанка? Більше чи менше?
Універсального числа немає, але є підхід, який майже завжди кращий за фіксовані 1000 символів.
1. Ріжте за структурою, а не за символами. Для Confluence: розділ під заголовком = кандидат у чанк. Таблицю і блок коду не розривайте взагалі — розірвана таблиця без шапки марна.
2. Додайте контекст у сам чанк. На початок кожного чанка — назва сторінки і шлях заголовків:
Деплой сервісів › Відкат релізу › Kubernetes
Щоб відкотити реліз, виконайте ...Це сильно покращує і пошук, і розуміння моделлю, звідки шматок.
3. Розмір перевіряйте на своїх даних. Зберіть 50 реальних питань, для кожного позначте сторінку, де відповідь. Прогоніть кілька варіантів (наприклад, 300, 600 і 1000 токенів) і порівняйте recall@5 — чи потрапляє потрібний чанк у топ-5. Це займе пів дня, але дасть відповідь саме для вашої документації.
4. Подумайте про «малий для пошуку — великий для контексту». Шукаєте по невеликих чанках (точніше), а в промпт кладете весь розділ, з якого чанк узято. Так модель не бачить інструкцію «без початку».
З мого досвіду для технічної документації працює 400–800 токенів з цілими розділами і хлібними крихтами в заголовку, плюс гібридний пошук (BM25 + вектори) — бо в документації багато точних назв команд і параметрів, які ембеддинги ловлять погано.
Увійдіть через Google — і зможете відповідати, голосувати й ставити власні питання. Це безкоштовно.
Увійти через Google