https://www.facebook.com/1109702285552276/

Surrounded by Data, Dhaka (2026)

25/06/2026

মেসি না রোনালদো? আরও ডেটা দিয়েও কেন এই তর্ক কখনো শেষ হবে না
শেয়ারড রিয়েলিটির নীরব মৃত্যু — আর যে অ্যালগরিদমগুলো সেটাকে কবর দিয়েছে।

আধুনিক ফুটবলের সবচেয়ে বড় তর্কটা একবার মীমাংসা করতে গেলেই একটা অদ্ভুত ব্যাপার চোখে পড়ে। খেলাটা নিয়ে আমাদের হাতে আগে কখনো এত ডেটা ছিল না — এক্সপেক্টেড গোলস, প্রোগ্রেসিভ ক্যারি, প্রেস, বল রিকভারি, প্রতিটা টাচ মাপার জন্য আস্ত আস্ত কোম্পানি দাঁড়িয়ে গেছে — অথচ “মেসি না রোনালদো?” প্রশ্নটার মীমাংসা আজ আগের চেয়ে আরও অসম্ভব মনে হয়। বেশি সংখ্যা বেশি ঐকমত্য আনেনি। এনেছে আরও সুন্দরভাবে সাজানো অমিল।

এই প্যারাডক্সটা আসলে ফুটবল নিয়ে না। গত দুই দশকে আমাদের সঙ্গে ঘটে যাওয়া সবচেয়ে বড় পরিবর্তনগুলোর একটার ছোট্ট, দৃশ্যমান উপসর্গ এটা — এমন একটা পরিবর্তন, এত গভীর আর এত সম্পূর্ণ, যে আমরা সেটাকে খেয়াল করাই বন্ধ করে দিয়েছি। আমরা আর একটা শেয়ারড রিয়েলিটিতে থাকি না। আর যে যন্ত্রটা সেটা আমাদের কাছ থেকে কেড়ে নিয়েছে, আমাদের অনেকেই সেই যন্ত্রটাই বানিয়ে জীবিকা চালাই।
যে পানিটা আমরা আর দেখি না

একটা পুরোনো কথা আছে — মাছই সবার শেষে পানি আবিষ্কার করে। যে পরিবর্তনগুলো আমাদের সবচেয়ে গভীরে বদলে দেয়, সেগুলোই সবচেয়ে দ্রুত অদৃশ্য হয়ে যায়। কারণ কোনো কিছু একবার “স্বাভাবিক” হয়ে গেলে, আমরা সেটাকে আর পরিবর্তন হিসেবেই দেখি না।

আধুনিক ইতিহাসের বেশিরভাগ সময় ধরে একটা সমাজ ঘটনার মোটামুটি একটাই সংস্করণ শেয়ার করত। একটা দেশ একই সন্ধ্যার খবর দেখত, একই সকালের পত্রিকা খুলত, একই কয়েকটা ঘটনা নিয়ে একই ডিনার টেবিলে তর্ক করত। তথ্য ছিল দুর্লভ, আর বিতরণ ছিল কেন্দ্রীভূত। আমাদের ভাষায় বললে, সমাজ চলত একটা single source of truth-এর কাছাকাছি কিছুর ওপর — একটাই মূল, সম্পাদকের হাতে সাজানো ডেটাসেট, যেটা প্রায় সবাই কোয়েরি করত।

সেই পৃথিবীটা আর নেই। কমছে না — নেই। আর প্রায় কেউই এর শেষকৃত্যটা খেয়াল করেনি।
আর্কিটেকচারটা কীভাবে নীরবে বদলে গেল

পরিবর্তনটা ছিল আর্কিটেকচারাল। আর এখানে নির্দিষ্ট হওয়া জরুরি, কারণ পুরো গল্পটাই লুকিয়ে আছে এই মেকানিজমের মধ্যে।

পুরোনো মডেলটা ছিল ব্রডকাস্ট: ওয়ান-টু-মেনি বিতরণ, যেখানে মানুষ-সম্পাদক ঠিক করত পুরো একটা অডিয়েন্স কী দেখবে। নতুন মডেলটা অ্যালগরিদমিক: ওয়ান-টু-ওয়ান বিতরণ, যেখানে মেশিন লার্নিং সিস্টেম ঠিক করে প্রত্যেকটা মানুষ আলাদাভাবে কী দেখবে। সম্পাদক অপটিমাইজ করত — অসম্পূর্ণভাবে, কিন্তু সচেতনভাবে — গুরুত্ব আর জনস্বার্থের মতো জিনিসের জন্য। অ্যালগরিদম অপটিমাইজ করে আরও সংকীর্ণ, আরও সহজে মাপা যায় এমন একটা জিনিসের জন্য: এনগেজমেন্ট। ক্লিক-থ্রু রেট, ডোয়েল টাইম, ওয়াচ টাইম, সেশন লেংথ, স্ক্রল ডেপথ। এর অবজেক্টিভ ফাংশন আপনার মনোযোগ, আপনার বোঝাপড়া না।

