Контекст, меморија и работниот простор на AI

Еден едноставен експеримент

Замисли дека разговараш со колега за нов SaaS проект цели 30 минути.

Во разговорот поминувате низ:

• архитектурата на системот;
• базата на податоци;
• API интеграциите;
• корисничките улоги;
• плаќањата;
• безбедноста;
• аналитиката;
• AI модулите.

На крајот му велиш:

Нормално е колегата да знае на што мислиш, затоа што го памети разговорот и ја има целата претходна слика за проектот.

Сега замисли дека некој во средината на разговорот избришал половина од дискусијата.

Одеднаш колегата можеби повеќе не знае:

• на кој проект работите;
• која база ја користите;
• кои технологии сте ги избрале;
• каква е архитектурата;
• кои одлуки веќе сте ги донеле.

Токму тука започнува концептот на Context Window.

Контекстот е работната маса на AI

Најлесно е да го замислиш контекстот како работна маса.

На една нормална маса можеш удобно да поставиш:

• лаптоп;
• телефон;
• тетратка;
• неколку документи.

Но ако се обидеш на истата маса да ставиш 200 книги, 15 лаптопи и 50 папки, повеќе нема да имаш простор за нормална работа.

Истото важи и за AI.

Што се случува кога контекстот станува предолг?

Не треба да претпоставуваш дека секој AI систем бесконечно ги задржува сите претходни информации.

Во зависност од конкретниот модел и платформата, постарите информации може повеќе да не бидат дел од активниот контекст, да бидат скратени, резимирани или обработени преку посебен механизам за меморија.

Затоа моделот понекогаш може да изгледа како да „заборавил“ нешто што сте го договориле претходно.

Реален пример со Laravel проект

Замисли дека имаш Laravel проект со:

• 300 PHP датотеки;
• 120 JavaScript датотеки;
• 50 миграции;
• 40 Blade шаблони;
• конфигурациски датотеки;
• tests;
• документација.

Еден чест пристап е:

Тоа речиси никогаш не е најдобар начин за работа.

Многу подобар пристап е:

• прво да ја објасниш архитектурата;
• да ја прикажеш структурата на проектот;
• да дефинираш конкретен проблем;
• да работиш модул по модул;
• на крај да направиш интеграција и проверка на целината.

Зошто AI понекогаш си противречи?

Ова е едно од најчестите прашања при подолга работа со AI.

На пример, на почетокот од разговорот му кажуваш:

По многу пораки, моделот одеднаш предлага решение за MySQL.

Тоа не мора да значи дека моделот „не знае“ што е PostgreSQL.

Може едноставно информацијата за избраната база повеќе да не биде доволно видлива во активниот контекст или да биде потисната од поголема количина понови информации.

Работи во структурирани сесии

Наместо еден бесконечен разговор со стотици пораки за сите можни теми, многу подобро е работата да ја поделиш на јасни сесии.

На пример:

• архитектура;
• backend;
• frontend;
• база на податоци;
• тестирање;
• безбедност;
• документација;
• deployment.

На пример:

Со ваков пристап моделот многу полесно разбира каде сте застанале и што треба да продолжи.

Контекст не е исто што и меморија

Овие два поими често се мешаат.

Не секоја AI апликација има ист тип на меморија, а не секоја зачувана информација автоматски е дел од активниот контекст.

Затоа професионалниот систем мора јасно да дефинира што се чува, колку долго се чува, кога се вчитува и кој има пристап до тие информации.

Практична задача

Направи два одделни разговора со AI.

Разговор А

Разговор Б

Спореди:

• колку добро AI го следи контекстот;
• колку често си противречи;
• колку корекции се потребни;
• колку лесно продолжува од претходната точка.

Зошто AI е толку важен?

AI не е само уште една технологија во листата на алатки.

Тој постепено станува нов функционален слој што може да се вградува во огромен број софтверски системи.

Како што денес е нормално една апликација да има интернет конекција, database, API и authentication, така сè повеќе апликации ќе имаат и некаква форма на AI capability.

Но тоа не значи дека секоја функција треба да стане AI.

Митови што треба да ги заборавиш

Мит 1: AI ќе ги замени сите програмери

Мит 2: AI секогаш е во право

Мит 3: Доволно е да научам еден модел

Практичен пример: систем за резервации

Замисли дека треба да изградиш систем за резервации.

Класичен пристап

• програмерот ги дефинира правилата;
• корисникот пополнува форма;
• системот ги проверува условите;
• податоците се зачувуваат во база;
• корисникот добива потврда.

Пристап со AI

• AI може да му помогне на корисникот да го формулира барањето;
• да предложи најсоодветни слободни термини;
• да открие потенцијални конфликти;
• да создаде персонализирана потврда;
• да анализира трендови во резервациите;
• да предложи оперативни подобрувања.

Од работната маса на авторот

Кога првпат почнав да експериментирам со AI, мислев дека најважно е да научам како функционира конкретен модел.

Со текот на времето сфатив дека моделите се менуваат многу побрзо отколку инженерските принципи.

Денес многу поголемо внимание посветувам на архитектурата, процесите, податоците, контекстот и начинот на размислување отколку на тоа кој модел е моментално најпопуларен.

Клучни поенти

• Context Window е активниот работен простор на моделот.
• Контекстот и меморијата не се ист концепт.
• Долг разговор не гарантира дека секоја стара информација останува релевантна или достапна.
• За сложени проекти е подобро да се работи во јасно организирани сесии.
• Кратките резимеа значително ја подобруваат конзистентноста при продолжување на работата.
• Критичните архитектонски и деловни одлуки треба експлицитно да се документираат.
• AI не треба да се додава во секоја функција само затоа што е достапен.
• Архитектурата и процесите се подолгорочно поважни од изборот на конкретен модел.

Master Mission

Пред да продолжиш, одговори на следните прашања:

• Кои информации во твојот проект се толку важни што AI секогаш треба повторно да ги добие како контекст?
• Дали твоите AI разговори се организирани по проект и задача или мешаш повеќе теми во ист контекст?
• Ако денес исчезне моделот што најчесто го користиш, дали архитектурата на твојот систем би можела лесно да премине на друг?
• Кои функции во твојот систем навистина имаат корист од AI, а кои се подобро решени со класична логика?
• Дали AI го гледаш како алатка или како контролирана компонента во поширока архитектура?