কনটেন্টে যান

৫. ফরওয়ার্ড ডিপ্লয়েড ইঞ্জিনিয়ারিং — আপনার লোকাল-LLM কর্মসূচির আসল প্রয়োজনীয় ভূমিকা

পড়তে সময়: ৩০ মিনিট। কোনো কোড নেই। উদ্দেশ্য: এই বইয়ের চারটি ফেজ যে কাজটি বর্ণনা করে, সেই কাজটিকে একটি নাম ও শৃঙ্খলা দেওয়া — যাতে পরের কোয়ার্টারে নতুন কোনো ইঞ্জিনিয়ার যোগ দিলে সে জানে সে কোন ভূমিকায় প্রবেশ করছে এবং AI শিল্পের বাকি অংশ যে ভাষা ব্যবহার করে সেটি ব্যবহার করতে পারে। পূর্বশর্ত: অ্যাডপশন সারসংক্ষেপ। ফরওয়ার্ড ডিপ্লয়েড ইঞ্জিনিয়ারিং (FDE) হলো ডিস্কভার / পাইলট / বিল্ড / স্কেল-এর একটি দৃষ্টিভঙ্গি, বদলে দেওয়া নয়।

ফরওয়ার্ড ডিপ্লয়েড ইঞ্জিনিয়ার (FDE) এর ভূমিকা Palantir / OpenAI / Anthropic-এর প্রচলিত buzzword থেকে AI অর্গানাইজেশন চার্টে এখন একটি স্বাভাবিক লাইন আইটেমে পরিণত হয়েছে। নামটি সহজ অংশ; শৃঙ্খলাটিই গুরুত্বপূর্ণ। FDE-রা সাধারণ ব্যাকএন্ড টিমের মতো সফটওয়্যার তৈরি করে না। তারা গ্রাহকের পরিবেশে যথেষ্ট দীর্ঘ সময় বসে থাকে, গ্রাহকের প্রকৃত ডেটার উপর গ্রাহকের নিজস্ব হার্ডওয়্যারে একটি কার্যকর সিস্টেম তৈরি করে এবং চলে যাওয়ার আগে সেই চলমান সিস্টেমটি গ্রাহকের নিজস্ব ইঞ্জিনিয়ারদের কাছে হস্তান্তর করে। হস্তান্তরটিই হলো deliverable, কোড নয়।

এই বই ইতিমধ্যেই সেই কাজটি বর্ণনা করে। চারটি ফেজ — ডিস্কভার, পাইলট, বিল্ড, স্কেল — হলো FDE-র playbook, কার্যকর ভাষায় লেখা। এই অধ্যায়টি হলো শব্দভান্ডার: ভূমিকা, পদ্ধতি, trade-offs, এবং AI শিল্পের বাকি অংশ যে FDE হায়ারিং মার্কেট এখন চালাচ্ছে তার সাথে সংযোগ।

আপনি যদি প্রথমবারের মতো এই বই পড়ছেন এমন কোনো ইঞ্জিনিয়ার হন, তাহলে বাস্তব উত্তরটি হলো: আপনার পরের দুই বছর একজন FDE-র মতো দেখাবে, ব্যাকএন্ড ইঞ্জিনিয়ারের মতো না। তিনজনের একটি প্ল্যাটফর্ম টিম দশটি ব্যবসায়িক ইউনিটে শিপিং করে এমন একটি লোকাল-LLM কর্মসূচির মালিক হবে। আপনি সেই তিনজনের একজন হবেন। কাজটি হলো FDE-র কাজ, এমনকি আপনার পদবী যদি এখনও "ML engineer" বা "platform engineer" বলে।

আপনি যদি কোনো ম্যানেজার হন, তাহলে বাস্তব উত্তরটি হলো: তিনজন ML engineer নিয়োগের আগে একজন FDE নিয়োগ করুন। একজন শক্তিশালী FDE-ই হলো একটি কর্মসূচি এবং একটি প্রকল্পের মধ্যে পার্থক্য। FDE হলেন সেই ব্যক্তি যিনি ১ম দিনে ব্যাংকের IT হেল্পডেস্কে যান, দুই সপ্তাহ ধরে হেল্পডেস্ক লিড-এর সাথে বসেন, এবং একটি চলমান classifier নিয়ে বেরিয়ে আসেন। আপনি যে তিনজন ML engineer নিয়োগ করতে পারতেন তারা সেই দুই সপ্তাহ মডেলের সাইজ নিয়ে তর্ক করতেন।

