LLM কীভাবে কাজ করে? Tokenization থেকে Next-token Prediction

👋 ১. Introduction ও Episode 01-এর Recap

Episode 01-এ আমরা RAG-এর সম্পূর্ণ mental model তৈরি করেছিলাম — Retrieval, Augmentation, এবং Generation কীভাবে একসাথে কাজ করে। সেখানে আমরা LLM সম্পর্কে একটি সংক্ষিপ্ত পরিচিতি দিয়েছিলাম: training, inference, parameters, tokens, context window, prompt, generation — এই পরিভাষাগুলো।

এই Episode-এ আমরা ঠিক এই জায়গা থেকে গভীরে যাচ্ছি। প্রশ্ন হলো — একটি LLM যখন একটি prompt পায়, তখন ভেতরে ভেতরে ঠিক কী ঘটে? কীভাবে text থেকে একটি উত্তর তৈরি হয়?

গুরুত্বপূর্ণ একটি বিষয় আগে থেকেই স্পষ্ট করে নেওয়া ভালো: এই Episode transformer architecture-এর সম্পূর্ণ গাণিতিক ব্যাখ্যা (matrix multiplication, backpropagation ইত্যাদি) দেবে না। লক্ষ্য হলো একটি সঠিক conceptual mental model তৈরি করা, যাতে পরবর্তী Episode-গুলোতে Embedding, Vector Search, এবং RAG Prompting বোঝা সহজ হয়।

এই Episode শেষে আপনি বুঝতে পারবেন:

Text কীভাবে token-এ ভাঙা হয়, এবং কেন LLM সরাসরি "শব্দ" পড়ে না
Token কীভাবে সংখ্যা এবং তারপর vector-এ রূপান্তরিত হয়
LLM মূলত কী predict করে (এবং কী predict করে না)
Context Window-এর প্রকৃত অর্থ ও এর ব্যবহারিক প্রভাব
Temperature, Top-K, Top-P-এর মতো sampling parameter কী করে
কেন এই সব জ্ঞান RAG system ডিজাইন করার সময় সরাসরি কাজে লাগে

✂️ ২. Tokenization কী? — Text থেকে Token

একটি সাধারণ ভুল ধারণা হলো — LLM সরাসরি শব্দ ("word") পড়ে এবং বোঝে। বাস্তবে, LLM টেক্সট প্রসেস করার আগে সেটিকে ছোট ছোট একক-এ ভাঙে, যাকে বলা হয় token।

Tokenization হলো raw text-কে ছোট ছোট অংশে (token) ভাঙার প্রক্রিয়া। একটি token পুরো শব্দ হতে পারে, একটি শব্দের অংশ (sub-word) হতে পারে, এমনকি একটি single character-ও হতে পারে — এটি নির্ভর করে model-এর tokenizer কীভাবে design করা হয়েছে তার উপর।

উদাহরণস্বরূপ, নিচের বাক্যটি দেখুন:

"Patience is important in Islam"

একটি সাধারণ sub-word tokenizer এটিকে এভাবে ভাঙতে পারে (এটি একটি conceptual উদাহরণ, exact tokenization মডেল-ভেদে ভিন্ন হয়):

["Patience", " is", " important", " in", " Islam"]

কিন্তু একটি কম পরিচিত বা জটিল শব্দ একাধিক token-এ ভাঙতে পারে:

"unforgettable" ↓ ["un", "forget", "table"] (conceptual উদাহরণ)

গুরুত্বপূর্ণ পয়েন্ট: 1 token ≠ 1 শব্দ। ইংরেজিতে গড়ে প্রায় ১ token = ৩-৪ character, কিন্তু Bangla বা Arabic-এর মতো ভাষায় tokenization প্রায়ই কম efficient হয় — একই বাক্যের জন্য বেশি token লাগতে পারে, কারণ বেশিরভাগ tokenizer মূলত ইংরেজি-কেন্দ্রিক text দিয়ে তৈরি।

কেন Tokenization দরকার?

প্রশ্ন	উত্তর
What? (এটা কী?)	Text-কে ছোট, সংখ্যায়িত (numbered) একক-এ ভাঙার প্রক্রিয়া
Why? (কেন দরকার?)	Neural network সরাসরি text বোঝে না — এটি সংখ্যা নিয়ে কাজ করে; tokenization এই রূপান্তরের প্রথম ধাপ
Where? (কোথায় ব্যবহৃত হয়?)	LLM pipeline-এর একদম শুরুতে — prompt processing-এর প্রথম ধাপ হিসেবে

