Chapter 1-এ আমরা শিখেছি কীভাবে LLM API ব্যবহার করে Application-এ AI যুক্ত করা যায়। Chapter 2-এ দেখেছি Embeddings, Vector Database এবং RAG ব্যবহার করে AI-কে নিজের Data-এর সাথে যুক্ত করা যায়। কিন্তু একটি AI Feature তৈরি করলেই কাজ শেষ নয়। User বাড়তে শুরু করলে, Conversation বড় হলে এবং একই সময়ে হাজার হাজার Request আসলে একটি নতুন সমস্যা সামনে আসে—Performance এবং Cost।

একটি AI Application Development Environment-এ খুব ভালো কাজ করতে পারে, কিন্তু Production-এ যাওয়ার পর ধীর হয়ে যেতে পারে, API Cost বেড়ে যেতে পারে, Database-এর উপর অতিরিক্ত Load পড়তে পারে কিংবা একই Request-এর জন্য অপ্রয়োজনীয়ভাবে অনেক Token পাঠাতে পারে। তাই AI Engineering-এর একটি গুরুত্বপূর্ণ অংশ হলো Optimization—কম Resource ব্যবহার করে দ্রুত, নির্ভরযোগ্য এবং Scalable AI System তৈরি করা।

---

Problem Statement — AI Application কেন ধীর এবং ব্যয়বহুল হয়ে যায়?

ধরুন একজন User একটি AI Chat Application-এ প্রতিবার Message পাঠাচ্ছে। প্রথম কয়েকটি Message খুব দ্রুত কাজ করছে। কিন্তু Conversation যত বড় হচ্ছে, প্রতিটি নতুন Request-এর সাথে পুরনো Message-গুলোও LLM-এর কাছে পাঠানো হচ্ছে।

Turn 1 → ছোট Context
Turn 10 → বড় Context
Turn 50 → আরও বড় Context
Turn 100 → বিশাল Context

এর ফলে তিনটি সমস্যা তৈরি হয়।

প্রথমত, Token Usage বাড়ে। দ্বিতীয়ত, Model-এর Response পেতে বেশি সময় লাগে। তৃতীয়ত, প্রতিটি Request-এর Cost বাড়তে থাকে। অর্থাৎ User যত বেশি Chat করবে, System তত বেশি Expensive হয়ে উঠবে।

এখানেই AI Optimization গুরুত্বপূর্ণ হয়ে ওঠে।

---

1. Context Optimization

LLM-এর কাছে যত বেশি Context পাঠানো হয়, সাধারণত তত বেশি Token Process করতে হয়। তাই একটি গুরুত্বপূর্ণ Optimization হলো অপ্রয়োজনীয় Context বাদ দেওয়া।

ধরো User-এর একটি Conversation-এ ২০০টি Message আছে। প্রতিটি Request-এ সব ২০০টি Message পাঠানোর পরিবর্তে সর্বশেষ Relevant Message-গুলো পাঠানো যেতে পারে।

200 Messages
     ↓
Relevant Context
     ↓
Last N Messages
     ↓
LLM

তবে শুধু পুরনো Message বাদ দিলে গুরুত্বপূর্ণ Information হারিয়ে যেতে পারে। তাই বড় Conversation-এর ক্ষেত্রে পুরনো Context-এর একটি Summary তৈরি করে সেটি নতুন Context-এর সাথে পাঠানো যেতে পারে।

Old Conversation
       ↓
Summary
       ↓
Recent Messages
       ↓
LLM Context

এভাবে Context ছোট রাখা যায়, কিন্তু গুরুত্বপূর্ণ Information-ও ধরে রাখা যায়।

---

2. Token Optimization

AI Application-এর অন্যতম বড় Cost হলো Token Usage। তাই শুধু Model Selection নয়, কত Token পাঠানো এবং Generate করা হচ্ছে সেটিও গুরুত্বপূর্ণ।