ফিডের নিচে বসে আছে একটা রিকমেন্ডার সিস্টেম, আর তার যুক্তিটা চমৎকার। কোলাবরেটিভ ফিল্টারিং-এর মাধ্যমে এটা শেখে যে “আপনার মতো আচরণ করা মানুষ এটাও পছন্দ করেছে” — প্রায়ই ম্যাট্রিক্স ফ্যাক্টরাইজেশন দিয়ে, যা কোটি কোটি ইন্টারঅ্যাকশনকে একটা ঘন লেটেন্ট স্পেসে চেপে ঢোকায়। আপনি পরিণত হন একটা এমবেডিং-এ — সংখ্যার একটা ভেক্টর, যেটা অস্বস্তিকর নিখুঁততায় আপনার রুচি, ভয় আর অভ্যাস বর্ণনা করে। কনটেন্ট-বেইজড ফিল্টারিং আরেকটা স্তর যোগ করে, আপনি যা দেখছেন তার ফিচারের সঙ্গে আরও একই ধরনের জিনিস মিলিয়ে দেয়।

তারপর লুপটা বন্ধ হয়। প্রতিটা স্ক্রল, থামা, লাইক, শেয়ার, রিওয়াচ — সবকিছু বিহেভিয়ারাল ডেটা হিসেবে লগ হয়ে যায়, আপনার মনোযোগ থেকে বেরোনো ধোঁয়ার মতো। সেই সিগন্যাল মডেলটাকে আবার ট্রেইন করে, মডেল আপনার ফিড নতুন করে সাজায়, নতুন ফিড আপনার পরের অ্যাকশন ঠিক করে, আর এভাবেই চলতে থাকে। কার্যত এটা আপনার ওপর চালানো রিইনফোর্সমেন্ট লার্নিং, কোটি কোটি একসঙ্গে চলা A/B টেস্টের স্কেলে। গবেষকরা দৃশ্যমান ফলাফলটার নাম বহু বছর আগেই দিয়েছেন: ফিল্টার বাবল, একো চেম্বার। সিস্টেমটা হোমোফিলি — একইরকমের প্রতি আমাদের টান — বাড়িয়ে তোলে, যতক্ষণ না প্রত্যেকে এমন একটা ফিডের ভেতর সিল হয়ে যায়, যা ঠিক তাকে স্ক্রল করানোর জন্যই টিউন করা।

পার্সোনালাইজেশন, তার যৌক্তিক শেষ বিন্দুতে পৌঁছালে, আপনাকে শেয়ারড পৃথিবীটার ভালো একটা ভিউ দেয় না। দেয় একটা ব্যক্তিগত পৃথিবী। একটা n=1 রিয়েলিটি।
গ্রাউন্ড ট্রুথের সমস্যা

এখানেই জিনিসটা অস্বস্তিকর হওয়া উচিত যে কারও জন্য, যে ডেটা নিয়ে কাজ করে।

আমরা যে মডেলই ট্রেইন করি, তার গ্রাউন্ড ট্রুথ দরকার — বাস্তবতার লেবেল করা, একমত-হওয়া সংস্করণ, যার বিপরীতে আমরা আমাদের প্রেডিকশন মাপি। সমাজেরও আগে একটা মোটামুটি গ্রাউন্ড ট্রুথ ছিল: তথ্য আর ঘটনার একটা সাধারণ সেট, যেটাকে বেশিরভাগ মানুষ বেসলাইন হিসেবে মেনে নিত — তা নিয়ে কী করা উচিত, সেটাতে দ্বিমত থাকলেও।

আমরা সেই ডেটাসেটটা শার্ড করে ফেলেছি। হাজারটা মেশিনে পার্টিশন করা একটা ডেটাবেসের মতো, বাস্তবতা এখন কোটি কোটি ব্যক্তিগত পার্টিশনে ভাগ হয়ে গেছে, আর আমরা প্রত্যেকে শুধু নিজেরটাই কোয়েরি করছি। আপনার ফিড আর আপনার প্রতিবেশীর ফিড একটা পৃথিবীর দুটো ভিউ না; ওগুলো দুটো আলাদা পৃথিবী। আমরা এখনো পুরোনো ধারণাটা নিয়ে চলি — “সত্য একটাই, আর আমরা সবাই সেটার দিকেই তাকিয়ে আছি” — কিন্তু নিচের আর্কিটেকচারটা আর এই ধারণাটা সাপোর্ট করে না। শেয়ারড টেবিলটা নেই। আছে শুধু শার্ড।
কেন GOAT তর্কটা কখনো শেষ হবে না

এতেই আমরা ফিরে আসি মেসি আর রোনালদোর কাছে — এই সবকিছুর সবচেয়ে নিষ্পাপ প্রমাণ হিসেবে।

ফুটবল এখন পৃথিবীর সবচেয়ে বেশি পরিমাপ-করা ক্ষেত্রগুলোর একটা। আমরা এক্সপেক্টেড গোলস দশমিকের ঘর পর্যন্ত মাপতে পারি, একজন স্ট্রাইকারের ফিনিশিংকে তার সুযোগ-তৈরি থেকে আলাদা করতে পারি, একজন ডিফেন্ডারের প্রেসকে তার রিকভারির বিপরীতে ওজন করতে পারি। বাকি সব ডেটাসেটে আমরা যে যুক্তি খাটাই, সেই যুক্তি বলে — এত পরিমাপের তো গ্রেটেস্ট-অফ-অল-টাইম প্রশ্নটাকে একটা উত্তরের দিকে নিয়ে যাওয়ার কথা। উল্টো সেটা আরও দূরে সরে যায়। কেন?