FDE কী

"ফরওয়ার্ড ডিপ্লয়েড ইঞ্জিনিয়ার" শব্দটি ২০০০-এর দশকের শেষের দিকে Palantir থেকে এসেছে। মূল deployment মডেলটি ছিল: গ্রাহকের পরিবেশে সিনিয়র ইঞ্জিনিয়ারদের একটি ছোট দল পাঠানো, তাদের একটি সমস্যা দেওয়া, এবং গ্রাহকের ডেটার বিরুদ্ধে শিপ করতে দেওয়া। "ফরওয়ার্ড"-এর "ফরওয়ার্ড" হলো "forward operating base"-এর "ফরওয়ার্ড" — ইঞ্জিনিয়ার গ্রাহকের এলাকায়, সদর দপ্তর থেকে দেখছে না।

এক লাইনে কাজটি: একজন FDE হলেন সেই ইঞ্জিনিয়ার যার কাজ হলো গ্রাহকের প্রথম কার্যকর সিস্টেম শিপ করা, ইঞ্জিনিয়ারের পঞ্চম abstraction layer নয়।

ভূমিকাটির অস্তিত্বের কারণ হলো ভেন্ডরের ডেমো এবং গ্রাহকের প্রথম প্রোডাকশন ব্যবহারের মধ্যবর্তী ফাঁকটি এমন কাজে পূর্ণ যা কোনো ভেন্ডরের প্রোডাক্ট টিম কখনো করবে না। ভেন্ডর একটি মডেল শিপ করে। গ্রাহকের একটি workflow, একটি ডেটা-রেসিডেন্সি সীমাবদ্ধতা, একটি বিদ্যমান ticketing সিস্টেম, একটি on-call rotation, একটি change-management বোর্ড এবং একজন CISO রয়েছে যাকে স্বাক্ষর করতে হবে। ভেন্ডর ticketing সিস্টেমের সাথে integrate করবে না, CISO-এর সাথে সম্প্রীতি করবে না, change-management বোর্ডে বসবে না। গ্রাহকের পক্ষে কেউ একজনকে এই সবকিছু করতে হবে। সেই কেউ হলেন FDE।

তিনটি বৈশিষ্ট্য ভূমিকাটিকে সংজ্ঞায়িত করে। প্রথমটি হলো কাজের নৈকট্য: FDE গ্রাহকের কাছে, প্ল্যাটফর্ম টিমের কাছে নয়, এবং গ্রাহক সেটা বুঝতে পারে। দ্বিতীয়টি হলো সময়ের জরুরিতা: FDE-র deliverable হলো ২-সপ্তাহের প্রোটোটাইপ এবং ৮-সপ্তাহের পাইলট, ৬-মাসের রোডম্যাপ নয়। তৃতীয়টি হলো হস্তান্তরের মালিকানা: FDE শুধু সিস্টেম শিপ করে না, FDE চলে গিয়ে গ্রাহকের কাছে এমন ইঞ্জিনিয়ার রেখে আসে যারা এটি চালাতে পারে। হস্তান্তরটিই হলো deliverable; সিস্টেমটি হলো প্রমাণ।

এটি ভাবার একটি দরকারী উপায়: একজন ব্যাকএন্ড ইঞ্জিনিয়ার অভ্যন্তরীণ ব্যবহারকারীদের কাছে একটি service শিপ করে; একজন FDE একজন গ্রাহকের কাছে (বা যে অভ্যন্তরীণ টিম গ্রাহক সেই টিমের কাছে) একটি service শিপ করে। ভূমিকার বিবরণের বাকি অংশ এই একটি পার্থক্য থেকে অনুসরণ করে।

FDE পদ্ধতি: অডিট → ইভালস → ডিপ্লয়মেন্ট

FDE-র playbook-এ তিনটি ধাপ রয়েছে, ক্রমানুসারে। এগুলি এই বইয়ের চারটি ফেজের সাথে প্রায় ১:১ ম্যাপ করে।

FDE ধাপ বইয়ের ফেজ FDE কী করছে সময়-বাক্স
অডিট ডিস্কভার টিমের সাথে বসে, workflow ম্যাপ করা, bottleneck খুঁজে বের করা, বার লেখা। ১–২ সপ্তাহ
ইভালস পাইলট একটি ছোট প্রোটোটাইপ তৈরি করা, প্রকৃত ডেটার উপর shadow mode-এ চালানো, বার-এর বিরুদ্ধে পরিমাপ করা। ২–৪ সপ্তাহ
ডিপ্লয়মেন্ট বিল্ড + স্কেল প্রোটোটাইপকে গ্রাহকের হার্ডওয়্যারে production-এ নিয়ে যাওয়া, গ্রাহকের ইঞ্জিনিয়ারদের কাছে হস্তান্তর করা। ৪–৮ সপ্তাহ

