Context Engineering: Susi sa Tino at Murang AI

Inilalarawan pa rin ng karamihan sa mga tao ang isang AI agent bilang isang modelong nakakonekta sa mga tool. Teknikal na kapaki-pakinabang ito ngunit hindi sapat sa pagpapatakbo. Kailangan din ng isang agent ng pinamamahalaang pananaw sa mundo: ano ang nangyari na, ano ang mahalaga ngayon, aling mga katotohanan ang mapagkakatiwalaan, ano ang nananatiling hindi tiyak, at ano ang dapat nitong gawin sa susunod.

Ang pananaw na iyon ang konteksto nito. Ang pagdidisenyo nito ay nagiging isang natatanging kasanayan—na tatawagin kong context engineering.

Ang context engineering ay hindi lamang pagsusulat ng prompt. Isa itong disiplina ng paghubog sa impormasyong nakikita ng isang agent sa bawat hakbang upang manatili itong magkakaugnay nang hindi ipinapadala ang buong transcript, library ng dokumento, o kasaysayan ng tool pabalik sa isang mamahaling modelo sa bawat pagliko. Nasa pagitan ng arkitektura ng impormasyon, retrieval, disenyo ng software, at pag-uugali ng modelo ang gawaing ito.

Bakit madalas na masamang payo ang “bigyan ang agent ng mas maraming konteksto”

Nakakatukso ang mas mahahabang context window na panatilihin ang lahat. Ngunit hindi ginagarantiyahan ng mas maraming materyal ang mas mahusay na pangangatwiran. Maaaring matabunan ang mahahalagang tagubilin ng mga lumang obserbasyon, magkakasalungat na tala, paulit-ulit na output ng tool, o isang mahalagang katotohanang nakabaon sa gitna ng mahabang pagkakasunod-sunod. Sinasalamin ng pagtalakay ng digest sa gawi na “lost in the middle” ang isang praktikal na problema: maaaring teknikal na matanggap ng isang agent ang ebidensiya ngunit mabigo pa rin itong gamitin.

Mayroon ding direktang gastos. Bawat token na inilalagay sa isang request ay maaaring magdagdag sa latency at gastos sa inference, depende sa pagpepresyo at mga kaayusan sa caching ng provider. Ang sistemang paulit-ulit na nagpapasa ng lumalaking transcript ay maaaring bumagal at maging mas mahal habang nagpapatuloy ang isang gawain.

Kaya ang layunin ay hindi maximum na konteksto. Ito ay sapat at nakatuong konteksto: ang pinakamaliit na mapagkakatiwalaang working set para sa desisyong kinakaharap.

Apat na desisyong pangdisenyo sa likod ng magkakaugnay na agent

1. Panatilihin ang belief state, hindi lamang ang transcript

Itinatala ng transcript ang mga sinabi. Itinatala naman ng belief state ang kasalukuyang pinaniniwalaan ng agent tungkol sa gawain.

Halimbawa, maaaring magpanatili ang isang agent na humahawak ng support escalation ng mga nakabalangkas na field tulad ng:

• Layunin: tukuyin kung kwalipikado ang customer para sa kapalit na produkto.
• Mga alam na katotohanan: petsa ng pagbili at serial number ng produkto, kasama ang mga sangguniang pinagmulan.
• Mga bukas na tanong: kung naganap ang pagkasira sa mga kondisyong saklaw ng warranty.
• Mga limitasyon: huwag mangako ng refund bago ang pag-apruba.
• Susunod na aksiyon: kunin ang patakaran sa warranty at ihambing ang mga petsa.
• Kumpiyansa o katayuan: beripikado, hinuha, pinagtatalunan, o hindi alam.

Kahawig ng pamamaraang ito ang pananaliksik ng ABBEL ng Berkeley, na gumagamit ng mga supervised na belief state sa natural na wika sa halip na umasa sa buong kasaysayan ng interaksiyon. Hindi ang isang partikular na format ang mahalagang ideya. Ang mahalaga ay paghiwalayin ang matibay na estado ng gawain mula sa mga detalyeng pang-usap na maaaring itapon.