RAG-এর প্রসঙ্গে Tokenization-এর একটি সরাসরি ব্যবহারিক প্রভাব আছে: Context Window এবং Chunk Size — দুটোই আসলে "character" নয়, token-এ পরিমাপ করা হয়। Episode 01-এ আলোচিত Chunking-এর "token-based chunking" পদ্ধতি ঠিক এই ধারণার উপর ভিত্তি করেই কাজ করে।

🔢 ৩. Token ID ও Input Embedding — সংখ্যা থেকে Vector

Tokenization-এর পর, প্রতিটি token-কে একটি অনন্য (unique) সংখ্যায় রূপান্তর করা হয় — একে বলা হয় Token ID।

Text ↓ (Tokenizer) Tokens: ["Patience", " is", " important"] ↓ (Vocabulary lookup) Token IDs: [30612, 318, 1593] (conceptual উদাহরণ)

প্রতিটি model-এর একটি নির্দিষ্ট vocabulary থাকে — সব সম্ভাব্য token-এর একটি তালিকা, যেখানে প্রতিটি token-এর একটি নির্দিষ্ট ID (সংখ্যা) বরাদ্দ করা থাকে। এই ID-গুলো শুধু একটি "index" — এগুলোর মধ্যে নিজে থেকে কোনো semantic meaning নেই।

তারপর এই Token ID-গুলোকে একটি Embedding Layer-এর মধ্য দিয়ে পাঠানো হয়, যা প্রতিটি ID-কে একটি vector-এ রূপান্তর করে — একে বলা হয় Input Embedding।

Token IDs: [30612, 318, 1593] ↓ (Embedding Layer) Input Embeddings: [[0.02, -0.15, 0.88, ...], [0.41, 0.09, -0.22, ...], ...]

গুরুত্বপূর্ণ স্পষ্টীকরণ — এই Embedding, Episode 01-এ আলোচিত RAG Embedding-এর মতো নয়।

LLM-এর ভেতরের এই Input Embedding Layer শুধুমাত্র সেই নির্দিষ্ট model-এর ভেতরে ব্যবহৃত হয়, এবং এটি পুরো model architecture-এর একটি অভ্যন্তরীণ অংশ। অন্যদিকে, RAG-এ ব্যবহৃত Sentence Embedding (যেমন আমাদের project-এ ব্যবহৃত paraphrase-multilingual-MiniLM-L12-v2) একটি সম্পূর্ণ বাক্য বা অনুচ্ছেদকে একটি single vector-এ রূপান্তর করে, যা document retrieval-এর জন্য ব্যবহৃত হয়। দুটোই "embedding" শব্দটি ব্যবহার করে, কিন্তু উদ্দেশ্য ও ব্যবহার আলাদা — এই পার্থক্যটি সিরিজের পরবর্তী "Embedding কী?" Episode-এ আরও বিস্তারিত আলোচনা করা হবে।

🧠 ৪. Neural Network ও Parameters — LLM-এর "মস্তিষ্ক"

Input embedding তৈরি হওয়ার পর, এই vector-গুলো model-এর মূল অংশের মধ্য দিয়ে প্রবাহিত হয় — একটি বিশাল neural network।

Neural Network হলো স্তরে স্তরে (layer) সাজানো গাণিতিক function-এর একটি সিরিজ, যা input vector নিয়ে ধাপে ধাপে রূপান্তরিত করে একটি output vector তৈরি করে। প্রতিটি layer-এর ভেতরে থাকে parameters (weights) — এগুলোই সেই মান, যা training-এর সময় সমন্বয় (adjust) করা হয়।

যখন বলা হয় একটি model-এ "৭ বিলিয়ন parameter" আছে, এর মানে হলো — এই model-এর ভেতরে প্রায় ৭ বিলিয়ন সংখ্যা (weight) আছে, যেগুলো training-এর সময় বিপুল পরিমাণ text data দেখে ধীরে ধীরে এমনভাবে সমন্বয় করা হয়েছে, যাতে model ভাষার প্যাটার্ন ভালোভাবে ধারণ করতে পারে।