পদ্ধতিটি লোকাল-LLM শিল্পের চেয়ে পুরনো। এটি ২০০০-এর দশকের শেষের দিকে Palantir যে আকৃতি ব্যবহার করেছিল, ২০১০-এর দশকের শেষের দিকে প্রাথমিক applied-AI consultancy-গুলি যে আকৃতি ব্যবহার করেছিল, এবং গ্রাহকের ডেটার বিরুদ্ধে শিপ করে এমন যেকোনো consultancy যে আকৃতি ব্যবহার করে সেটি। এই বইয়ের লোকাল-LLM কর্মসূচিটি একই আকৃতি, ডেটা-রেসিডেন্সি সীমাবদ্ধতা যোগ করা হয়েছে, এবং ডেটা-রেসিডেন্সি সীমাবদ্ধতাই FDE-কে বাধ্যতামূলক করে তোলে, ঐচ্ছিক নয়।

ধাপ ১ — অডিট (১–২ সপ্তাহ)

FDE প্রথম এক বা দুই সপ্তাহ গ্রাহকের সাইটে কাটায়। কনফারেন্স রুমে নয় — ফ্লোরে, প্রকৃত কাজ করা ইঞ্জিনিয়ারদের সাথে। কাজটি হলো workflow ম্যাপ করা, bottleneck খুঁজে বের করা এবং বার লেখা। আউটপুট হলো একটি এক-পৃষ্ঠার মেমো যেখানে একটি হ্যাঁ / না / হ্যাঁ-কিন্তু রায় থাকে — ঠিক ডিস্কভার deliverable, দুটি সংযোজন সহ:

  1. মেমোতে স্বাক্ষর করেন গ্রাহকের sponsor, FDE-র ম্যানেজার নয়। গ্রাহকের স্বাক্ষরই প্রমাণ যে কাজটির একজন স্থানীয় মালিক আছে।
  2. মেমোতে গ্রাহকের ইঞ্জিনিয়ারের নাম থাকে যিনি হস্তান্তর গ্রহণ করবেন। কোনো নাম ছাড়া, হস্তান্তরের কোনো গন্তব্য নেই।

অডিটই সবচেয়ে গুরুত্বপূর্ণ ধাপ, কারণ অডিটই খারাপ ধারণাগুলি সস্তায় হত্যা করে। যে FDE অডিট এড়িয়ে যায় এবং তৈরি শুরু করে, সে ৮ সপ্তাহ ব্যয় করবে ভুল জিনিস তৈরি করে, এবং গ্রাহক জানবে এটি FDE-র দোষ। যে FDE ২-সপ্তাহের অডিট চালায় এবং একটি "না" মেমো লেখে, তাকে ধন্যবাদ জানানো হবে, কারণ গ্রাহক এইমাত্র ৮ সপ্তাহ বাঁচিয়েছে।

ধাপ ২ — ইভালস (২–৪ সপ্তাহ)

FDE একটি ছোট প্রোটোটাইপ শিপ করে, গ্রাহকের প্রকৃত ডেটার বিরুদ্ধে shadow mode-এ চালায় এবং agreement rate পরিমাপ করে। এটি পাইলট ফেজ, একটি সংযোজন সহ: eval সেটটি হলো গ্রাহকের eval সেট, ভেন্ডরের নয়। ভেন্ডরের eval সেট বিমূর্তভাবে মডেল benchmark করার জন্য। গ্রাহকের eval সেট হলো জিজ্ঞাসা করা "এই মডেলটি কি হেল্পডেস্ক লিড যেভাবে উত্তর দিতেন সেভাবে উত্তর দিয়েছে?"। দুটি একই জিনিস নয়।

eval সেটটিও FDE-র সবচেয়ে মূল্যবান artifact। FDE চলে যাওয়ার পরে এটিই টিকে থাকে। FDE চলে যায়, এবং গ্রাহক eval সেট রাখে। ছয় মাস পরে, যখন মডেল আপগ্রেড করতে হয়, eval সেটই আপগ্রেড সিদ্ধান্তকে reproducible করে তোলে। eval সেট হলো মডেলের সাথে গ্রাহকের চুক্তি — frozen reference যা বলে "ভালো দেখতে এটি এরকম"।