কারণ তর্কটা কখনো ডেটার সমস্যা ছিল না। এটা শেয়ারড রিয়েলিটির তিনটা ব্যর্থতা, একটার ওপর আরেকটা সাজানো।

প্রথমত, দুই পক্ষ আলাদা আলাদা অবজেক্টিভ ফাংশনের জন্য অপটিমাইজ করে। এক পক্ষ মহত্ত্বকে সংজ্ঞায়িত করে শিল্প, সৃষ্টি, ড্রিবলিং, অসম্ভবকে সহজ বানিয়ে ফেলা দিয়ে; আরেক পক্ষ সংজ্ঞায়িত করে গোল, ফাইনাল, দীর্ঘস্থায়িত্ব, আর লিগ-দশকজুড়ে আধিপত্য দিয়ে। কোনো একমত-হওয়া টার্গেট ভেরিয়েবল নেই। আর যখন দুই পক্ষ এটাই ঠিক করেনি যে তারা আসলে কীসের জন্য অপটিমাইজ করছে, তখন কোনো পরিমাণ ডেটাই একজন বিজয়ী ঘোষণা করতে পারে না — সে শুধু অমিলটাকে আরও বেশি রেজোলিউশনে আবার বর্ণনা করতে পারে।

দ্বিতীয়ত, সবাই চেরি-পিক করে। প্রতি পক্ষ সেই মেট্রিকগুলো সামনে আনে যেগুলো তাদের লোককে সুন্দর দেখায়, আর বাকিগুলো চুপচাপ ফেলে দেয় — সিলেকশন বায়াসকে ব্যবহার করা হয় একটা অস্ত্র হিসেবে। সংখ্যাগুলো উত্তর খুঁজতে ব্যবহার হচ্ছে না; ব্যবহার হচ্ছে আগে থেকেই থাকা একটা উত্তরকে রক্ষা করতে। এটা মোটিভেটেড রিজনিং-এর সঙ্গে বিগ ডেটার দেখা, আর এখানে বিগ ডেটা হেরে যায়।

কিন্তু তৃতীয় কারণটা সবচেয়ে গভীর। ছোটবেলায় যে খেলোয়াড়ের প্রেমে আপনি পড়েছিলেন, সে কখনো একটা স্ট্যাট লাইন ছিল না। সে ছিল আপনার শৈশব, আপনার বসার ঘর, আপনার বাবার ধারাভাষ্য, যে পৃথিবীটার ভেতরে বড় হতে হতে আপনি তাকে দেখেছিলেন। আপনি যখন তাকে রক্ষা করেন, আপনি একটা গোলসংখ্যা রক্ষা করছেন না — আপনি রক্ষা করছেন সেই পৃথিবীটা। আর এজন্যই তর্কটা কখনো শেষ হয় না:

আমি আপনার যুক্তি ভাঙতে পারি। কিন্তু আপনার পৃথিবীটা ভাঙতে পারি না।

দুজন মানুষ ঠিক একই সংখ্যার দিকে তাকিয়ে থেকেও দুটো আলাদা বাস্তবতায় বাস করতে পারে, কারণ সংখ্যাগুলো কখনো সেই জিনিস ছিল না যেটার দিকে তারা আসলে তাকিয়ে ছিল।
ডেটায় ঘেরা মানুষের জন্য এর মানে কী

আপনি যদি ডেটা নিয়ে কাজ করেন, এই গল্পটা স্বস্তির না, আর হওয়াও উচিত না — কারণ যন্ত্রটা আমরাই বানাই। রিকমেন্ডেশন ইঞ্জিন, পার্সোনালাইজেশন লেয়ার, টার্গেটিং মডেল, আর সেই ড্যাশবোর্ডগুলো, যেগুলো প্রতিশ্রুতি দেয় যে বেশি পরিমাপ মানেই বেশি সত্য।

