AI/LLM System Design

RAG architecture, LLM gateway, খরচ ও গতি

রোডম্যাপের মাস ৯পড়তে প্রায় ৮ মিনিট

AI feature বানানো এক জিনিস, লাখো user এর জন্য নির্ভরযোগ্য, নিরাপদ আর লাভজনকভাবে চালানো আরেক জিনিস। LLM এর চরিত্র সাধারণ API থেকে আলাদা: ধীর (সেকেন্ড), ব্যয়বহুল (প্রতি request এ পয়সা না, টাকার হিসাব), অনিশ্চিত (একই প্রশ্নে আলাদা উত্তর), আর বাইরের provider এর সীমার উপর নির্ভরশীল। এই অধ্যায়ে AI system এর architecture: LLM gateway, RAG এর বড় রূপ, খরচ, গতি, নিরাপত্তা আর মান।

#একটা AI product এর পূর্ণ ছবি

App SSE stream AI service auth, quota, orchestration Guardrail input/output যাচাই Retrieval vector + keyword Cache উত্তর / prompt Tools order, refund API LLM gateway routing, fallback, retry, rate limit, খরচ হিসাব, log/trace → provider A / B, বড়/ছোট model Eval + feedback মান মাপা, নমুনা review
Model শুধু একটা অংশ। চারপাশের retrieval, guardrail, gateway, cache আর eval ই product কে নির্ভরযোগ্য বানায়।

#LLM gateway

App এর প্রতিটা জায়গা থেকে সরাসরি provider এর API ডাকার বদলে একটা কেন্দ্রীয় স্তর:

কাজ কেন
একটা interface Feature code জানে না কোন provider/model; বদলানো এক জায়গায়
Model routing সহজ কাজ ছোট model এ, কঠিন কাজ বড় model এ
Fallback একটা provider/model এর সমস্যা বা refusal হলে বিকল্পে
Retry আর timeout Rate limit আর অস্থায়ী error সামলানো (Resilience)
Quota আর rate limit User/team প্রতি দৈনিক token বা টাকার সীমা
খরচ হিসাব প্রতিটা call এর token আর টাকা, feature আর user অনুযায়ী
Log আর trace Prompt, উত্তর, latency (ব্যক্তিগত তথ্য আড়াল করে)
Secret API key এক জায়গায়, app এর প্রতিটা অংশে ছড়ানো না

#গতি (latency) এর কৌশল

LLM এর উত্তর কয়েক সেকেন্ড নেয়; user এর অনুভূতি গুরুত্বপূর্ণ:

  • Streaming: প্রথম শব্দ দ্রুত দেখানো (time to first token) পুরো উত্তরের সময়ের চেয়ে বেশি গুরুত্বপূর্ণ
  • ছোট model সহজ কাজে: classification, routing, ছোট সারাংশ
  • সমান্তরাল কাজ: retrieval আর user এর তথ্য আনা একসাথে
  • Prompt caching: লম্বা স্থির অংশ (system prompt, নীতিমালা, tool এর বর্ণনা) cache হলে দ্রুত আর সস্তা
  • Async/background: যেটা তাৎক্ষণিক লাগে না (রাতের report, review বিশ্লেষণ) queue আর batch এ
  • UX: "খুঁজছি...", "উত্তর লিখছি..." এর মতো অগ্রগতির বার্তা

#খরচের architecture

AI feature এর খরচ ব্যবহারের সাথে সরাসরি বাড়ে, সাধারণ server এর মতো স্থির না। তাই design এর সময়েই হিসাব:

Text
মাসিক খরচ ≈ সক্রিয় user × দিনে প্রশ্ন × ৩০ × (input token × input দাম + output token × output দাম)

খরচ কমানোর lever, সহজ থেকে কঠিন:

  1. Caching: একই উত্তর (FAQ) নিজের cache এ; লম্বা স্থির prompt এর prompt caching
  2. Context ছোট রাখা: RAG এ শুধু দরকারি chunk; লম্বা chat history এর সারাংশ
  3. Output ছোট রাখা: সংক্ষিপ্ত উত্তর চাওয়া, max_tokens
  4. Model routing: সহজ কাজ সস্তা model এ (প্রায়ই দামের পার্থক্য দশ গুণের বেশি)
  5. Batch: তাৎক্ষণিক না লাগলে batch API (কম দাম)
  6. Quota: free user এর দৈনিক সীমা, paid plan এ বেশি

#বড় পরিসরের RAG