Dapat masagot ng isang kapaki-pakinabang na update sa belief state ang mga ito: Ano ang nagbago? Anong ebidensiya ang sumusuporta rito? Ano ang nananatiling hindi nalulutas? Ano ang dapat mangyari sa susunod? Kung hindi masuri ng isang engineer ang mga sagot na iyon, malamang na may mga nakatagong palagay na dala ang agent sa isang malabong prompt.

2. Mag-retrieve para sa desisyon, hindi para sa paksa

Madalas nagsisimula ang mga retrieval system sa malawak na tanong gaya ng “maghanap ng impormasyon tungkol sa account ng customer.” Mas mainam ang query na nakaugnay sa susunod na desisyon: “kunin ang kasalukuyang tuntunin sa refund para sa mga pagbiling higit sa 30 araw na ang edad, na epektibo sa rehiyon ng customer.”

Mahalaga ang pagbabagong iyon dahil isang anyo ng pagpili ng konteksto ang retrieval. Dapat matanggap ng agent ang mga sipi ng patakaran, rekord, o halimbawang may kaugnayan sa kasalukuyang aksiyon—hindi isang pangkalahatang bunton ng mga kaugnay na dokumento.

Maaaring pagandahin ng mga filter ang pagpiling ito bago pa makakita ng anumang resulta ang modelo. Halimbawa, sinusuportahan ng Amazon Bedrock AgentCore Web Search ang mga filter sa domain at petsa ng publikasyon na ipinapatupad ng server sa bawat request. Hindi pinatutunayan ng gayong mga kontrol na tama ang isang pinagmulan, ngunit maaari nilang bawasan ang pagkakalantad sa hindi nauugnay o luma nang materyal at gawing hayag ang patakaran sa retrieval.

Dapat tukuyin ng mga propesyonal na nagdidisenyo ng retrieval ang mga sumusunod:

• kung aling mga pinagmulan ang pinahihintulutan para sa bawat gawain;
• kung paano tinutukoy ang pagiging bago;
• kung anong metadata ang kasama sa bawat resulta;
• kung paano inilalahad ang mga salungat na source;
• kung kailan dapat huminto ang agent at humingi ng paglilinaw.

Ang “Maghanap sa web” ay isang kakayahan. Ang “Maghanap sa mga source na ito, sa loob ng saklaw ng petsang ito, ng ebidensiyang nauugnay sa pasyang ito” ay context engineering.

3. Mag-compress nang hindi binubura ang kawalang-katiyakan

Kailangan ang compression kapag mahaba ang isang gawain, ngunit maaaring gawing tiyak na mga katotohanan ng payak na pagbubuod ang mga pahayag na pansamantala lamang. Mapanganib ang isang rolling summary na nagsasabing “kinumpirma ng user ang address” kung ipinahiwatig lamang ito ng orihinal na palitan ng mensahe.

Pinananatili ng mahusay na compression ang mga pagkakaibang kailangan ng isang agent para sa ligtas na pangangatwiran:

• katotohanan laban sa hinuha;
• kasalukuyang tagubilin laban sa makasaysayang tagubilin;
• nakumpletong aksyon laban sa iminungkahing aksyon;
• beripikadong source laban sa hindi beripikadong pahayag;
• alam na sagot laban sa tanong na hindi pa nalulutas.

Isang praktikal na paraan ang pagpapanatili ng magkakahiwalay na seksyon para sa mga pasya, ebidensiya, palagay, hadlang, at nakabinbing aksyon. Isa pa ang paglalagay ng mga source ID o timestamp sa mahahalagang pahayag. Dapat mapalitan ang mga summary bilang mga artifact, hindi ang mga ito ang tanging natitirang rekord: panatilihin ang mga pinagbabatayang kaganapan para sa pag-audit at pagbawi, habang binibigyan ang modelo ng isang siksik na working view.