FDE-র নিয়ম: কোনো প্রোটোটাইপ production-এ যাবে না eval সেট ছাড়া। eval সেট ছাড়া প্রোটোটাইপ হলো ডেমো। eval সেট সহ প্রোটোটাইপ হলো পণ্য।

ধাপ ৩ — ডিপ্লয়মেন্ট (৪–৮ সপ্তাহ)

FDE প্রোটোটাইপটি নেয়, একটি service হিসেবে package করে, গ্রাহকের হার্ডওয়্যারে deploy করে এবং গ্রাহকের ইঞ্জিনিয়ারদের কাছে হস্তান্তর করে। ডিপ্লয়মেন্ট হলো বিল্ড ফেজ, একটি সংযোজন সহ: FDE থাকে না। হস্তান্তরটিই হলো deliverable। যদি FDE-র প্রস্থানের মুহূর্তটিই হয় যখন সিস্টেমটি কাজ করা বন্ধ করে দেয়, তাহলে ডিপ্লয়মেন্ট ব্যর্থ।

হস্তান্তরের চারটি অংশ রয়েছে:

  1. একটি runbook যা গ্রাহকের ইঞ্জিনিয়াররা পরীক্ষা করেছে, FDE নয়।
  2. একটি rollback ফায়ার-ড্রিল যা গ্রাহকের ইঞ্জিনিয়াররা চালায়, FDE দেখে, উল্টোটা নয়।
  3. একটি on-call rotation যেখানে গ্রাহকের নাম থাকে, FDE-র নয়।
  4. একটি লিখিত হস্তান্তর মেমো যা বলে কী কাজ করে, কী করে না এবং পরবর্তী ৯০ দিনে গ্রাহকের কী দেখা উচিত।

চারটিই সত্য হলে, FDE চলে যেতে পারে। এগুলির কোনোটি অনুপস্থিত থাকলে, FDE-র কাজ শেষ হয়নি, এমনকি সিস্টেম production-এ থাকলেও।

কেন লোকাল-LLM এন্টারপ্রাইজের FDE প্রয়োজন (এবং ক্লাউড-মডেল কোম্পানিগুলির নয়)

একটি ক্লাউড-মডেল কোম্পানি তার গ্রাহকের AI ফিচার শিপ করতে পারে কেউ গ্রাহকের অফিসে না গিয়েও। মডেলটি ভেন্ডরের ডেটা সেন্টারে, API ভেন্ডরের infrastructure-এ, গ্রাহকের ডেটা একটি Data Processing Agreement-এর অধীনে ভেন্ডরের কাছে পাঠানো হয়, এবং গ্রাহক শুধু একজন sales engineer-এর সাথে কথা বলে। Sales engineer FDE নন — তারা গ্রাহকের সাইটে থাকে না, গ্রাহকের ডেটার বিরুদ্ধে তৈরি করে না এবং চলমান সিস্টেম হস্তান্তর করে না। তারা বিক্রি করে।

একটি লোকাল-LLM এন্টারপ্রাইজ এটি করতে পারে না। তিনটি সীমাবদ্ধতা FDE-কে অন-সাইটে বাধ্য করে:

  1. ডেটা নেটওয়ার্ক ছেড়ে যেতে পারে না। কোনো DPA নেই, কোনো hosted API নেই, কোনো SaaS shortcut নেই। মডেলটিকে গ্রাহকের হার্ডওয়্যারে, গ্রাহকের ডেটার বিরুদ্ধে, গ্রাহকের নেটওয়ার্কে চলতে হবে। এটি ঘটানোর জন্য কাউকে গ্রাহকের সাইটে থাকতে হবে।
  2. গ্রাহকের হার্ডওয়্যার হলো গ্রাহকের হার্ডওয়্যার। FDE একটি জেনেরিক VM-এ LM Studio ইনস্টল করতে পারে না। FDE-কে গ্রাহকের নির্দিষ্ট workstation-এ, নির্দিষ্ট OS-এ, নির্দিষ্ট AV সফটওয়্যারে, নির্দিষ্ট firewall rules এবং নির্দিষ্ট change-management বোর্ড approval সহ LM Studio ইনস্টল করতে হবে। এর কোনোটিই জেনেরিক নয়।
  3. গ্রাহকের workflow হলো গ্রাহকের workflow। হেল্পডেস্ক ভেন্ডরের হেল্পডেস্ক নয়। ticketing সিস্টেম ভেন্ডরের ticketing সিস্টেম নয়। shift handover ভেন্ডরের shift handover নয়। FDE-কে গ্রাহকের কাছ থেকে গ্রাহকের workflow শিখতে হবে, sales deck থেকে নয়।

