LLM Chatbot ও RAG System ডিজাইন

LLM চালিত chatbot এখন প্রায় প্রতিটি প্রোডাক্টে ঢুকছে — কাস্টমার সাপোর্ট থেকে ইন্টারনাল ডকুমেন্ট সার্চ। কিন্তু কাঁচা LLM শুধু তার training-এর সময় পর্যন্ত জানে আর মাঝে মাঝে আত্মবিশ্বাসের সাথে ভুল বলে (hallucination)। তাই বাস্তব সিস্টেমে আমরা RAG (Retrieval-Augmented Generation) ব্যবহার করি — চলো পুরো জিনিসটা ডিজাইন করি।

১. সমস্যা বোঝা (Requirements)

Functional requirements:

• কোম্পানির ডকুমেন্ট (PDF, wiki, FAQ) ingest করে searchable knowledge base বানাও।
• ব্যবহারকারীর প্রশ্নের জন্য relevant তথ্য খুঁজে grounded উত্তর দাও।
• উত্তর streaming-এ দেখাও যাতে ব্যবহারকারী অপেক্ষা না করে।
• উৎস (citation) দেখাও যাতে উত্তর যাচাই করা যায়।
• মাল্টি-টার্ন conversation মনে রাখো।

Non-functional requirements:

• Latency: প্রথম টোকেন (time-to-first-token) ১ সেকেন্ডের কম; পুরো উত্তর streaming।
• Accuracy/Grounding: উত্তর retrieved context-এ ভিত্তি করে; hallucination ন্যূনতম।
• Cost: প্রতি query-র token খরচ নিয়ন্ত্রণে।
• Freshness: নতুন ডকুমেন্ট কয়েক মিনিটে index হবে।
• Safety: prompt injection, PII leak, ক্ষতিকর আউটপুট ঠেকানো (guardrails)।

২. স্কেল আন্দাজ (Estimation)

ডকুমেন্ট সংখ্যা          : ১০০,০০০ ডকুমেন্ট
গড় chunk/ডকুমেন্ট        : ২০ → মোট ~২ মিলিয়ন chunk
Embedding dim            : ১,৫৩৬ float × ৪ বাইট ≈ ৬ KB/chunk
Vector storage           : ২M × ৬KB ≈ ১২ GB (ANN index, RAM)

চ্যাট QPS                : ১০০ QPS (পিক)
প্রতি query token:
  retrieved context      : ~৪-৬ chunk × ~৪০০ token ≈ ২,০০০ token
  system + history       : ~১,০০০ token
  output                 : ~৫০০ token
  মোট input              : ~৩,০০০ token, output ~৫০০ token

খরচ আন্দাজ (উদাহরণ মূল্যে): input ~$3/M, output ~$15/M ধরলে
  per query ≈ (৩০০০×$3 + ৫০০×$15)/1M ≈ $0.016
  ১০০ QPS × ৮৬,৪০০ সে = ~৮.৬M query/দিন → cost বড়, cache অপরিহার্য

Latency:
  embedding query        : ~৩০ ms
  vector search          : ~৩০ ms
  LLM time-to-first-token: ~৫০০-৮০০ ms

মূল শিক্ষা: token খরচই dominant cost; semantic cache ও context সংকোচন দিয়ে এটা নাটকীয়ভাবে কমানো যায়।

৩. API ডিজাইন

POST /v1/chat
  body: { session_id, message, user_id }
  → 200 OK (Server-Sent Events stream)
    event: token  data: "আংশিক উত্তর..."
    event: sources data: [ { doc_id, title, url, score } ]
    event: done   data: { tokens_used, cached: false }

POST /v1/ingest
  body: { doc_id, source_url, content, metadata }
  → 202 Accepted   # async chunk → embed → upsert

DELETE /v1/documents/{doc_id}   # vector ও metadata মুছে ফেলা

Streaming-এর জন্য SSE বা WebSocket ব্যবহার করা হয়, যাতে token একটার পর একটা ব্যবহারকারীকে পাঠানো যায়।

৪. ডেটা মডেল ও Features

উপাদান	বিবরণ	কোথায় থাকে
Document	original content, metadata (source, date, ACL)	doc store
Chunk	~৩০০-৫০০ token টুকরো, overlap সহ	vector DB payload
Embedding	chunk-এর vector	vector DB (ANN)
Conversation	session history (turn-by-turn)	session store (Redis)
Cache	query embedding → উত্তর	semantic cache
ACL/permission	কোন user কোন doc দেখতে পারে	metadata filter

Offline (ingest) pipeline: ডকুমেন্ট → পরিষ্কার → chunk → embed → vector DB-তে upsert। এটা batch বা streaming-এ চলে।

Online (query) pipeline: query embed → retrieve → prompt build → LLM → stream। দুটো পথ আলাদা কিন্তু একই embedding মডেল ব্যবহার করে — না হলে query ও chunk একই space-এ থাকবে না।