এই Episode-এ আমরা কীভাবে এই parameter-গুলো training-এর সময় adjust হয় (gradient descent, backpropagation) তার গণিত নিয়ে যাব না — শুধু এই ধারণাটুকু গুরুত্বপূর্ণ: parameters হলো model-এর "শেখা জ্ঞান" সংরক্ষণ করার জায়গা।

🔗 ৫. Transformer ও Attention — সংক্ষিপ্ত ধারণা

আধুনিক বেশিরভাগ LLM (GPT, Mistral, Llama ইত্যাদি) একটি নির্দিষ্ট neural network architecture-এর উপর ভিত্তি করে তৈরি, যাকে বলা হয় Transformer। এর গণিত জটিল, কিন্তু মূল ধারণাটি conceptually সহজ।

Attention হলো Transformer-এর একটি মূল mechanism, যা model-কে একটি বাক্যের প্রতিটি token পড়ার সময় — সেই বাক্যের অন্য কোন কোন token-এর সাথে এটি বেশি সম্পর্কিত, তা "মনোযোগ" (attention) দিয়ে বিবেচনা করতে দেয়।

উদাহরণস্বরূপ, নিচের বাক্যটি বিবেচনা করুন:

"The Hadith mentions patience, and it emphasizes its importance."

এখানে "it" শব্দটি কীসের কথা বলছে? মানুষ সহজেই বুঝতে পারে "it" মানে "patience"। Attention mechanism model-কে ঠিক এই ধরনের সম্পর্ক ধরতে সাহায্য করে — একটি token processing করার সময়, বাক্যের প্রাসঙ্গিক অন্য token-গুলোর দিকে বেশি "মনোযোগ" দেওয়া।

এই Episode-এ আমরা Attention-এর গাণিতিক সূত্র (Query, Key, Value matrices) নিয়ে বিস্তারিত যাচ্ছি না। শুধু এই conceptual ধারণাটি মনে রাখা যথেষ্ট: Transformer একটি বাক্যের ভেতরের শব্দগুলোর পারস্পরিক সম্পর্ক বিবেচনা করে context বোঝার চেষ্টা করে — শব্দগুলো আলাদা আলাদাভাবে না পড়ে।

এটি RAG-এর সাথেও পরোক্ষভাবে সম্পর্কিত: Sentence Embedding model (যা RAG-এ document/query embed করতে ব্যবহৃত হয়) প্রায়ই এই একই Transformer architecture-এর একটি রূপ ব্যবহার করে, যাতে পুরো বাক্যের অর্থ একটি single vector-এ ভালোভাবে সংকুচিত (compress) করা যায়।

🎯 ৬. Next-token Prediction — LLM আসলে কী predict করে

এখন সবচেয়ে গুরুত্বপূর্ণ ধারণাটি: একটি LLM মূলত কী কাজ করে? উত্তরটি বিস্ময়করভাবে সহজ:

একটি LLM-এর মূল কাজ হলো — এখন পর্যন্ত দেখা token-গুলোর ভিত্তিতে, পরবর্তী সবচেয়ে সম্ভাব্য token কী হবে তার একটি probability distribution predict করা।

উদাহরণস্বরূপ, model যদি এই input পায়:

"Patience is a key part of"

তাহলে এটি পরবর্তী token-এর জন্য একটি probability distribution তৈরি করে, যেমন (conceptual উদাহরণ):

সম্ভাব্য পরবর্তী token	Probability
"faith"	34%
"Islam"	21%
"life"	18%
"character"	9%
(অন্যান্য সব token)	বাকি %

একটি token বেছে নেওয়ার পর, সেটি পরবর্তী input-এর অংশ হয়ে যায়, এবং একই প্রক্রিয়া আবার চলে — একটি একটি করে token generate হতে থাকে, যতক্ষণ না উত্তর সম্পূর্ণ হয় বা একটি "stop" token আসে।

Input: "Patience is a key part of" ↓ predict next token → "faith" Input: "Patience is a key part of faith" ↓ predict next token → " in" Input: "Patience is a key part of faith in" ↓ predict next token → " Islam" ↓ ... (চলতে থাকে)

এই প্রক্রিয়াকে বলা হয় Autoregressive Generation — model নিজের আগের output-কে পরবর্তী prediction-এর input হিসেবে ব্যবহার করে, একবারে একটি token।

এখান থেকেই Hallucination-এর একটি গভীর কারণ বোঝা যায় (Episode 01-এ আলোচিত): LLM কোনো "সত্যতা যাচাই" প্রক্রিয়া চালায় না — এটি শুধু পরিসংখ্যানগতভাবে সবচেয়ে সম্ভাব্য পরবর্তী token বেছে নেয়। যদি ভুল তথ্য পরিসংখ্যানগতভাবে "স্বাভাবিক" শোনায়, model সেটাই generate করতে পারে — কারণ এর কোনো external fact-checking mechanism নেই।

📏 ৭. Context Window গভীরভাবে

Episode 01-এ আমরা Context Window-এর সংক্ষিপ্ত সংজ্ঞা দিয়েছিলাম। এখন এর ব্যবহারিক প্রভাব আরও গভীরভাবে বুঝি।

Context Window হলো একটি LLM একবারে সর্বোচ্চ কতগুলো token (input prompt + generated output মিলিয়ে) মনে রাখতে/প্রসেস করতে পারে, তার সীমা। এটি token-এ পরিমাপ করা হয়, character বা শব্দে নয়।

ধরুন একটি model-এর context window ৮,০০০ token। এর মানে —

যদি আপনার system prompt + retrieved context (RAG থেকে) + user question + model-এর generated answer — এই সবকিছু মিলিয়ে ৮,০০০ token পার হয়ে যায়, তাহলে model হয় error দেবে, অথবা শুরুর অংশ "ভুলে" যাবে (truncate হয়ে যাবে) — নির্ভর করে system কীভাবে এটি handle করে তার উপর।

RAG-এ Context Window-এর সরাসরি প্রভাব

এটাই কারণ যে কেন Episode 01-এ আমরা বলেছিলাম — পুরো knowledge base LLM-কে পাঠানো সম্ভব না। Context Window-এর সীমার কারণেই আমাদের Retrieval ধাপ দরকার — যাতে শুধুমাত্র সবচেয়ে প্রাসঙ্গিক, সীমিত সংখ্যক chunk বেছে নিয়ে সেগুলোই context window-এর ভেতরে ফিট করানো যায়।

Context Window ব্যবহার হয় কীসে (RAG-এ)
System prompt (instructions)
Retrieved chunks (Top-K documents)
User-এর প্রশ্ন
Model-এর generated answer

এই কারণেই Top-K-এর মান (কতগুলো chunk retrieve করা হবে) একটি গুরুত্বপূর্ণ design decision — বেশি chunk মানে বেশি প্রাসঙ্গিক তথ্য থাকার সম্ভাবনা, কিন্তু একই সাথে context window দ্রুত পূর্ণ হয়ে যাওয়ার এবং কম গুরুত্বপূর্ণ তথ্য দিয়ে "noise" তৈরি হওয়ার ঝুঁকিও বাড়ে।

🎲 ৮. Sampling ও Decoding — কীভাবে চূড়ান্ত output তৈরি হয়

অংশ ৬-এ আমরা দেখেছি, model প্রতিটি ধাপে একটি probability distribution তৈরি করে। কিন্তু চূড়ান্তভাবে কোন token বাছাই হবে, তা নির্ধারণ করে Decoding/Sampling strategy।

পদ্ধতি	সংক্ষিপ্ত ব্যাখ্যা
Greedy Decoding	প্রতিবার সবচেয়ে বেশি probability-র token বেছে নেওয়া — deterministic কিন্তু কখনো কখনো একঘেয়ে (repetitive) output দিতে পারে
Temperature	Probability distribution-কে কতটা "flat" বা "sharp" করা হবে তা নিয়ন্ত্রণ করে; কম temperature = বেশি predictable, বেশি temperature = বেশি "creative"/random
Top-K Sampling	শুধুমাত্র সবচেয়ে বেশি probability-র K সংখ্যক token থেকে randomly বেছে নেওয়া
Top-P (Nucleus) Sampling	Probability-র cumulative sum একটি নির্দিষ্ট threshold (P) পার না হওয়া পর্যন্ত token-গুলোর মধ্যে থেকে বেছে নেওয়া

RAG-এর জন্য practical পরামর্শ: RAG system-এ সাধারণত তুলনামূলক কম temperature পছন্দ করা হয় (যেমন 0 থেকে 0.3-এর মধ্যে), কারণ আমরা চাই model retrieved context-এর উপর ভিত্তি করে সঠিক, grounded, এবং সামঞ্জস্যপূর্ণ উত্তর দিক — অতিরিক্ত "creative" বা random উত্তর নয়। তবে এটি একটি সাধারণ guideline, চূড়ান্ত সিদ্ধান্ত use-case-এর উপর নির্ভর করে।

🔄 ৯. Training, Fine-tuning ও Inference — পার্থক্য স্পষ্ট করা

Episode 01-এ আমরা RAG বনাম Fine-tuning নিয়ে সংক্ষেপে আলোচনা করেছিলাম। এখন তিনটি সম্পর্কিত ধারণা একসাথে স্পষ্ট করা যাক।

Pre-training ↓ (বিপুল, সাধারণ text data দিয়ে — সবচেয়ে ব্যয়বহুল ধাপ) Base Model ↓ Fine-tuning (ঐচ্ছিক) ↓ (নির্দিষ্ট task/style/domain-এর জন্য অতিরিক্ত training) Fine-tuned Model ↓ Inference ↓ (বাস্তব ব্যবহারকারীর প্রশ্নের জন্য real-time output তৈরি) Answer

ধাপ	কখন হয়	কী পরিবর্তন হয়
Pre-training	মডেল তৈরির সময়, একবার (অত্যন্ত ব্যয়বহুল)	Parameters শূন্য থেকে শেখা হয়
Fine-tuning	Pre-training-এর পরে, ঐচ্ছিকভাবে	বিদ্যমান parameters সামান্য সমন্বয় করা হয়
Inference	প্রতিবার ব্যবহারকারী প্রশ্ন করলে	Parameters অপরিবর্তিত থাকে, শুধু output তৈরি হয়

RAG সম্পূর্ণভাবে Inference ধাপে কাজ করে। RAG ব্যবহার করলে model-এর parameters কখনোই পরিবর্তিত হয় না — আমরা শুধু inference-এর সময় prompt-এ অতিরিক্ত, প্রাসঙ্গিক তথ্য যোগ করি। এটাই RAG-কে fine-tuning-এর তুলনায় দ্রুত এবং সহজে আপডেটযোগ্য করে তোলে।

✍️ ১০. Prompt Engineering — বেসিক ধারণা

যেহেতু LLM-এর সাথে যোগাযোগের একমাত্র মাধ্যম হলো prompt (input text), তাই prompt কীভাবে সাজানো হয় তা output-এর মান সরাসরি প্রভাবিত করে।

Prompt-এর সাধারণ অংশগুলো

অংশ	কাজ
System Prompt	Model-কে তার ভূমিকা ও আচরণ সম্পর্কে নির্দেশনা দেয় (যেমন: "তুমি একজন Islamic knowledge assistant, শুধুমাত্র দেওয়া context থেকে উত্তর দাও")
Context	RAG-এ retrieve করা প্রাসঙ্গিক তথ্য এখানে যুক্ত করা হয়
User Prompt	ব্যবহারকারীর প্রকৃত প্রশ্ন
Few-shot Examples (ঐচ্ছিক)	Model-কে কাঙ্ক্ষিত output format দেখানোর জন্য কিছু উদাহরণ input-output pair

Episode 01-এ ব্যবহৃত conceptual prompt-টি আবার দেখা যাক এই কাঠামোর আলোকে:

prompt = f"""নিচের তথ্যের ভিত্তিতে প্রশ্নের উত্তর দাও: {context} প্রশ্ন: What does the Quran say about patience? """

এখানে "নিচের তথ্যের ভিত্তিতে প্রশ্নের উত্তর দাও" অংশটি একটি সাধারণ instruction হিসেবে কাজ করছে (system prompt-এর মতো), {context}-এ RAG থেকে retrieve করা তথ্য বসছে, এবং শেষে আসল user question যুক্ত হচ্ছে। এই কাঠামোটিই RAG Prompting-এর ভিত্তি, যা সিরিজের পরবর্তী "RAG Prompting" Episode-এ আরও বিস্তারিতভাবে আলোচনা করা হবে।

🚫 ১১. LLM-এর সীমাবদ্ধতা — Token-এর দৃষ্টিকোণ থেকে

এখন যেহেতু আমরা tokenization, next-token prediction, এবং context window বুঝেছি, Episode 01-এ আলোচিত LLM-এর সীমাবদ্ধতাগুলো আরও স্পষ্টভাবে দেখা যায়।

