RAG সহজভাবে: AI আসলে কীভাবে আপনার নিজের ডেটা থেকে উত্তর দেয়

যে AI অ্যাসিস্ট্যান্টই সাধারণ ইন্টারনেট-জ্ঞান নয়, বরং আপনার নিজের ডকুমেন্ট, আপনার পলিসি বা আপনার ডেটাবেজ নিয়ে প্রশ্নের উত্তর দেয় - তার ভেতরে প্রায় নিশ্চিতভাবেই একই কৌশল চলছে: Retrieval-Augmented Generation, সংক্ষেপে RAG। আমি ERP ডেটা আর অভ্যন্তরীণ ডকুমেন্টের ওপর RAG পাইপলাইন তৈরি করেছি, আর দেখেছি একই ভুল বোঝাবুঝিতে টিমের পর টিম হোঁচট খাচ্ছে। এই লেখাটি সেই ব্যাখ্যা যা শুরুতে কেউ আমাকে দিলে ভালো হতো: RAG ধাপে ধাপে আসলে কী করে, বেশিরভাগ ব্যবসায়িক প্রয়োজনে এটি কেন fine-tuning-কে হারায়, কোন ইঞ্জিনিয়ারিং সিদ্ধান্তগুলো সবকিছু গড়ে বা ভাঙে, আর টিউটোরিয়ালগুলো যে ব্যর্থতার ধরনগুলো এড়িয়ে যায়।

১. RAG যে সমস্যার সমাধান করে

একটি large language model যা জানে তা তার ট্রেনিংয়ে শেখা: বিপুল পরিমাণ সাধারণ জ্ঞান, একটি নির্দিষ্ট সময়ে জমাট বাঁধা। আপনার প্রাইস লিস্ট, আপনার HR পলিসি, গত মাসের প্রোডাকশনের সংখ্যা, কিংবা মঙ্গলবারে সই করা চুক্তি - এসবের কিছুই সে জানে না। তবু জিজ্ঞেস করলে পাবেন AI-এর সবচেয়ে বিপজ্জনক আউটপুট - একটি সাবলীল, আত্মবিশ্বাসী অনুমান।

এটি ঠিক করার সৎ উপায় মাত্র দুটি। মডেলটিকে বদলানো (fine-tuning), অথবা প্রশ্নের সময় মডেল কী পড়তে পায় তা বদলানো। RAG দ্বিতীয় পথ, আর ব্যবসায়িক জ্ঞানের ক্ষেত্রে এটি এত ঘন ঘন জেতে যে প্রতিটি গুরুতর "নিজের ডেটার সঙ্গে চ্যাট" সিস্টেমের ডিফল্ট আর্কিটেকচার হয়ে উঠেছে।

এক বাক্যে ধারণাটি: মডেল উত্তর দেওয়ার আগে সিস্টেম আপনার নিজের ডেটার সবচেয়ে প্রাসঙ্গিক অংশগুলো খুঁজে এনে প্রম্পটে বসিয়ে দেয় - ফলে মডেল স্মৃতি থেকে নয়, প্রমাণ থেকে উত্তর দেয়।

২. পাইপলাইন, ধাপে ধাপে

একটি RAG সিস্টেমের দুটি অর্ধ ভিন্ন ভিন্ন সময়ে চলে।

২.১ ইনডেক্সিং (আগে থেকে করা)

1. সংগ্রহ করুন উৎস উপকরণ - ডকুমেন্ট, উইকি পেজ, পলিসি, ডেটাবেজ রেকর্ড, টিকিটের ইতিহাস।
2. Chunk করুন - নিখুঁতভাবে retrieve করার মতো ছোট টুকরোয় ভাগ করুন - সাধারণত প্রতিটি কয়েকশ শব্দের, আদর্শভাবে সেকশন ও অনুচ্ছেদের মতো স্বাভাবিক সীমানা ধরে।
3. Embed করুন প্রতিটি chunk: একটি embedding মডেল টেক্সটটিকে একটি vector-এ রূপান্তর করে - সংখ্যার একটি লম্বা তালিকা - এমনভাবে যে কাছাকাছি অর্থের টেক্সট সেই vector space-এ কাছাকাছি জায়গায় পড়ে।
4. সংরক্ষণ করুন vector-গুলো, মূল টেক্সট ও মেটাডেটাসহ (উৎস, তারিখ, অনুমতি), একটি vector store-এ - আলাদা কোনো vector ডেটাবেজ, কিংবা ক্রমবর্ধমানভাবে সেই একই ডেটাবেজ যেখানে আপনার ব্যবসার ডেটা আগে থেকেই আছে।