৫. হাই-লেভেল ডিজাইন

কম্পোনেন্ট:

• Client — চ্যাট UI, streaming রেন্ডার করে।
• API / Chat Orchestrator — পুরো RAG flow সাজায়।
• Ingestion Service — chunk + embed + upsert।
• Embedding Service — query ও chunk embed।
• Vector Database — ANN similarity search।
• Semantic Cache — পুনরাবৃত্ত query-র উত্তর ধরে রাখে।
• LLM Service — prompt নিয়ে stream-এ উত্তর তৈরি করে।
• Guardrail layer — input/output filter।
• Session store — conversation history।

Flow ধাপে ধাপে:

1. ব্যবহারকারীর message orchestrator-এ আসে; input guardrail (prompt injection, PII, abuse) চেক।
2. Semantic cache দেখা হয়; কাছাকাছি query থাকলে cached উত্তর stream করে শেষ।
3. না হলে message embed করে vector DB-তে ACL filter সহ top-k chunk retrieve।
4. Retrieved chunk + system prompt + recent history দিয়ে prompt তৈরি (token budget মেনে)।
5. Prompt LLM-এ পাঠিয়ে token streaming শুরু; প্রথম token দ্রুত client-এ।
6. Output guardrail (toxic/PII/leak) প্রবাহের উপর প্রয়োগ; সাথে citation যোগ।
7. সম্পূর্ণ উত্তর ও query semantic cache-এ লেখা, session history আপডেট, এবং token usage লগ।

৬. গভীরে (Deep Dive)

Chunking ও Embedding

Chunking-এর মান retrieval-এর মান নির্ধারণ করে। খুব বড় chunk মানে অপ্রাসঙ্গিক টেক্সট context-এ ঢুকে token নষ্ট; খুব ছোট মানে অর্থ ভেঙে যায়। সাধারণত ৩০০-৫০০ token, কিছুটা overlap সহ — যাতে একটা ধারণা দুই chunk-এর সীমানায় হারিয়ে না যায়। কাঠামোগত ডকুমেন্টে heading-aware splitting আরও ভালো কাজ করে। সব chunk একটা embedding মডেল দিয়ে vector-এ রূপান্তরিত হয়ে metadata (doc_id, source, ACL) সহ vector DB-তে যায়।

Retrieval Quality

শুধু vector similarity যথেষ্ট নয়। উন্নত করার উপায়:

• Hybrid search: keyword (BM25) + vector মিলিয়ে, যাতে নির্দিষ্ট নাম/কোড-ও ধরা পড়ে।
• Reranking: প্রথমে বেশি candidate এনে একটা ছোট cross-encoder দিয়ে আবার rank করা, তারপর top কয়েকটা LLM-কে দেওয়া।
• Metadata filter: ACL দিয়ে ব্যবহারকারীর অনুমতি নেই এমন doc আগেই বাদ — security ও relevance দুটোই।

Guardrails ও Grounding

Prompt-এ স্পষ্ট নির্দেশ দাও — "শুধু প্রদত্ত context থেকে উত্তর দাও; না জানলে বলো জানা নেই।" এতে hallucination কমে। Output-এ citation দিলে ব্যবহারকারী যাচাই করতে পারে। Input ও output দুই দিকেই guardrail — input-এ prompt injection ও PII, output-এ toxic content ও sensitive তথ্য leak ধরা।

৭. বটলনেক ও স্কেলিং

• LLM latency ও cost: সবচেয়ে বড় খরচ ও দেরির উৎস। সমাধান — semantic cache (একই অর্থের query-তে hit), context token কমানো, সহজ প্রশ্নে ছোট/সস্তা মডেল আর কঠিন প্রশ্নে বড় মডেল (model routing), এবং streaming দিয়ে perceived latency কমানো।
• Vector search scale: index sharding ও replication; ১২ GB index RAM-এ, বড় হলে distributed ANN।
• Freshness: ingest async; নতুন doc দ্রুত embed ও upsert, পুরোনো delete করলে vector-ও মুছতে হবে।
• Retrieval quality drift: ডকুমেন্ট বদলালে retrieval খারাপ হতে পারে; offline eval set দিয়ে নিয়মিত পরিমাপ (answer relevance, faithfulness)।
• Caching tradeoff: semantic cache cost বাঁচায় কিন্তু stale উত্তর দিতে পারে; TTL ও invalidation দরকার।

৮. সারসংক্ষেপ

RAG chatbot-এর মূল হলো দুটো pipeline — offline ingest (chunk → embed → vector DB) আর online query (retrieve → prompt → LLM → stream)। ভালো chunking, hybrid retrieval ও reranking দিয়ে grounding বাড়ে; semantic cache ও model routing দিয়ে cost ও latency কমে; আর guardrail দিয়ে নিরাপত্তা আসে। এগুলো একসাথে না করলে chatbot হয় ধীর, ব্যয়বহুল, না হয় অনিরাপদ।