16/01/2026
Context Engineering
ගොඩාක් වෙලාවට අපි හිතන්නේ AI එකක් හෝ LLM (Large Language Model) එකක් වැරදි උත්තරයක් දුන්නම ඒක ඒ Model එකේ අවුලක් කියලා. ඒත් ඇත්තටම අලුත්ම research වලට අනුව ගොඩක් LLM failures වලට හේතුව Model එක නෙමෙයි ඒකට දෙන Context එකේ තියෙන ප්රශ්නයි.
නිකමට හිතන්න ඔයා හදන Chatbot එකක් ගැන. ඔයා අහනවා "අපේ company එකේ refund policy එක මොකක්ද?" කියලා. එතකොට bot එක හරිම confident පිට කියනවා "අපිට refund policy එකක් නෑ, සල්ලි ආපහු දෙන්නෙම නෑ" කියලා. හැබැයි ඇත්තටම ඔයාගේ site එකේ අලුත් policy එකක් තියෙනවා දවස් 30ක් ඇතුළත refund දෙනවා කියලා.
ඉතින් මොකද මේ වුණේ? Bot එක බොරු කිව්වද? නෑ. එයාට හරියට Context එක ලැබිලා නෑ. එයා පරණ data බලලා, හරි නැත්තම් වැරදි තැනකින් තොරතුරු අරගෙන තමයි ඒ උත්තරේ හැදුවේ. අන්න එතනදි තමයි මේ Context Engineering කියන මාතෘකාව එළියට එන්නේ. ඇත්තටම RAG-powered tools (Retrieval-Augmented Generation) එක්ක මේ Context Engineering හරියට පාවිච්චි කරපු නිසා healthcare diagnostic errors 15% කින් විතර අඩු කරගන්න පුළුවන් වුණා කියලා මේ ළඟදි report වෙලා තිබුණා. ඉතින් මේක පොඩි දෙයක් නෙමෙයි නේද?
හරි, Context Engineering කියන්නේ මොකක්ද?
සරලවම කිව්වොත්, Context Engineering කියන්නේ LLM එකකට උත්තරයක් දෙන්න කලින්, ඒකට අවශ්ය නිවැරදි තොරතුරු සපයන Data Pipeline එක Design කරන එකටයි. එහෙම නැතුව නිකන්ම Model එකට ප්රශ්නයක් දෙන එක නෙමෙයි. මොකද අපි තීරණය කරන්න ඕන Model එක මොනවද බලන්නේ සහ නොබලන්නේ කියන එක.
ගොඩක් අය මේක Prompt Engineering එක්ක පටලවා ගන්නවා. ඒත් මේ දෙක සම්පූර්ණයෙන්ම වෙනස්. මෙහෙම හිතන්නකෝ Prompt එක කියන්නේ ඔයාගේ ගමනේ අන්තිම ටික, ඒ කියන්නේ Last Mile එක වගේ. හැබැයි Context එක කියන්නේ ඔයා ඒ තැනට එන්න පාවිච්චි කරන ප්රධාන Highway එක වගේ. Highway එක කැඩිලා නම්, ඔයා අන්තිම ටික කොච්චර හොඳට ගියත් වැඩක් නෑනේ.
ඉතින් මේක නිසා සාමාන්ය RAG systems වලදි අපි කරන්නේ LLM එකේ තියෙන සීමිත මතකයට (Context Window) පිටින් තියෙන අපේ ලොකු knowledge base එකෙන්, අවශ්ය දේ විතරක් වෙලාවට අරගෙන දෙන එකයි. මොකද LLM එක දකින හැමදේම තමයි එයාගේ Context එක වෙන්නේ. අපේ වැඩේ තමයි අර highway එක අවුලක් නැතුව හදන එක. එතකොට කිසිම ප්රශ්නයක් නැතුව අපිට ඕන දේ කරගන්න පුළුවන්.
Core Pipeline
දැන් අපි බලමු කොහොමද මේ වැඩේ වෙන්නේ කියලා. මේක, පියවරෙන් පියවර යන process එකක්. මේ pipeline එකේ ප්රධාන කොටස් ටික තමයි
Crawl → Clean → Chunk → Embed → Index → Retrieve → Compose Context → Generate Response
මේ හැම step එකක්ම හරිම වැදගත්. උදාහරණයක් විදියට Clean කරන එක ගමු. ඔයා website එකකින් data ගන්නකොට අනවශ්ය HTML tags, ads, navigation bars අයින් කරේ නැත්නම්, Model එක ඒවත් කියවලා වැරදි උත්තර දෙන්න පුලුවන් මොකද Retrieve කරන කොට, වැරදි කෑල්ලක් අහු වුනොත් මුළු උත්තරේම වරදිනවා.ඉතින් මේ දවස්වල developers ලාගේ ලොකුම challenge එක වෙලා තියෙන්නේ මේ pipeline එක හරියට හදාගන්න එකයි. මොකද එක තැනක් fail වුනොත්, මුළු output එකම fail වෙනවා.
Playwright එකෙන් Crawling කරමු
දැන් අපි පටන් ගන්නේ Data එකතු කරන තැනින්නේ (Crawling). ඉස්සර නම් අපි නිකන් requests library එකක් දාලා HTML එක ගත්තා. ඒත් දැන් එහෙම බෑ. අද තියෙන ගොඩක් sites Dynamic (JavaScript වලින් වැඩ කරන ඒවා). ඉතින් මේකට හොඳම විසඳුම තමයි Playwright.
දන්නවද, අද වෙනකොට Single Page Applications (SPAs) සහ Progressive Web Apps (PWAs) වලට data ගන්න Playwright තමයි dominant tool එක වෙලා තියෙන්නේ. ඇයි දන්නවද? Playwright වලට පුළුවන් ඇත්ත browser එකක් වගේ හැසිරෙන්න. Login වෙන්න, buttons click කරන්න, scroll කරන්න වගේ දේවල් (dynamic sites handling) මේකට ලේසියෙන්ම පුළුවන්. මේ වෙද්දි Playwright වල multi-language support එක සහ advanced features තවත් update වෙලා තියෙනවා.
ඒකයි අපි අපේ crawling වැඩේට මේක use කරන්න ඕන. ඒ වගේම මතක තියාගන්න ඕන දෙයක් තමයි, අපි data store කරනකොට නිකන්ම text එක විතරක් තියන් මදි. HTML or Source structure එක, metadata, URL එක සහ ගත්ත වෙලාව (timestamp) වගේ දේවල් store කරගන්න ඕන. නැත්නම් පස්සේ retrieve කරනකොට අපි අමාරුවේ වැටෙනවා.
Chunking
හරි, දැන් data ටික ගත්තා. ඊළඟට තියෙන්නේ Chunking. මේක තමයි ගොඩක් අය අනාගන්න තැන. ගොඩක් අය කරන්නේ ලොකු text එකක් අරගෙන characters 500න් 500ට split කරන එක (Fixed-size chunking). එහෙම කරන්න එපා! එතකොට වෙන්නේ sentence or paragraph එක මැදින් කැඩෙනවා, එතකොට ඒකේ meaning එකයි intent එකයි දෙකම නැති වෙනවා.
ඒ වෙනුවට පාවිච්චි කරන්න Semantic Chunking හරි Structure-aware Chunking. ඒ කියන්නේ තේරුම අනුව හරි paragraph අනුව හරි කඩන එක. ඒවගේම Recursive Splitters පාවිච්චි කරලා පොඩි Overlap Strategy එකක් තියාගන්න. මේකෙන් වෙන්නේ වාක්ය දෙකක් හරි වචන දෙකක් හරි මැද්දෙන් කැඩුණත්, ඒ අතර තියෙන සම්බන්ධය (relation) කැඩෙන්නේ නැති එක. ඒ වගේම ඔයා මේ chunks save කරනකොට, ඒකට ID එකක්, ආපු source එක (URL), සහ section title එක වගේ දේවල් අනිවාර්යයෙන්ම track කරන්න.
Retrieval එක හරියටම කරගන්න
දැන් අපි chunking කරපු data ටික හොයාගන්නේ කොහොමද? ඉස්සර වගේ වචන ගැලපෙනවද කියලා බලන (Keyword search / TF-IDF) ක්රමය විතරක් දැන් හරියන්නේ නෑ modern RAG වලට. අපි පාවිච්චි කරන්න ඕන Embeddings. ඒ කියන්නේ වචන වල තේරුම mathematical data විදියට (vectors) store කරන එක එතකොට අපිට ඒක හොයන්නත් තේරුමම use කරන්න වෙනවා ඒකට තමයි අපි semantic search, agentic search වගේ දේවල් පාවිච්චි කරන්නේ.
හැබැයි හොඳම ක්රමය තමයි Hybrid Retrieval. ඒ කියන්නේ Embeddings (Dense search) සහ Keywords දෙකම පාවිච්චි කරන එක. ඊට පස්සේ එන result එක Rerank කරන එක ගොඩක් වැදගත්. මේකෙන් වෙන්නේ අපි හොයාගත්ත top results ටික ආයෙත් සැරයක් check කරලා, වඩාත්ම ගැලපෙන ඒවා උඩට ගන්න එක. මේකෙන් වෙන්නේ user ට බොරු උත්තර (Hallucinations) යන එක නවත්තන එකයි. නිකන් බොරු කියලා user ඉස්සරහා fail වෙන්න ඕන නෑනේ.
Advanced Topics: මේ දවස්වල Trend වෙන දේවල්
Context Engineering වල මේ දවස්වල අලුතෙන්ම කතා වෙන, ගොඩක් වැදගත් මාතෘකා දෙකක් තියෙනවා:
1️⃣ CAG/KV-cache Context Caching: හිතන්න එකම ප්රශ්නය සිය දහස් වාරයක් එනවා කියලා. හැම පාරම retrieve කර කර ඉන්න ගියොත් cost එකයි, latency එකයි දෙකම වැඩි වෙනවා. ඒ නිසා අපි context එක cache කරනවා (retrieve සහ generate අතර). මේකෙන් response time එක මාර විදියට fast වෙනවා.
2️⃣ CRAG (Corrective RAG): මේක නම් දැන් standard එකක් වෙගෙන එන්නේ. නිකන්ම RAG නෙමෙයි, මේකෙන් කරන්නේ retrieve කරපු data වල quality එක evaluate කරන එක. Data මදි නම් හෝ වැරදි නම්, system එකටම පුළුවන් query එක වෙනස් කරලා (reformulate), ආයෙත් search කරන්න. මේකෙන් LLM එක බොරු හිතල කියන එක (Hallucinations) ගොඩක් දුරට අඩු කරනවා. Robust system එකක් හදනවා නම් CRAG නැතුව බෑ.
Production Mindset - Evaluate කරන්න ඕනි
අපි system එක හැදුවට පස්සේ කොහොමද දන්නේ මේක හරියටම වැඩද කියලා? නිකන්ම "හරි වගේ" කියලා හරියන්නේ නෑ. Enterprise level එකේදී අද වෙනකොට 37% ක්ම companies Models 5කට වඩා පාවිච්චි කරනවා. ඒ නිසා Evaluation කියන්නේ අනිවාර්ය දෙයක්.
ඔයාට ඕන Golden Set එකක්. ඒ කියන්නේ ප්රශ්න සහ ඊට ලැබෙන්න ඕන හරි උත්තර සෙට් එකක්. ඊට පස්සේ බලන්න ඕන:
❔ Retrieval Hit-rate: අවශ්ය document එක retrieve වුණාද?
❔ Faithfulness: දීපු context එකට අනුවද උත්තරේ දුන්නේ?
❔ Latency: කොච්චර වෙලාවක් ගියාද?
සිංහලෙන්ම කිව්වොත්: මනින්න බැරි නම්, production එකට දාලා බෑ. මොකද වැරදි උත්තරයක් ගියොත් වගකීම ඔයාගේ.
Implementation Blueprint - කොහොමද Start කරන්නේ?
ඔයාට දැන්ම මේක පටන් ගන්න ඕන නම්, මෙන්න සරල blueprint එකක්. මේ වගේ modules ටිකක් හදාගන්න:
✅ Scraper Module: Playwright පාවිච්චි කරලා web pages ටික අදින script එක.
✅ Cleaner Script: HTML tags අයින් කරලා text එක සුද්ද කරන කොටස.
✅ Chunker: Text එක meaningful විදියට කෑලි කඩන තැන.
✅ Vector Store: මේ කෑලි Embeddings විදියට save කරන තැන (උදා: ChromaDB, Pinecone).
✅ RAG Chain: User ගේ ප්රශ්නය අරන්, අදාල කෑලි හොයලා, LLM එකට යවන ප්රධාන logic එක.
✅ Eval Script: හදපු එකේ quality එක check කරන කොටස.
අන්තිමට කියන්න තියෙන්නේ මේකයි: LLM applications කියන්නේ ඇත්තටම Context System එකක්. ඔයාගේ Context එක කොච්චර හොඳද කියන එක මත තමයි ඔයාගේ AI එකේ quality එක තීරණය වෙන්නේ.
මේ වෙනකොට Agentic Context Evolution (ACE) වගේ අලුත් trends එනවා. මේ ACE system එක AppWorld leaderboard එකේ 59.4% accuracy එකක් අරන් තියෙනවා කියලත් වාර්තා වෙනවා. ඒ කියන්නේ contexts තමන් විසින්ම දියුණු කරගන්න පුළුවන් Agents ලා බිහිවෙමින් ඉන්නේ.
ඉතින් ඔයත් නිකන් ඉන්න එපා. පොඩි pipeline එකක් හදලා බලන්න. කරලා බලලම තමයි ඉගෙන ගන්න වෙන්නේ. මොකද මේ tech එක දවසින් දවස වෙනස් වෙනවා. කරන්න ඉගෙනගන්න ආසයි නම් එන්න අපි උගන්නන්නම් හරියටම වැඩේ කරන විදිය.
