Чому ШІ забуває ваші інструкції посеред роботи

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

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

Контекстне вікно простими словами

Велика мовна модель не памʼятає розмову так, як памʼятає людина. LLM щоразу отримує весь діалог заново, цілим шматком, і в цього шматка є фізична межа. Називається ця межа контекстним вікном.

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

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

Чому в українській мові це відбувається частіше

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

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

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

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

Три правила, після яких це перестає ламатись

Перше: один чат на одну задачу. Це найдієвіше і найпростіше.

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

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

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

Ознаки, що контекстне вікно вже переповнене

Момент переповнення не оголошується, але він помітний, якщо знати, на що дивитись:

• модель починає відповідати загально там, де до цього відповідала конкретно

• LLM перестає бачити файл, який ви завантажили на початку

• зʼявляються вигадані деталі, яких у ваших документах не було

• модель просить уточнити те, про що ви вже домовлялись

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

Окрема історія: коли думати не треба

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

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

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

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

Що робити, коли задача не влазить у принципі

Буває, що документ або масив даних завеликий, і ніякі чати не рятують.

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

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

Як переносити роботу в новий чат без втрат

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

Порядок, який знімає проблему за пʼять хвилин:

• перед тим як закривати чат, попросіть коротке зведення: що вирішено, які обмеження, які файли використані, на якому кроці зупинились

• перевірте це зведення очима. Модель переказує сама себе, і на цьому кроці легко губиться деталь — краще спіймати її зараз

• відкрийте новий чат і почніть із цього зведення, а не з переказу історії

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

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

Файл у чаті і файл у базі знань це різні речі

Плутанина, через яку люди вирішують, що інструмент не вміє працювати з документами.

Коли ви кидаєте файл прямо в діалог, його вміст займає місце у вікні нарівні зі звичайним текстом. Великий документ зʼїдає вікно одразу, і далі все йде за описаним сценарієм.

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

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

Чому нові версії не знімають проблему

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

Вікно справді росте. Але росте і те, що в нього кладуть: більші файли, довші ланцюжки, більше кроків в одній задачі. Але задачі ростуть разом із вікном: більше вікно люди одразу починають заповнювати більшими задачами.

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

Головне про контекстне вікно

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

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

Механіку запитів і роботу з контекстом ми розбираємо на тренінгу з промпт-інжинірингу, а короткі відповіді на типові питання є в FAQ.