Дистрактори в RAG: чому, збільшуючи k, ви купуєте конкурентів, а не відповіді

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

Нічого тут не зламано. Ретривер зробив саме те, що від нього вимагали. Ці дев'ять чанків — не випадково просочений шум, а його продукт.

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

Назва для того, що ми відвантажуємо

У звіті Chroma про Context Rot, опублікованому 14 липня 2025 року, проведено розрізнення, яке більшість текстів про ретрив ігнорує. Нерелевантний контент до запитання не має жодного стосунку. Дистрактор пов'язаний із темою, але на запитання не відповідає.

Поводяться вони зовсім по-різному. На вісімнадцяти моделях навіть один дистрактор знижував точність порівняно з базовим варіантом, де була лише «голка». З чотирма дистракторами шкода накопичувалася, і ефект зростав із довжиною входу. В одній парі «копиця — голка» два з чотирьох написаних вручну дистракторів потрапляли в галюциновані відповіді значно частіше за два інші. Сімейства моделей теж розійшлися: моделі Claude за неоднозначності частіше утримувалися від відповіді, а моделі GPT упевнено відповідали — і помилялися.

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

Звідси наслідок: кращі ембединги роблять лише гірше. Увесь сенс сильнішого ретривера — підсунути уривки ближче до запитання. Для першої позиції це і є мета. Для решти дев'яти це означає, що кожен майже-влучний уривок гостріший за все, що підняла б торішня модель. Гроші йдуть на якість дистракторів, а називається це повнотою.

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

Прихована половина вартості

Є й друга плата, яка в рахунку не з'являється ніколи.

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

Chroma оцінила цей розрив. У їхніх прогонах LongMemEval кожне запитання подавали двічі. Одна версія йшла з повним входом, у середньому 113 000 токенів. Інша — зі сфокусованим, у середньому 300 токенів, де був лише потрібний уривок. Усі сімейства моделей гірше впоралися з повним входом. Найбільший розрив показали моделі Claude, переважно тому, що відмовлялися відповідати, щойно виникала неоднозначність.

Те саме запитання, та сама модель, відповідь є в обох вікнах. Змінилося лише те, що оточувало відповідь.

Більше вікно не врятує

У вересні 2025 року Anthropic опублікувала допис про context engineering, де названо архітектурну причину. У трансформері кожен токен дивиться на всі інші, що дає n² попарних зв'язків для n токенів, і зі зростанням n модель тримає ці зв'язки дедалі слабше. Лишається обмежений бюджет уваги, тож додатковий контекст окупається дедалі гірше.

Цей спад — схил, а не урвище, тому його й не помічають. Ніщо не викидає помилку. Точність просто витікає.

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

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

Чотири види токенів і як кожен із них підводить

Вид	Приклади	Як підводить
Статичні	Системний промпт, файли правил, описи інструментів	Надсилаються на кожному ході, тож ціна росте з кількістю ходів. Розмивають контекст.
Видобуті	Чанки, підтягнуті під кожен запит	Оплачуються за кожну вибірку. Приносять майже-влучання.
Накопичені	Історія чату, виведення інструментів	Ростуть лише в один бік. Ламаються пізно, часто за кілька ходів після отруєння.
Винесені назовні	Нотатки, файли, зведення від субагентів	Зберігати дешево. Застарівають без жодного попередження.

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

Повтор зі сфокусованим контекстом

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

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

chunks = index.query(question, k=10)   # one may answer, the rest merely resemble
prompt = SYSTEM + "\n\n".join(c.text for c in chunks) + question

А цикл порівняння — так:

for case in failing_cases:
    full = assemble_context(case.question)
    focused = case.gold_passage
    log(case.id, ask(full), ask(focused))  # the gap is your context tax

Порівняйте два стовпці. Якщо сфокусована версія проходить там, де повна падає, жодне оновлення моделі не допоможе.

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

Арифметика однієї сесії підтримки

Цифри Chroma — це базова лінія. Далі йде простий підрахунок.

Візьмімо агента підтримки з преамбулою на 6000 токенів, медіанною сесією у дванадцять ходів і ретривом top-8 приблизно по 700 токенів на чанк.

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

Порівняйте це зі сфокусованим промптом приблизно на 300 токенів, який на тих самих запитаннях показав кращий результат, ніж вхід на 113 000 токенів. Витрати — лише половина шкоди. Ці токени ще й тягнуть точність донизу.

Що змінити насамперед

Ставтеся до кожного токена як до місця, на яке потрібна ліцензія.

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

Видобутий контекст має виправдовувати своє місце тим, що здатен відповісти. Тож ранжуйте за тим, чи несе чанк відповідь, а не за схожістю, і зменшуйте k, доки повтор не перестане показувати покращення. Дешевий спосіб — другий прохід, де кожного кандидата показують маленькій моделі з одним запитанням «так чи ні»: чи містить уривок відповідь. Усе, що отримало «ні», відкидається. Зазвичай так іде більша частина вибірки.

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