Binabanggit sa digest na maaaring magastos ang recursive summarization at context compaction at maaari nitong pababain ang performance, lalo na sa mga domain na kakaunti ang datos gaya ng collaborative code generation. Babala ito laban sa awtomatikong pagtrato sa summarization bilang walang nawawalang impormasyon. Kailangang subukan ang compression sa mga kinatawang gawain, kabilang ang mga sitwasyong kung saan binabago ng isang maliit na paglilinaw ang tamang sagot.

4. Salain ang mga obserbasyon bago maging memorya ang mga ito

Patuloy na lumilikha ng mga obserbasyon ang mga agent na gumagamit ng tool: mga resulta ng paghahanap, log, teksto ng pahina, tugon ng API, screenshot, output ng compiler, at mga intermediate plan. Hindi lahat ng obserbasyon ay nararapat isama sa susunod na model call, lalo na sa pangmatagalang state.

Tatlong tanong ang itinatanong ng observation filtering:

1. May kaugnayan ba ang obserbasyong ito sa kasalukuyang pasya?
2. Sapat ba itong awtoritatibo upang maimpluwensiyahan ang belief state?
3. Naglalaman ba ito ng mga tagubiling dapat ituring na datos sa halip na mga utos?

Ang ikatlong tanong ay hangganan sa seguridad pati na rin hangganan sa konteksto. Maaaring maglaman ang isang web page ng tekstong naglalayong ilihis ang agent. Maaaring maging kapaki-pakinabang na ebidensiya ang isang nakuhang dokumento nang wala itong awtoridad na baguhin ang mga layunin o pahintulot ng agent. Kaya dapat uriin ng filtering ang nilalaman ayon sa papel nito: tagubilin, ebidensiya, metadata, o hindi pinagkakatiwalaang teksto.

Nakakatipid din ng pera ang filtering. Kung nagbabalik ang isang browser tool ng buong pahina ngunit presyo, petsa, at product identifier lamang ang kailangan ng gawain, ang pagpasa ng buong pahina ay lumilikha ng ingay at kumokonsumo ng mga token. Maaaring mapabuti ng pagkuha muna sa mga nauugnay na field ang pagiging maaasahan at gastos.

Isang simpleng context budget para sa workflow ng isang agent

Bago pumili ng modelo o magdagdag ng isa pang tool, imapa ang konteksto ng agent sa apat na layer:

1. Kontrol: mga tuntunin ng system, mga pahintulot, iskema ng output, at mga kondisyong hindi maaaring baguhin.
2. Estado: kasalukuyang layunin, mga napagpasyahan, mga bukas na tanong, at susunod na hakbang.
3. Ebidensya: mga nakuhang tala o obserbasyong may kaugnayan sa hakbang na iyon, kasama ang pinagmulan.
4. Kasaysayan: mga naunang pangyayaring itinatago para sa pagbawi, pag-debug, o pag-audit ngunit hindi isinasama maliban kung kinakailangan.

Pagkatapos, magtakda ng patakaran sa pag-promote. Maaaring manatiling pansamantala ang isang obserbasyon, maging ebidensya para sa kasalukuyang hakbang, mag-update sa kalagayan ng paniniwala, o maisulat sa pangmatagalang memorya. Dapat may dahilan ang pag-promote. Kung hindi, magiging hindi naisaayos na imbakan ang memorya.

Sa bawat hakbang ng agent, itala ang pakete ng kontekstong ipinadala sa modelo: ang mga kategorya nito, tinatayang laki sa token, mga filter sa retrieval, at bersyon ng compression. Dahil dito, masasagot ang isang praktikal na tanong kapag nagbago ang pag-uugali: nagkamali ba ang modelo, o maling mundo ang ibinigay dito ng system?

Ano ang dapat subukan bago ituring na maaasahan ang disenyo

