বাংলা জ্ঞানভান্ডারে RAG না fine-tuning—ভুল পছন্দে খরচ বাড়ে

বাংলা chatbot বা knowledge assistant যদি নিয়মিত বদলানো নথি থেকে উৎসসহ উত্তর দেয়, তাহলে RAG দিয়ে শুরু করাই যুক্তিসংগত। কাজটি স্থির ও সংকীর্ণ হলে—যেমন নির্দিষ্ট ভাষাভঙ্গি বজায় রাখা, অভিন্ন JSON তৈরি বা entity extraction—এবং পর্যাপ্ত মানসম্মত উদাহরণ থাকলে fine-tuning বেশি উপযোগী।

একই সহকারীকে হালনাগাদ তথ্য উদ্ধৃতিসহ বলতে এবং প্রতিষ্ঠানের নিজস্ব ভঙ্গি বা কাঠামো মানতে হলে hybrid নকশা বিবেচনা করুন: retrieval বর্তমান জ্ঞান সরবরাহ করবে, fine-tuned মডেল নিয়ন্ত্রণ করবে কাজ ও প্রকাশভঙ্গি। ভুল স্থাপত্যে খরচ বাড়ে দুইভাবে—পরিবর্তনশীল তথ্য মডেলে ধরে রাখতে বারবার training লাগে, অথবা ছোট ও স্থির কাজের প্রতিটি অনুরোধে অপ্রয়োজনীয় দীর্ঘ context পাঠাতে হয়।

প্রথম সিদ্ধান্ত: জ্ঞান কোথায় থাকবে

RAG-এ বাংলা নথি মডেলের বাইরে একটি জ্ঞানভান্ডারে থাকে। প্রশ্ন এলে retriever প্রাসঙ্গিক অংশ খুঁজে মডেলকে দেয়। কোনো প্রজ্ঞাপন, ফি, নীতিমালা বা FAQ বদলালে নথি ও index হালনাগাদ করা যায়; pipeline-এ document ID ও passage metadata ধরে রাখলে উত্তরের পাশে ব্যবহৃত উৎসও দেখানো সম্ভব।

Fine-tuning নির্বাচিত উদাহরণ দিয়ে মডেলের আচরণ বা নির্দিষ্ট কাজ শেখায়। পরিবর্তনশীল তথ্যভান্ডারের বিকল্প হিসেবে এটি দুর্বল, কারণ নথি বদলালে training data, validation ও deployment আবার করতে হতে পারে। AWS Prescriptive Guidance-এর তুলনা custom document থেকে উৎসনির্ভর প্রশ্নোত্তরের জন্য RAG দিয়ে শুরু করতে বলে; ঘন ঘন বদলানো নথিতে fine-tuning-এর সময় ও উৎস দেখাতে না পারাকে সীমাবদ্ধতা হিসেবেও চিহ্নিত করে।

তাই প্রথম প্রশ্ন ‘কোন প্রযুক্তি ভালো’ নয়, বরং ‘সঠিক উত্তরটি কি বর্তমান নথির ওপর নির্ভরশীল?’ উত্তর হ্যাঁ হলে retrieval স্তর প্রয়োজন। আর নথি নয়, প্রত্যাশিত আচরণটি যদি স্থির হয়, তখন fine-tuning-এর পক্ষে যুক্তি শক্তিশালী হয়।

চারটি বাংলা scenario-তে সিদ্ধান্তের matrix

