Kur konteksti e pengon AI-në: Pse agjenti duhet të dijë edhe çfarë të harrojë?

Kur një AI Agent punon mbi një detyrë software, konteksti është një nga burimet e tij më të rëndësishme. Ai mund të përfshijë kërkesën e përdoruesit, skedarët e projektit, historinë e ndryshimeve, udhëzimet e ekipit, arkitekturën e sistemit dhe përfundimet e nxjerra nga detyra të mëparshme.

Në pamje të parë, mund të duket se sa më shumë informacion të marrë agjenti, aq më i mirë do të jetë rezultati. Nëse AI-ja njeh më shumë pjesë të repository-t dhe ruan më shumë histori, ajo duhet të jetë në gjendje të marrë vendime më të sakta.

Por sasia e kontekstit nuk është e barabartë me cilësinë e kontekstit.

Informacioni i vjetër, i parëndësishëm ose kontradiktor mund ta largojë agjentin nga problemi që duhet të zgjidhë. Në vend që ta ndihmojë, historia e tepërt mund ta bëjë procesin më të kushtueshëm, më të ngadaltë dhe më pak të fokusuar.

GitHub ka njoftuar se kërkuesit e tij kanë ndërtuar një benchmark duke përdorur sekuenca pull requests reale dhe kanë analizuar ndikimin e kontekstit të grumbulluar. Tema që do të prezantohet në GitHub Universe 2026 fokusohet pikërisht te ajo që një agjent duhet të mbajë mend dhe te informacioni që duhet të lërë pas.

Kjo e zhvendos pyetjen nga “sa kontekst mund të ruajë AI-ja?” te një pyetje më e rëndësishme: “cili kontekst është ende i vlefshëm për detyrën aktuale?”

Konteksti dhe memoria nuk janë e njëjta gjë

Konteksti është informacioni që agjenti përdor gjatë një detyre të caktuar. Ai mund të përfshijë prompt-in, skedarët e hapur, rezultatet e kërkimit, përdorimin e mjeteve dhe përgjigjet e mëparshme.

Memoria, nga ana tjetër, është informacioni që ruhet për t’u përdorur në detyra të ardhshme.

Një agjent mund të zbulojë, për shembull, se versioni i një API-je duhet të jetë i njëjtë në kodin e klientit, në server dhe në dokumentacion. Ky është një përfundim që mund të jetë i dobishëm edhe gjatë një ndryshimi të ardhshëm.

Nëse ky informacion ruhet si memorie, një agjent tjetër mund ta përdorë më vonë për të kontrolluar nëse të gjitha vendet janë përditësuar.

Por jo çdo informacion që shfaqet gjatë një detyre duhet të ruhet.

Një skedar i hapur rastësisht, një degë zhvillimi që nuk u bashkua me kodin kryesor apo një zgjidhje e përkohshme nuk duhet të trajtohen automatikisht si njohuri afatgjatë për projektin.

Prandaj, menaxhimi i kontekstit AI kërkon një ndarje të qartë ndërmjet informacionit të përkohshëm dhe njohurive që meritojnë të ruhen.

Më shumë informacion mund ta largojë agjentin nga problemi

Gjatë një code review, agjenti duhet të kuptojë nëse ndryshimi i propozuar krijon një problem real. Për ta bërë këtë, zakonisht duhet të nisë nga diff-i dhe të kërkojë vetëm kodin që lidhet me pyetjen e kontrollit.

Nëse në vend të kësaj ai fillon të eksplorojë gjerësisht repository-n, çdo rezultat kërkimi dhe çdo skedar i lexuar i shtohet kontekstit të punës.

Ky informacion vazhdon të shoqërojë arsyetimin e agjentit edhe kur nuk është më i dobishëm. Si pasojë, agjenti mund të shpenzojë më shumë burime duke analizuar materiale të parëndësishme dhe të humbasë fokusin te ndryshimi që duhet të kontrollojë.

GitHub ka raportuar një rast ku mjete më të mira për eksplorimin e kodit e përkeqësuan fillimisht rezultatin e Copilot code review. Agjenti kërkonte shumë gjerësisht, lexonte më tepër kod sesa nevojitej dhe grumbullonte kontekst gjatë procesit. Pas përshtatjes së udhëzimeve që e orientonin të nisej nga diff-i dhe të kërkonte prova të kufizuara, kostoja mesatare e review-t u reduktua me rreth 20%, duke ruajtur të njëjtën cilësi.

Kjo tregon se aftësia për të gjetur më shumë informacion nuk është gjithmonë përmirësim. Vlera qëndron te gjetja e informacionit të duhur.

Konteksti duhet të përputhet me detyrën

Një agjent që implementon një funksion dhe një agjent që kontrollon një pull request nuk kanë të njëjtën nevojë për kontekst.