অপ্রয়োজনীয় System Prompt, অতিরিক্ত Conversation History, বড় Document বা অপ্রয়োজনীয় Metadata বারবার পাঠানো উচিত নয়।

একটি ভালো AI Architecture প্রতিটি Request-এর জন্য চিন্তা করে—

কোন Information সত্যিই Model-এর দরকার?

যেটি দরকার নেই সেটি Context থেকে বাদ দেওয়া যায়।

এটি শুধু Cost কমায় না; অনেক সময় Response Latency-ও কমায়।

---

3. Model Selection এবং Model Routing

সব Task-এর জন্য সবচেয়ে বড় Model ব্যবহার করার দরকার নেই।

ধরো একটি Application-এ তিন ধরনের কাজ আছে।

Simple Classification → Small Model
Normal Conversation   → Medium Model
Complex Reasoning     → Large Model

Simple Task-এর জন্য ছোট এবং দ্রুত Model ব্যবহার করলে Cost অনেক কমানো যায়।

এটিকে Model Routing বলা হয়।

একটি Router প্রথমে বুঝবে User-এর Request কী ধরনের। তারপর সেই অনুযায়ী উপযুক্ত Model নির্বাচন করবে।

User Request
     ↓
Model Router
     ├── Simple → Fast Model
     ├── Normal → Standard Model
     └── Complex → Powerful Model

Production AI System-এ এটি Cost এবং Performance দুটোই Optimize করতে পারে।

---

4. Streaming — Perceived Latency কমানো

ধরো Model-এর সম্পূর্ণ উত্তর তৈরি হতে ৮ সেকেন্ড লাগছে।

যদি User-কে ৮ সেকেন্ড অপেক্ষা করিয়ে তারপর পুরো Response দেখানো হয়, Application ধীর মনে হবে।

কিন্তু Streaming ব্যবহার করলে Model প্রথম Token তৈরি করার সাথে সাথে সেটি User-এর কাছে পাঠানো যায়।

LLM
 ↓
Token 1 → User
 ↓
Token 2 → User
 ↓
Token 3 → User
 ↓
Token 4 → User

এখানে পুরো Generation শেষ হওয়ার আগেই User Response দেখতে শুরু করে।

তাই Streaming-এর একটি বড় সুবিধা হলো Perceived Latency কমানো।

তবে Production Environment-এ Proxy বা Compression Layer যেন Streaming Response Buffer না করে, সেটিও নিশ্চিত করতে হয়। অন্যথায় Backend Streaming করলেও User শেষ পর্যন্ত পুরো Response একসাথে পেতে পারে।

---

5. Caching — একই কাজ বারবার না করা

একটি AI Application-এ সব Data প্রতিবার নতুন করে Database বা External API থেকে Fetch করার দরকার নেই।

যে Data ঘন ঘন Read হয় কিন্তু খুব কম পরিবর্তন হয়, সেটি Cache করা যায়।

Request
  ↓
Cache
  │
  ├── Hit → Return
  │
  └── Miss
       ↓
    Database
       ↓
      Cache

Redis-এর মতো Cache Layer ব্যবহার করে Frequently Accessed Data দ্রুত Return করা যায়।

উদাহরণ হিসেবে Application Configuration, Product Metadata, Public Settings বা অন্য কোনো Frequently Read Data Cache করা যেতে পারে।

তবে Cache-এর ক্ষেত্রে TTL এবং Invalidation Strategy গুরুত্বপূর্ণ। পুরনো Data অনির্দিষ্ট সময় Cache করে রাখলে Data Stale হয়ে যেতে পারে।

---

6. Database Optimization

AI Application-এর Performance শুধু LLM-এর উপর নির্ভর করে না। Backend Database Query-ও পুরো Request-এর Latency বাড়াতে পারে।

ধরো একটি Query বারবার একই ধরনের Filter এবং Sorting ব্যবহার করছে কিন্তু Database-এ উপযুক্ত Index নেই।

