RAG या फाइन-ट्यूनिंग? वास्तविक क्लाइंट परियोजनाओं ने चुनाव के बारे में हमें क्या सिखाया

एंटरप्राइज़ AI पर मेरी लगभग हर बातचीत पहले घंटे के भीतर उसी दोराहे पर पहुँच जाती है। क्लाइंट के पास एक बड़ा भाषा मॉडल होता है, जो डेमो में प्रभावशाली तो लगता है, लेकिन उसे क्लाइंट के उत्पादों, नीतियों या लिखने के अंदाज़ की जानकारी नहीं होती। कमरे में कोई पूछता है: क्या हमें अपने डेटा पर मॉडल को फाइन-ट्यून करना चाहिए, या उसके इर्द-गिर्द रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) बनाना चाहिए?

ईमानदारी से कहें तो, आम तौर पर सवाल ही गलत ढंग से पूछा जाता है। RAG और फाइन-ट्यूनिंग अलग-अलग समस्याओं का समाधान करते हैं। जो टीमें इन्हें एक-दूसरे का विकल्प मानती हैं, वे अक्सर गलत समस्या को ठीक करने में महीनों और GPU बजट का बड़ा हिस्सा खर्च कर देती हैं। हम व्यावहारिक रूप से यह फ़ैसला कैसे करते हैं और हमने क्या सही और क्या ग़लत होते देखा है, यह जानिए।

पहले समझें कि मॉडल में किस चीज़ की कमी है

जब कोई मॉडल व्यावसायिक काम के लिए खराब जवाब देता है, तो उसमें दो में से किसी एक चीज़ की कमी होती है।

उसमें जानकारी की कमी है। उसे आपकी नवीनतम मूल्य-सूची, 2025 के आपूर्तिकर्ता अनुबंध की शर्त या पिछले महीने लॉन्च हुए उत्पाद की समस्या-निवारण प्रक्रिया की जानकारी नहीं होती। यह तथ्यों से जुड़ी समस्या है।

उसके व्यवहार में कमी है। उसे पर्याप्त जानकारी है, लेकिन वह आपकी ज़रूरत के मुताबिक जवाब नहीं देता। वह आपके आउटपुट फ़ॉर्मैट की अनदेखी करता है, गलत लहजे में लिखता है, आपके आंतरिक कोड को ग़लत समझता है या टिकटों को आपकी 40 श्रेणियों में बाँटने जैसे सीमित और बार-बार किए जाने वाले काम का पालन नहीं कर पाता। यह कौशल से जुड़ी समस्या है।

पहली समस्या के लिए RAG सही साधन है। दूसरी के लिए फाइन-ट्यूनिंग। मुझे दिखने वाली ज़्यादातर उलझन इस कोशिश से पैदा होती है कि तथ्यों को सिखाने के लिए फाइन-ट्यूनिंग का इस्तेमाल किया जाए।

जानकारी जोड़ने का फाइन-ट्यूनिंग अच्छा तरीका क्यों नहीं है

यह सोचना लुभावना है कि अगर आप किसी मॉडल को अपने दस्तावेज़ों पर प्रशिक्षित करेंगे, तो वह उन्हें “जान” जाएगा। व्यवहार में, वह उन दस्तावेज़ों की शैली कहीं अधिक भरोसेमंद ढंग से सीखता है, बजाय उनके भीतर के तथ्यों के। Microsoft के शोधकर्ताओं ने ज्ञान-आधारित सवालों के लिए दोनों तरीकों की सीधे तुलना की और पाया कि RAG ने लगातार बिना पर्यवेक्षण वाली फाइन-ट्यूनिंग से बेहतर प्रदर्शन किया—मॉडल ने प्रशिक्षण के दौरान जिन तथ्यों को देखा था, उनके लिए भी और बिल्कुल नए तथ्यों के लिए भी।

इसके व्यावहारिक नुकसान भी हैं। तथ्य बदलते रहते हैं। आपकी नीति या सूची में हर बदलाव के बाद, मॉडल को दोबारा प्रशिक्षित किए जाने तक फाइन-ट्यून किया हुआ मॉडल पुरानी जानकारी पर आधारित रहता है। इससे स्रोत का पता लगाने की क्षमता भी खो जाती है: जब फाइन-ट्यून किया हुआ मॉडल कोई आँकड़ा बताता है, तो आप उस दस्तावेज़ की ओर इशारा नहीं कर सकते जिससे वह लिया गया है। बीमा और स्वास्थ्य सेवा के विनियमित क्षेत्रों के क्लाइंट के लिए, यह बात ही आम तौर पर चर्चा समाप्त करने के लिए काफ़ी होती है।