সীমাবদ্ধতা	Token/Architecture-ভিত্তিক ব্যাখ্যা
Knowledge Cutoff	Training data একটি নির্দিষ্ট সময় পর্যন্ত সংগৃহীত — parameters সেই সময় পর্যন্ত তথ্যই ধারণ করে
Context Window সীমা	একবারে সীমিত সংখ্যক token-ই প্রসেস করা যায়, তাই সম্পূর্ণ knowledge base একসাথে দেওয়া অসম্ভব
Hallucination	Next-token prediction পরিসংখ্যানভিত্তিক, সত্যতা-যাচাইভিত্তিক নয়
Private/নতুন Data-এর অনুপস্থিতি	Parameters শুধুমাত্র training-এর সময় দেখা data থেকেই শেখে; নতুন/private document parameters-এ নেই

এই প্রতিটি সীমাবদ্ধতাই মূলত RAG কেন প্রয়োজন তার প্রযুক্তিগত ভিত্তি। RAG এই সীমাবদ্ধতাগুলো "সমাধান" করে না (LLM architecture নিজেই অপরিবর্তিত থাকে), বরং এগুলোর চারপাশে কাজ করার একটি ব্যবহারিক কৌশল সরবরাহ করে — Inference-এর সময় সঠিক, সীমিত, প্রাসঙ্গিক তথ্য সরবরাহ করে।

🔗 ১২. এই সবকিছু কেন RAG-এর জন্য গুরুত্বপূর্ণ

এই Episode-এ শেখা প্রতিটি ধারণা RAG system ডিজাইন করার সময় সরাসরি সিদ্ধান্তে প্রভাব ফেলে:

LLM Concept	RAG-এ প্রভাব
Tokenization	Chunk size ও context limit token-এ পরিমাপ করা হয়, character-এ নয়
Context Window	Top-K-এর মান এবং কতগুলো chunk retrieve করা যাবে তা সীমাবদ্ধ করে
Next-token Prediction	ভুল/অপ্রাসঙ্গিক context দিলে model সেই ভিত্তিতেই ভুল উত্তর "predict" করবে — তাই retrieval quality গুরুত্বপূর্ণ
Temperature/Sampling	RAG-এ সাধারণত কম temperature পছন্দনীয়, যাতে output বেশি grounded ও কম random হয়
Input Embedding বনাম Sentence Embedding	RAG retrieval আলাদা, বিশেষায়িত (specialized) embedding model ব্যবহার করে — LLM-এর নিজস্ব internal embedding নয়

সংক্ষেপে: RAG আসলে LLM-এর ভেতরের কাজের পদ্ধতির সাথে মানিয়ে কাজ করার একটি কৌশল — LLM-কে পরিবর্তন না করে, তার input (prompt/context)-কে বুদ্ধিমত্তার সাথে সাজানো।

🕌 ১৩. Case Study: আমাদের Project-এ Mistral ও Ollama

আমাদের Islamic_Knowleged_Assistant_RAG_Server project-এ Generation ধাপের জন্য Mistral model ব্যবহার করা হয়েছে, যা Ollama-এর মাধ্যমে স্থানীয়ভাবে (locally) চালানো হয়।

এই Episode-এর ধারণাগুলো কীভাবে এখানে প্রযোজ্য

ধারণা	Project-এ প্রয়োগ
Tokenization ও Context Window	Mistral model-এর নিজস্ব context window সীমা আছে — retrieved Quran/Hadith chunk এবং প্রশ্ন এর মধ্যেই ফিট করাতে হয়
Next-token Prediction	Mistral, retrieved context এবং প্রশ্নের ভিত্তিতে token-by-token উত্তর generate করে
Inference (Training নয়)	Ollama শুধুমাত্র Mistral-এর pre-trained parameters দিয়ে inference চালায় — কোনো fine-tuning এখানে হচ্ছে না
Local/Offline Inference	Ollama-এর মাধ্যমে Mistral local machine-এ চলে, কোনো external API call ছাড়াই — এটি project-টিকে সম্পূর্ণ offline রাখে