এই কারণেই এই বইয়ের লোকাল-LLM কর্মসূচি কাঠামোগতভাবে একটি FDE কর্মসূচি, এমনকি আমরা এটিকে এতক্ষণ FDE বলিনি। on-prem সীমাবদ্ধতা FDE-কে বাধ্যতামূলক করে তোলে, ঐচ্ছিক নয়। একটি ক্লাউড-মডেল কোম্পানি একজন sales engineer নিয়োগ করে শিপ করতে পারে; একটি লোকাল-LLM কোম্পানিকে একজন FDE নিয়োগ করে গ্রাহকের সাথে embed করতে হবে।

স্বাভাবিক ফলাফল হলো FDE-র বাজার মূল্য sales engineer-এর চেয়ে বেশি, কারণ FDE-কে প্রতিস্থাপন করা কঠিন। পণ্য জানেন এমন একজন sales engineer হলেন sales engineer; যে sales engineer গ্রাহকের হার্ডওয়্যারে কার্যকর সিস্টেম শিপ করেছেন এবং গ্রাহকের ইঞ্জিনিয়ারদের কাছে হস্তান্তর করেছেন, তিনি হলেন FDE। প্রথমজনকে এক সপ্তাহে প্রতিস্থাপন করা যায়; দ্বিতীয়জনকে বেড়ে উঠতে ছয় মাস লাগে।

"অটোমেট করবেন কি করবেন না" নিয়ম

FDE-র কাজের সবচেয়ে কঠিন অংশ হলো "অটোমেট করবেন না" অর্ধেক। ডিফল্ট ধারণা — যে প্রতিটি workflow অটোমেশনের প্রার্থী — ভুল, এবং যে FDE এটি বিশ্বাস করে সে গ্রাহকের সময় নষ্ট করবে। নিয়মটি LLM-এর চেয়ে পুরনো, এবং এটিই একজন FDE-কে prompt-সহ একজন junior engineer থেকে আলাদা করে।

একটি workflow লোকাল-LLM অটোমেশনের জন্য ভালো প্রার্থী যদি এবং শুধু যদি এই তিনটিই সত্য হয়:

  1. ইনপুট সীমিত। একটি ticket, একটি config ফাইল, একটি অভ্যন্তরীণ নথির একটি অনুচ্ছেদ, একটি shift log। "সম্পূর্ণ গ্রাহক ডেটাবেস" নয়, "শেয়ার ড্রাইভের প্রতিটি নথি" নয়। সীমিত ইনপুট মানে মডেলের context window bottleneck নয়।
  2. আউটপুট হলো সিদ্ধান্ত, generation নয়। একটি category, একটি priority, একটি risk flag, একটি ৩-বুলেট summary, একটি পরিচিত প্রশ্নের উত্তর। গ্রাহককে email নয়, দীর্ঘ-ফর্ম রিপোর্ট নয়, "প্রতিটি ব্যবহারকারীর আবেগীয় অবস্থার জন্য ব্যক্তিগতকৃত প্রতিক্রিয়া" নয়। সিদ্ধান্ত পরীক্ষাযোগ্য; generation নয়।
  3. কাজের আজ পরিমাপযোগ্য খরচ আছে। মানুষ কাজটি করছে, কাজটি সময় নেয়, সময়ের অর্থ খরচ হয়, ত্রুটির হার পরিমাপযোগ্য। কাজটি যদি বর্তমানে বিনামূল্যে হয়, বা ত্রুটির হার অজানা হয়, কাজটি অটোমেশনের জন্য প্রস্তুত নয় — এটি পরিমাপের জন্য প্রস্তুত।

যে FDE গ্রাহকের শীর্ষ ১০টি workflow-এর বিরুদ্ধে এই তিনটি প্রশ্ন চালায়, সে দেখবে ৬–৭টি প্রার্থী নয়। সব ১০টিতে একটি অটোমেশন প্রার্থী খুঁজে পাওয়ার প্রবৃত্তি হলো ব্যর্থ হওয়ার প্রবৃত্তি। ভালো খবর হলো যে ৩–৪টি যেগুলি প্রার্থী সেগুলি সাধারণত উচ্চ-মূল্যের, এবং সেই ৩–৪টিতে শিপ করাই কর্মসূচি তৈরি করে।

