৭টি ভুল করার আগে আমি RAG ইনফ্রাস্ট্রাকচারে ৫০০ ডলার খরচ করেছি
আমি ব্যক্তিগত ডকুমেন্ট সার্চের জন্য একটি RAG পাইপলাইন তৈরি করেছিলাম। কম্পিউট খরচ এবং ডিবাগিং করতে আমার ৫০০ ডলার এবং কয়েক সপ্তাহ সময় লেগেছিল। ফলাফল ছিল খুবই খারাপ। ব্যবহারকারীরা অপ্রাসঙ্গিক উত্তর পাচ্ছিলেন এবং কুয়েরিগুলো ছিল ধীরগতির।
আমি পাইপলাইনটি অডিট করলাম এবং ৭টি সাধারণ ভুল খুঁজে পেলাম। সেগুলো ঠিক করার পর সবকিছু বদলে গেল।
১. ফিক্সড টোকেন চাঙ্কিং (Fixed Token Chunking) আমি নির্দিষ্ট টোকেন সংখ্যা অনুযায়ী ডকুমেন্টগুলোকে ভাগ করেছিলাম। এতে কনটেক্সট বা প্রেক্ষাপট নষ্ট হয়ে যাচ্ছিল। একটি বাক্য মাঝখান থেকে ভেঙে যাচ্ছিল। LLM খণ্ডিত ডেটা পাচ্ছিল এবং নিম্নমানের উত্তর দিচ্ছিল।
- সমাধান: parent-document retrieval সহ semantic chunking ব্যবহার করুন।
- প্যারাগ্রাফ বা হেডার এর মতো প্রাকৃতিক সীমানা অনুযায়ী ভাগ করুন।
- সার্চের জন্য ছোট ছোট child chunks তৈরি করুন।
- কোনো ম্যাচ পাওয়া গেলে LLM-কে সম্পূর্ণ parent document প্রদান করুন।
- চাঙ্কগুলোর মধ্যে ১০-২০% ওভারল্যাপ রাখুন।
২. ডিফল্ট সার্চ ওয়েট (Default Search Weights) আমি vector এবং keyword সার্চের জন্য ৫০/৫০ অনুপাত ব্যবহার করেছিলাম। টেকনিক্যাল ডকুমেন্টের ক্ষেত্রে সঠিক কিওয়ার্ড বেশি গুরুত্বপূর্ণ।
- সমাধান: ডাইনামিক ওয়েট ব্যবহার করুন।
- তথ্যমূলক কুয়েরি (Factual queries): ৩৫% vector, ৬৫% keyword।
- সিম্যান্টিক কুয়েরি (Semantic queries): ৭৫% vector, ২৫% keyword।
৩. HNSW প্যারামিটার অতিরিক্ত অপ্টিমাইজ করা
আমি ef_construction এর মান সর্বোচ্চ সেট করেছিলাম। একটি বড় ইনডেক্সের ক্ষেত্রে এটি আমার সার্ভার ক্র্যাশ করিয়েছিল এবং সমস্ত RAM ব্যবহার করে ফেলেছিল।
- সমাধান: যথাযথ HNSW সেটিংস ব্যবহার করুন।
- M এর মান ৮ থেকে ৩২ এর মধ্যে রাখুন।
ef_constructionএর মান ২০০ সেট করুন।ef_searchএর মান ৫০ সেট করুন।
৪. ভুল এমবেডিং মডেল (Wrong Embedding Models) আমি ওয়েব টেক্সটের ওপর প্রশিক্ষিত একটি সাধারণ মডেল ব্যবহার করেছিলাম। এটি আমার টেকনিক্যাল ইঞ্জিনিয়ারিং ডকুমেন্টগুলো বুঝতে পারছিল না।
- সমাধান: টেকনিক্যাল বা কোড কন্টেন্টের জন্য fine-tuned করা মডেলে পরিবর্তন করুন।
৫. ন্যাচারাল ল্যাঙ্গুয়েজ মিসম্যাচ (Natural Language Mismatch) ব্যবহারকারীরা প্রশ্ন করেন যেমন "কেন আমার বিল্ড ধীরগতির হচ্ছে।" কিন্তু ডকুমেন্টেশনে ব্যবহৃত হয় "CI pipeline optimization"-এর মতো শব্দ। এদের মধ্যে কোনো মিল ছিল না।
- সমাধান: একটি LLM query rewrite ধাপ যোগ করুন।
- সার্চ করার আগে ব্যবহারকারীর কুয়েরিটিকে টেকনিক্যাল শব্দে পুনরায় লিখুন।
৬. অতিরিক্ত বা অপ্রয়োজনীয় কনটেক্সট (Redundant Context) টপ ১০টি চাঙ্ক রিট্রিভ করার অর্থ ছিল প্রায়ই একই প্যারাগ্রাফ তিনবার পাওয়া। এর ফলে হ্যালুসিনেশন (hallucinations) তৈরি হচ্ছিল।
- সমাধান: ফলাফলে বৈচিত্র্য নিশ্চিত করতে Maximal Marginal Relevance (MMR) ব্যবহার করুন।
৭. শুধুমাত্র এন্ড-টু-এন্ড ইভালুয়েশন (End-to-End Evaluation Only) আমি শুধু চূড়ান্ত উত্তরটি পরীক্ষা করতাম। সমস্যাটি রিট্রিভ্যালে নাকি LLM-এ ছিল, তা আমি জানতাম না।
- সমাধান: রিট্রিভ্যাল আলাদাভাবে মূল্যায়ন করুন।
- hit rate এবং Mean Reciprocal Rank (MRR) ট্র্যাক করুন।
- ১০০টি query-document পেয়ারের একটি টেস্ট সেট তৈরি করুন।
সমাধান করার পরের ফলাফল: • উত্তরের প্রাসঙ্গিকতা (Answer relevance): ৪৫% থেকে ৮৫% • কুয়েরি ল্যাটেন্সি (Query latency): ৩.২ সেকেন্ড থেকে ১.৮ সেকেন্ড • মাসিক খরচ: ১৮০ ডলার থেকে ৯৫ ডলার
প্রথমে chunking ঠিক করুন। তারপর weights। এরপর embedding quality।
RAG নিয়ে আপনার সবচেয়ে বড় মাথাব্যথা কী? কমেন্টে আমাকে জানান।
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi