Дослідницька команда оприлюднила на arXiv у вересні 2026 року метод retrieval-augmented генерації коду, який для кожного запиту підбирає не цілі файли чи фрагменти репозиторію, а вузьку підмножину «критичних токенів» — тих елементів контексту, які найсильніше впливають на точність наступного рядка коду. Це прямий виклик стандартному підходу repo-level RAG, де модель отримує top-k схожих чанків за embedding-подібністю незалежно від того, чи справді вони потрібні для конкретної генерації.
Проблема класичного retrieval для коду добре знайома будь-кому, хто будував coding-агента поверх великого репозиторію: LLM бачить лише поточний файл, а функція, яку треба викликати, оголошена в сусідньому модулі, або сигнатура класу змінилася кілька комітів тому. Без правильного контексту модель або галюцинує API, або дублює логіку, яка вже існує в репозиторії. Розширювати контекстне вікно — дорого і не завжди рятує, бо релевантні рядки губляться серед сотень нерелевантних чанків.
За даними arXiv, запропонований метод адаптивно змінює обсяг і склад retrieval-контексту залежно від того, наскільки конкретна ділянка коду залежить від зовнішніх символів — імпортів, викликів функцій, атрибутів класів. Замість фіксованого top-k retrieval система оцінює важливість токенів індивідуально і підтягує лише те, що дійсно впливає на наступний крок генерації.
Що саме змінює новий підхід у repo-level retrieval?
Головна відмінність — перехід від retrieval на рівні «документ/чанк» до retrieval на рівні токена. Класичний RAG для коду розбиває репозиторій на чанки (файли, функції, класи), рахує embedding-подібність до поточного контексту і підтягує top-k найближчих. Новий метод натомість визначає, які токени в потенційному продовженні коду є «критичними» — тобто такими, чия правильність напряму залежить від зовнішнього контексту, — і будує retrieval-запит саме під них.
- Adaptive retrieval — обсяг контексту не фіксований, а підлаштовується під складність конкретної ділянки коду.
- Critical-token фокус — пріоритет мають токени з високою залежністю від зовнішніх символів репозиторію, а не весь текст чанка.
- Менше шуму в промпті — модель не бачить нерелевантні фрагменти, які лише «зʼїдають» контекстне вікно.
Чим це відрізняється від того, що вже роблять coding-агенти?
Більшість сучасних coding-агентів і IDE-асистентів досі покладаються на embedding-пошук по файлах чи символах із фіксованою кількістю результатів. Це працює прийнятно для невеликих репозиторіїв, але деградує на кодових базах із десятками тисяч файлів, де семантично схожий, але функціонально нерелевантний код легко потрапляє в top-k і витісняє справді потрібний контекст. Зосередження на критичних токенах замість схожості цілих фрагментів — це зміна самої одиниці виміру релевантності, а не чергове тюнінгування embedding-моделі.
Кому це дасть перевагу вже зараз?
Найбільше виграють команди, що будують або підтримують coding-агентів для великих монорепозиторіїв — там, де ціна помилки retrieval найвища: пропущена залежність означає зламаний білд, а не просто гіршу підказку в автодоповненні. За нашою оцінкою, підхід також актуальний для внутрішніх code-review асистентів і агентів рефакторингу, яким критично не переплутати сигнатуру функції в сусідньому модулі.
Практично це означає, що RAG-шар coding-агента варто переглядати не лише як питання «який embedding вибрати», а як окрему задачу вибору гранулярності retrieval. Команди, які вже мають pipeline на основі top-k chunk retrieval, можуть додати критично-токенний фільтр як другий прохід — без переписування всієї архітектури пошуку.
Висновок AiiN
Наша теза: перехід від retrieval «документами» до retrieval «токенами» — не косметичне вдосконалення, а натяк на те, куди рухається RAG для коду загалом. Coding-агенти дедалі частіше працюють автономно на цілих репозиторіях, і саме там ціна нерелевантного контексту максимальна — модель не просто відповідає гірше, вона змінює код, який реально піде в продакшн. Ми вже писали про те, хто перевірить навички AI-агента, перш ніж він зіпсує продакшн — якість retrieval-шару якраз одна з тих архітектурних деталей, що визначає цю відповідь.
Що таке critical-token retrieval простими словами?
Це техніка, за якої система для генерації коду підбирає контекст не цілими файлами чи фрагментами, а окремими токенами, які найсильніше впливають на правильність наступного рядка — наприклад, іменами функцій із зовнішніх модулів чи сигнатурами класів.
Чи можна додати цей підхід до наявного RAG-пайплайна?
За описом методу — так: адаптивний відбір критичних токенів можна реалізувати як додатковий фільтр поверх наявного embedding-based retrieval, не змінюючи базову архітектуру пошуку.