RAG সহজ ভাষায়: নিজের নথি থেকে প্রশ্নের উত্তর

Language model শুধু তার training data জানে, যা পুরোনো হতে পারে এবং আপনার ব্যক্তিগত নথি নেই। RAG (retrieval-augmented generation) এটি ঠিক করে: প্রশ্নের সময় সিস্টেম আপনার নিজের কনটেন্ট থেকে প্রাসঙ্গিক অংশ খুঁজে আনে এবং উত্তর দিতে model-কে দেয়।

দুটি পর্ব

Indexing (আগে থেকে করা)

১. নথি জোগাড় করুন: সহায়তা নিবন্ধ, PDF, wiki পেজ, ticket। ২. পরিষ্কার করে chunk-এ ভাগ করুন। ৩. প্রতিটি chunk-এর embedding বানিয়ে লেখা ও metadata-সহ সংরক্ষণ করুন (embeddings লেখা দেখুন)।

উত্তর দেওয়া (প্রতিটি প্রশ্নে)

১. ব্যবহারকারীর প্রশ্ন নিন, ঐচ্ছিকভাবে আরও পরিষ্কার করে নতুন করে লিখুন। ২. সবচেয়ে প্রাসঙ্গিক chunk খুঁজে আনুন (vector, keyword বা hybrid search), প্রয়োজনে re-rank করুন। ৩. নির্দেশ, পাওয়া chunk ও প্রশ্ন নিয়ে prompt বানান। ৪. Model সেই উৎসের ভিত্তিতে উত্তর লেখে, আদর্শভাবে citation-সহ।

একটি সহজ prompt

Answer the question using only the sources below.
If the sources do not contain the answer, say "I don't know based on the available documents."
Cite the source number for each claim, like [1].

Sources:
[1] (Refund policy) Refunds are available within 30 days of purchase...
[2] (Shipping) Orders ship within 2 business days...

Question: Can I get a refund after 45 days?

RAG কেন ব্যবহার করবেন

• Model আবার প্রশিক্ষণ ছাড়াই তাজা ও ব্যক্তিগত জ্ঞান।
• কম hallucination, কারণ উত্তর লেখায় নোঙর করা।
• Citation, যাতে ব্যবহারকারী যাচাই করতে পারে।
• সহজ হালনাগাদ: নথি বদলে আবার index করুন, উত্তর বদলে যায়।
• Retrieval-এর সময় access control সম্ভব।

RAG বনাম fine-tuning

• RAG প্রশ্নের সময় জ্ঞান যোগ করে। তথ্য, নথি ও বদলানো তথ্যের জন্য সেরা।
• Fine-tuning model-এর আচরণ বা শৈলী বদলায় (ফরম্যাট, সুর, বিশেষ কাজ)। তথ্য নির্ভরযোগ্যভাবে ধরে রাখতে দুর্বল এবং হালনাগাদে ধীর।
• দুটি মেলানো যায়, তবে RAG ও ভালো prompt দিয়ে শুরু করুন।

RAG কোথায় ব্যর্থ হয়

বেশিরভাগ "খারাপ AI উত্তর" retrieval সমস্যা, model সমস্যা নয়।

• সঠিক chunk আসেনি: খারাপ chunking, দুর্বল embedding, ভুল filter, বা প্রশ্নে ভিন্ন শব্দ। hybrid search, query নতুন করে লেখা ও re-ranking চেষ্টা করুন।
• অতিরিক্ত বা অগোছালো context: অপ্রাসঙ্গিক chunk model-কে বিভ্রান্ত করে। কম কিন্তু ভালো chunk আনুন।
• উত্তর কয়েকটি নথিতে ছড়ানো: একটি chunk যথেষ্ট নয়। বেশি আনুন বা বহু-ধাপের retrieval করুন।
• পুরোনো বা পরস্পরবিরোধী নথি: metadata-য় তারিখ ও সংস্করণ রাখুন এবং বাসি কনটেন্ট সরান।
• Model উৎস উপেক্ষা করে: নির্দেশ দৃঢ় করুন এবং citation ও "জানি না" চান।
• Table, PDF ও scan খারাপভাবে বের হয়। ভালো parsing গুরুত্বপূর্ণ।

মূল্যায়ন করুন

কয়েকটি ভাগ্যবান demo দেখে বিচার করবেন না। প্রত্যাশিত উত্তর বা প্রত্যাশিত উৎস নথিসহ আসল প্রশ্নের ছোট test set বানিয়ে মাপুন:

• Retrieval: সঠিক অংশ কি সেরা ফলে এসেছে?
• Faithfulness: উত্তর কি পাওয়া লেখা দ্বারা সমর্থিত?
• উত্তরের মান: এটি কি সঠিক ও সম্পূর্ণ?

Chunking, embedding model, prompt বা LLM বদলালেই test আবার চালান।

নিরাপত্তা ও গোপনীয়তা

• অনুমতি মানুন। বর্তমান ব্যবহারকারী যা পড়তে পারে সেই অনুযায়ী retrieval filter করুন। এক গ্রাহকের নথি কখনো অন্যের উত্তরে আসতে দেবেন না।
• নথিকে অবিশ্বস্ত ইনপুট ধরুন। ওয়েব পেজ বা আপলোড করা ফাইলে লুকানো নির্দেশ ("আগের নিয়ম উপেক্ষা করে ... প্রকাশ করো") থাকতে পারে, যাকে indirect prompt injection বলে। নির্দেশ ও data আলাদা রাখুন, টুল দিয়ে model কী করতে পারে সীমিত করুন, এবং যাচাই ছাড়া উদ্ধার করা লেখা দিয়ে সংবেদনশীল কাজ চালাতে দেবেন না। এই সিরিজের LLM নিরাপত্তা লেখা দেখুন।
• যে secret বা ব্যক্তিগত data লাগে না তা index করবেন না।
• যে বাইরের embedding বা model API-তে কনটেন্ট পাঠান তার গোপনীয়তা শর্ত দেখুন।

ব্যবহারিক টিপ

• ব্যবহারকারীকে লিংক হিসেবে উৎস দেখান।
• ব্যর্থতা খুঁজতে প্রশ্ন, উদ্ধার করা chunk ও উত্তর log করুন (গোপনীয়তার যত্নসহ)।
• Feedback বোতাম দিন এবং খারাপ উত্তর নিয়মিত পর্যালোচনা করুন।
• সহজভাবে শুরু করুন: ভালো chunk, hybrid retrieval, দৃঢ় prompt। test-এ প্রয়োজন দেখালেই জটিলতা যোগ করুন।

মূল কথা: RAG আপনার নথি থেকে প্রাসঙ্গিক অংশ খুঁজে আনে এবং model-কে সেখান থেকে উত্তর দিতে বলে। মান মূলত chunking ও retrieval-এর ওপর নির্ভর করে, তাই আসল প্রশ্নে পরীক্ষা করুন, অনুমতি মানুন এবং উদ্ধার করা লেখাকে অবিশ্বস্ত ধরুন।

---

AI ও LLM সিরিজ, পর্ব ১ (language model দিয়ে বানানো): 4 নম্বর (মোট 5)। আগের লেখা: Embedding ও vector search ডেভেলপারের জন্য সহজ ব্যাখ্যা.