তখন Database অনেক Document Scan করতে পারে।

Without Index
Query
 ↓
Scan thousands/millions of documents
 ↓
Result

Index থাকলে:

Query
 ↓
Index
 ↓
Relevant Documents
 ↓
Result

তাই AI Application Optimize করার সময় Database Query এবং Indexing-ও পরীক্ষা করতে হবে।

---

7. N+1 Query Problem

আরেকটি Common Performance Problem হলো N+1 Query।

ধরো Application প্রথমে ২০টি Conversation নিয়ে এলো। তারপর প্রতিটি Conversation-এর জন্য আলাদাভাবে Message Count এবং Last Message Query করল।

তাহলে একটি Request-এ অনেকগুলো Database Query তৈরি হতে পারে।

এর পরিবর্তে Aggregation বা Batch Query ব্যবহার করা যায়।

Bad:

Conversation 1 → Query
Conversation 2 → Query
Conversation 3 → Query
...
Conversation 20 → Query


Better:

All Conversations
       ↓
One Batch/Aggregation Query
       ↓
Results

এভাবে Database Round Trip কমানো যায়।

---

8. Parallel Processing

সব কাজ Sequentially করার দরকার নেই।

ধরো একটি Request-এর জন্য তিনটি Independent Data দরকার:

Database A
Database B
Configuration

যদি একটির পর একটি Fetch করা হয়:

A → B → Config

তাহলে মোট সময় তিনটির Latency যোগ হতে পারে।

যদি তারা একে অপরের উপর নির্ভরশীল না হয়:

A ─┐
B ─┼→ Results
C ─┘

তাহলে Parallel Processing করা যায়।

এতে Request-এর মোট Latency উল্লেখযোগ্যভাবে কমতে পারে।

---

9. Concurrency Control

Parallel Processing শক্তিশালী হলেও সবকিছু একসাথে চালানো ঠিক নয়।

ধরো একটি Background Job-এর মধ্যে ১০,০০০টি User-এর জন্য AI Request পাঠাতে হবে।

সবগুলো একসাথে পাঠালে—

• LLM Provider Rate Limit হতে পারে
• Database Overload হতে পারে
• Memory Usage বেড়ে যেতে পারে
• External API Block করতে পারে

তাই Bounded Concurrency ব্যবহার করা হয়।

10,000 Jobs
     ↓
Batch of 20
     ↓
Process
     ↓
Next 20
     ↓
Process

অর্থাৎ System একই সময়ে সীমিত সংখ্যক কাজ চালাবে।

এটি Performance এবং Stability-এর মধ্যে Balance তৈরি করে।

---

10. Queue ব্যবহার করা

সব কাজ User-এর HTTP Request-এর মধ্যে করার দরকার নেই।

যেসব কাজ দীর্ঘ সময় নিতে পারে বা Background-এ করা যায়, সেগুলো Queue-তে পাঠানো ভালো।

উদাহরণ:

User Request
     ↓
Backend
     ↓
Queue
     ↓
Worker
     ↓
AI Processing

যেমন Document Processing, Large File Embedding, Report Generation, Email Sending বা Batch AI Processing Background Worker দিয়ে করা যেতে পারে।

এর ফলে Main API দ্রুত Response দিতে পারে এবং Heavy Work আলাদা Worker Handle করতে পারে।

---

11. Retry এবং Exponential Backoff

External AI API সবসময় 100% সফল হবে না। Network Error, Temporary Server Error বা Rate Limit হতে পারে।

তাই Temporary Failure-এর ক্ষেত্রে Retry করা যায়।

কিন্তু সঙ্গে সঙ্গে বারবার Request পাঠানো উচিত নয়।

Attempt 1
   ↓
Fail
   ↓
Wait
   ↓
Attempt 2
   ↓
Fail
   ↓
Wait Longer
   ↓
Attempt 3

এটিকে Exponential Backoff বলা হয়।

