Чи бувало у вас таке: ШІ-агент відповідає точно й послідовно, а за мить пропускає важливі деталі, плутає контекст або додає зайву інформацію?
Першою виникає думка про збій чи некоректний запит, але причина може бути менш очевидною. Замість моделі чи промпта варто звернути увагу на обсяг, із яким ШІ-агент працює протягом усієї сесії. У LLM довгі вхідні дані можуть не допомагати, а навпаки — розмивати фокус.
Чому так відбувається, як розпізнати проблему та які підходи допомагають її уникнути? Відповідаємо далі.
Як LLM працюють з довгими запитами
Насамперед зафіксуймо: увага моделі — обмежена.
Коли ШІ генерує відповідь, він не читає весь ваш текст однаково прискіпливо. Модель розподіляє увагу між токенами, оцінюючи, що є важливим а що другорядним. І цей ресурс не безмежний.
Наприклад, якщо:
- у вхідному тексті 500 токенів, важливий факт має більше шансів залишитися помітним.
- у вхідному тексті токенів уже 50 000, той самий факт може буквально загубитися серед решти інформації. Формально він наявний у тексті, але фактично модель уже приділяє йому менше уваги.
Це явище має назву Context Rot. Велике вікно контексту не означає, що модель однаково добре працює з усім, що ви змогли туди помістити.
Щоб спростити цю логіку, уявімо увагу моделі як обмежений бюджет. Перед тим як згенерувати наступний фрагмент відповіді, модель оцінює попередні токени й вирішує, які з них важливіші саме зараз. Чим більше токенів у вхідному тексті, тим більше елементів конкурують за цю увагу.
Це можна описати так:
// Simplified illustration — not actual LLM code
public float[] generateNextToken(String[] contextTokens) {
float[] scores = new float[contextTokens.length];
for (int i = 0; i < contextTokens.length; i++) {
// How relevant is each past token to what we are generating?
scores[i] = computeRelevance(currentState, contextTokens[i]);
}
// Scores must sum to 1.0 — a fixed attention budget
float[] weights = softmax(scores);
return weightedCombination(contextTokens, weights);
}
Що таке ефект Lost in the Middle і як він впливає на якість відповідей
Суть Lost in the Middle полягає в тому, що модель не однаково добре працює з інформацією. Її розташування має велике значення. Якщо важливий фрагмент знаходиться на початку або наприкінці тексту, модель краще помічає його. Але якщо він опиняється посередині, шанс його пропустити вищий.
Це підтверджують і результати досліджень компанії Samaya AI:
- На початку тексту точність відповідей становить близько 75%.
- Наприкінці тексту — близько 72%.
- У середині тексту — може знижуватися до 55%.
Варто зазначити, що ефект Lost in the Middle найпомітніше проявлявся в ранніх поколіннях LLM (наприклад, GPT-3.5, Llama 2 або Claude 2). Сучасні моделі значно краще працюють із довгими вхідними даними.
Проте проблема не зникла повністю. Найчастіше вона проявляється в складних сценаріях, коли моделі потрібно зіставити інформацію з кількох джерел та сформувати ґрунтовний висновок. Наразі саме так працюють RAG-системи, ШІ-агенти, корпоративні ШІ-помічники та внутрішні пошукові сервіси.
Як виглядає Context Rot: приклади
Підступність цього явища полягає в тому, що його складно помітити одразу. Модель не повідомляє про перевантаження контекстом — натомість вона дедалі частіше пропускає важливі деталі або робить надто узагальнені висновки.
Сценарій 1. ШІ-агент сам перенавантажує себе проміжними висновками
Уявімо coding-агента, якому треба знайти й виправити баг. Він проходить через десятки файлів, робить кілька хибних припущень, тестує різні шляхи, повертається назад. Усе це накопичується у вхідних даних.
До моменту, коли агент нарешті знаходить потрібний файл, його контекст уже перевантажений попередніми кроками. У результаті модель отримує все необхідне для виконання завдання, але використовує ці дані менш ефективно, ніж могла б у компактнішому контексті.
Сценарій 2. Дрейфуючий конвеєр RAG
Також популярний випадок — retrieval-пайплайн (механізм пошуку релевантних документів), який для кожного запиту повертає більше документів, ніж насправді потрібно. Логіка авжеж зрозуміла: краще надати моделі більше інформації, щоб нічого важливого не залишилося поза увагою.Проте такий підхід нерідко дає протилежний результат.
Замість десяти частково релевантних фрагментів ефективніше передати три-чотири, але справді найвідповідніших. Особливо якщо до них уже додаються:
- системний промпт;
- історія діалогу;
- інструкції безпеки;
- виклики інструментів;
- службові повідомлення.
У результаті модель отримує всю необхідну інформацію, але через перевантажений контекст може не звернути належної уваги на фрагмент, який є вирішальним для правильної відповіді.
Як зменшити вплив Context Rot
Повністю усунути це обмеження неможливо, але його можна суттєво мінімізувати. Збільшення контекстного вікна не допоможе. Варто сконцентруватись на ефективному керуванні інформацією, яку отримує модель.
Ось кілька практик, які можуть спрацювати:
1. Не перевантажувати запит зайвою інформацією
Кожен фрагмент тексту у вхідних даних повинен мати зрозумілу мету.
Наприклад, якщо до запиту додається попередня історія діалогу, варто розуміти, яку саме інформацію вона допомагає моделі врахувати. Якщо ці повідомлення вже не впливають на поточне завдання, їх краще прибрати або стиснути.
Якщо ви не можете швидко пояснити, навіщо певний блок потрапив у запит, найімовірніше, він зайвий.
2. Скорочувати історію взаємодії
Якщо агент працює з довгими діалогами або багатокроковими сценаріями, не варто безконтрольно накопичувати всю історію. Натомість періодично перетворюйте попередні кроки на короткі підсумки, залишаючи в активному контексті лише інформацію, яка потрібна для поточного завдання.
Мета не зберети все, а підтримувати компактний і актуальний робочий контекст.
3. Налаштувати систему оповіщень щодо об’єму контексту
Налаштуйте автоматичні оповіщення, які повідомлятимуть, коли обсяг контексту наближається до критичних значень. Хорошою відправною точкою можуть бути 50 000 токенів для попередження та 100 000 токенів для критичного сповіщення.
Втім, ці значення не є універсальними. Підбирайте їх на основі тестів для вашої моделі та сценарію використання, щоб попередити погіршення якості.
4. Правильно розміщувати ключову інформацію
З огляду на те, що відомо про розподіл уваги, за можливості розміщуйте найважливіші дані ближче до початку або кінця запиту, де модель має більше шансів помітити їх.
Це не універсальне правило, але воно добре працює як додаткова оптимізація.
Вплив розташування інформації допоможе оцінити positional accuracy test (тест на точність позиціювання). Він показує, чи змінюється якість відповіді залежно від того, де в контексті розташований ключовий факт.
Приклад такого тесту:
public void positionalAccuracyTest(LlmClient client, String keyFact, String fillerText) {
double[] positions = {0.1, 0.5, 0.9}; // beginning, middle, end
for (double pos : positions) {
int split = (int) (fillerText.length() * pos);
String context = fillerText.substring(0, split)
+ "\nKEY: " + keyFact + "\n"
+ fillerText.substring(split);
String response = client.complete(context, "Summarise the most important information from the context.");
boolean found = response.toLowerCase().contains(keyFact.toLowerCase());
System.out.printf("Position %d%%: %s%n",
(int)(pos * 100), found ? "RECALLED" : "MISSED");
}
}
Як довгий контекст впливає на бюджет
Більшість провайдерів LLM стягують оплату за кількість оброблених токенів. Тому чим довшим стає контекст, тим дорожчим є кожен виклик моделі:
- Більше токенів → вища вартість кожного виклику моделі, адже кожен токен враховується під час тарифікації.
- Довший контекст → більше обчислювальних ресурсів для обробки, оскільки механізм attention масштабується приблизно квадратично відносно довжини послідовності.
Парадоксальним є те, що вища вартість не гарантує кращої якості — після певного обсягу контексту точність відповідей може навіть стати гіршою.
Механізм attention (розподіл уваги моделі між токенами) у трансформерах порівнює кожен токен з іншими токенами в контексті. Тому зі збільшенням довжини контексту кількість таких порівнянь зростає дуже швидко: подвоєння кількості токенів може збільшити обсяг обчислень приблизно в чотири рази.
Кому варто враховувати обмеження контекстного вікна
Проблеми з довгим контекстом можуть виникати на різних етапах розробки та експлуатації ШІ-систем. Проте залежно від ролі в команді вони проявляються по-різному.
Оптимізація контексту може бути корисною:
- Інженерам — щоб швидше знаходити причину деградації відповідей.
- Архітекторам і техлідам — щоб проєктувати ШІ-системи, які залишаються ефективними навіть зі зростанням контексту.
- Product-менеджерам — щоб контролювати не лише якість відповідей, а й продуктивність і вартість експлуатації функцій штучного інтелекту.
Замість висновків
«Більше — не завжди означає краще» — вислів, який не втрачає актуальності навіть у контексті сучасних технологій.
Сьогодні недостатньо просто користуватися ШІ-інструментами — важливо розуміти принципи їхньої роботи. У блозі ITEDU ми регулярно ділимося цікавими матеріалами, трендами, тулзами та практиками зі світу ІТ. А на наших курсах допомагаємо перетворити теоретичні знання на навички, які знадобляться у реальній роботі.
Приєднуйтеся до спільноти ITEDU та розвивайтеся разом із нами.