Agjenti që implementon një ndryshim mund të ketë nevojë të kuptojë arkitekturën e një moduli, varësitë me komponentët e tjerë dhe mënyrën si testohet funksionaliteti.

Agjenti i code review-t duhet të jetë më i fokusuar. Ai duhet të nisë nga ndryshimi konkret, të formulojë pyetje të sakta dhe të kërkojë vetëm provat që nevojiten për të konfirmuar ose hedhur poshtë një problem.

Edhe kur të dy agjentët përdorin të njëjtat mjete, mënyra si duhet ta mbledhin kontekstin është e ndryshme.

Kjo do të thotë se menaxhimi i kontekstit nuk mund të zgjidhet me një rregull universal. Çdo rol duhet të ketë kufij, strategji kërkimi dhe kritere të qarta për informacionin që mund të ngarkojë.

Një agjent nuk duhet të lexojë të gjithë repository-n vetëm sepse ka mundësi ta bëjë këtë. Ai duhet të lexojë pjesën që lidhet me vendimin që po përpiqet të marrë.

Informacioni i saktë sot mund të jetë i gabuar nesër

Software-i ndryshon vazhdimisht.

Një rregull i identifikuar në një degë të projektit mund të zëvendësohet përpara se ajo degë të bashkohet. Një konventë kodimi mund të ndryshojë. Një komponent mund të hiqet, ndërsa një varësi mund të zëvendësohet me një zgjidhje tjetër.

Nëse AI-ja ruan një përfundim pa kontrolluar burimin e tij, ajo mund ta përdorë atë edhe pasi informacioni të ketë humbur vlefshmërinë.

Problemi nuk është vetëm se memoria është e vjetër. Problemi është se ajo mund të duket ende bindëse.

Një përfundim i ruajtur nga AI-ja mund të jetë shkruar qartë dhe të tingëllojë teknikisht i saktë, edhe pse kodi aktual nuk e mbështet më.

Për këtë arsye, memoria nuk duhet të përdoret si e vërtetë e pandryshueshme. Ajo duhet të trajtohet si një informacion që kërkon verifikim ndaj gjendjes aktuale të sistemit.

Memoria duhet të ruajë edhe burimin e saj

Një mënyrë për të kufizuar përdorimin e memories së pasaktë është që çdo informacion i ruajtur të shoqërohet me referencën që e mbështet.

Në sistemin e përshkruar nga GitHub, memoriet ruhen me citime drejt vendndodhjeve konkrete në kod. Përpara se ta përdorë një memorie, agjenti kontrollon në kohë reale nëse skedarët dhe pjesët e referuara vazhdojnë ta mbështesin atë informacion.

Nëse kodi e kundërshton memorien ose vendndodhja nuk ekziston më, agjenti nuk duhet ta përdorë përfundimin e vjetër. Ai mund ta korrigjojë atë duke u bazuar te provat e reja.

Kjo qasje e zhvendos verifikimin në momentin e përdorimit. Në vend që sistemi të përpiqet ta pastrojë vazhdimisht të gjithë memorien, ai kontrollon informacionin kur bëhet i nevojshëm për një detyrë konkrete.

GitHub raporton se në testet e tij, përdorimi i memories së verifikuar solli një rritje prej 3% në precision dhe 4% në recall gjatë code review.

Pra, memoria mund ta përmirësojë rezultatin, por vetëm kur informacioni ruhet dhe përdoret me mekanizma verifikimi.

Të harrosh është pjesë e inteligjencës së sistemit

Harresa zakonisht shihet si kufizim. Në sistemet me AI, ajo mund të jetë një mekanizëm i rëndësishëm kontrolli.

Një memorie që nuk është përdorur për një periudhë të gjatë mund të mos jetë më relevante. Një informacion që nuk mund të verifikohet duhet të largohet. Një përfundim që lidhet me një degë të braktisur nuk duhet të vazhdojë të ndikojë te detyrat e reja.

Copilot Memory i kufizon memoriet në nivel repository dhe i kontrollon ato ndaj codebase-it aktual përpara përdorimit. GitHub gjithashtu përcakton një afat automatik prej 28 ditësh për memoriet, ndërsa pronarët e repository-t mund t’i kontrollojnë dhe t’i fshijnë ato.

Kjo tregon se harresa nuk duhet të ndodhë rastësisht. Ajo mund të projektohet përmes afateve të skadimit, kontrollit të burimeve dhe mekanizmave të administrimit.

Një sistem i mirë memorieje nuk është ai që ruan gjithçka. Është ai që ruan informacionin e dobishëm për aq kohë sa ai vazhdon të jetë i vlefshëm.

Konteksti duhet të përzgjidhet, jo të ngarkohet i gjithi

Kur fillon një detyrë të re, agjenti mund të ketë akses në histori bisedash, dokumentacion, memories të repository-t, skedarë dhe rezultate nga procese të mëparshme.