২.২ কোয়েরির সময় (প্রতিটি প্রশ্নে)

1. প্রশ্নটি embed করুন একই embedding মডেল দিয়ে।
2. খুঁজুন সেই chunk-গুলো যাদের vector প্রশ্নের vector-এর সবচেয়ে কাছে বসে - semantic similarity, keyword ম্যাচিং নয়।
3. প্রম্পট সাজান: ব্যবহারকারীর প্রশ্ন আর সবচেয়ে মিল-থাকা chunk-গুলো, সঙ্গে এমন নির্দেশনা - "শুধু প্রদত্ত context ব্যবহার করে উত্তর দাও; উত্তর এতে না থাকলে তা-ই বলো।"
4. Generate করুন: ল্যাঙ্গুয়েজ মডেল সেই chunk-গুলোতে ভিত্তি করে উত্তর লেখে - আর ভালোভাবে বানানো সিস্টেমে জানায় কোন সূত্রগুলো সে ব্যবহার করেছে।

এই তো পুরো কৌশল। কোনো রিট্রেনিং নেই, মডেলে অস্ত্রোপচার নেই। বুদ্ধিমত্তাটি সাধারণ; জ্ঞানটি আপনার - প্রতিটি প্রশ্নে টাটকা করে ঢুকিয়ে দেওয়া।

৩. Embedding: যে অংশটি ঠিকমতো বোঝা জরুরি

জাদুর উপাদানটি হলো embedding। "annual leave entitlement" আর "how many holiday days do I get" যখন vector হয়, তারা কাছাকাছি পড়ে - প্রায় কোনো শব্দ না মিলেও। এটিই RAG-কে অর্থ দিয়ে retrieve করতে দেয়, যেখানে keyword সার্চ ব্যর্থ হয়।

এ থেকে দুটি বাস্তব ফলাফল আসে। প্রথমত, embedding মডেলটি গুরুত্বপূর্ণ: এটিকে আপনার ভাষা সামলাতে হবে (বাংলা ও অন্যান্য অ-ইংরেজি কনটেন্টের জন্য এটি সত্যিকারের উদ্বেগ - একটি দুর্বল multilingual embedding নীরবে retrieval নষ্ট করে দেয়, যা Sovereign AI লেখায় ভাষাকে প্রথম শ্রেণির চাহিদা হিসেবে দেখার আমার যুক্তির সঙ্গে মিলে যায়)। দ্বিতীয়ত, ইনডেক্সিং ও কোয়েরিতে একই embedding মডেল ব্যবহার করতেই হবে - ভিন্ন মডেলের vector ভিন্ন space-এ বাস করে, তাদের তুলনা অর্থহীন। পরে embedding মডেল বদলালে সবকিছু আবার ইনডেক্স করতে হয়।

৪. ব্যবসায়িক জ্ঞানে RAG কেন fine-tuning-কে হারায়

Fine-tuning - নিজের উদাহরণে অতিরিক্ত ট্রেনিং - মডেলকে নিজের ব্যবসা শেখানোর সুস্পষ্ট উপায় মনে হয়। বাস্তবে, জ্ঞানভিত্তিক ব্যবহারে যেসব মাপকাঠি গুরুত্বপূর্ণ তার প্রায় সবগুলোতেই এটি RAG-এর কাছে হারে:

• টাটকা থাকা। আপনার ডেটা প্রতিদিন বদলায়। RAG-এ আপডেট হওয়া ডকুমেন্ট কয়েক মিনিটে রি-ইনডেক্স হয়ে যায়। Fine-tuning-এ তা মানে নতুন একটি ট্রেনিং রান।
• উৎস চিহ্নিত করা। RAG বলে দিতে পারে উত্তরটি ঠিক কোন chunk থেকে এসেছে - নিয়ন্ত্রিত শিল্পে AI কমপ্লায়েন্স লেখায় বর্ণিত অডিট শৃঙ্খলার জন্য যা অপরিহার্য। Fine-tune করা মডেলের জ্ঞান ভেতরে সেঁটে থাকে, উৎস খোঁজার উপায় নেই।
• অ্যাক্সেস কন্ট্রোল। RAG প্রশ্নকর্তার অনুমতি অনুযায়ী retrieval ফিল্টার করতে পারে - ফাইন্যান্সের chunk ফাইন্যান্সের কর্মীদের জন্য। Fine-tune করা মডেলের কাছে কে জিজ্ঞেস করছে তার কোনো ধারণা নেই; যা সে শিখেছে, যে কেউ তা বের করে নিতে পারে।
• খরচ ও দক্ষতা। RAG পাইপলাইন একটি ইঞ্জিনিয়ারিং প্রকল্প; ভালোভাবে fine-tuning একটি machine-learning প্রকল্প। বেশিরভাগ টিমের প্রথম দক্ষতাটি আছে, দ্বিতীয়টি নেই।