RAG का पहला वर्णन Lewis आदि के 2020 के शोधपत्र में किया गया था; इसमें जानकारी मॉडल के बाहर रखी जाती है। सवाल पूछे जाने पर आप उससे जुड़े अंश खोजकर संदर्भ के रूप में मॉडल को देते हैं। जानकारी अपडेट करने के लिए इंडेक्स अपडेट करना होता है, मॉडल को फिर से प्रशिक्षित नहीं। साथ ही, हर जवाब के साथ उसके स्रोत का उल्लेख किया जा सकता है।

हमारा एक लॉजिस्टिक्स क्लाइंट इसका अच्छा उदाहरण है। उसके ग्राहक जानना चाहते थे कि उनकी खेप कहाँ है और कौन-से दस्तावेज़ अभी नहीं मिले हैं—और उन्हें तुरंत जवाब चाहिए था। यह जानकारी हर कुछ मिनट में बदल जाती है। कोई भी प्रशिक्षण मॉडल को अद्यतन नहीं रख सकता था, इसलिए हमने जो सहायक बनाया, वह याददाश्त से जवाब देने के बजाय सवाल पूछे जाने पर लाइव ट्रैकिंग और IoT डेटा से जवाब देता है। काम करने लायक एकमात्र डिज़ाइन रिट्रीवल ही था।

फाइन-ट्यूनिंग कहाँ कारगर साबित होती है

फाइन-ट्यूनिंग अप्रासंगिक नहीं हुई है। बस, इसका दायरा लोगों की अपेक्षा से संकरा है। हम तीन स्थितियों में इसका सहारा लेते हैं:

• कड़े, बार-बार इस्तेमाल होने वाले आउटपुट फ़ॉर्मैट। जब मॉडल को हर दिन हज़ारों बार एक ही संरचित आउटपुट देना हो—जैसे, इनवॉइस से फ़ील्ड निकालकर एक तय JSON स्कीमा में भरना—तो छोटा फाइन-ट्यून किया हुआ मॉडल अक्सर बड़े मॉडल को प्रॉम्प्ट देने से अधिक भरोसेमंद और बहुत सस्ता पड़ता है।
• क्षेत्र-विशेष की भाषा। कुछ क्षेत्रों में ऐसे संक्षिप्त कोड होते हैं जिन्हें बेस मॉडल ग़लत समझता है। लॉजिस्टिक्स के स्थिति-कोड, चिकित्सकीय संक्षिप्त रूप और आंतरिक उत्पाद कोड इसके आम उदाहरण हैं। थोड़ा-सा फाइन-ट्यूनिंग इस समस्या को ठीक कर सकता है।
• बड़े पैमाने पर लागत और विलंबता। जब कोई काम स्पष्ट रूप से परिभाषित हो जाए, तो छोटा फाइन-ट्यून किया हुआ मॉडल बड़े सामान्य प्रयोजन वाले मॉडल की जगह ले सकता है। LoRA जैसी विधियाँ इसे किफ़ायती बनाती हैं, क्योंकि इनमें पूरे मॉडल के बजाय अतिरिक्त वेट्स के एक छोटे समूह को प्रशिक्षित किया जाता है।

ध्यान दें कि इनमें से कोई भी बात तथ्यों के बारे में नहीं है। ये उस काम पर मॉडल को व्यवहार करना सिखाने के बारे में हैं जिसे आप पहले से अच्छी तरह समझते हैं।

RAG की ज़्यादातर विफलताएँ जानकारी खोजने में नाकामी होती हैं

जब कोई टीम मुझसे कहती है, “हमने RAG आज़माया, लेकिन यह काम नहीं आया,” तो समस्या शायद ही कभी मॉडल में होती है। समस्या जानकारी खोजने के चरण में होती है। मॉडल उतना ही अच्छा हो सकता है जितने अच्छे वे अंश हैं जो उसे दिए जाते हैं।

समाधान भले ही चमकदार न लगें, लेकिन कारगर हैं:

