Бо в моделі є робочий стіл обмеженого розміру, і кожне нове повідомлення, файл чи скріншот займає на ньому місце. Коли стіл заповнений, найперше з поля зору зсуваються ранні правила, перші факти і те технічне завдання, з якого все починалося. Модель при цьому продовжує відповідати так само впевнено.
Коротко
- Модель читає розмову частинами, які називаються токенами. Усе, що вона бачить одночасно, вміщується у вікно контексту, і це вікно має межу.
- Коли розмова виростає, продукт або відкидає найстаріші частини, або стискає їх у короткий переказ. В обох випадках деталі з початку розмови втрачаються, а першими зникають правила, які ви дали на старті.
- Скріншоти таблиць займають на столі набагато більше місця, ніж ті самі дані у файлі, і при цьому передають їх гірше.
- Змішування кількох схожих документів в одній довгій розмові призводить до того, що модель переносить умови з одного документа в інший.
- Рішення полягає в тому, щоб вчасно стиснути завдання до короткого стану справи і почати нову розмову з ним і з потрібними файлами.
Дві історії з одного тижня
Минулого місяця до мене звернулася команда, яка готувала аналітику по продажах. Дані в них лежали в Excel, але працювати з ними в моделі вирішили через скріншоти: відкривали таблицю, робили знімок екрана, вставляли в розмову, питали, робили наступний знімок. За годину в розмові було кілька десятків картинок. Потім продукт повідомив, що ліміт використання вичерпано, і наступну відповідь команда змогла отримати приблизно через п'ять годин. Робочий день пропав. Коли ми потім подивилися на ту саму задачу, виявилося, що весь обсяг даних у вигляді одного файлу займав у розмові малу частку того місця, яке забрали скріншоти. І модель читала файл точніше, бо цифри в ньому лежали як цифри, а на картинці їх ще треба було розпізнати.
Друга історія з юридичної практики. Компанія з кількома локаціями перевіряла договори оренди, і для зручності юрист складала всі договори в одну розмову: спочатку перший, потім другий, потім третій, з питаннями до кожного. Через деякий час модель почала відповідати про строки й штрафи одного приміщення цифрами з договору іншого. Ніхто не помічав цього одразу, бо договори були схожі за структурою, а відповіді звучали переконливо. Після цього команда ввела правило: один договір живе в одній розмові, а модель шукає відповіді лише в наданому файлі і цитує рядок, на який спирається. Перевірка людиною лишилася, але тепер людина звіряє цитату з конкретним місцем документа.
Обидві історії про одне й те саме явище. Команди не зробили нічого дивного, вони працювали так, як працюють у звичайному месенджері, де історія листування нічого не коштує. У моделі історія коштує місця на столі, і місця цього скінченна кількість.
Що таке токен і вікно контексту
Токен - це шматочок тексту, яким модель рахує все, що читає і пише. Коротке англійське слово часто займає один токен. Українське слово через особливості навчання моделей зазвичай займає більше: два, три, іноді чотири токени, бо розбивається на частини. Фраза "перевірте строк оплати за договором" людина прочитає одним поглядом, а модель розкладе на помітно більшу кількість токенів, ніж здається на око. Картинка теж перетворюється на токени, і скріншот таблиці коштує в рази більше, ніж та сама таблиця в текстовому вигляді.
Вікно контексту - це обсяг токенів, який модель тримає перед очима одночасно. У нього потрапляє все: ваші правила на старті, кожне ваше повідомлення, кожна відповідь моделі, кожен файл і кожна картинка. Сучасні моделі мають великі вікна, до сотень тисяч токенів, і на коротких задачах цю межу ніхто не відчуває. На довгій робочій розмові з файлами, правками і десятками уточнень межа настає значно швидше, ніж здається.
Я пояснюю це через стіл. Уявний стіл моделі вміщує певну кількість аркушів. Кожне ваше повідомлення - новий аркуш, кожна відповідь моделі - ще один, кожен скріншот - кілька аркушів одразу. Поки стіл вільний, модель бачить усе. Коли він заповнений, щось доводиться зсунути.
Що відбувається, коли стіл заповнюється
Тут продукти поводяться по-різному. Одні відкидають найстаріші повідомлення, і вони зникають повністю. Інші стискають початок розмови в короткий переказ і кладуть на стіл замість оригіналу. Стиснення звучить краще, але переказ завжди коротший за оригінал, і першими з нього випадають деталі: конкретна цифра, виняток з правила, формулювання, яке ви довго погоджували.
Є і третій ефект, який працює ще до того, як стіл заповнився. Навіть коли вся розмова формально вміщується у вікно, модель гірше тримає в робочому фокусі те, що лежить далеко від останніх повідомлень. Свіжі аркуші зверху, старі внизу стосу. Правило, яке ви дали на першому кроці, фізично є на столі, але на сотому кроці модель спирається на нього слабше, ніж на останні десять реплік.
Тому ранні правила зникають першими. Ви на старті написали: відповідай лише з наданого файлу, суми в гривнях без копійок, строки в календарних днях. Три години по тому модель раптом додає копійки і рахує в робочих днях. З вашого погляду вона забула домовленість. З погляду механіки домовленість або вилетіла зі столу, або опинилася так глибоко в стосі, що нові повідомлення її перекрили.
Мені тут пригадується робота з інвестиційними мандатами. Коли клієнт на першій зустрічі ставив обмеження, наприклад, частка однієї компанії в портфелі не більше десяти відсотків, це обмеження записували в документ, який лежав зверху кожної справи. Ніхто не розраховував, що менеджер портфеля через пів року згадає його з пам'яті після сотні дзвінків. З моделлю діє той самий принцип: правило, яке має працювати завжди, повинно щоразу лежати зверху, а не на початку довгої історії.
Чому з довжиною падає якість відповідей
Коли стіл переповнений або перекошений до останніх реплік, у відповідях з'являються три симптоми. Модель плутає факти між документами, як у випадку з договорами різних локацій. Модель порушує правила, які діяли на старті. І модель починає впевнено відповідати на питання, дані для якого вже зсунулися зі столу. Останнє найнебезпечніше, бо зовні виглядає як нормальна робота.
Сама довжина розмови при цьому нічого не каже про те, скільки там корисної інформації. У типовому довгому треді більша частина місця зайнята чернетками, які вже відкинуті, проміжними варіантами, повторними поясненнями і відповідями моделі, які ніхто не читав до кінця. Ця маса витісняє зі столу саме те, що важить: погоджене технічне завдання і перевірені факти.
Як стиснути завдання, не повторюючи весь чат
Коли розмова стала довгою, найкращий крок - зупинитися і скласти стан справи. Це короткий документ на одну сторінку, у якому є тільки те, що має значення для продовження роботи. Технічне завдання, тобто ТЗ, тут стискається до кількох речень: що ми робимо і для кого. Далі йдуть правила, які діють завжди: формат, одиниці, джерела, заборони. Потім перевірені факти з посиланням на файл чи рядок. Потім рішення, які вже ухвалені, щоб модель не пропонувала їх заново. І відкриті питання, з яких починається наступний крок.
Скласти такий документ можна попросити саму модель, поки розмова ще в робочому стані: "Зведи стан справи за цією структурою, для кожного факту вкажи джерело, нічого не додавай від себе". Після цього стан справи обов'язково читає людина, бо модель могла вже втратити частину ранніх деталей, і саме зараз їх найлегше повернути. Далі відкривається нова розмова, куди кладуться стан справи і тільки ті файли, які потрібні для наступного кроку. Стіл знову вільний, правила лежать зверху, і модель бачить завдання цілком.
Для повторюваної роботи стан справи з часом перетворюється на постійний файл правил, який підтягується до кожної нової розмови. Тоді довжина окремого треду перестає мати значення: розмови стають короткими і одноразовими, а знання про задачу живе в документі.
Мій висновок такий: довга розмова псує відповіді, бо вікно контексту моделі скінченне, і коли воно заповнюється, модель втрачає або стискає ранні частини, а з ними правила, перші факти і вихідне завдання. Керувати цим можна трьома звичками: давати моделі дані файлами, а не скріншотами, тримати один документ в одній розмові і вчасно переносити роботу в нову розмову з коротким станом справи. Для власника бізнесу це означає менше тихих помилок у договорах, звітах і розрахунках і менше робочих днів, втрачених через вичерпаний ліміт.
Що робити далі
- Передавайте моделі таблиці файлом Excel або CSV замість скріншотів. Це економить місце на столі і дає моделі цифри без розпізнавання з картинки.
- Тримайте один договір, один звіт чи одну справу в одній розмові і просіть модель шукати відповіді лише в наданому файлі, з цитатою рядка.
- Домовтеся в команді про сигнал для переходу: розмова тягнеться понад годину, модель уперше порушила правило зі старту або назвала факт, якого ви в ній не бачите.
- На цьому сигналі просіть модель скласти стан справи за структурою: завдання, правила, перевірені факти з джерелами, ухвалені рішення, відкриті питання. Прочитайте його і виправте втрачене.
- Почніть нову розмову зі станом справи і потрібними файлами, а для повторюваних задач збережіть правила в окремому файлі, який додається до кожної нової розмови.
Про цей матеріал
Текст спирається на практику впровадження ШІ в невеликих компаніях і командах, з якими я працюю. Історії зі скріншотами і з договорами різних локацій взяті з реальних робочих сесій, усі деталі, за якими можна впізнати компанії, прибрані. Механіка токенів і вікна контексту описана в загальному вигляді, бо конкретні ліміти й способи стиснення відрізняються між продуктами і змінюються з оновленнями. Я Михайло Пацан, вісімнадцять років працював на фінансових ринках, а тепер допомагаю підприємцям упроваджувати ШІ і навчаю цього керівників.