এটি ডিস্কভার — ধাপ ১-এ যুক্তি, এবং এটি সেখানে থাকার কারণ হলো যুক্তিটি FDE-র যুক্তি। বই এবং ভূমিকা একই জিনিস।

"মিলিয়ন-ডলার হায়ার" সমস্যা

FDE মার্কেট টাইট। সেরা FDE-রা হলেন সেই ইঞ্জিনিয়াররা যারা গ্রাহকের অফিসে বসতে পারেন, এমন একটি workflow শিখতে পারেন যা গ্রাহক সচেতনভাবে বর্ণনা করতে জানে না, একটি ২০০-লাইনের প্রোটোটাইপ লিখতে পারেন, shadow-mode eval চালাতে পারেন, এটিকে service হিসেবে package করতে পারেন, গ্রাহকের হার্ডওয়্যারে deploy করতে পারেন এবং হস্তান্তর করতে পারেন — সব ১২ সপ্তাহে। সেই ইঞ্জিনিয়ার বিরল। তাদের সেরাটি হলেন সেই লোকেরা যাদের Applied-AI consultancies এবং platform কোম্পানিগুলি \(৪০০k–\)৭০০k base salary-তে নিয়োগ করার চেষ্টা করছে। সবচেয়ে খারাপটি হলেন সেই লোকেরা যারা ৬টি ধাপের ২টি করতে পারে।

একজন FDE-র প্রয়োজন এমন একজন hiring manager-এর তিনটি বিকল্প আছে, খরচের ক্রমানুসারে:

  1. ৫+ বছরের প্ল্যাটফর্ম কাজ এবং গ্রাহক-মুখী মনোভাব সহ একজন সিনিয়র ইঞ্জিনিয়ার নিয়োগ করুন। তাদের FDE playbook-এ প্রশিক্ষণ দিন (এই অধ্যায়টি playbook-এর ৩০-মিনিটের সংস্করণ)। প্রশিক্ষণের খরচ হলো একজন অভিজ্ঞ FDE-র সাথে ৬ মাসের shadowing, এবং ব্যর্থতার হার উচ্চ — প্রার্থীদের অর্ধেক প্রকাশ পাবে যে তারা সিনিয়র ইঞ্জিনিয়ার যারা ticketing সিস্টেম ছাড়া কাজ করতে পারে না। বাকি অর্ধেক হবেন সেই লোকেরা যাদের আপনি নিয়োগ করতে চেয়েছিলেন।
  2. একটি applied-AI consultancy থেকে একজন FDE নিয়োগ করুন। এটি দ্রুত কিন্তু বেশি ব্যয়বহুল; চলমান হার হলো \(৪০০k–\)৭০০k base salary সাথে equity। সুবিধা হলো তারা playbook ইতিমধ্যে লোড করা অবস্থায় আসে। অসুবিধা হলো তারা একটি লোকাল-LLM engagement করেনি, এবং on-prem সীমাবদ্ধতাই প্রথম স্থানে FDE-কে বাধ্যতামূলক করে তোলে। লোকাল-LLM-নির্দিষ্ট ops কাজ শিখতে আপনি তাদের ৩–৬ মাসের salary প্রদান করবেন।
  3. একটি engagement-এর জন্য consultant FDE নিয়োগ করুন। দ্রুততম পথ, সর্বোচ্চ unit cost। প্রথম engagement-এর জন্য দরকারী, দ্বিতীয় engagement-এর জন্য অদরকারী। প্রথম engagement হলো যখন FDE গ্রাহকের পরিবেশের জন্য playbook লেখে; দ্বিতীয় engagement হলো যখন গ্রাহকের নিজস্ব ইঞ্জিনিয়াররা playbook চালায়। আপনি যদি ৩ নম্বর engagement-এও এখনও FDE consultant কিনছেন, আপনি একটি কর্মসূচি তৈরি করছেন না।