• खंडों को अक्षरों की गिनती से नहीं, अर्थ के आधार पर बाँटें। किसी अनुबंध को हर 500 अक्षरों पर बाँटने से उसकी शर्तें बीच में कट जाती हैं। अनुभागों और शीर्षकों के आधार पर बाँटने से संदर्भ बरकरार रहता है।
• हर खंड के साथ संदर्भ जोड़ें। “सीमा 30 दिन है” कहने वाला खंड यह जाने बिना बेकार है कि वह किस नीति से जुड़ा है। Anthropic ने बताया कि इंडेक्स बनाने से पहले हर खंड में दस्तावेज़ का संक्षिप्त संदर्भ जोड़ने से—जिस तरीके को वह संदर्भ-आधारित रिट्रीवल कहता है—खोज में हुई चूकों में 49% की कमी आई; री-रैंकिंग के साथ इसे इस्तेमाल करने पर कमी 67% रही।
• कीवर्ड और वेक्टर खोज को मिलाएँ। वेक्टर खोज अर्थ समझने में अच्छी है, लेकिन पार्ट नंबर जैसे सटीक शब्दों के मामले में कमज़ोर है। हाइब्रिड खोज दोनों को समेटती है।
• रिट्रीवल की अलग से जाँच करें। वास्तविक सवालों का ऐसा संग्रह तैयार करें जिनके सही स्रोत-अंश पहले से ज्ञात हों। फिर अंतिम जवाबों का मूल्यांकन करने से पहले मापें कि सही अंश सबसे ऊपर के नतीजों में आता है या नहीं।

दोनों का इस्तेमाल कब करें

व्यावहारिक इस्तेमाल में सबसे असरदार प्रणालियाँ अक्सर दोनों को मिलाती हैं। RAG तथ्य उपलब्ध कराता है। हल्के तौर पर फाइन-ट्यून किया गया मॉडल प्रारूप, लहजे और क्षेत्र-विशेष की भाषा को संभालता है। शोध भी इसी दिशा में आगे बढ़ रहा है: UC Berkeley का RAFT दृष्टिकोण मॉडल को खास तौर पर इस तरह फाइन-ट्यून करता है कि वह हासिल किए गए दस्तावेज़ों का बेहतर इस्तेमाल करे और अप्रासंगिक दस्तावेज़ों को अनदेखा करे।

लेकिन क्रम मायने रखता है। हम लगभग हमेशा पहले RAG बनाते हैं, उसकी कमियों को मापते हैं और उसके बाद ही तय करते हैं कि फाइन-ट्यूनिंग करना उचित है या नहीं। शुरुआत ही फाइन-ट्यूनिंग से करने का मतलब है कि असली कमी का पता चलने से पहले ही प्रशिक्षण पर खर्च करना।

फ़ैसला लेने की आसान सूची

1. क्या यह काम ऐसे तथ्यों पर निर्भर करता है जो हर तिमाही में एक से अधिक बार बदलते हैं? RAG का इस्तेमाल करें।
2. क्या उपयोगकर्ताओं या ऑडिटरों को यह जानना ज़रूरी है कि जवाब कहाँ से आया? RAG का इस्तेमाल करें।
3. क्या समस्या जवाबों के तथ्यों में नहीं, बल्कि उनके प्रारूप, लहजे या शब्दावली में है? फाइन-ट्यूनिंग पर विचार करें।
4. क्या यह सीमित दायरे वाला ऐसा काम है जिसे बड़े पैमाने पर किया जाता है, जहाँ लागत या गति मायने रखती है? छोटे मॉडल को फाइन-ट्यून करने पर विचार करें।
5. क्या आपने रिट्रीवल की गुणवत्ता को अलग से मापा है? अगर नहीं, तो कोई और कदम उठाने से पहले यह करें।

निष्कर्ष

RAG और फाइन-ट्यूनिंग एक-दूसरे के प्रतिद्वंद्वी नहीं हैं। एक मॉडल को सही जानकारी देता है, तो दूसरा उसके व्यवहार को आकार देता है। पहले साफ़ तौर पर समझें कि आपकी असल समस्या क्या है, मॉडल को दोष देने से पहले रिट्रीवल को दुरुस्त करें, और फाइन-ट्यूनिंग को ऐसा सुधार मानें जिसे सिस्टम के काम करने के बाद अपनाया जाता है—न कि उसे काम कराने का कोई शॉर्टकट।