কেন একটি আত্মবিশ্বাসী উত্তর না দেওয়ার চেয়েও খারাপ হতে পারে
আপনি আপনার কোম্পানির অভ্যন্তরীণ চ্যাটবটটি তৈরি করা শেষ করলেন। আপনি এতে কোম্পানির সমস্ত এইচআর (HR) পলিসি, ইঞ্জিনিয়ারিং স্পেসিফিকেশন এবং অনবোর্ডিং ডকুমেন্ট যুক্ত করলেন। একজন নতুন কর্মচারী ক্লায়েন্ট ডিনারের জন্য ভ্রমণ ব্যয়ের সীমা সম্পর্কে জানতে চাইলেন। বটটি তাৎক্ষণিকভাবে উত্তর দিল। এটি শুনতে খুব আত্মবিশ্বাসী মনে হচ্ছিল। এটি যে সীমাটি উল্লেখ করল তা হলো জনপ্রতি ৭৫ ডলার।
আসল পলিসি অনুযায়ী এটি ৫০ ডলার। বটটি উত্তরটি নিজে থেকে বানিয়ে ফেলেছে। এটি আপনার ফাইলগুলো কখনোই খোলেনি। এটি কেবল কয়েক বছর আগের ট্রেনিং ডেটার প্যাটার্ন থেকে অনুমান করে উত্তরটি দিয়েছে। ব্যক্তিগত নথিপত্রের বিপরীতে র (raw) লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) চালানোর কঠিন বাস্তবতা এটাই। আপনার অভ্যন্তরীণ জ্ঞান বা তথ্যের ওপর তাদের কোনো অ্যাক্সেস নেই। যখন তাদের প্রয়োজনীয় তথ্যগুলো তাদের ট্রেনিং ওয়েটসের (training weights) বাইরে থাকে, তখন তারা অজ্ঞতা স্বীকার করার পরিবর্তে তথ্য বানিয়ে ফেলে। প্রোডাকশন পর্যায়ে এটি আর মজার বিষয় থাকে না, বরং এটি একটি দায়বদ্ধতা বা ঝুঁকির কারণ হয়ে দাঁড়ায়।
Retrieval-Augmented Generation, বা RAG, ঠিক এই সমস্যাটি সমাধানের জন্যই তৈরি করা হয়েছে। মডেলটিকে সবকিছু মনে রাখার জন্য বলার পরিবর্তে, আপনি তাকে তথ্য খুঁজে দেখার সুযোগ করে দেন।
অনুমান করা থেকে পড়া পর্যন্ত
একটি র (raw) LLM-কে একজন মেধাবী সহকর্মীর মতো ভাবুন যার ফটোগ্রাফিক মেমরি আছে, কিন্তু তিনি আপনার যোগদানের আগেই কোম্পানি ছেড়ে চলে গেছেন। তিনি চমৎকার গদ্য লিখতে পারেন, লজিক পাজল সমাধান করতে পারেন এবং জটিল বিষয় সহজভাবে ব্যাখ্যা করতে পারেন। তবে তাকে গত প্রান্তিকের API পরিবর্তনের কথা জিজ্ঞেস করলে, তিনি কেবল এমন কিছু বানিয়ে বলবেন যা শুনতে বিশ্বাসযোগ্য মনে হয়। তার কাছে অন্য কোনো উপায় নেই।
RAG সেই সহকর্মীকে একটি ফাইলিং ক্যাবিনেটের অ্যাক্সেস দেয়। যখন একজন ব্যবহারকারী কোনো প্রশ্ন করেন, সিস্টেমটি অন্ধভাবে প্রশ্নটি মডেলের কাছে পাঠিয়ে দেয় না। এটি প্রথমে প্রাসঙ্গিক নথিগুলো খুঁজে বের করে, সেগুলোকে প্রম্পট হিসেবে কনটেক্সট (context) হিসেবে যুক্ত করে এবং তারপর মডেলটিকে তা পড়ে উত্তর দিতে বলে। মডেলটি তখন তথ্য মনে করার পরিবর্তে তার সামনে থাকা তথ্যগুলো বোঝার দিকে মনোনিবেশ করে।
এই প্রক্রিয়াটি দুটি ভাগে বিভক্ত: অফলাইন প্রস্তুতি এবং অনলাইন রেসপন্স।
ধাপ ১: প্রস্তুতি পর্ব (অফলাইন)
কেউ প্রশ্ন করার অনেক আগে থেকেই, আপনাকে আপনার অগোছালো ডকুমেন্ট সংগ্রহকে একটি সার্চযোগ্য নলেজ বেস (knowledge base)-এ রূপান্তর করতে হবে। এই প্রস্তুতিই নির্ধারণ করে আপনার RAG সিস্টেমটি সফল হবে নাকি নীরবে ব্যর্থ হবে।
Document loaders হলো আপনার শুরুর বিন্দু। এই কানেক্টরগুলো PDF, Notion ওয়ার্কস্পেস, SharePoint ফোল্ডার, ওয়েব পেজ এবং ইন্টারনাল উইকি থেকে র (raw) টেক্সট সংগ্রহ করে। এখানেই প্রথম সমস্যার সম্মুখীন হতে হয়। একটি লোডার হয়তো একটি Word ডকুমেন্ট থেকে পরিষ্কার টেক্সট বের করতে পারে, কিন্তু একটি স্ক্যান করা PDF-এর ক্ষেত্রে ব্যর্থ হতে পারে যেখানে কোনো টেক্সট লেয়ার নেই, বরং সেটি কেবল একটি ছবি। লোডারটি একটি খালি স্ট্রিং (empty string) রিটার্ন করে, আপনার ডাটাবেসে কিছুই জমা হয় না এবং পরবর্তীতে ব্যবহারকারী কোনো সতর্কতা ছাড়াই "আমি জানি না" এমন উত্তর পায়। আপনার লোডারগুলো আসলে কী এক্সট্র্যাক্ট করেছে তা সবসময় যাচাই করে নিন। পাইপলাইনটির ওপর আস্থা রাখার আগে প্রতিটি সোর্স থেকে কিছু ডকুমেন্ট নিয়ে স্পট চেক (spot check) করে নিন।
এরপর আসে text splitting, যাকে চাঙ্কিং (chunking)-ও বলা হয়। আপনি আশি পৃষ্ঠার একটি সিকিউরিটি পলিসি একবারে প্রম্পটে দিতে পারবেন না; এতে কনটেক্সট লিমিট ছাড়িয়ে যাবে এবং মূল তথ্যটি নয়েজের (noise) নিচে চাপা পড়ে যাবে। পরিবর্তে, আপনি ডকুমেন্টগুলোকে ছোট ছোট টুকরো বা চাঙ্কে (chunks) ভাগ করবেন। আসল কৌশল হলো সঠিক সাইজ নির্বাচন করা। চাঙ্ক যদি খুব ছোট হয়, যেমন একটি মাত্র বাক্য, তবে অনেক সময় গুরুত্বপূর্ণ কনটেক্সট হারিয়ে যেতে পারে। যেমন, "সব অনুরোধ অবশ্যই ম্যানেজারের মাধ্যমে অনুমোদিত হতে হবে" — এই চাঙ্কটি ভুলে যেতে পারে যে এই নিয়মটি কেবল আন্তর্জাতিক ভ্রমণের ক্ষেত্রে প্রযোজ্য। আবার চাঙ্ক যদি খুব বড় হয়, যেমন পুরো অধ্যায়, তবে এমবেডিং (embedding) দুর্বল হয়ে পড়ে এবং রিট্রিভাল (retrieval) বিভ্রান্ত হয় কারণ এতে একসাথে পনেরোটি ভিন্ন বিষয় থাকতে পারে। বাস্তবে, অনেক টিম ৩০০ থেকে ৫০০ টোকেনের (tokens) মধ্যে চাঙ্ক দিয়ে শুরু করে এবং ৫০-টোকেনের একটি ওভারল্যাপ (overlap) রাখে যাতে বিভাজনের মাঝখানে থাকা বাক্যগুলো ভেঙে না যায়। আপনার কন্টেন্টের ওপর ভিত্তি করে এটি পরিবর্তন করুন। API ডকুমেন্টেশনের ক্ষেত্রে ছোট চাঙ্ক কার্যকর। আইনি চুক্তির ক্ষেত্রে শর্তযুক্ত লজিক বজায় রাখার জন্য প্রায়ই বড় চাঙ্ক প্রয়োজন হয়।
চাঙ্কিং করার পর, প্রতিটি অংশকে একটি embedding-এ রূপান্তরিত করা হয়। এর মানে হলো টেক্সটটিকে একটি মডেলের মাধ্যমে চালানো যা সংখ্যার একটি তালিকা বা ভেক্টর (vector) আউটপুট দেয়, যা ওই চাঙ্কের অর্থগত তাৎপর্য (semantic meaning) প্রকাশ করে। এই গাণিতিক স্পেসে একই ধরনের ধারণাগুলো কাছাকাছি থাকে। যেমন, "401k matching policy" এবং "retirement contribution rules" কাছাকাছি থাকবে, কিন্তু "401k matching policy" এবং "office printer setup" দূরে থাকবে। এই ভেক্টরগুলো একটি vector database-এ জমা রাখা হয়, যেমন Pinecone, Weaviate, অথবা Chroma-এর মতো কোনো ওপেন-সোর্স বিকল্প। ভেক্টর স্টোর কেবল তথ্য জমা রাখার জায়গা নয়। এটি একটি ইনডেক্স যা approximate nearest-neighbor সার্চের জন্য অপ্টিমাইজ করা হয়েছে, যা আপনাকে লক্ষ লক্ষ ডকুমেন্টের মধ্য থেকেও মিলিসেকেন্ডের মধ্যে সবচেয়ে প্রাসঙ্গিক চাঙ্ক খুঁজে পেতে সাহায্য করে।
ধাপ ২: লাইভ পাথ (অনলাইন)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The