আমাদের ক্ষেত্রের স্বস্তিদায়ক মিথটা হলো — ডেটা নিরপেক্ষ, আর বেশি ডেটা মানুষকে ঐকমত্যের দিকে টানে। মেসি-রোনালদোর তর্কটা পুরো জনজীবনের স্কেলে বড় করে দেখলে অন্য কথা বলে। ডেটা নিজে নিজেকে ব্যাখ্যা করে না। সেটা পড়া হয় পূর্বধারণার ভেতর দিয়ে, অস্ত্র বানানো হয় বাছাই দিয়ে, আর বিচার করা হয় এমন সব অবজেক্টিভ ফাংশনের বিপরীতে, যেগুলোতে আমরা খুব কমই একমত। একটা ফিডকে এনগেজমেন্টের জন্য অপটিমাইজ করে নিজেকে বলা যায়, আমরা জনগণকে তথ্য দিচ্ছি — কিন্তু গুডহার্টের সূত্র (Goodhart's Law) তার দাম ঠিকই আদায় করে নেবে: যখন কোনো পরিমাপ লক্ষ্যে পরিণত হয়, তখন সেটা আর ভালো পরিমাপ থাকে না। আমরা টাইম-অন-অ্যাপ ম্যাক্সিমাইজ করি, আর যে বাস্তবতাটা ব্যবহারকারীরা শেয়ার করতে চাইছিল, সেটাকেই ভেঙে টুকরো করি।

আমরা ডেটায় ঘেরা — আর সেটাই দিয়ে আমরা কোনোভাবে আরও দূরে সরে গেছি। আমরা সবচেয়ে দামি যে কাজটা করতে পারি, সেটা আরেকটা মেট্রিক যোগ করা না। সেটা হলো পানিটা আবার দৃশ্যমান করা: মনে রাখা, আর মনে করিয়ে দেওয়া — স্ক্রিনের একটা সংখ্যা কোনো শেয়ারড সত্য না, আর আমাদের যুগের সবচেয়ে গভীর পরিবর্তনটা সেটাই, যেটাকে খেয়াল করা আমরা সবাই চুপচাপ বন্ধ করে দিয়েছি।

তাই যে প্রশ্নটা দিয়ে শুরু করেছিলাম, সেটা দিয়েই শেষ করি। মেসি না রোনালদো? উত্তর দেওয়ার আগে খেয়াল করি — আমরা আসলে ডেটার দিকে হাত বাড়াচ্ছি না। আমরা হাত বাড়াচ্ছি একটা পৃথিবীর দিকে। আমরা সবাই তা-ই করছি — আর যেকোনো অ্যালগরিদমের চেয়ে বেশি, এটাই কারণ যে আমরা আর একই পৃথিবীতে থাকি না।

original post link : https://www.linkedin.com/pulse/messi-ronaldo-why-more-data-never-end-debate-sadnan-mohosin-ormrc/

23/05/2026

salary দেখে চাকরি নিলে, ৬ মাস পরে রিগ্রেট করার সম্ভাবনা ৭০%।

Data-র চাকরি evaluate করার সময় যে জিনিসগুলো বেশিরভাগ মানুষ skip করে:

✅ ডেটা কে collect করে?
যদি উত্তর হয় "engineering team" — তুমি সারাদিন dirty data clean করবে, মডেল বানাবে না।

✅ Last data hire কতদিন ছিল?
যদি ৬ মাসের বেশি কেউ থাকেনি, কারণটা জিজ্ঞেস করো। সৎ উত্তর না পেলে সেটাই উত্তর।

✅ Business team কি data দিয়ে সিদ্ধান্ত নেয়, নাকি gut feeling-এ?
যদি dashboards শুধু দেখায়, কেউ পড়ে না — তোমার কাজের কোনো impact হবে না।

✅ তোমার কাজের output কে দেখবে?
যদি শুধু manager দেখে, growth সীমিত। যদি product বা leadership দেখে, তাহলে গল্প আলাদা।

✅ Tools কি তুমি শিখতে চাও?
নাকি ৫ বছর ধরে একই legacy Excel system?

✅ "Data-driven" কথাটা কতবার বললো interview-এ?
বেশি বললে মানে সত্যিকারের culture নেই, buzzword দিয়ে ঢাকছে।

✅ কোনো Data roadmap আছে কিনা?
নাকি তুমিই সেটা "build" করবে — কোনো support ছাড়া, কোনো budget ছাড়া?

Salary negotiation-এর আগে এই ৭টা প্রশ্নের উত্তর খোঁজো।
ভালো offer মানে শুধু বেশি টাকা না — মানে কাজটা তোমাকে ১ বছর পরেও ভালো রাখবে।

তোমার শেষ job switch-এ কোন জিনিসটা আগে বুঝলে ভালো হতো? 👇

22/05/2026

Data career-এ একটা trap আছে যেটায় বেশিরভাগ মানুষ পড়ে — কিন্তু কেউ সরাসরি বলে না।

তুমি SQL শিখলে। Python শিখলে। Power BI dashboard বানাতে পারো। Tableau-তে চমৎকার visualization করো।

কিন্তু কেউ যখন জিজ্ঞেস করে —
"এই analysis দিয়ে business কী করবে?"
"এই metric drop মানে আসলে কী?"
"তুমি কোন decision-টা change করতে চাইছো এই data দিয়ে?"

তখন চুপ হয়ে যাও।

এটাকে বলে Tool Fluency vs Business Thinking gap।

Tool fluency তোমাকে job দেয়।
Business thinking তোমাকে career দেয়।

---

আমি একটা realistic scenario দেখি বারবার:

একজন junior analyst ঘণ্টার পর ঘণ্টা কাজ করে একটা সুন্দর churn analysis তৈরি করলো। Numbers accurate। Visual clean।

কিন্তু রিপোর্টটা দেখে manager জিজ্ঞেস করলো —
"So what should we do about it?"

সে বললো — "সেটা তো আপনারা ঠিক করবেন।"

সেই দিন থেকে সে হয়ে গেলো 'report বানানোর লোক।' Promotion আর হয়নি দুই বছর।

---

ভুলটা কী ছিল?

সে ভেবেছিল তার কাজ হলো সঠিক data দেওয়া।
কিন্তু আসল কাজ ছিল সঠিক প্রশ্নের উত্তর দেওয়া।

---

প্র্যাকটিক্যাল fix:

➊ প্রতিটা analysis শুরু করার আগে লেখো — "এই analysis কোন decision-কে better করবে?"

➋ শুধু কী হচ্ছে (what) বলো না — কেন হচ্ছে (why) এবং এরপর কী করা উচিত (so what) বলো।

➌ Stakeholder যা চেয়েছে তা দেওয়ার পাশাপাশি একটা extra insight add করো যেটা তারা চাননি কিন্তু দরকার।

---

Tools শেখা easy। সেটা করো।
কিন্তু business context বোঝার অভ্যাস না থাকলে, তুমি সবসময় ex*****on layer-এই আটকে থাকবে।

তোমার career-এ এই gap কি কখনো feel করেছো? কীভাবে deal করেছো?

22/05/2026

ChatGPT-কে question করো — সে জবাব দেয়।
AI Agent-কে একটা goal দাও — সে নিজেই plan করে, tool use করে, কাজ শেষ করে ফেরত আসে।

এই দুটো এক জিনিস না।

২০২৬ সালে সবচেয়ে বেশি যে টার্মটা tech world-এ ঘুরছে সেটা হলো — AI Agent। কিন্তু বেশিরভাগ মানুষ এখনো ভাবছে এটা হয়তো একটু স্মার্ট chatbot।

আসলে পার্থক্যটা অনেক গভীর।

🤖 সাধারণ AI (যেমন chatbot):
— তুমি input দাও
— সে output দেয়
— কাজ শেষ

⚡ AI Agent:
— তুমি একটা goal দাও
— সে নিজে ভাবে: "এই কাজটা করতে আমার কী কী দরকার?"
— নিজে web search করে, code run করে, file পড়ে, email draft করে
— একটা step শেষ হলে পরের step নিজেই ঠিক করে
— তারপর final result নিয়ে আসে

Real example বোঝো:

তুমি বললে — "আমাদের last quarter-এর sales data দেখে একটা executive summary বানাও আর সেটা CFO-কে email করো।"

Chatbot: "অবশ্যই! আপনি data paste করুন, আমি summary লিখে দিচ্ছি।"

AI Agent: নিজে database connect করলো → data pull করলো → analysis করলো → summary draft করলো → CFO-এর email খুঁজে নিলো → send করলো। তুমি শুধু approve করলে।

এই shift টা কেন এত বড়?

কারণ এতদিন AI ছিল একটা smart assistant — তোমাকে সব কিছু বলে দিতে হতো।
এখন AI হয়ে যাচ্ছে একটা autonomous worker — তুমি শুধু outcome চাও।

এই কারণেই Salesforce, SAP, ServiceNow — সবাই এখন "Agentic AI" নিয়ে race করছে। কারণ যে company প্রথমে reliable AI agents deploy করতে পারবে, তাদের operational cost একটা ভিন্ন level-এ নেমে যাবে।

তোমার কাছে প্রশ্ন —
তুমি কি মনে করো AI Agent আসলে job replace করবে, নাকি নতুন ধরনের কাজ তৈরি করবে? Comment-এ বলো। 👇

21/05/2026

তুমি ৬ মাস ধরে SQL শিখলে। কিন্তু interview-এ একটা real dataset দেখে blank হয়ে গেলে।

এই mistake টা শুধু তুমি করোনি — হাজার হাজার data learner করে।

ভুলটা হলো:
➤ Tutorial data-তে practice করা।

Tutorial data মানে কী?
— সব column perfectly filled
— কোনো duplicate নেই
— Date format consistent
— কোনো NULL নেই যেটা logic break করে

Real life data-তে কী থাকে?
— একটা customer_id তিনভাবে লেখা: "C001", "c001", "C-001"
— order_date এর column-এ কোথাও "2024-01-15", কোথাও "15/01/24"
— Revenue column-এ string mixed with numbers
— Join করলে row দ্বিগুণ হয়ে যাচ্ছে কিন্তু কেন বুঝতে পারছো না

Tutorial শেষ করার পরেও যদি Kaggle-এর messy dataset বা government open data নিয়ে কাজ না করো — তুমি আসলে controlled environment-এ সাঁতার শিখেছো, সমুদ্রে নামোনি।

Fix টা simple:
✅ প্রতি সপ্তাহে একটা "ugly" dataset নাও
✅ প্রথম কাজ হবে শুধু data cleaning
✅ কোনো tutorial follow করবে না — নিজে error দেখো, নিজে solve করো
✅ কতগুলো NULL ছিল, কীভাবে handle করলে — সেটা document করো

এই practice টা ৪ সপ্তাহ করলে interview-এ "এই data-তে কী সমস্যা দেখছো?" প্রশ্নটা আর ভয় লাগবে না।

তোমার সবচেয়ে বড় messy data moment কোনটা ছিল? নিচে বলো 👇

30/04/2026

তুমি query তিনবার rewrite করেছ। Index দিয়েছ। EXPLAIN ANALYZE দেখেছ। তারপরও query slow। এখন কী করবে?

বেশিরভাগ ক্ষেত্রে সমস্যাটা query-তে না — সমস্যা database-এর ভেতরের physical health-এ।

─────────────────────────
🔑 আগে key terms বুঝে নাও
─────────────────────────

▸ Dead tuple — PostgreSQL-এ কোনো row UPDATE বা DELETE হলে সেই পুরনো version সাথে সাথে মুছে যায় না। সে জায়গা নিয়ে পড়ে থাকে — এটাই dead tuple।

▸ Table bloat — অনেক dead tuple জমলে table আসলের চেয়ে অনেক বড় হয়ে যায়, কিন্তু কাজের data কম।

▸ Query planner — PostgreSQL execute করার আগে সিদ্ধান্ত নেয়: Seq Scan ভালো, নাকি Index Scan? এই সিদ্ধান্ত নেওয়ার engine হলো planner।

▸ Autovacuum — PostgreSQL নিজে থেকে background-এ VACUUM চালায়। কিন্তু heavy write workload-এ এটা পিছিয়ে পড়ে।

─────────────────────────
⚙️ কী হয় আসলে?
─────────────────────────

ধর তোমার orders table-এ প্রতিদিন ৫০,০০০ row UPDATE হয়। PostgreSQL প্রতিটা UPDATE-এ নতুন version লেখে, পুরনোটা dead হয়ে পড়ে থাকে।

এক সপ্তাহ পর:
• Live rows: ৩,০০,০০০
• Dead tuples: ২,৫০,০০০

Planner statistics এখনো পুরনো — সে ভাবছে table-এ মাত্র ৮০,০০০ row আছে।

তাই planner বলে: "এত কম row? Index scan দরকার নেই, Seq Scan-ই যথেষ্ট।"

কিন্তু আসলে সে ৫,৫০,০০০ row-এর bloated table scan করছে। Query slow হওয়াটা স্বাভাবিক।

─────────────────────────
🔍 Diagnose করবে কীভাবে?
─────────────────────────

এই query চালাও:

SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_analyze
FROM pg_stat_user_tables
WHERE relname = 'orders';

যদি দেখ n_dead_tup অনেক বেশি এবং last_analyze অনেক পুরনো — তাহলে সমস্যা এখানেই।

Fix:
VACUUM ANALYZE orders;

VACUUM dead tuples সরাবে, ANALYZE planner-কে নতুন statistics দেবে।

─────────────────────────
⚠️ Common mistake
─────────────────────────

অনেকে মনে করেন autovacuum থাকলে ম্যানুয়ালি কিছু করতে হবে না।

কিন্তু heavy write workload-এ autovacuum নিজেই পিছিয়ে পড়ে — dead tuples জমতে থাকে, statistics stale হতে থাকে। Production-এ batch job বা pipeline চালানোর পর manually ANALYZE করার অভ্যাস রাখো।

আর VACUUM FULL সাবধানে — এটা table-এ exclusive lock নেয়, পুরো table rewrite করে। Production চলাকালীন এটা চালালে সব read-write ব্লক হয়ে যাবে।

─────────────────────────
🧩 Mini challenge
─────────────────────────

তোমার planner estimate দেখাচ্ছে 500 rows, কিন্তু actual rows 85,000। Query তে কোনো bug নেই।

এই mismatch-এর সবচেয়ে likely কারণ কী?

(উত্তর নিচে 👇)
...

✅ উত্তর: Stale statistics। ANALYZE অনেকদিন চলেনি, তাই planner ভুল row count দিয়ে ex*****on plan বানিয়েছে। ANALYZE চালালে planner নতুন estimate পাবে এবং সঠিক plan বেছে নেবে।

─────────────────────────
💡 Takeaway
─────────────────────────

▸ Slow query মানেই খারাপ query না — table bloat আর stale statistics-ও দায়ী হতে পারে।
▸ VACUUM মুক্ত করে জায়গা, ANALYZE দেয় planner-কে সঠিক তথ্য — দুটো আলাদা কাজ, দুটোই দরকার।
▸ pg_stat_user_tables দিয়ে আগে diagnose করো, তারপর fix করো।

─────────────────────────

তোমার production database-এ কি কখনো autovacuum failure বা table bloat diagnose করেছ? কীভাবে ধরেছিলে? 👇

27/04/2026

তোমার model training-এ ৯৯% accuracy দেখাচ্ছে — কিন্তু production-এ গিয়ে সব গোলমাল।

এটা bug না। এটা তোমার feature নিজেই চিট করছিল।

---

🔴 সমস্যাটা কোথায়?

ধরো তুমি একটা model বানাচ্ছ যে predict করবে — কোনো customer loan default করবে কিনা।

তুমি বুদ্ধি করে একটা feature বানালে:
"এই customer যে city-তে থাকে, সেই city-র সব customer-দের average default rate"

দেখতে নিরীহ। আসলে মারাত্মক।

কারণ যখন তুমি এই average হিসাব করলে, তুমি পুরো dataset ব্যবহার করলে — মানে সেই customer নিজেও ঐ average-এর ভেতরে আছে। Model তখন শিখে নিচ্ছে: "যার target = 1, তার city-র average বেশি" — কারণ সে নিজেই সেই average বাড়িয়েছে!

এটাই Target Leakage through Aggregation।

---

🧩 Key Terms সহজ ভাষায়

▸ Target Leakage — যখন feature-এর ভেতরে answer আগেই ঢুকে যায়
▸ Group Aggregation — city/category ধরে mean, sum, ratio বের করা
▸ Temporal Boundary — কোন সময়ের আগের data ব্যবহার করা যাবে সেই সীমা
▸ Train-Test Split — random split করলেই leakage ধরা যায় না, time-based split দরকার

---

📊 Worked Example

ধরো তোমার dataset:

Row 1: customer_A, city=Dhaka, default=1
Row 2: customer_B, city=Dhaka, default=0
Row 3: customer_C, city=Dhaka, default=1

❌ Leaky Feature:
city_avg_default = mean(সব Dhaka customer-এর default)
= (1+0+1)/3 = 0.67

Row 1-এর জন্য এই feature বানাতে গিয়ে তুমি Row 1-এর নিজের target (default=1) ব্যবহার করলে।
Model এখন জানে — এই feature high মানে default likely। কিন্তু real prediction-এ নতুন customer-এর নিজের future outcome তো জানা নেই!

✅ সঠিক উপায় — Leave-One-Out Encoding:
Row 1-এর জন্য: mean(Row 2, Row 3) = (0+1)/2 = 0.5
Row 2-এর জন্য: mean(Row 1, Row 3) = (1+1)/2 = 1.0
Row 3-এর জন্য: mean(Row 1, Row 2) = (1+0)/2 = 0.5

এখন প্রতিটি row-এর নিজের target বাদ দিয়ে average হচ্ছে।

Time-series data-তে আরও কড়া নিয়ম:
January-র prediction-এ শুধু December পর্যন্তের data ব্যবহার করো। February-র data কখনো না।

---

⚠️ Common Mistake

অনেকে মনে করে: "আমি তো random train-test split করেছি, তাহলে leakage কোথা থেকে আসবে?"

কিন্তু leakage ধরা পড়ে feature বানানোর সময়, split করার সময় না।

পুরো dataset দিয়ে group mean বানিয়ে তারপর split করলে — test set-এর information আগেই training feature-এ ঢুকে গেছে।

সমাধান: আগে split করো, তারপর শুধু training set দিয়ে aggregation feature বানাও। Test set-এ সেই trained statistics apply করো।

---

🧠 Mini Challenge

তোমার কাছে e-commerce order data আছে। তুমি একটা feature বানাতে চাও:
"এই product category-র historical return rate"

কোন ক্ষেত্রে এটা leaky হবে?

উত্তর ভাবো... তারপর নিচে দেখো 👇

উত্তর: যদি তুমি পুরো dataset-এর return rate নাও — তাহলে future return events training-এ ঢুকে যাচ্ছে। সঠিক উপায়: প্রতিটি order-এর prediction date-এর আগের orders থেকে return rate হিসাব করো।

---

💡 Takeaway

▸ Training-এ ভালো metric মানেই model ভালো না — leakage check করো
▸ Group aggregation feature বানানোর সময় জিজ্ঞেস করো: "এই row-এর নিজের target কি এই feature-এ আছে?"
▸ Time-series হলে temporal boundary মানো, random split যথেষ্ট না

---

তোমার কাজে কি কখনো এমন হয়েছে — training metric দারুণ ছিল কিন্তু real data-তে কাজ করেনি? কারণটা কি ছিল বলো তো। 👇

26/04/2026

Retrieval ঠিকঠাক কাজ করছে — তবু উত্তর ভুল আসছে। এটা RAG-এর সবচেয়ে বিপজ্জনক failure, কারণ এটা চোখে পড়ে না।

তুমি vector search দিয়ে সঠিক chunk খুঁজে পেলে। Embedding quality ভালো। Chunk size ঠিক আছে। কিন্তু user যখন answer পাচ্ছে, সেটা আংশিক ভুল, অথবা confident tone-এ সম্পূর্ণ ভুল। Production-এ এই ধরনের failure সবচেয়ে কঠিন — কারণ retrieval metrics দেখলে মনে হয় সব ঠিক আছে।

━━━━━━━━━━━━━━━━
🔑 আগে কিছু terms বুঝে নিই

▪ RAG (Retrieval-Augmented Generation) — LLM-কে শুধু তার training data-র উপর নির্ভর না করিয়ে, বাইরে থেকে relevant document খুঁজে এনে answer তৈরি করা।
▪ Vector search — text-কে number-এ convert করে similarity দিয়ে কাছের chunk খোঁজা।
▪ Prompt grounding — LLM-কে বলে দেওয়া যে শুধু দেওয়া context থেকে উত্তর দাও, নিজে থেকে কিছু বানিও না।
▪ LLM hallucination — model যখন context-এ না থাকা তথ্য confident ভাবে বলে দেয়।

━━━━━━━━━━━━━━━━
⚙️ তিনটা failure zone — একটা example দিয়ে দেখি

ধরো তোমার একটা HR policy chatbot আছে। User জিজ্ঞেস করলো:
"বার্ষিক leave কতদিন?"

Retrieval দুটো chunk ফেরত দিল:
• Chunk A (2022 policy): "Annual leave: 18 days"
• Chunk B (2024 updated policy): "Annual leave: 15 days (revised)"

দুটো chunk-ই relevant। Retrieval সফল।

কিন্তু এরপর তিনটা জায়গায় problem হতে পারে:

🔴 Zone 1 — Context Assembly Failure
দুটো chunk একসাথে LLM-এ পাঠানো হলো, কিন্তু কোনটা latest সেটা বলা হলো না। LLM এখন conflicting information পাচ্ছে। সে নিজে সিদ্ধান্ত নিলো — বেশিরভাগ সময় ভুলটাই বেছে নেয়।

🔴 Zone 2 — LLM Grounding Failure
Prompt-এ clearly বলা নেই যে "শুধু context থেকে উত্তর দাও।" তখন model নিজের training থেকে একটা সংখ্যা বানিয়ে দেয় — হয়তো বলে "20 days।" Context-এ এই সংখ্যা নেই।

🔴 Zone 3 — Answer Faithfulness Failure
Chunk ঠিক পেয়েছে, grounding আছে, কিন্তু model summary করতে গিয়ে important condition বাদ দিয়ে দিলো। যেমন বললো "15 days" — কিন্তু বললো না যে এটা শুধু permanent employees-এর জন্য।

━━━━━━━━━━━━━━━━
⚠️ সবচেয়ে common mistake

Team retrieval accuracy measure করে খুশি হয়ে বসে থাকে। ভাবে retrieval ভালো মানে system ভালো।

কিন্তু retrieved chunk আর final answer আলাদাভাবে evaluate করতে হয়। একটা দিয়ে আরেকটা judge করা যাবে না।

Fix: প্রতিটা stage আলাদাভাবে log করো — কোন chunk retrieve হলো, কী context assemble হলো, final answer কী এলো। তারপর manually বা LLM-as-judge দিয়ে faithfulness check করো।

━━━━━━━━━━━━━━━━
🧩 Mini Challenge

তোমার RAG system user-এর প্রশ্নের জন্য সঠিক chunk retrieve করেছে। কিন্তু answer-এ একটা extra condition আছে যেটা chunk-এ ছিলো না।

এটা কোন zone-এর failure?
— Context Assembly?
— LLM Grounding?
— Answer Faithfulness?

উত্তর নিচে 👇
...

✅ এটা Zone 2 — LLM Grounding Failure। Model নিজের training থেকে extra কিছু যোগ করেছে কারণ prompt তাকে সেটা থেকে বিরত রাখেনি।

━━━━━━━━━━━━━━━━
💡 Takeaway

▪ Retrieval success ≠ Answer correctness — এই দুটো আলাদা metric।
▪ RAG pipeline-এ তিনটা আলাদা failure zone আছে: context assembly, LLM grounding, answer faithfulness।
▪ প্রতিটা zone আলাদাভাবে debug করতে শেখো — একসাথে দেখলে কোনটা ভাঙছে বোঝা যাবে না।

━━━━━━━━━━━━━━━━
💬 তোমার RAG system-এ কি এই তিনটার মধ্যে কোনো layer আলাদাভাবে evaluate করার কোনো mechanism আছে? নাকি শুধু end-to-end accuracy দেখো?

26/04/2026

২০২৬ সালে একটা চাকরির চাহিদা হঠাৎ করে অনেক বেড়ে গেছে — Chief Data Officer (CDO)।

MIT-এর সাম্প্রতিক একটা সার্ভেতে দেখা গেছে, বড় কোম্পানিগুলোতে CDO পদ ৭০%-এ পৌঁছেছে — গত বছরের চেয়ে ২০% বেশি। কারণটা সহজ: AI-তে টাকা ঢালা শুরু হয়েছে, কিন্তু data ঠিকমতো গোছানো না থাকলে সেই টাকা পানিতে যাবে।

এখানে একটা জিনিস বুঝতে হবে:
AI model কিনে ফেলা সহজ।
কিন্তু সেই model-এ কোন data দেবে, কতটুকু বিশ্বাস করবে, output দিয়ে কী decision নেবে — এটা ঠিক করার জন্য একজন দরকার যে data আর business দুটোই বোঝে।

এই কারণেই CDO-দের কদর বাড়ছে। তারা শুধু dashboard বানায় না — তারা পুরো কোম্পানির "data কীভাবে সিদ্ধান্ত নেবে" সেই কাঠামোটা তৈরি করে।

GenAI নিয়ে যত興উৎসাহ, তার পেছনে একটা boring কিন্তু জরুরি সত্য আছে:
$4.4 trillion productivity gain তখনই আসবে, যখন data গভর্নেন্স ঠিক থাকবে।

তোমরা যারা data career নিয়ে ভাবছো — শুধু model চালাতে শেখা এখন যথেষ্ট না। Business context বোঝা, data কোথা থেকে আসছে সেটা trace করতে পারা, আর decision-maker-দের ভাষায় কথা বলতে পারাটাই এখন আসল edge।

তোমার কাছে যদি প্রশ্ন করি — তোমার কোম্পানিতে বা তুমি যে কোম্পানিতে কাজ করতে চাও, সেখানে data নিয়ে কে সিদ্ধান্ত নেয়? নাকি সেটা এখনো কেউ ঠিকমতো করছেই না?

Surrounded by Data

25/06/2026

23/05/2026

22/05/2026

22/05/2026

21/05/2026

30/04/2026

27/04/2026

26/04/2026

26/04/2026

Address

Website

Alerts

Shortcuts

Share

Category

Listing takedown request