Ngarkimi i të gjitha këtyre të dhënave në prompt nuk është domosdoshmërisht strategjia më e mirë.

Sistemi duhet të përcaktojë se cilat informacione lidhen me objektivin aktual. Një detyrë mbi autentikimin mund të ketë nevojë për rregullat e sigurisë dhe varësitë përkatëse, por jo për historinë e një ndryshimi të vjetër në ndërfaqen grafike.

Kjo kërkon mekanizma për kërkimin, renditjen dhe filtrimin e memories. Informacionet mund të vlerësohen sipas lidhjes me pyetjen, kohës kur janë krijuar, besueshmërisë së burimit dhe vlefshmërisë së tyre në kodin aktual.

Objektivi nuk është ta mbushësh dritaren e kontekstit. Objektivi është t’i japësh agjentit informacionin minimal që i nevojitet për të marrë një vendim të saktë.

Memoria e përbashkët mund të shpërndajë njohuri dhe gabime

Kur disa AI Agents punojnë mbi të njëjtin projekt, memoria mund të lejojë që njohuritë e zbuluara nga njëri të përdoren nga të tjerët.

Një agjent code review mund të identifikojë një konventë të rëndësishme. Një agjent programimi mund ta zbatojë atë gjatë krijimit të një shërbimi të ri, ndërsa një agjent në terminal mund ta përdorë gjatë diagnostikimit të një problemi.

Kjo mund të reduktojë nevojën për t’ia shpjeguar të njëjtin kontekst secilit agjent.

Por memoria e përbashkët krijon edhe një rrezik. Nëse një informacion i gabuar ruhet dhe nuk verifikohet, ai mund të shpërndahet në disa procese. Një gabim i vetëm mund të ndikojë te implementimi, kontrolli i kodit dhe diagnostikimi.

Prandaj, ndarja e memories duhet të shoqërohet me ndarjen e provave. Agjentët nuk duhet të trashëgojnë vetëm një përfundim, por edhe mundësinë për të kontrolluar burimin e tij.

Menaxhimi i kontekstit bëhet pjesë e arkitekturës

Në sistemet tradicionale, konteksti mund të jetë thjesht një pjesë e prompt-it. Kur AI Agents fillojnë të punojnë në procese afatgjata, ai bëhet një komponent arkitekturor.

Sistemi duhet të përcaktojë se ku ruhet memoria, kush mund ta krijojë, cilët agjentë mund ta lexojnë, sa kohë qëndron aktive dhe si kontrollohet vlefshmëria e saj.

Duhet gjithashtu të jetë e mundur të kuptohet se cili informacion ndikoi në një vendim të agjentit.

Nëse AI-ja propozon një ndryshim duke u bazuar në një memorie të mëparshme, ekipi duhet të jetë në gjendje të shohë se çfarë përmbante ajo memorie, nga cili kod ishte nxjerrë dhe nëse u verifikua përpara përdorimit.

Kjo e bën menaxhimin e kontekstit pjesë të auditimit, sigurisë dhe përgjegjësisë së sistemit.

AI duhet të dijë jo vetëm çfarë di, por edhe pse e di

Për Soft&Solution Group, memoria e një AI Agent nuk duhet të trajtohet si një depo e pakufizuar informacioni.

Vlera e saj varet nga aftësia për të lidhur çdo përfundim me një burim, për ta kontrolluar ndaj gjendjes aktuale të sistemit dhe për ta larguar kur nuk është më i vlefshëm.

Siç shprehet Ermal Beqiri, themelues i Soft&Solution Group:

“Një AI Agent nuk bëhet më i saktë vetëm sepse ruan më shumë informacion. Ai duhet të dallojë çfarë lidhet me detyrën aktuale, të verifikojë nëse memoria vazhdon të mbështetet nga sistemi dhe të lërë pas kontekstin që nuk është më i vlefshëm. Inteligjenca nuk qëndron vetëm te ajo që agjenti kujton, por edhe te mënyra si zgjedh çfarë të përdorë.”

AI Agents po kalojnë nga biseda të izoluara drejt proceseve që mund të vazhdojnë në disa detyra, mjete dhe faza të zhvillimit. Në këtë model, memoria mund të ruajë njohuritë e projektit dhe ta bëjë punën më të qëndrueshme.

Por memoria e pakontrolluar mund të krijojë zhurmë, të rrisë kostot dhe të shpërndajë informacion të vjetruar.

Për këtë arsye, menaxhimi i kontekstit AI nuk duhet të fokusohet te ruajtja e çdo gjëje. Ai duhet të përcaktojë çfarë ia vlen të ruhet, si verifikohet dhe kur duhet të harrohet.

AI-ja më e dobishme nuk është ajo që mban mend gjithçka. Është ajo që përdor informacionin e duhur, në momentin e duhur dhe për arsyen e duhur.