• বাংলা FAQ—সাধারণত RAG: পণ্যের শর্ত, সেবার সময় বা সহায়তা-নীতি বদলাতে পারে। প্রশ্নের সঙ্গে ছোট প্রাসঙ্গিক passage উদ্ধার করুন; উত্তর না থাকলে অনুমান না করে fallback দিন। FAQ স্থির হলেও প্রতিটি দাবির উৎস দেখাতে হলে retrieval রাখুন।
• সরকারি ও নিয়ন্ত্রক তথ্য—RAG: কার্যকর হওয়ার তারিখ, সংশোধিত পরিপত্র, প্রযোজ্য এলাকা এবং বাতিল সংস্করণের metadata রাখুন। তথ্য fine-tuning-এ মুখস্থ করালে কোন সংস্করণ থেকে উত্তর এসেছে তা দেখানো এবং পরিবর্তনের পরে দ্রুত সংশোধন করা কঠিন হয়।
• প্রতিষ্ঠানের বাংলা tone—fine-tuning, প্রয়োজনে hybrid: উত্তরকে ধারাবাহিকভাবে সংক্ষিপ্ত, আনুষ্ঠানিক বা অনুমোদিত শব্দচয়নে লিখতে হলে supervised input-output উদাহরণ কাজে আসতে পারে। একই উত্তরে পরিবর্তনশীল FAQ-ও লাগলে retrieved context যুক্ত করুন।
• Entity extraction—fine-tuning: বাংলা চালান, আবেদন বা বার্তা থেকে নাম, তারিখ, জেলা, টাকার পরিমাণ ও reference number নির্দিষ্ট schema-তে তুলতে labelled examples গুরুত্বপূর্ণ। extracted entity-কে বর্তমান master record-এর সঙ্গে মেলাতে হলে lookup-টি আলাদা retrieval বা database ধাপে রাখুন।

এই matrix-এ training data একটি কঠিন সীমা। production-এ দেখা বানানভুল, ছোট প্রশ্ন, দীর্ঘ input, প্রত্যাখ্যানযোগ্য অনুরোধ ও প্রত্যাশিত output format training এবং validation—দুই ভাগেই না থাকলে fine-tuning-এর ফল ভরসাযোগ্য হবে না। এমন dataset না থাকলে prompt ও RAG দিয়ে baseline বানিয়ে বাস্তব ব্যর্থতার নমুনা সংগ্রহ করা কম ঝুঁকির সিদ্ধান্ত।

বাংলা retrieval-এ embedding-এর বাইরেও পরীক্ষা দরকার

একই বিষয় বাংলা নথিতে ‘অ্যাকাউন্ট’, ‘একাউন্ট’ বা ইংরেজি account হিসেবে থাকতে পারে। যুক্তাক্ষর, বাংলা ও আরবি অঙ্ক, যতিচিহ্ন, OCR-এর ভুল এবং সাধু-চলিত রূপও query ও passage-এর মিল দুর্বল করতে পারে। ব্যবহারকারী বাংলা লিপি, ইংরেজি শব্দ ও Roman-script বাংলা একই প্রশ্নে মেশালে শুধু multilingual embedding বেছে নেওয়াই যথেষ্ট নয়।

Roman-script Bengali-English query নিয়ে FIRE 2025-এর Benglish গবেষণা অনিয়মিত transliteration ও code-mixing-কে retrieval-এর বাধা হিসেবে পরীক্ষা করেছে; গবেষণাটির pipeline প্রথমে BM25 দিয়ে candidate নেয়, পরে SBERT দিয়ে rerank করে। তবে এর corpus ছিল social-media ধরনের ১,০৭,৯০০ document এবং test query মাত্র ২০টি—ফলে ফলটি সব বাংলা জ্ঞানভান্ডারের সাধারণ benchmark নয়।

ন্যূনতম evaluation set হিসেবে ৬০টি বাস্তবধর্মী প্রশ্ন রাখা যেতে পারে—এটি একটি সম্পাদকীয় প্রস্তাব, প্রতিষ্ঠিত benchmark নয়। চারটি scenario থেকে ১৫টি করে মূল প্রশ্ন নিন; প্রতিটির প্রচলিত বানান-রূপ এবং প্রাসঙ্গিক ক্ষেত্রে Banglish সংস্করণ আলাদা test case হিসেবে যোগ করুন। প্রত্যেকটির expected document ID, প্রাসঙ্গিক passage, উত্তরযোগ্যতার অবস্থা ও গ্রহণযোগ্য citation আগে চিহ্নিত থাকা দরকার।