তবে Retry করার আগে একটি গুরুত্বপূর্ণ বিষয় হলো Idempotency। একই Operation Retry করলে যেন Duplicate Action না হয়।

---

12. Timeout এবং Resource Protection

ধরো AI Provider কোনো কারণে Response দিতে অনেক সময় নিচ্ছে। যদি Backend Request-টি অনির্দিষ্ট সময় ধরে Open রাখে, তাহলে অনেক Connection জমে যেতে পারে।

তাই External API Call-এর জন্য Timeout রাখা উচিত।

Request
   ↓
LLM API
   ↓
Timeout
   ↓
Abort
   ↓
Controlled Error

এতে একটি Slow External Service পুরো Backend System-কে আটকে দিতে পারে না।

---

13. Rate Limiting

AI API প্রতিটি Request-এর জন্য Cost তৈরি করতে পারে। তাই Public AI Application-এ Rate Limiting অত্যন্ত গুরুত্বপূর্ণ।

ধরো একজন User প্রতি সেকেন্ডে শত শত Request পাঠাচ্ছে।

তাহলে সেটি শুধু Server Load নয়, AI API Cost-ও বাড়াতে পারে।

তাই User, Session, API Key বা Tenant অনুযায়ী Limit দেওয়া যায়।

User
 ↓
Rate Limiter
 ├── Within Limit → AI Request
 └── Exceeded → Reject / Delay

এটি Abuse এবং Unexpected AI Cost দুটোই কমাতে সাহায্য করে।

---

14. Monitoring এবং Observability

Optimization অনুমান করে করা উচিত নয়। আগে Measure করতে হবে, তারপর Optimize করতে হবে।

একটি Production AI System-এ গুরুত্বপূর্ণ Metrics হতে পারে:

• Request Latency
• Time to First Token (TTFT)
• Total Response Time
• Input Tokens
• Output Tokens
• Cost per Request
• Error Rate
• Cache Hit Rate
• Database Query Time
• Model Response Time
• Queue Processing Time

একটি Request-এর জন্য এমন একটি ধারণাগত Flow রাখা যায়:

Request
 ↓
DB Time
 ↓
Retrieval Time
 ↓
LLM Time
 ↓
Generation Time
 ↓
Total Latency

তখন বোঝা যায় Bottleneck আসলে কোথায়।

---

15. Performance Optimization-এর সঠিক Approach

সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো—আগে Measure, পরে Optimize।

অনেক Developer অনুমান করে Code Optimize করেন। কিন্তু বাস্তবে Bottleneck অন্য জায়গায় থাকতে পারে।

সঠিক Process:

Measure
   ↓
Find Bottleneck
   ↓
Optimize
   ↓
Test
   ↓
Measure Again

Database-এর ক্ষেত্রে Query Execution Plan দেখা যেতে পারে। API-এর ক্ষেত্রে p50, p95 এবং p99 Latency দেখা যেতে পারে। AI-এর ক্ষেত্রে Token Usage এবং Model Latency Track করা যায়।

এভাবে Optimization Data-driven হয়।

---

16. AI Application-এর একটি Optimized Architecture

সবগুলো Concept একসাথে ধরলে একটি Production AI System অনেকটা এমন হতে পারে:

                    User
                      │
                      ▼
                API Gateway
                      │
                Rate Limiter
                      │
                      ▼
                Backend API
                      │
          ┌───────────┴───────────┐
          │                       │
        Cache                  Database
          │                       │
          └───────────┬───────────┘
                      │
                      ▼
               Context Builder
                      │
                      ▼
                Model Router
                      │
             ┌────────┴────────┐
             │                 │
        Fast Model        Large Model
             │                 │
             └────────┬────────┘
                      │
                      ▼
                  Response
                      │
                      ▼
                  Streaming
                      │
                      ▼
                     User

Background কাজের জন্য Queue এবং Worker আলাদা করা যায়:

Application
    ↓
Queue
    ↓
Worker
    ↓
AI / Database / External APIs