লক্ষ্যণীয়: Mistral (Generation-এর LLM) এবং paraphrase-multilingual-MiniLM-L12-v2 (Retrieval-এর Sentence Embedding model) — এই দুটো সম্পূর্ণ আলাদা model, আলাদা উদ্দেশ্যে ব্যবহৃত। একটি text generate করে, অন্যটি text-কে vector-এ রূপান্তর করে search-এর জন্য। এই পার্থক্যটি অংশ ৩-এ আলোচিত Input Embedding বনাম Sentence Embedding-এর একটি বাস্তব উদাহরণ।

🚧 ১৪. সাধারণ ভুল ধারণা

ভুল ধারণা	বাস্তবতা
"LLM শব্দ ধরে ধরে পড়ে ও বোঝে"	না, LLM token নিয়ে কাজ করে, যা শব্দের অংশ, পূর্ণ শব্দ, বা তার বেশি হতে পারে
"Context Window মানে character সংখ্যা"	না, Context Window token-এ পরিমাপ করা হয়, character বা শব্দে নয়
"LLM নিজে থেকে বুঝে তথ্য সত্য কিনা"	না, LLM পরিসংখ্যানগতভাবে সবচেয়ে সম্ভাব্য পরবর্তী token predict করে — সত্যতা যাচাই এর কাজ না
"RAG ব্যবহার করলে model fine-tune হয়ে যায়"	না, RAG শুধু inference-এর সময় prompt-এ তথ্য যোগ করে, model-এর parameters অপরিবর্তিত থাকে
"LLM-এর ভেতরের Embedding আর RAG-এর Embedding একই জিনিস"	না, LLM-এর Input Embedding token-ভিত্তিক ও model-নির্দিষ্ট, আর RAG-এর Sentence Embedding সম্পূর্ণ বাক্য/অনুচ্ছেদের জন্য আলাদা, বিশেষায়িত model দিয়ে তৈরি হয়

✅ ১৫. Conclusion

এই Episode-এ আমরা যা শিখলাম:

✓ Tokenization কীভাবে raw text-কে token-এ ভাঙে, এবং কেন 1 token সবসময় 1 শব্দ নয়
✓ Token ID ও Input Embedding-এর মাধ্যমে সংখ্যা কীভাবে vector-এ রূপান্তরিত হয়
✓ Neural Network ও Parameters কীভাবে model-এর "শেখা জ্ঞান" ধারণ করে
✓ Transformer ও Attention-এর conceptual ধারণা — কীভাবে model শব্দের পারস্পরিক সম্পর্ক বিবেচনা করে
✓ Next-token Prediction — LLM-এর মূল কাজ, এবং কীভাবে Autoregressive Generation চলে
✓ Context Window-এর প্রকৃত অর্থ, এবং কেন এটি RAG-এ Top-K সিদ্ধান্তকে প্রভাবিত করে
✓ Temperature, Top-K, Top-P-এর মতো sampling parameter কীভাবে output নিয়ন্ত্রণ করে
✓ Pre-training, Fine-tuning, ও Inference-এর মধ্যে স্পষ্ট পার্থক্য
✓ Prompt-এর মূল অংশ — System Prompt, Context, User Prompt, Few-shot Examples
✓ LLM-এর সীমাবদ্ধতাগুলো token/architecture-এর দৃষ্টিকোণ থেকে আরও গভীরভাবে বোঝা
✓ আমাদের project-এ Mistral (Generation) ও Sentence Embedding model (Retrieval)-এর ভূমিকা কীভাবে আলাদা

এখন আমাদের কাছে LLM কীভাবে কাজ করে তার একটি শক্ত conceptual ভিত্তি আছে। পরবর্তী Episode-এ আমরা RAG-এর আরেকটি মূল স্তম্ভ — Embedding — নিয়ে অনেক গভীরে যাব।

➡️ ১৬. Next Episode

পরবর্তী Episode: "Embedding কী? (গভীরভাবে)"

পরের পর্বে আমরা Sentence Embedding model কীভাবে কাজ করে তা গভীরভাবে দেখব — কীভাবে একটি সম্পূর্ণ বাক্য একটি single vector-এ রূপান্তরিত হয়, embedding dimension-এর অর্থ কী, এবং কেন paraphrase-multilingual-MiniLM-L12-v2-এর মতো model multilingual semantic search-এর জন্য কার্যকর।

⬅ পূর্ববর্তী Episode: RAG কী? পরবর্তী Episode: Embedding কী? (শীঘ্রই) ➡

LLM কীভাবে কাজ করে?

📑 বিষয়বস্তু