কিছুই সংরক্ষণ না করা ডকুমেন্ট RAG

এই পেজে

1. সারসংক্ষেপ
2. সমস্যা
3. সীমাবদ্ধতা
4. পদ্ধতি ও আর্কিটেকচার
5. ফলাফল
6. এখন হলে যা অন্যভাবে করতাম

সমস্যা

বেশির ভাগ "PDF-এর সঙ্গে চ্যাট" টুল আপনার ডকুমেন্ট এমন এক ভেক্টর ডেটাবেসে রেখে দেয়, যার নিয়ন্ত্রণ আপনার হাতে নেই। আমি চেয়েছিলাম এমন ডকুমেন্ট প্রশ্নোত্তর ব্যবস্থা, যেখানে আপনি নিজের Hugging Face টোকেন দেবেন, একটি PDF বা টেক্সট ফাইল আপলোড করবেন, আর শুধু সেই ফাইলের ভিত্তিতেই উত্তর পাবেন; সার্ভারে কিছুই সংরক্ষিত হবে না।

সীমাবদ্ধতা

• কোনো সংরক্ষণ নয়। আপলোড মেমরিতেই প্রসেস হয়, কখনো ডিস্কে বা ডেটাবেসে লেখা হয় না।
• নিজের টোকেন। ব্রাউজার ব্যবহারকারীর Hugging Face টোকেন localStorage-এ রাখে এবং প্রতিটি রিকোয়েস্টে বেয়ারার হেডার হিসেবে পাঠায়। সার্ভার নিজের টোকেন ব্যবহার করে কেবল তখনই, যদি তা কনফিগার করা থাকে।
• উন্মুক্ত ডেমো। যে কেউ এটি ব্যবহার করতে পারে, তাই রিকোয়েস্টে রেট লিমিট আছে, প্রশ্ন ১,০০০ অক্ষরে সীমিত, ফাইলের আকার সীমিত, আর শুধু .txt ও .pdf গ্রহণ করা হয়। API ডকুমেন্টেশন একটি গোপন টোকেন দিয়ে সুরক্ষিত।
• হোস্টেড ইনফারেন্স। এমবেডিং ও জেনারেশন চলে Hugging Face-এর ইনফারেন্স এন্ডপয়েন্টে, তাই একই ডকুমেন্টে বারবার একই কাজ এড়াতে হয়।

পদ্ধতি ও আর্কিটেকচার

1. Cloudflare-এ React + Vite

   ক্লায়েন্ট

   Hugging Face টোকেন ব্রাউজারের localStorage-এই থাকে

2. POST /rag/query · ফাইল + প্রশ্ন + বেয়ারার টোকেন

   FastAPI প্রবেশপথ

   API

   রেট লিমিট · শুধু .txt/.pdf · আকার ও ১,০০০ অক্ষরের সীমা

3. লেখা বের করা

   এক্সট্র্যাক্ট

   PDF-এর জন্য pypdf, টেক্সটের জন্য UTF-8, শুধু মেমরিতে

4. ক্যাশ কী: SHA-256(ফাইল) + মডেল + চাংকিং + টোকেন হ্যাশ

   • ভেক্টর স্টোর আবার ব্যবহার

     ক্যাশ হিট

     পাঁচ মিনিট বৈধ

   • ভাগ ও এমবেড করা

     ক্যাশ মিস

     রিকার্সিভ স্প্লিটার → HF এমবেডিং → ইন-মেমরি স্টোর

5. টপ-k সাদৃশ্য অনুসন্ধান

   রিট্রিভ

   প্রতি প্রশ্নে k = ১ থেকে ১০

6. তথ্যভিত্তিক উত্তর

   জেনারেট

   HF চ্যাট কমপ্লিশন · টেম্পারেচার ০ · সর্বোচ্চ ৫১২ টোকেন

7. স্ট্রিম করা উত্তর

   আগে উত্তর, তারপর মেট্রিক

   ক্লায়েন্ট

   টোকেন, জেনারেশনের সময় ও প্রতি সেকেন্ডে টোকেন

›ডায়াগ্রামের বর্ণনা

React ক্লায়েন্ট ফাইল, প্রশ্ন আর ব্যবহারকারীর Hugging Face টোকেন একটি FastAPI এন্ডপয়েন্টে পাঠায়। API রেট লিমিট ও ইনপুটের সীমা যাচাই করে, মেমরিতে লেখা বের করে, আর ফাইল, মডেল, চাংকিং সেটিং ও টোকেনের হ্যাশ দিয়ে ক্যাশে থাকা ভেক্টর স্টোর খোঁজে। না পেলে লেখা ভাগ করে এমবেড করে; পেলে ক্যাশের স্টোরটিই ব্যবহার করে। এরপর টপ-k চাংক রিট্রিভ করে, টেম্পারেচার ০-তে তথ্যভিত্তিক উত্তর তৈরি করে, এবং উত্তর স্ট্রিম করার পর জেনারেশনের মেট্রিক পাঠায়।

ফলাফল

সিস্টেমটি চালু আছে rag.abdullahalrafi.com-এ, সোর্স কোড GitHub-এ। এরর যায় Sentry-তে, আর ক্যাশ হিট ও মিস ব্রেডক্রাম্ব হিসেবে লগ হয়, তাই ধীর উত্তরের কারণ যে পুনরায় এমবেডিং, তা খুঁজে বের করা যায়।

এখন হলে যা অন্যভাবে করতাম

• মডেলের নিজস্ব টোকেনাইজার দিয়ে টোকেন গুনতাম। এখন প্রতি সেকেন্ডে টোকেনের হিসাব হয় ফাঁকা জায়গা ধরে ভাগ করে, যা সাবওয়ার্ড টোকেন কম গোনে এবং বিভিন্ন মডেলের গতি তুলনা কঠিন করে।
• ছোট একটি লেবেল করা প্রশ্নসেট দিয়ে রিট্রিভাল যাচাই করতাম, আর চাংকের আকার ও টপ-k এনভায়রনমেন্ট ভেরিয়েবলে অনুমান করে না বসিয়ে সেই অনুযায়ী ঠিক করতাম।
• একাধিক ওয়ার্কারের কথা মাথায় রাখতাম। ক্যাশ এখন একটি প্রসেসেই থাকে; একটি শেয়ার করা, এনক্রিপ্টেড ক্যাশ হিট রেট বাড়াত, তবে তাতে 'কিছুই সংরক্ষণ না করার' প্রতিশ্রুতির সত্যিকারের মূল্য দিতে হতো।