RAG অধ্যায়ের ছোট রূপ থেকে বড় system এ যা বদলায়:

  • Ingestion pipeline: document আসে নানা জায়গা থেকে (upload, Google Drive, website), queue দিয়ে worker রা parse → chunk → embed করে; বদলালে শুধু বদলানো অংশ আবার
  • Permission সহ index: প্রতিটা chunk এ কে দেখতে পারবে তার তথ্য (owner, team, role), খোঁজার সময় filter; document এর permission বদলালে index ও আপডেট
  • Hybrid search + reranking: vector আর keyword মিলিয়ে বেশি প্রার্থী, তারপর reranker
  • Vector database এর scale: লাখো-কোটি vector এ pgvector এর বদলে বা পাশে বিশেষ vector DB, sharding
  • Freshness: পুরনো তথ্যে উত্তর না দিতে মেয়াদ আর পুনরায় index

#নিরাপত্তা আর guardrail

ঝুঁকি প্রতিরোধ
Prompt injection (user বা document থেকে) Data আর নির্দেশ আলাদা, tool এ permission যাচাই, ঝুঁকির কাজে মানুষের অনুমোদন
Data ফাঁস (অন্যের document, system prompt এর গোপন তথ্য) Retrieval এ permission filter, system prompt এ গোপন তথ্য না রাখা
ক্ষতিকর বা ভুল উত্তর Output যাচাই (format, নিষিদ্ধ বিষয়), সূত্র দেখানো, "জানি না" বলার নির্দেশ
ব্যক্তিগত তথ্য log এ Log এর আগে আড়াল (phone, NID), সংরক্ষণের সময়সীমা
খরচের আক্রমণ (ইচ্ছা করে লম্বা prompt) Input এর আকারের সীমা, quota, rate limit

#মান: eval আর feedback loop

Production Log + feedback 👍/👎, ভুল Eval set বাড়ানো নতুন case উন্নতি + মাপা prompt/model/retrieval মাপার পর তবেই release
AI feature কখনো "শেষ" হয় না। বাস্তব ব্যবহার থেকে শেখা, মাপা, উন্নতি, আবার মাপা।
  • Offline eval: release এর আগে নির্দিষ্ট set এ (Agent ও Evals)
  • Online মাপ: 👍/👎 এর হার, প্রশ্নের পর user কী করলো (support ticket খুললো মানে উত্তর কাজে আসেনি), latency, খরচ
  • Model বদলের আগে: নতুন model সস্তা বা দ্রুত হলেও eval না চালিয়ে বদলাবে না; কিছু কাজে ভালো, কিছুতে খারাপ হতে পারে

#Interview এ AI system design

"একটা customer support chatbot design করো" এ যা বলবে:

  1. Requirement: কোন প্রশ্নের ধরন, কোন ভাষা, কোন কাজ করতে পারবে (refund? শুধু তথ্য?), মানুষের কাছে কখন হস্তান্তর
  2. Estimation: দিনে কত conversation, token, মাসিক খরচ
  3. Architecture: gateway, RAG (FAQ/নীতিমালা), tool (order status), guardrail, cache, মানুষের হস্তান্তর
  4. Deep dive: prompt injection, permission, latency (streaming), খরচ কমানো, eval আর feedback

#অনুশীলন

#নিজেকে যাচাই করো

LLM gateway রাখার তিনটা লাভ বলো।

Provider বা model বদলানো এক জায়গায় (feature code অপরিবর্তিত), fallback আর retry কেন্দ্রীয়ভাবে, আর প্রতিটা call এর খরচ, quota আর log এক জায়গায় নিয়ন্ত্রণ।

AI feature এ streaming কেন গুরুত্বপূর্ণ?

পুরো উত্তর আসতে কয়েক সেকেন্ড লাগে। Streaming এ প্রথম শব্দ দ্রুত আসে, user অপেক্ষার অনুভূতি পায় না, আর লম্বা উত্তরও স্বাভাবিক মনে হয়।

বড় RAG system এ permission কোথায় প্রয়োগ করতে হয়?

Retrieval এর সময় খোঁজার filter এ: প্রতিটা chunk এ কে দেখতে পারবে সেই তথ্য রেখে শুধু user এর অনুমোদিত chunk খোঁজা। LLM কে পরে বলা "অন্যের তথ্য দেখাবে না" যথেষ্ট না।

সস্তা নতুন model এ সরাসরি বদলানো কেন ঝুঁকিপূর্ণ?

কিছু কাজে সে ভালো, কিছুতে খারাপ হতে পারে, আর সেটা অনুভূতি দিয়ে বোঝা যায় না। Eval set চালিয়ে মান, খরচ আর গতি তুলনা করে তবেই বদলাতে হয়।

চিহ্ন দিলে sidebar আর রোডম্যাপে এই অধ্যায়ের station ভরে যাবে।