मी एक RAG App बनवले, मग त्याला विचारले की मला कोणती कार आवडते. त्याला ते माहित नव्हते.

मी Kenning नावाचे एक document-chat टूल बनवत आहे. वापरकर्त्यांना अपलोड केलेल्या फाइल्सबद्दल प्रश्न विचारता यावेत यासाठी ते RAG (Retrieval-Augmented Generation) वापरते.

मी संपूर्ण पाइपलाइन शून्यापासून (from scratch) खालील गोष्टी वापरून तयार केली:

  • Java 21 आणि Spring Boot
  • Spring AI
  • PostgreSQL (pgvector सह)
  • Ollama (llama3.2:3b आणि nomic-embed-text चालवत)
  • Docker Compose

ही पाइपलाइन अशी काम करते: फाईल अपलोड करा → मजकूर (text) काढा → मजकुराचे तुकडे (chunk text) करा → तुकड्यांचे वेक्टर्समध्ये (vectors) रूपांतर करा → pgvector मध्ये साठवा → समान तुकड्यांचा शोध घ्या → तुकडे + प्रश्न मॉडेलला पाठवा → स्रोतांसह (sources) उत्तर मिळवा.

सिस्टम काम करत होती, पण मला दोन वेगवेगळ्या त्रुटी (failures) जाणवल्या. त्या दिसायला सारख्या होत्या, पण त्यांची कारणे वेगळी होती.

त्रुटी १: मॉडेल गोंधळले होते.

मी विचारले: "या प्रोजेक्टमध्ये कोणते embedding model वापरले आहे?" दस्तऐवजात याचे उत्तर स्पष्टपणे दिले होते. मॉडेलने योग्य मजकूर शोधला (retrieve केला). तरीही, पुढच्या वाक्यात योग्य मॉडेलचे नाव पुन्हा सांगतानाही, मॉडेलने "मला माहित नाही" असे उत्तर दिले.

माझा सिद्धांत: 3B मॉडेल खूप लहान आहे. त्याने योग्य डेटा शोधला पण आत्मविश्वासाने उत्तर देऊ शकले नाही. मोठे मॉडेल वापरल्यास ही समस्या सुटू शकते.

त्रुटी २: मॉडेलला काहीच सापडले नाही.

मी विचारले: "मला कोणत्या कार ब्रँड आवडतो?" दस्तऐवजात मी BMW आवडते असा उल्लेख होता. पण सिस्टमने शून्य निकाल दिले. similarity score माझ्या ठरवलेल्या मर्यादेपेक्षा (threshold) खूपच कमी होता.

माझा सिद्धांत: Chunk dilution. माझा टेस्ट डॉक्युमेंट छोटा होता. त्यात Spring AI, OAuth2 आणि माझी कार आवड यांसारखे अनेक विषय एकाच तुकड्यात (chunk) मिसळले होते. त्यामुळे त्या तुकड्याचा वेक्टर (vector) सर्व विषयांमध्ये विखुरला गेला. कारबद्दलच्या विशिष्ट प्रश्नाचे महत्त्व एका मोठ्या तुकड्यासमोर कमी झाले. चांगली chunking strategy वापरल्यास ही समस्या सुटू शकते.

शिकलेले धडे:

  • लहान मॉडेल्सच्या तर्कशक्तीच्या (reasoning) मर्यादा असतात.
  • साधी (naive) chunking पद्धत शोधण्याच्या अचूकतेवर (retrieval accuracy) परिणाम करते.
  • केवळ त्रुटी सुधारण्यापेक्षा ती "का" आली याचे शोध घेणे (debugging) अधिक महत्त्वाचे आहे.

आर्किटेक्चर टिकून आहे. ते संथ आहे आणि कधीकधी चुकीचे असते, पण प्रक्रिया (loop) पूर्ण झाली आहे.

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