Kailangang may mga pagsubok ang context engineering na nakatuon sa paghawak ng impormasyon, hindi lamang sa kalidad ng panghuling sagot. Kabilang sa mga kapaki-pakinabang na kaso ang:

• isang kritikal na katotohanang inilagay sa simula, sa hulihan, at sa gitna ng mahabang kasaysayan;
• dalawang source na hindi nagkakasundo, kung saan mas bago ang isa kaysa sa isa;
• isang buod na naglalaman ng panandang nagsasaad ng kawalang-katiyakan;
• isang tugon ng tool na naglalaman ng maraming hindi kaugnay na teksto;
• isang malisyosong utos na nakapaloob sa nakuhang content;
• pagpapanumbalik ng estado matapos i-pause at muling simulan ang agent;
• ang parehong gawain na may mas maliit na budget para sa konteksto;
• isang walang laman o lipas nang resulta ng retrieval.

Sukatin kung pinipili ng agent ang tamang ebidensya, napapanatili ang kawalang-katiyakan, sinusunod ang kasalukuyang constraint, at iniiwasang ulit-ulitin ang hindi kinakailangang konteksto. Lalo nang mahalaga rito ang mga inirerekomendang regression area ng digest—pagkawala ng konteksto, grounding ng retrieval, structured output, hindi pagwawakas, at pagpapanumbalik ng estado.

Magpatakbo ng maraming pagsubok kung mahalaga ang pagkakaiba-iba ng modelo, at ihambing ang gastos at latency ng bawat estratehiya sa konteksto. Hindi awtomatikong mas mahusay ang mas maikling prompt kung nagdudulot ito ng mas maraming tool call o retry. Ang kapaki-pakinabang na layunin ay ang gastos ng isang tama at maaaring mabawing workflow—hindi ang bilang ng token ng isang request.

Ang implikasyon sa karera: ang context engineer ay isang cross-functional na tungkulin

Ang mga taong magiging mahalaga sa larangang ito ay hindi kinakailangang yaong sumusulat ng pinakamahahabang prompt. Magagawa nilang isalin ang isang proseso ng negosyo tungo sa estado, ebidensya, awtoridad, at mga tuntunin sa pagpapasya.

Nangangailangan ito ng ilang kongkretong kakayahan:

• pagdidisenyo ng mga schema para sa estado ng gawain at provenance;
• pagsulat ng mga patakaran sa retrieval at mga filter ng metadata;
• pagbuo ng mga routine para sa compression at pagpili ng obserbasyon;
• paghihiwalay ng mga pinagkakatiwalaang tagubilin mula sa hindi pinagkakatiwalaang content;
• pag-profile ng paggamit ng token, latency, mga retry, at mga tool call;
• pagsubok sa pagkawala at muling pagbuo ng state;
• pagpapaliwanag sa mga hindi espesyalista kung bakit nakita—o hindi nakita—ng isang agent ang isang partikular na katotohanan.

Maaaring ipakita ng isang mahusay na portfolio project ang parehong agent sa ilalim ng tatlong patakaran sa context: buong transcript, rolling summary, at structured belief state na may naka-target na retrieval. Ipakita ang mga kasong matagumpay ang gawain, ang mga kasong nabigo, ang context na ipinadala sa bawat hakbang, at ang mga trade-off sa gastos o latency. Mas kapani-paniwala ito kaysa sa isang chatbot demo dahil inilalantad nito ang mga desisyong pangdisenyo na nagpapaaasahan sa isang agent.

Direkta ang estratehikong aral: hindi nagiging magkakaugnay ang mga agent dahil lamang sa nagiging mas mahusay ang mga modelo. Nagiging magkakaugnay sila kapag ang mga nakapaligid na sistema ay nagpapanatili ng disiplinado, napapanahon, at angkop ang laki na tala ng gawain. Ang context engineering ay ang kasanayan sa pagbuo ng talang iyon—at sa pag-alam kung ano ang dapat iwanan.

Si Priya Raman ang responsableng human editor ng AI Career Brief.