Fine-tuning-এর বাস্তব ব্যবহার এখনও আছে - মডেলকে একটি স্টাইল, একটি ডোমেইনের ভাষারীতি, বা একটি কাঠামোবদ্ধ আউটপুট ফরম্যাট শেখানো। পরিষ্কার নিয়মটি: আচরণের জন্য fine-tune, জ্ঞানের জন্য RAG।

৫. যে ইঞ্জিনিয়ারিং সিদ্ধান্তগুলো সবকিছু গড়ে বা ভাঙে

Chunking হলো কৌশল, নিছক নলকাজ নয়। বেশি বড় chunk retrieval পাতলা করে দেয় (সঠিক বাক্যটি এক পাতা গোলমালের নিচে চাপা); বেশি ছোট হলে context হারায় (টেবিলের সারি, header ছাড়া)। ডকুমেন্টের কাঠামোকে সম্মান করুন, সেকশনগুলো একসঙ্গে রাখুন, আর প্রতিটি chunk-এ মেটাডেটা জুড়ে দিন - উৎস, সেকশনের শিরোনাম, তারিখ। আমার অভিজ্ঞতায় "AI ভুল উত্তর দিয়েছে" টিকিটের বেশিরভাগেরই মূল কারণ retrieval ভুল chunk পরিবেশন করেছে, মডেলের যুক্তি খারাপ ছিল না।

Retrieval-এর মান মাপতে হবে। উত্তর বিচারের আগে retrieval বিচার করুন: এক সেট পরীক্ষামূলক প্রশ্নে প্রাসঙ্গিক chunk কি শীর্ষ ফলাফলে এসেছে? না এলে কোনো প্রম্পট ইঞ্জিনিয়ারিং আপনাকে বাঁচাবে না। Hybrid সার্চ - vector similarity-র সঙ্গে ক্লাসিক keyword ম্যাচিং মিলিয়ে - নাম, কোড আর পার্ট নম্বরের ক্ষেত্রে ফলাফল লক্ষণীয়ভাবে ভালো করে, যেগুলো embedding দুর্বলভাবে সামলায়।

নির্দেশনাটি গুরুত্বপূর্ণ। Generation প্রম্পটে শুধু প্রদত্ত context থেকে উত্তর দেওয়া বাধ্যতামূলক করতে হবে এবং স্পষ্টভাবে অনুমতি দিতে হবে - "প্রাপ্য ডকুমেন্টে এটি খুঁজে পাইনি।" যে RAG সিস্টেমকে "পাওয়া যায়নি" বলতে দেওয়া হয়, সেটি সবসময় কিছু-একটা তৈরি করতে বাধ্য সিস্টেমের চেয়ে বহুগুণ বেশি বিশ্বাসযোগ্য।

সিকিউরিটি মানে retrieval-এর সিকিউরিটি। Retrieval যা তুলে দেয়, মডেল তা-ই দেখে। ইনডেক্সে এমন ডকুমেন্ট থাকলে যা কোনো ব্যবহারকারীর দেখার কথা নয়, RAG দিব্যি তা সুন্দর বাক্যে ফাঁস করে দেবে। বাস্তব ডিপ্লয়মেন্টে কোয়েরির সময় permission ফিল্টারিং ঐচ্ছিক নয় - এটি প্রাইভেট LLM চালানোর সেই একই ডেটা-স্কোপিং শৃঙ্খলা।

৬. RAG কোথায় ব্যর্থ হয় - সৎভাবে

RAG সর্বরোগের ওষুধ নয়, আর এর ব্যর্থতার ধরনগুলো জানাই প্র্যাকটিশনারকে স্লাইড-ডেক থেকে আলাদা করে।

