मैंने एक RAG App बनाया, फिर उससे पूछा कि मुझे कौन सी कार पसंद है। उसे पता नहीं था।

मैं Kenning नाम का एक document-chat टूल बना रहा हूँ। यह उपयोगकर्ताओं को अपलोड की गई फाइलों के बारे में प्रश्न पूछने की अनुमति देने के लिए RAG (Retrieval-Augmented Generation) का उपयोग करता है।

मैंने पूरी पाइपलाइन को स्क्रैच से बनाया है, जिसमें इनका उपयोग किया गया है:

  • Java 21 और Spring Boot
  • Spring AI
  • PostgreSQL के साथ pgvector
  • Ollama (llama3.2:3b और nomic-embed-text चला रहा है)
  • Docker Compose

पाइपलाइन इस तरह काम करती है: फ़ाइल अपलोड करें → टेक्स्ट निकालें → टेक्स्ट को चंक्स (chunks) में बाँटें → चंक्स को वेक्टर्स में बदलें → pgvector में स्टोर करें → समान चंक्स खोजें → मॉडल को चंक्स + प्रश्न भेजें → स्रोतों के साथ उत्तर प्राप्त करें।

सिस्टम काम कर रहा था, लेकिन मुझे दो अलग-अलग विफलताओं का सामना करना पड़ा। वे दिखने में एक जैसी थीं, लेकिन उनके कारण अलग थे।

विफलता 1: मॉडल भ्रमित था। मैंने पूछा: "यह प्रोजेक्ट किस embedding model का उपयोग करता है?" दस्तावेज़ में स्पष्ट रूप से उत्तर दिया गया था। मॉडल ने सही टेक्स्ट निकाला। हालाँकि, इसने यह कहते हुए उत्तर दिया कि उसे नहीं पता, जबकि अगली ही पंक्ति में उसने सही मॉडल का नाम दोहराया था।

मेरा सिद्धांत: 3B मॉडल बहुत छोटा है। इसने सही डेटा तो निकाला लेकिन एक आत्मविश्वासपूर्ण उत्तर देने में सक्षम नहीं था। एक बड़ा मॉडल संभवतः इसे ठीक कर देगा।

विफलता 2: मॉडल को कुछ नहीं मिला। मैंने पूछा: "मुझे कौन सा कार ब्रांड पसंद है?" दस्तावेज़ में उल्लेख था कि मुझे BMW पसंद है। लेकिन सिस्टम ने शून्य परिणाम दिए। समानता स्कोर (similarity score) मेरे थ्रेशोल्ड (threshold) को पार करने के लिए बहुत कम था।

मेरा सिद्धांत: Chunk dilution। मेरा टेस्ट दस्तावेज़ छोटा था। इसने Spring AI, OAuth2 और मेरी कार की पसंद जैसे कई विषयों को एक ही चंक में मिला दिया था। उस चंक का वेक्टर उन सभी विषयों के बीच फैल (dilute) गया। कारों के बारे में एक विशिष्ट प्रश्न एक व्यापक चंक के सामने अपनी शक्ति खो बैठा। बेहतर चंकिंग रणनीति इसे ठीक कर देगी।

सीखे गए सबक:

  • छोटे मॉडलों की तर्क करने की क्षमता (reasoning limits) सीमित होती है।
  • साधारण चंकिंग (Naive chunking) रिट्रीवल सटीकता को प्रभावित करती है।
  • केवल त्रुटि को ठीक करने से कहीं अधिक महत्वपूर्ण "क्यों" को डीबग करना है।

आर्किटेक्चर टिकाऊ है। यह धीमा है और कभी-कभी गलत भी होता है, लेकिन लूप पूरा हो चुका है।

Source: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

Optional learning community: https://t.me/GyaanSetuAi