১. স্তরসমূহ — পাঁচটি চুক্তি¶
এক বাক্যে: সিস্টেমটা পাঁচটি স্তরের স্ট্যাক, প্রতিটির সংকুচিত কাজ, আর বেশিরভাগ পরিবর্তন একটা স্তরেই থাকে।
আর্কিটেকচার ওভারভিউ পাঁচটি স্তর পরিচয় করিয়েছে — Edge, Application, Workflow, Core, Infrastructure। এই পাতায় সেই স্তরগুলোকে চুক্তি বানানো হলো: প্রতিটি কী দায়িত্ব পালন করে, কী করে না, আর একটা সাধারণ পরিবর্তন কোথায় যায়। প্রজেক্টের একটা নিয়ম থাকলে তা এটাই — সন্দেহ হলে এক স্তর বদলাও, দুই স্তরের সীমানা নয়।
পাঁচটি স্তর¶
১. Edge¶
অপারেটরের ব্রাউজার, টার্মিনাল, বা ফোন। প্রশ্ন করা ব্যক্তি, বা মানুষ ছাড়া ওয়ার্কফ্লো ট্রিগার করা সিস্টেম (টিকেটিং সিস্টেম, cron job, রাউটার লগ পুশ)।
- যা: রিকোয়েস্টের উৎস আর রেসপন্সের গন্তব্য।
- যা নয়: মডেল স্টেট, প্রম্পট টেমপ্লেট, বা বিজনেস লজিক রাখার জায়গা। Edge যদি ওয়ার্কফ্লো সম্পর্কে কিছু "জানে", স্তরবিন্যাস ভেঙে গেছে।
- পরিবর্তন কোথায়: UI কপি, CSS, ফর্মের শেইপ, আপস্ট্রিম সিস্টেমের ওয়েবহুক পেলোড। অপারেটর যা দেখে, শুধু তা।
২. Application¶
তোমার চলতি সিস্টেম — intranet, Slack bot, ticketing UI, Streamlit dashboard, অপারেটর পোর্টাল। এই স্তর AI-কে ব্যবসার সামনে আনে। এটা HTTP বলে। "প্রম্পট" বলে না।
- যা: এক বা তার বেশি ওয়ার্কফ্লো মডিউলের সামনে HTTP ফ্রন্ট ডোর। অথেনটিকেশন, রেট লিমিট, request id, অডিট লগ রো, আর Workflow স্তরের ওপর পাতলা অর্কেস্ট্রেশন।
- যা নয়: প্রম্পট লেখার জায়গা, মডেল কলের জায়গা, বা বিজনেস ডিসিশন এনকোডের জায়গা। Application স্তরে যদি "few-shot" বা "temperature" শব্দ থাকে, কিছু একটা ভুল হচ্ছে।
- পরিবর্তন কোথায়: নতুন রাউট, নতুন auth ইন্টিগ্রেশন, নতুন আপস্ট্রিম কানেক্টর, ইউজার-ফেসিং এরর মেসেজ পরিবর্তন।
৩. Workflow¶
সংকুচিত AI টাস্ক — অভিযোগ শ্রেণীবিভাগ, SLA ঝুঁকি মাপা, রানবুক থেকে রিট্রিভ। এখানে প্রম্পট থাকে, বিজনেস রুল থাকে, আর টাইপড আউটপুট চুক্তি থাকে। এক মডিউল = এক ওয়ার্কফ্লো = এক কাজ।
- যা: একটা ফাংশন
input → outputযেখানে ফাংশনটা "মডেলে প্রম্পট পাঠাও, Pydantic স্কিমায় ভ্যালিডেট কর, টাইপড অবজেক্ট রিটার্ন কর" দিয়ে ইমপ্লিমেন্ট। মডিউল প্রম্পট, few-shot উদাহরণ, সিস্টেম প্রম্পট, আর স্কিমা — সব নিজের মালিকানায় রাখে। - যা নয়: কোন UI কল করছে তা জানে না, কোন মডেল চলছে তা জানে না, অন্য মডিউল আছে তা জানে না। Workflow মডিউল রিপ্লেসেবল, কপি-পেস্টেবল, আর নোটবুক থেকে ইভ্যাল করতে পারো।
- পরিবর্তন কোথায়: প্রম্পট এডিট, নতুন few-shot উদাহরণ, স্কিমা অ্যাড, ইভ্যাল সেট। সিস্টেমে সবচেয়ে বেশি এডিট হওয়া স্তর — ডিজাইন অনুযায়ী।
৪. Core¶
প্রতিটি Workflow মডিউলের শেয়ার্ড লাইব্রেরি: LM Studio / vLLM / Ollama client (retry আর timeout সহ), ChromaDB retriever, settings loader (pydantic-settings), structured-logging helper।
- যা: টাইপড ইউটিলিটি যা মডেল রানটাইম আর ভেক্টর স্টোর স্থিত API-এর পেছনে লুকায়।
- যা নয়: কোনো নির্দিষ্ট বিজনেস ওয়ার্কফ্লো সম্পর্কে জানে না। Core "ISP অভিযোগ" কী তা জানে না। "chat completion request" আর "embedding search" কী তা জানে।
- পরিবর্তন কোথায়: মডেল রানটাইম বদলাও (LM Studio → vLLM), ChromaDB client আপগ্রেড, retry policy যোগ, logger বাগ ফিক্স। Core ছোঁয়া মানে সব Workflow মডিউল প্রভাবিত — পরিবর্তন ছোট আর version-pinned রাখো।
৫. Infrastructure¶
হার্ডওয়ার আর মডেল রানটাইম: GPU বক্স, CPU বক্স, LM Studio লোকাল সার্ভার, vLLM, Ollama, ডিস্কে মডেল ওয়েট ফাইল।
- যা: ইনফারেন্স আসলে যেখানে হয়। মডেল ওয়েট, GPU ড্রাইভার, OS, হোস্ট-লেভেল ফায়ারওয়াল রুল — এগুলোর মালিক।
- যা নয়: প্রম্পট, স্কিমা, বা অপারেটর সম্পর্কে জানে না। Infrastructure "এই টোকেন স্ট্রিম দাও, এই টোকেন স্ট্রিম রিটার্ন কর" — আর কিছু নয়।
- পরিবর্তন কোথায়: মডেল আপগ্রেড (Qwen 2.5 1.5B → Gemma 3 4B, বা 1.5B → নতুন 1.5B), ড্রাইভার আপগ্রেড, হার্ডওয়ার বদল, LM Studio ভার্সন বাম্প। প্রতিটি মডেল আপগ্রেডে CI-তে ফ্রোজেন ইভ্যাল সেট রি-রান হয়।
একটা সাধারণ পরিবর্তন কোথায় যায়?¶
এই প্রজেক্টে বেশিরভাগ ইঞ্জিনিয়ারিং কাজ ঠিক একটা স্তর ছোঁয়। PR খোলার আগে এই টেবিল দিয়ে স্যানিটি চেক করো।
| পরিবর্তন | স্তর | আরও ছোঁয় |
|---|---|---|
| "অভিযোগ শ্রেণীবিভাগে নতুন ক্যাটেগরি যোগ করলাম" | Workflow | Application (API রেসপন্সে নতুন enum ভ্যালু) |
| "LM Studio থেকে vLLM-এ শিফট করছি" | Infrastructure | Core (URL/transport বদল); ইভ্যাল সেট রি-রান |
| "ড্যাশবোর্ডে মডেলের confidence দেখাচ্ছে" | Application | Workflow (রেসপন্সে confidence যোগ) |
| "প্রতিটি মডেল কলে কে ট্রিগার করল তা লগ করতে হবে" | Core | Application (user id পাস) |
| "নতুন টিকেটিং সিস্টেম ইন্টিগ্রেশন যোগ করলাম" | Application | — |
| "রানবুক রিট্রিভালে নতুন embedding মডেল ব্যবহার" | Infrastructure | Core (retriever config); Workflow (ইভ্যাল সেট রি-রান) |
| "intranet URL বদলেছে" | Application | — |
| "SLA classifier দুটো ভাগ করলাম — risk আর approver" | Workflow | Application (এক রাউটের বদলে দুটো) |
তিন বা তার বেশি স্তর ছোঁয়া পরিবর্তন হলে থমো আর ভাবো — তুমি কি সীমানা রিবিল্ড করছ? বেশিরভাগ সময় উত্তর হলো পরিবর্তন নিচে নামানো (Workflow বা Core-এ) যাতে ওপরের স্তরগুলো জানতে না হয়।
এই পাতা যা নয়¶
- কোড-লেভেল ম্যাপ নয়। Workflow মডিউলগুলো একে অপরেকে import করে না; এগুলো স্বতন্ত্র এন্ট্রি পয়েন্ট যা Core শেয়ার করে। কোড-লেভেল ভিউ-এর জন্য গ্রহণযাত্রা → বিল্ড দেখো।
- ডিপ্লয়মেন্ট ডায়াগ্রাম নয়। এই পাতা দায়িত্ব নিয়ে। নেটওয়ার্ক প্লেসমেন্ট — কোন বক্সে কী চলে, কোন পোর্ট, কোন ফায়ারওয়াল — তা নিরাপত্তা-তে আছে।
- Application স্তর সরাসরি মডেল কল করার অজুহাত নয়। Workflow স্তরের পুরো উদ্দেশ্য হলো Application কখনো প্রম্পট দেখবে না। যদি দেখে, structured-output চুক্তি শেষ।
আরও দেখো¶
- আর্কিটেকচার ওভারভিউ — পাঁচ-স্তর স্ট্যাক এক নজরে, ডায়াগ্রাম সহ
- ডেটা প্রবাহ — প্রতিটি সীমানায় কী যায়, কোন ফরম্যাটে, আর কী নেটওয়ার্ক ছাড়ে না
- নিরাপত্তা — থ্রেট মডেল, নেটওয়ার্ক প্লেসমেন্ট, অডিট লগিং
- গ্রহণযাত্রা → বিল্ড — এই স্ট্যাক প্রোডাকশনে নামানোর চার ওয়ার্কস্ট্রিম