retrieval hit rate, top-k-তে সঠিক passage, citation-এর সমর্থন, উত্তরহীন প্রশ্নে abstention এবং end-to-end latency মাপুন। শুধু চূড়ান্ত উত্তরের সাবলীলতা দেখলে ভুল passage থেকে লেখা সুন্দর বাংলাও সফল বলে গণ্য হতে পারে। একই set-এ lexical, dense ও hybrid retrieval তুললে normalization বা reranker যোগ করার প্রভাব বোঝা যাবে।

Latency ও token খরচ কোথায় তৈরি হয়

RAG-এর প্রতিটি request-এ search, সম্ভাব্য reranking এবং retrieved context পাঠানোর সময় যোগ হয়। বড় top-k, দীর্ঘ chunk ও পুনরাবৃত্ত passage input token বাড়ায়। অন্যদিকে fine-tuned মডেল ছোট prompt-এ স্থির format দিতে পারলেও dataset পরিষ্কার, training, evaluation, model hosting ও পরবর্তী retuning-এর খরচ থাকে।

AWS-এর Amazon Nova পরীক্ষায় Micro ও Lite মডেলকে ১,০০০টি AWS-নির্দিষ্ট প্রশ্নোত্তর দিয়ে fine-tune করা হয় এবং ১০টি test question-এ বিভিন্ন configuration তুলনা করা হয়। ওই সীমিত পরীক্ষায় base model-এর তুলনায় fine-tuning latency প্রায় ৫০% ও RAG প্রায় ৩০% কমায়; fine-tuned মডেলে মোট token ৬০%-এর বেশি কমলেও context পাঠানোর কারণে RAG-এ তা দ্বিগুণের বেশি হয়। এগুলো বাংলা workload-এর পূর্বাভাস নয়—corpus, model, retrieval depth, hosting ও output length বদলালে ফলও বদলাবে।

নিজস্ব হিসাব তিন ভাগে করুন: এককালীন data preparation ও training, নিয়মিত index বা model maintenance, এবং প্রতি request-এর retrieval, reranking, token ও serving ব্যয়। গড়ের সঙ্গে p95 latency মাপুন। একই traffic sample ও quality threshold-এ RAG, fine-tuned এবং hybrid variant না চালালে কোনটি সবচেয়ে সাশ্রয়ী তা নিশ্চিতভাবে বলা যাবে না।

ছোট pilot-এ চূড়ান্ত পছন্দ

1. use case-কে knowledge lookup, style control অথবা structured task হিসেবে ভাগ করুন। একাধিক লক্ষ্য থাকলে প্রতিটির acceptance criterion আলাদা লিখুন।
2. একই base model ও evaluation set দিয়ে prompt-only এবং RAG baseline তৈরি করুন। retrieval failure ও generation failure আলাদা রাখুন।
3. যথেষ্ট labelled example থাকলে tone বা extraction task-এর fine-tuned variant যোগ করুন। পরিবর্তনশীল তথ্যকে training label-এর স্থায়ী জ্ঞান হিসেবে আটকে রাখবেন না।
4. quality, citation correctness, abstention, p95 latency এবং প্রতি সফল উত্তরের মোট ব্যয় তুলনা করুন। কোনো variant বাধ্যতামূলক threshold পূরণ না করলে শুধু ভালো গড় স্কোরের জন্য সেটি production-এ নেবেন না।
5. RAG সঠিক তথ্য দিলেও format বা tone ধারাবাহিক না হলে hybrid পরীক্ষা করুন। hybrid স্বয়ংক্রিয়ভাবে সেরা নয়; এতে indexing ও model training—দুই ধরনের maintenance-ই থাকে।

বাংলা knowledge assistant-এর কার্যকর default হলো পরিবর্তনশীল জ্ঞানের জন্য RAG, স্থির আচরণের জন্য fine-tuning। দুটি চাহিদা এক হলে hybrid যৌক্তিক, কিন্তু সিদ্ধান্তটি নিজস্ব নথি ও production query দিয়ে মাপতে হবে—নইলে token, latency বা retraining-এর ব্যয় deployment-এর পরে ধরা পড়বে।