বেশিরভাগ লোকাল-LLM এন্টারপ্রাইজের জন্য সঠিক উত্তর হলো বিকল্প ১: সিনিয়র ইঞ্জিনিয়ার নিয়োগ করুন, তাদের এই বইয়ের মধ্য দিয়ে চালান এবং ৫০% ব্যর্থতার হার গ্রহণ করুন। যে ৫০% সফল হয় তারা হলেন আপনি যে FDE চেয়েছিলেন; যে ৫০% ব্যর্থ হয় তারা এখনও সিনিয়র ইঞ্জিনিয়ার, এবং আপনার সিনিয়র ইঞ্জিনিয়ার যাই হোক দরকার ছিল।

কেস স্টাডিগুলি FDE engagement হিসেবে

এই বইয়ের তিনটি কেস স্টাডি — ISP support, Bank IT, Factory IT — হলো worked FDE engagements। FDE lens-এর মাধ্যমে এগুলি পড়া হলো অনুশীলনে একজন FDE কী করে তা দেখার দ্রুততম উপায়।

ISP support triage (কেস স্টাডি)। দুই-ইঞ্জিনিয়ারের একটি FDE টিম NOC লিড-এর সাথে এক সপ্তাহ বসেছিল, tier-1 ticket workflow ম্যাপ করেছিল, একটি হ্যাঁ রায় লিখেছিল, NOC-র বিদ্যমান workstation-এ একটি Qwen 1.5B classifier শিপ করেছিল, প্রকৃত tickets-এর বিরুদ্ধে ৯০ দিনের shadow mode চালিয়েছিল এবং NOC-র নিজস্ব ইঞ্জিনিয়ারদের কাছে সিস্টেমটি হস্তান্তর করেছিল। ৯১.৩% category agreement এবং ২.৬ সেকেন্ড p95 হলো audit artifacts। হস্তান্তর মেমো এবং eval সেট হলো deliverable। FDE আর অন-সাইটে নেই; NOC ইঞ্জিনিয়াররা সিস্টেমের মালিক।

Bank IT helpdesk (কেস স্টাডি)। তিন-ইঞ্জিনিয়ারের একটি FDE টিম (একজন platform, একজন data, একজন ops) ব্যাংকের IT হেল্পডেস্ক লিড-এর সাথে দুই সপ্তাহ বসেছিল, workflow audit করেছিল, ব্যাংকের নিজস্ব SOP-এর উপর একটি RAG সিস্টেম তৈরি করেছিল, এটিকে একটি Teams bot হিসেবে deploy করেছিল, ৬০ দিনের shadow mode চালিয়েছিল এবং হস্তান্তর করেছিল। ০% hallucinated content এবং ৯৬.৭% citation accuracy হলো audit artifacts। প্রোটোটাইপের আগে লিখিতভাবে স্বাক্ষরিত CISO-র বার হলো deliverable। ব্যাংকের হেল্পডেস্ক ইঞ্জিনিয়াররা সিস্টেমের মালিক; ব্যাংকের security টিম audit log-এর মালিক; ব্যাংকের infrastructure টিম LM Studio host-এর মালিক।

Factory IT operations (কেস স্টাডি)। দুই-ইঞ্জিনিয়ারের একটি FDE টিম কারখানার ফ্লোরে ১০ দিন কাটিয়েছিল, তিনটি shift handover দেখেছিল, free-form notes workflow ম্যাপ করেছিল, একটি containment-check validator সহ একটি ৫-ফিল্ডের typed summarizer তৈরি করেছিল, কারখানার নিজস্ব server-এ deploy করেছিল, ৭৫ দিনের shadow mode চালিয়েছিল এবং হস্তান্তর করেছিল। ০% hallucinated fields এবং n=8-এ ১০০% safety-incident recall হলো audit artifacts। containment-check validator হলো deliverable — এটি সেই test যা মূল FDE টিম কখনো দেখেনি এমন নতুন failure modes তৈরি না করে আপগ্রেড সারভাইভ করতে সিস্টেমকে সক্ষম করে।

তিনটিতেই FDE-র কাজ একই আকৃতির: workflow audit করা, বার লেখা, প্রোটোটাইপ শিপ করা, shadow mode চালানো, হস্তান্তর করা। পার্থক্যগুলি স্থানীয় — মডেলের সাইজ, ডেটা, হার্ডওয়্যার, গ্রাহকের compliance regime — এবং যেটি পরিবর্তন হয় না সেটি হলো FDE-র playbook।

FDE যা করে না

