এই ৭টি ভুল সংশোধনের আগে আমি RAG ইনফ্রাস্ট্রাকচারে $৫০০ খরচ করেছি
আমি প্রাইভেট ডকুমেন্ট সার্চের জন্য একটি RAG পাইপলাইন তৈরি করেছিলাম। এতে কম্পিউট খরচ হিসেবে আমার $৫০০ এবং ডিবাগিংয়ে কয়েক সপ্তাহ লেগেছিল। ফলাফল ছিল খুবই খারাপ। ব্যবহারকারীরা ভুল উত্তর পাচ্ছিলেন এবং কুয়েরিগুলো ছিল ধীরগতির।
আমি পাইপলাইনটি অডিট করেছি। আমি ৭টি ভুল খুঁজে পেয়েছি। সেগুলো সংশোধন করার পর সবকিছু বদলে গেছে।
১. ফিক্সড টোকেন চাঙ্কিং (Fixed Token Chunking) আমি ৫১২ টোকেন করে ডকুমেন্টগুলোকে ভাগ (split) করতাম। এতে কনটেক্সট বা প্রেক্ষাপট নষ্ট হয়ে যাচ্ছিল। একটি API-এর ব্যাখ্যা মাঝপথেই ভেঙে যাচ্ছিল। LLM খণ্ড খণ্ড অংশ পাচ্ছিল এবং অর্থহীন উত্তর দিচ্ছিল। সমাধান: সিম্যান্টিক চাঙ্কিং (semantic chunking) ব্যবহার করুন।
- প্যারাগ্রাফ বা হেডার-এর মতো স্বাভাবিক সীমানা অনুযায়ী ভাগ করুন।
- প্যারেন্ট-ডকুমেন্ট রিট্রিভাল (parent-document retrieval) ব্যবহার করুন।
- সার্চের জন্য ছোট চাইল্ড চাঙ্ক (child chunks) তৈরি করুন।
- LLM-এর কাছে সম্পূর্ণ প্যারেন্ট ডকুমেন্টটি ফেরত পাঠান।
- চাঙ্কগুলোর মধ্যে ১০-২০% ওভারল্যাপ রাখুন।
২. ভুল হাইব্রিড সার্চ ওয়েট (Bad Hybrid Search Weights) আমি ভেক্টর এবং কিওয়ার্ড সার্চের জন্য ৫০/৫০ অনুপাত ব্যবহার করেছিলাম। টেকনিক্যাল ডকুমেন্টের ক্ষেত্রে এটি ব্যর্থ হয়েছিল। টেকনিক্যাল ব্যবহারকারীদের ক্ষেত্রে সঠিক কিওয়ার্ড ম্যাচ প্রয়োজন হয়। সমাধান: ডাইনামিক ওয়েট (dynamic weights) ব্যবহার করুন।
- তথ্যমূলক কুয়েরি (Factual queries): ৩৫% ভেক্টর, ৬৫% কিওয়ার্ড।
- সিম্যান্টিক কুয়েরি (Semantic queries): ৭৫% ভেক্টর, ২৫% কিওয়ার্ড।
- সাধারণ কুয়েরি (General queries): ৬০% ভেক্টর, ৪০% কিওয়ার্ড।
৩. HNSW প্যারামিটার অতিরিক্ত টিউন করা (Over-tuning HNSW Parameters)
আমি ef_construction সর্বোচ্চ সেট করেছিলাম। এতে আমার সার্ভার ক্র্যাশ করেছিল। এটি সমস্ত উপলব্ধ RAM ব্যবহার করে ফেলছিল।
সমাধান: যথাযথ প্যারামিটার ব্যবহার করুন।
- M-এর মান ৮ থেকে ৩২-এর মধ্যে রাখুন।
ef_construction২০০ সেট করুন।ef_search৫০ সেট করুন। মেমরি ব্যবহার ৭০% কমে গেছে।
৪. সাধারণ এমবেডিং মডেল (General Embedding Models) আমি উইকিপিডিয়াতে প্রশিক্ষিত একটি মডেল ব্যবহার করেছিলাম। কিন্তু আমার ডকুমেন্টগুলো ছিল টেকনিক্যাল ইঞ্জিনিয়ারিং রানবুক। মডেলটি আমার ডোমেইন বুঝতে পারছিল না। সমাধান: টেকনিক্যাল বা কোড কন্টেন্টের জন্য ফাইন-টিউন করা মডেল ব্যবহার করুন।
৫. কুয়েরি রিরাইটিং না করা (No Query Rewriting) ব্যবহারকারীরা স্বাভাবিক ভাষায় প্রশ্ন করেন। কিন্তু টেকনিক্যাল ডকুমেন্টে ফরমাল টার্ম বা শব্দ ব্যবহার করা হয়। এই দুটির মধ্যে মিল থাকে না। সমাধান: কুয়েরি রিরাইট করার জন্য একটি লাইটওয়েট LLM ধাপ যুক্ত করুন।
- ব্যবহারকারী জিজ্ঞাসা করেন: "why is my build slow"
- সিস্টেমটি রিরাইট করে: "CI pipeline performance optimization"
- এটি রিকল (recall) ৪০% উন্নত করেছে।
৬. অতিরিক্ত বা পুনরাবৃত্তিমূলক ফলাফল (Redundant Results) টপ-১০ চাঙ্ক রিট্রিভ করার সময় প্রায়ই একই প্যারাগ্রাফ তিনবার চলে আসছিল। ফলে LLM একই কথা বারবার বলছিল। সমাধান: ফলাফলে বৈচিত্র্য নিশ্চিত করতে Maximal Marginal Relevance (MMR) ব্যবহার করুন।
৭. ভুল জিনিস পরীক্ষা করা (Testing the Wrong Thing) আমি পুরো পাইপলাইনটি একসাথে পরীক্ষা করেছিলাম। ফলে আমি বুঝতে পারছিলাম না সমস্যাটি রিট্রিভ্যালে নাকি LLM-এ। সমাধান: রিট্রিভাল ইভ্যালুয়েশন (retrieval evaluation) আলাদাভাবে করুন।
- হিট রেট (hit rate) ট্র্যাক করুন।
- Mean Reciprocal Rank (MRR) ট্র্যাক করুন।
- ১০০টি কুয়েরি-ডকুমেন্ট পেয়ারের একটি টেস্ট সেট তৈরি করুন।
সংশোধনের পর ফলাফল:
- উত্তরের প্রাসঙ্গিকতা: 45% থেকে 85%
- ল্যাটেন্সি: 3.2s থেকে 1.8s
- মাসিক খরচ: $180 থেকে $95
প্রথমে chunking ঠিক করুন। তারপর weights। এরপর embedding quality।