• সমষ্টিগত প্রশ্ন। "কতগুলো চুক্তিতে penalty clause আছে?" - এর জন্য সবকিছু পড়তে হয়, কাছাকাছি পাঁচটি chunk আনলে হয় না। এটি একটি কোয়েরি, retrieval নয় - একে SQL বা অ্যানালিটিক্সে পাঠান।
• Multi-hop যুক্তি। যে প্রশ্নের উত্তরে এমন কয়েকটি ডকুমেন্টের তথ্য মেলাতে হয় যেগুলো আলাদাভাবে প্রশ্নটির সঙ্গে মেলে না, সেগুলোর retrieval খারাপ হয়। Agentic প্যাটার্ন (একাধিক দফা retrieval) সাহায্য করে, বাড়তি জটিলতার বিনিময়ে।
• পরস্পরবিরোধী সূত্র। কোনো পলিসির v1 আর v7 দুটোই ইনডেক্সে থাকলে retrieval যেকোনোটি পরিবেশন করতে পারে। ইনডেক্স পরিচ্ছন্নতা - বাতিল ডকুমেন্ট সরিয়ে রাখা - অনাড়ম্বর কিন্তু অপরিহার্য।
• অবশিষ্ট hallucination। Grounding বানানো উত্তর নাটকীয়ভাবে কমায়, তবে মডেল এখনও context ভুলভাবে জোড়া দিতে পারে। উদ্ধৃতি, সঙ্গে উচ্চ-ঝুঁকির উত্তরে মানুষের রিভিউ - এটিই থেকে যায় নিরাপত্তার জাল।

৭. স্ট্রাকচার্ড ডেটায় RAG: ERP-এর দিক

RAG নিয়ে বেশিরভাগ লেখা ডকুমেন্ট ধরে নেয়, কিন্তু প্যাটার্নটি স্ট্রাকচার্ড ব্যবসায়িক ডেটাতেও প্রসারিত হয় - আর সেখানেই আমার Oracle-এর কাজ এর সঙ্গে মেলে। টেবিল ও কলামের বর্ণনা embed করা যায় যাতে সিস্টেম প্রশ্নের জন্য সঠিক ডেটা সোর্স খুঁজে পায়; retrieval ধাপটি হতে পারে একটি SQL কোয়েরি যার ফলাফল context হয়ে ওঠে; আর ডেটাবেজ নিজেই vector সংরক্ষণ করতে পারে - সেই in-database পদ্ধতি যা আমি Oracle 26ai দিয়ে ERP ডেটায় AI অ্যাসিস্ট্যান্ট লেখায় বর্ণনা করেছি।

ব্যবসার ডেটা যেখানে আগে থেকেই থাকে সেখানেই vector রাখার একটি নীরব মহাশক্তি আছে: vector-গুলো প্রথম দিন থেকেই ডেটাবেজের ব্যাকআপ, সিকিউরিটি আর অডিট ব্যবস্থার উত্তরাধিকার পায় - আর সংবেদনশীল কিছুই ভবনের বাইরে যায় না, যা sovereign পদ্ধতির পুরো লক্ষ্যই।

৮. একটি বাস্তব প্রকল্প: নিয়ন্ত্রিত কোম্পানিতে পলিসির উত্তর

সম্প্রতি আমি যে অভ্যন্তরীণ অ্যাসিস্ট্যান্ট নিয়ে কাজ করেছি, তাকে কয়েকশ পলিসি ও SOP ডকুমেন্ট থেকে কর্মীদের প্রশ্নের উত্তর দিতে হতো - এমন কোম্পানিতে যেখানে একটি ভুল কমপ্লায়েন্স উত্তরের পরিণতি আছে। নির্মাণটি ওপরের সবকিছু মেনে হয়েছে: শিরোনাম-সংযুক্ত সেকশন-সচেতন chunking, একটি multilingual embedding মডেল (প্রশ্ন আসত ইংরেজি ও বাংলায়), বিভাগ অনুযায়ী permission ফিল্টার, আর এমন generation প্রম্পট যা পলিসি নম্বর উদ্ধৃত করা বা প্রত্যাখ্যান বাধ্যতামূলক করেছিল।

এটিকে বিশ্বাসযোগ্য করেছিল মডেল নয় - উদ্ধৃতি আর প্রত্যাখ্যানগুলো। কর্মীরা ক্লিক করে ঠিক পলিসির অনুচ্ছেদে পৌঁছাতে পারতেন, আর সিস্টেম যখন বলত "বর্তমান পলিসিতে এটি নেই," সেই সততা যেকোনো সাবলীল অনুমানের চেয়ে বেশি আস্থা তৈরি করেছিল। লঞ্চের আগে পঞ্চাশটি বাস্তব প্রশ্নের একটি সাধারণ টেস্ট সেট দিয়ে retrieval-এর মান টিউন করা হয়েছিল, আর পুরোটা চলেছিল কোম্পানির নিয়ন্ত্রণে থাকা অবকাঠামোতে। এটাই প্রোডাকশনে RAG: বেশিরভাগটা যত্নশীল ইঞ্জিনিয়ারিং, সামান্য AI, আর সত্যের প্রতি অগাধ শ্রদ্ধা।

সাধারণ জিজ্ঞাসা (FAQ)

সহজ ভাষায় RAG কী?

Retrieval-Augmented Generation একটি AI মডেলকে আপনার নিজের ডেটা থেকে উত্তর দেওয়ায়। প্রশ্ন এলে সিস্টেম প্রথমে আপনার ডকুমেন্ট বা ডেটাবেজ থেকে সবচেয়ে প্রাসঙ্গিক অংশগুলো খুঁজে বের করে, তারপর প্রশ্নের সঙ্গে সেগুলো মডেলকে দেয় - ফলে উত্তরটি মডেলের সাধারণ স্মৃতি নয়, আপনার নিজের উপকরণে ভিত্তি করে তৈরি হয়। কোনো রিট্রেনিং লাগে না।

RAG আর fine-tuning-এর পার্থক্য কী?

RAG প্রশ্নের সময় প্রাসঙ্গিক কনটেন্ট খুঁজে এনে আপনার জ্ঞান যুক্ত করে; fine-tuning অতিরিক্ত ট্রেনিং দিয়ে মডেলটিকেই বদলে দেয়। ব্যবসায়িক জ্ঞানের ক্ষেত্রে RAG সাধারণত জেতে: আপডেট মানে তাৎক্ষণিক রি-ইনডেক্সিং, উত্তর সূত্র উদ্ধৃত করতে পারে, আর অ্যাক্সেস কন্ট্রোল সম্ভব। Fine-tuning মানায় স্টাইল ও ফরম্যাটে, তথ্যে নয় - সহজ নিয়ম: আচরণের জন্য fine-tune, জ্ঞানের জন্য RAG।

RAG কি AI-এর hallucination বন্ধ করে?

উল্লেখযোগ্যভাবে কমায়, কারণ মডেল স্মৃতি থেকে নয়, সরবরাহ করা প্রমাণ থেকে উত্তর দেয় - তবে পুরোপুরি দূর করে না। বাস্তব প্রতিরক্ষা হলো grounding, সঙ্গে 'শুধু প্রদত্ত context থেকে উত্তর দাও' নির্দেশনা, 'পাওয়া যায়নি' বলার স্বাধীনতা, সূত্রের উদ্ধৃতি, আর উচ্চ-ঝুঁকির উত্তরে মানুষের রিভিউ।

Embedding কী এবং RAG-এ এটি কেন গুরুত্বপূর্ণ?

Embedding টেক্সটকে সংখ্যার vector-এ রূপান্তর করে, যেখানে কাছাকাছি অর্থের টেক্সট কাছাকাছি বিন্দুতে বসে - এটিই RAG-কে keyword নয়, অর্থ দিয়ে প্রাসঙ্গিক কনটেন্ট খুঁজতে দেয়। Embedding মডেলটিকে আপনার ভাষা ভালোভাবে সামলাতে হবে এবং ইনডেক্সিং ও কোয়েরি - দুটোতেই একই মডেল হতে হবে; মডেল বদলালে সবকিছু আবার ইনডেক্স করতে হয়।

শুধু ডকুমেন্ট নয়, ডেটাবেজের ডেটা নিয়েও কি RAG কাজ করে?

হ্যাঁ। টেবিল ও কলামের বর্ণনা embed করে প্রশ্নকে সঠিক ডেটা সোর্সে পাঠানো যায়, কোয়েরির ফলাফলই retrieved context হতে পারে, আর আধুনিক ডেটাবেজ নিজেই vector সংরক্ষণ করতে পারে - ফলে পাইপলাইন চলে যেখানে ব্যবসার ডেটা আগে থেকেই থাকে, আর সেই ডেটাবেজের সিকিউরিটি, ব্যাকআপ ও অডিট নিয়ন্ত্রণ পেয়ে যায়।