একটি সংক্ষিপ্ত তালিকা, কারণ FDE-র সীমানাই ভূমিকাকে মূল্যবান করে তোলে:

  • FDE sales engineer নন। Sales engineer পণ্য demo করে। FDE সিস্টেম শিপ করে। Sales engineer-এর deliverable হলো স্বাক্ষরিত order; FDE-র deliverable হলো গ্রাহকের পরিবেশে চলমান service।
  • FDE platform engineer নন। Platform engineer প্ল্যাটফর্ম তৈরি করে; FDE গ্রাহকের ডেটার বিরুদ্ধে শিপ করতে প্ল্যাটফর্ম ব্যবহার করে। প্ল্যাটফর্ম হলো FDE-র কাঁচামাল, FDE-র deliverable নয়।
  • FDE research engineer নন। FDE-রা মডেল train করে না, paper publish করে না, leaderboard benchmark চালায় না। FDE-রা এমন মডেল ব্যবহার করে যা বিদ্যমান; research অন্য কারো কাজ।
  • FDE consultant নন। Consultant পরামর্শ দেয়; FDE সিস্টেম শিপ করে। Consultant-এর deliverable হলো slide deck; FDE-র deliverable হলো গ্রাহক ব্যবহার করতে পারে এমন চলমান service।
  • FDE স্থায়ী fixture নন। FDE-র কাজ শেষ হয় যখন গ্রাহকের ইঞ্জিনিয়াররা সিস্টেমের মালিক হয়। দুই বছর থাকা FDE আর FDE নন — তারা operations engineer, এবং তাদের পুনর্বিন্যাস বা প্রতিস্থাপন করতে হবে।

ভূমিকাটি FDE কী করে সেটির চেয়ে FDE কী করে না সেটি দিয়ে সংজ্ঞায়িত। যে সিনিয়র ইঞ্জিনিয়ার উপরের পাঁচটি কাজই করে, সে FDE নয়; সে generalist, এবং FDE playbook generalist-দের playbook নয়।

FDE-কে এই বইয়ের বাকি অংশের সাথে সংযুক্ত করা

সংযোগটি সরাসরি, এবং এটিই FDE অধ্যায়ের উদ্দেশ্য।

FDE ধাপ বইয়ের অধ্যায় কেন FDE এটি পড়ে
অডিট ডিস্কভার ১-দিনের pre-mortem হলো FDE-র প্রথম-সপ্তাহের deliverable, ত্বরিত।
ইভালস পাইলট ২–৪ সপ্তাহের shadow mode হলো FDE-র eval ফেজ। eval সেটটিই deliverable।
ডিপ্লয়মেন্ট বিল্ড ৪–৮ সপ্তাহের productionisation হলো FDE-র hand-off ফেজ। runbook-টিই deliverable।
কর্মসূচি স্কেল ৩–৬ মাসের rollout হলো FDE-র পরবর্তী engagement, এবং FDE-র playbook-ই দ্বিতীয় engagement-কে প্রথমটির চেয়ে সস্তা করে তোলে।
লোকাল-LLM সীমাবদ্ধতা কেন AI Work Flow? ডেটা-রেসিডেন্সি যুক্তিই FDE-কে লোকাল-LLM এন্টারপ্রাইজে বাধ্যতামূলক করে তোলে, ঐচ্ছিক নয়।
ডিপ্লয়মেন্ট প্যাটার্ন আর্কিটেকচার: স্তর ৫-স্তরের মডেল হলো যার বিরুদ্ধে FDE integrate করে। FDE-র কাজ হলো গ্রাহকের workflow সঠিক স্তরে পৌঁছানো।
কার্যকরী চুক্তি রেফারেন্স: Python API typed contracts হলো যা FDE হস্তান্তর করে। ChatRequest, ChatResult, ModuleMeta, audit log — FDE-র deliverable হলো রেফারেন্স বিভাগে থাকা জিনিস।

FDE অধ্যায়টি হলো সেই অধ্যায় যা বইটিকে AI শিল্পের বাকি অংশের সাথে সংযুক্ত করে। অ্যাডপশন সারসংক্ষেপ-এর চারটি ফেজ হলো FDE-র playbook, রেফারেন্স বিভাগ হলো FDE-র toolbox, কেস স্টাডিগুলি হলো FDE-র portfolio এবং আর্কিটেকচার পৃষ্ঠাগুলি হলো FDE-র মানসিক মডেল। FDE অধ্যায়টিই বইটিকে শিল্পের বাকি অংশের কাছে পাঠযোগ্য করে তোলে, কারণ "FDE" হলো সেই শব্দ যা শিল্পের বাকি অংশ ব্যবহার করে।

আরও দেখুন