এই Architecture-এর লক্ষ্য শুধু দ্রুত Response দেওয়া নয়; বরং Cost, Scalability, Reliability এবং User Experience—সবকিছুর মধ্যে Balance তৈরি করা।

---

একজন AI Engineer কীভাবে Optimization নিয়ে চিন্তা করেন?

একজন Beginner সাধারণত প্রশ্ন করেন:

"কোন Model সবচেয়ে ভালো?"

কিন্তু একজন AI Engineer আরও অনেক প্রশ্ন করেন:

"এই Task-এর জন্য সবচেয়ে ছোট এবং যথেষ্ট ভালো Model কোনটি?"

তিনি আরও চিন্তা করেন—

কত Token পাঠানো হচ্ছে?

কোন Context সত্যিই দরকার?

কোন Data Cache করা যায়?

কোন কাজ Background-এ পাঠানো যায়?

কোন Request Parallel করা যায়?

কোথায় Rate Limit দরকার?

কোথায় Retry দরকার?

কোন API Slow হচ্ছে?

Database Query কোথায় Bottleneck তৈরি করছে?

আর সবচেয়ে গুরুত্বপূর্ণ—

"আমরা কীভাবে প্রমাণ করব যে Optimization-এর পরে System সত্যিই ভালো হয়েছে?"

এই চিন্তাভাবনাই AI Integration-কে একটি সাধারণ API Integration থেকে Production Engineering-এর দিকে নিয়ে যায়।

---

Chapter 3 থেকে কী শিখলাম?

এই Chapter-এ আমরা দেখলাম একটি AI Application Production-এ যাওয়ার পরে Performance এবং Cost কেন গুরুত্বপূর্ণ হয়ে ওঠে।

আমরা শিখলাম:

• Context Optimization
• Token Optimization
• Model Routing
• Streaming
• Caching
• Database Indexing
• N+1 Query Optimization
• Parallel Processing
• Concurrency Control
• Queue এবং Background Processing
• Retry ও Exponential Backoff
• Timeout
• Rate Limiting
• Monitoring ও Observability
• Data-driven Performance Optimization

---

উপসংহার

একটি AI Application ভালো হওয়া মানে শুধু ভালো উত্তর দেওয়া নয়। একটি Production AI System-কে একই সাথে Fast, Cost-Efficient, Reliable এবং Scalable হতে হয়।

একটি ছোট Application-এ হয়তো সরাসরি LLM API Call করলেই কাজ হয়ে যায়। কিন্তু User এবং Data বাড়ার সাথে সাথে Context Management, Caching, Database Optimization, Model Routing, Queue, Rate Limiting এবং Observability-এর মতো বিষয়গুলো অপরিহার্য হয়ে ওঠে।

তাই AI Engineering-এর একটি গুরুত্বপূর্ণ Principle হলো:

Better AI System ≠ শুধু Better Model

বরং,

Better AI System = Model + Architecture + Data + Performance + Reliability + Cost Optimization

এখন আমরা LLM ব্যবহার করতে জানি, AI-কে নিজের Data-এর সাথে যুক্ত করতে জানি এবং সেই AI System-কে কীভাবে Fast ও Scalable করা যায় সেটিও বুঝলাম।

কিন্তু পরবর্তী ধাপে আমরা আরও একটি বড় পরিবর্তন দেখতে পাব।

এখন পর্যন্ত AI মূলত আমাদের প্রশ্নের উত্তর দিয়েছে। এবার আমরা AI-কে এমনভাবে তৈরি করব যাতে সে নিজে সিদ্ধান্ত নিতে পারে, Tool ব্যবহার করতে পারে এবং একটি নির্দিষ্ট Goal পূরণ করার জন্য একাধিক Step execute করতে পারে।

সেখান থেকেই শুরু হবে পরবর্তী Chapter—

Chapter 4 — AI Agents: যখন AI শুধু উত্তর দেয় না, কাজও করে