Як ШІ-агентові вміститися в обмежене контекстне вікно: 7 практичних стратегій

Кожен, хто будував агента, що працює довше за кілька кроків, знає цю мить. Помилка повідомляє, що контекстне вікно переповнене, або модель раптом поводиться так, ніби розмови двадцять повідомлень тому не було. Виклики інструментів, довгі ланцюжки міркувань і громіздкі JSON-відповіді з'їдають токени з лякливою швидкістю.

Проблема зростає разом зі складністю агента. Що довше він працює, то більше стану мусить нести, і рано чи пізно вікно стає вузьким місцем. Тут допомагають сім технік. Усі вони не знадобляться: часто дві-три вже помітно змінюють вартість, швидкість і надійність. Мета — встигнути більше в тому самому вікні.

1. Стискайте історію

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

• ухвалені рішення
• міркування, які варто зберегти
• підсумкові результати інструментів
• уподобання користувача й поточний стан

Старі ходи стискаються, і повністю лишаються тільки останні. Викидайте приклади й світську балачку, тримайтеся за рішення й результати.

Наприклад, після двадцяти повідомлень увесь накопичений хвіст можна стиснути до нотатки на кшталт: користувач хоче консольний застосунок на Python, обрано Click, є три команди, тести й документація ще не готові. Моделі не потрібні всі попередні повідомлення. Їй потрібне те, що впливає на її наступний крок.

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

2. Відсіюйте повідомлення й фільтруйте за доречністю

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

• викидати старі логи інструментів, щойно їхні результати враховано
• видаляти величезні JSON-відповіді, витягнувши з них ключові поля
• лишати підсумкові відповіді й прибирати проміжну балачку

Уявіть вебпошук, що повертає HTML-сторінку на 20 000 токенів. Тримати сиру сторінку в контексті безглуздо. Розберіть її один раз, витягніть потрібне й викиньте розмітку. Модель однаково отримає корисні факти, не тягаючи за собою тисячі марних токенів.

3. Віддавайте важкі обчислення інструментам

Математику, симуляції й перетворення даних не варто опрацьовувати міркуваннями токен за токеном. Цю роботу може зробити інструмент на Python або бекенд-сервіс, а модель отримає лише компактний підсумок: одне число, невелике структуроване зведення або кілька ключових статистик.

Скажімо, треба проаналізувати величезний CSV. Не вставляйте його в промпт. Хай інструмент порахує статистику й повідомить щось на кшталт «100 тис. рядків, середня ціна 23.4, 5% порожніх значень у стовпці X». Це значно дешевше, ніж надсилати у вікно весь набір даних. Модель міркує, інструменти рахують.

4. Тримайте незмінні правила в системному промпті

Деякі інструкції за всю розмову не змінюються:

• тон асистента
• доступні інструменти
• вимоги до форматування
• еталонні приклади

Викладіть їх один раз у системному повідомленні й перестаньте повторювати. Якщо агент завжди має відповідати в одній конкретній JSON-структурі, нема чого нагадувати про це в кожному ході користувача. Залежно від розміру інструкції й частоти викликів моделі заощадження за довгу сесію може сягати сотень і навіть тисяч токенів.

5. Передавайте дескриптори, а не величезні блоки

Уявіть схему бази даних із тисяч рядків SQL, приблизно 20 000 токенів. Замість того щоб класти її у вікно, повідомте агентові, що схема зберігається під іменем на кшталт schema_v2 і за потреби її можна отримати через інструмент get_schema.

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

• схем баз даних
• довгих документів
• конфігураційних файлів
• документації API
• баз знань

Агент тримає невелике посилання й підтягує справжній вміст на вимогу.

6. Скорочуйте вивід інструментів, перш ніж його побачить модель

Сирий величезний вивід інструментів за можливості не має потрапляти просто в модель. Кілька типових скорочень:

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

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

100,000 rows
Average price: 23.4
Null values in column X: 5%

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

7. Використовуйте ковзне вікно

Остання техніка зберігає лише N останніх повідомлень, наприклад десять, разом зі зведенням ранніших ходів і невеликим сховищем важливих фактів. Кожен запит несе обмежене вікно недавніх повідомлень і найсуттєвіше з минулого, а не весь транскрипт.

Недавня частина може виглядати так:

Recent context:
Message 31
Message 32
...
Message 40

а частина зі старою інформацією — так:

Earlier summary:
User is building a Python CLI app.
Click was selected.
Three commands have been implemented.Important memory:
Tests and documentation are still pending.

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

З чого почати

Отже, сім технік:

1. стиснення контексту
2. відсіювання повідомлень і фільтрація за доречністю
3. винесення обчислень в інструменти
4. системні промпти для незмінних правил
5. дескриптори-замісники замість повного тексту
6. стиснений вивід інструментів
7. ковзне вікно

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