आरएजी पाइपलाइनों के लिए पुनर्प्राप्ति पैटर्न लागू करें

पूरा किया

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

इस इकाई में आरएजी वर्कलोड के लिए स्कीमा डिजाइन करना, चंक पुनर्प्राप्ति प्रश्नों को लागू करना, दस्तावेज़ अंतर्ग्रहण पाइपलाइनों का निर्माण, उद्धरण मेटाडेटा वापस करना और पुनर्प्राप्ति गुणवत्ता का मूल्यांकन करना शामिल है।

आरएजी आर्किटेक्चर और रिट्रीवर भूमिका को समझें

आरएजी सिस्टम तीन-चरणीय पैटर्न का पालन करते हैं:

1. क्वेरी एम्बेडिंग: एम्बेडिंग मॉडल का उपयोग करके उपयोगकर्ता के प्रश्न को वेक्टर में कनवर्ट करें
2. पुनर्प्राप्ति: क्वेरी एम्बेडिंग के समान दस्तावेज़ों के लिए वेक्टर स्टोर खोजें
3. पीढ़ी: पुनर्प्राप्त दस्तावेज़ों को संदर्भ के रूप में LLM में पास करें, जो एक प्रतिक्रिया उत्पन्न करता है

PostgreSQL इस आर्किटेक्चर में रिट्रीवर के रूप में कार्य करता है। पुनर्प्राप्ति की गुणवत्ता सीधे पीढ़ी की गुणवत्ता को प्रभावित करती है। यदि रिट्रीवर अप्रासंगिक दस्तावेज़ लौटाता है, तो एलएलएम में सही उत्तर देने के लिए आवश्यक संदर्भ का अभाव होता है और यह गलत जानकारी उत्पन्न कर सकता है। यदि रिट्रीवर प्रासंगिक दस्तावेजों को याद करता है, तो उत्तर अधूरा हो सकता है।

एक कानूनी अनुसंधान सहायक के लिए, प्रभावी पुनर्प्राप्ति का अर्थ है मामले की मिसाल, क़ानून और अनुबंध खंड ढूंढना जो वकील के प्रश्न को संबोधित करते हैं। एलएलएम तब इन स्रोतों को उद्धरणों के साथ एक सुसंगत उत्तर में संश्लेषित करता है।

RAG वर्कलोड के लिए डिज़ाइन स्कीमा

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

अलग दस्तावेज़ और टुकड़े

दो तालिकाओं का उपयोग करें: एक स्रोत दस्तावेज़ों के लिए और एक एम्बेडिंग वाले विखंडों के लिए:

CREATE TABLE source_documents (
    id SERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    source_url TEXT,
    document_type TEXT,
    ingested_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE document_chunks (
    id SERIAL PRIMARY KEY,
    document_id INTEGER REFERENCES source_documents(id) ON DELETE CASCADE,
    chunk_index INTEGER NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536),
    token_count INTEGER,
    start_char INTEGER,
    end_char INTEGER,
    UNIQUE (document_id, chunk_index)
);

यह डिज़ाइन कई लाभ प्रदान करता है:

• लचीली पुनर्प्राप्ति: आप अलग-अलग विखंडों को पुनर्प्राप्त कर सकते हैं या दस्तावेज़ अनुभागों का पुनर्निर्माण कर सकते हैं
• स्रोत ट्रैकिंग: प्रत्येक खंड उद्धरणों के लिए अपने स्रोत से वापस जुड़ता है
• कुशल भंडारण: दस्तावेज़ मेटाडेटा एक बार संग्रहीत किया जाता है, प्रति खंड डुप्लिकेट नहीं किया जाता है
• आसान अपडेट: किसी दस्तावेज़ को बदलने का अर्थ है उसके टुकड़ों को हटाना और फिर से निगलना

फ़िल्टरिंग और संदर्भ के लिए मेटाडेटा जोड़ें

मेटाडेटा शामिल करें जो फ़िल्टरिंग और संदर्भ पुनर्निर्माण में मदद करता है:

CREATE TABLE document_chunks (
    id SERIAL PRIMARY KEY,
    document_id INTEGER REFERENCES source_documents(id) ON DELETE CASCADE,
    chunk_index INTEGER NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536),
    token_count INTEGER,
    section_title TEXT,
    page_number INTEGER,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

अनुभाग शीर्षक और पृष्ठ संख्याएँ उपयोगकर्ताओं को पुनर्प्राप्त जानकारी को सत्यापित करने में मदद करती हैं और एलएलएम को प्रत्येक भाग के संदर्भ को समझने में मदद करती हैं।

RAG क्वेरी पैटर्न के लिए अनुक्रमणिका बनाएं

वेक्टर समानता सूचकांक (HNSW या IVFFlat) तेजी से एम्बेडिंग लुकअप सक्षम करते हैं, जैसा कि इस मॉड्यूल में पहले कवर किया गया था। आरएजी वर्कलोड को बी-ट्री इंडेक्स से भी लाभ होता है जो चंक पुनर्प्राप्ति के लिए अद्वितीय जोड़ों और फ़िल्टर को तेज करता है। जब आप चंक्स पुनर्प्राप्त करते हैं, तो आप अक्सर उद्धरण मेटाडेटा के लिए स्रोत दस्तावेज़ों में वापस शामिल होते हैं और किसी दस्तावेज़ के भीतर चंक स्थिति द्वारा फ़िल्टर या ऑर्डर करते हैं। इन अनुक्रमणिका के बिना, PostgreSQL प्रत्येक पुनर्प्राप्ति क्वेरी के लिए संपूर्ण विखंडन तालिका को स्कैन करता है।

-- B-tree index for document lookups (speeds up JOINs to source_documents)
CREATE INDEX document_chunks_document_id_idx
ON document_chunks (document_id);

-- Composite index for chunk ordering (supports context window queries)
CREATE INDEX document_chunks_doc_chunk_idx
ON document_chunks (document_id, chunk_index);

समग्र सूचकांक संदर्भ-विंडो (document_id, chunk_index) पुनर्प्राप्ति के लिए विशेष रूप से महत्वपूर्ण है, जहां आप आस-पास के संदर्भ प्रदान करने के लिए आसन्न खंड प्राप्त करते हैं। इसके बिना, PostgreSQL को पड़ोसियों को खोजने के लिए दस्तावेज़ के सभी हिस्सों को स्कैन करना होगा।

संदर्भ निर्माण के लिए चंक पुनर्प्राप्ति लागू करें

आरएजी क्वेरी उन हिस्सों को पुनः प्राप्त करता है जो एलएलएम का संदर्भ बन जाते हैं। आपके द्वारा चुना गया पुनर्प्राप्ति पैटर्न उत्तर गुणवत्ता और टोकन दक्षता दोनों को प्रभावित करता है। आपको तीन प्रतिस्पर्धी चिंताओं को संतुलित करने की आवश्यकता है: पर्याप्त प्रासंगिक सामग्री प्राप्त करना, टोकन सीमा के भीतर रहना, और एलएलएम को प्रत्येक भाग को समझने के लिए पर्याप्त संदर्भ प्रदान करना।

सबसे सरल तरीका सीधे शीर्ष-k के सबसे समान हिस्सों को पुनः प्राप्त करता है। यह अच्छी तरह से काम करता है जब आपके टुकड़े स्व-निहित होते हैं और आपके प्रश्न एकल विखंडन से सफाई से मेल खाते हैं। हालाँकि, कानूनी दस्तावेज़, तकनीकी विशिष्टताएँ और कथात्मक सामग्री अक्सर कई पैराग्राफों में अवधारणाओं को फैलाती हैं। एक हिस्सा संदर्भित पाठ को शामिल किए बिना "पूर्वगामी शर्तों" या "जैसा कि ऊपर वर्णित है" का संदर्भ दे सकता है।

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

टोकन सीमाएं एक और बाधा जोड़ती हैं। एलएलएम में निश्चित संदर्भ विंडो होती है, और आपको सिस्टम प्रॉम्प्ट, उपयोगकर्ता प्रश्न और उत्पन्न प्रतिक्रिया के लिए जगह की आवश्यकता होती है। यदि आप प्रत्येक 500 टोकन के औसत से 10 हिस्से प्राप्त करते हैं, तो एलएलएम द्वारा एक शब्द लिखने से पहले आपने 5,000 टोकन का उपभोग किया है। बजट के भीतर रहने के लिए पुनर्प्राप्ति के दौरान संचयी टोकन गणना को ट्रैक करें।

निम्न क्वेरी इन प्रतिरूपों को जोड़ती है। यह अपने पड़ोसियों के साथ सबसे समान हिस्सों को पुनः प्राप्त करता है, संचयी टोकन को ट्रैक करता है, और उद्धरण मेटाडेटा शामिल करता है:

WITH matched_chunks AS (
    -- Find the most similar chunks
    SELECT id, document_id, chunk_index, embedding <=> $1 AS distance
    FROM document_chunks
    ORDER BY embedding <=> $1
    LIMIT 3
),
context_window AS (
    -- Expand to include adjacent chunks for context
    SELECT DISTINCT dc.id, dc.document_id, dc.chunk_index, dc.content,
           dc.token_count, mc.distance
    FROM matched_chunks mc
    JOIN document_chunks dc ON dc.document_id = mc.document_id
        AND dc.chunk_index BETWEEN mc.chunk_index - 1 AND mc.chunk_index + 1
),
token_limited AS (
    -- Track cumulative tokens to respect LLM context limits
    SELECT cw.*, sd.title AS source_title, sd.source_url,
           SUM(cw.token_count) OVER (ORDER BY cw.distance, cw.chunk_index) AS cumulative_tokens
    FROM context_window cw
    JOIN source_documents sd ON cw.document_id = sd.id
)
SELECT id, content, source_title, source_url, distance
FROM token_limited
WHERE cumulative_tokens <= 3000
ORDER BY distance, chunk_index;

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

दस्तावेज़ अंतर्ग्रहण पाइपलाइनों को संभालें

नए दस्तावेज़ों को खोजने योग्य होने से पहले उन्हें संसाधित किया जाना चाहिए. अंतर्ग्रहण पाइपलाइन दस्तावेज़ों को टुकड़ों में विभाजित करती है, एम्बेडिंग उत्पन्न करती है, और सब कुछ PostgreSQL में संग्रहीत करती है।

आप दस्तावेज़ों को कैसे विभाजित करते हैं, यह सीधे पुनर्प्राप्ति गुणवत्ता को प्रभावित करता है। सही चंकिंग रणनीति आपकी सामग्री संरचना और क्वेरी पैटर्न पर निर्भर करती है:

• निश्चित आकार के टुकड़े: प्रत्येक N वर्ण या टोकन को विभाजित करें। यह दृष्टिकोण लागू करने के लिए सरल है और पूर्वानुमानित टोकन गणना का उत्पादन करता है, लेकिन यह वाक्यों या पैराग्राफ को मध्य-विचार में काट सकता है। जब आपकी सामग्री में स्पष्ट संरचनात्मक सीमाओं का अभाव हो या जब आपको टोकन बजट योजना के लिए लगातार चंक आकार की आवश्यकता हो, तो निश्चित आकार के चंकिंग का उपयोग करें।

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

• ओवरलैपिंग विखंड: सीमाओं पर संदर्भ को संरक्षित करने के लिए आसन्न खंडों से पाठ शामिल करें। उदाहरण के लिए, 1,000-वर्ण खंडों के बीच 200-वर्ण ओवरलैप यह सुनिश्चित करता है कि खंड सीमाओं तक फैली अवधारणाएं कम से कम एक पूर्ण खंड में दिखाई दें। ओवरलैपिंग का उपयोग तब करें जब आपके प्रश्न खंड सीमाओं के पास सामग्री से मेल खा सकते हैं।

कानूनी अनुसंधान सहायक परिदृश्य के लिए, पैराग्राफ या अनुभाग सीमाओं पर सिमेंटिक चंकिंग अच्छी तरह से काम करता है क्योंकि कानूनी पाठ असतत खंडों और तर्कों में व्यवस्थित होता है। प्रत्येक हिस्सा एक पूर्ण कानूनी अवधारणा का प्रतिनिधित्व करता है जो एलएलएम के संदर्भ में अकेले खड़ा हो सकता है।

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

दस्तावेज़ अद्यतनों के लिए निर्णय की आवश्यकता होती है: क्या आप दस्तावेज़ों का संस्करण बनाते हैं या उन्हें बदलते हैं? अधिकांश आरएजी अनुप्रयोगों के लिए, प्रतिस्थापन सरल है। मौजूदा विखंडू हटाएं ( ON DELETE CASCADE जब आप स्रोत दस्तावेज़ को हटाते हैं तो बाधा इसे स्वचालित रूप से संभालती है), फिर अद्यतन की गई सामग्री को फिर से निगलना चाहिए। यह दृष्टिकोण सुनिश्चित करता है कि आपके पुनर्प्राप्ति परिणाम हमेशा वर्तमान दस्तावेज़ स्थिति को दर्शाते हैं। यदि आपको संस्करण इतिहास की आवश्यकता है, तो एक version कॉलम source_documents जोड़ें और पुराने हिस्सों को नए के साथ रखें, क्वेरी समय पर संस्करण द्वारा फ़िल्टर करें।

HNSW इंडेक्स पुनर्निर्माण के बिना विलोपन को इनायत से संभालते हैं। IVFFlat इंडेक्स महत्वपूर्ण परिवर्तनों के बाद विखंडन जमा कर सकते हैं, क्वेरी प्रदर्शन को बनाए रखने के लिए समय-समय पर पुनर्निर्माण की आवश्यकता होती है।

उद्धरणों के साथ पुनर्प्राप्ति लागू करें

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

प्रभावी उद्धरणों के लिए केवल खंड सामग्री से अधिक की आवश्यकता होती है। आपके पुनर्प्राप्ति प्रश्नों को उपलब्ध होने पर स्रोत दस्तावेज़ शीर्षक, URL या दस्तावेज़ ID, अनुभाग शीर्षक और पृष्ठ संख्या वापस करनी चाहिए। यह मेटाडेटा आपके एप्लिकेशन प्रारूप उद्धरण देता है जिसे उपयोगकर्ता वास्तव में स्रोत पर वापस ले जा सकते हैं। दूरी स्कोर भी मदद करता है: आप उपयोगकर्ता सत्यापन के लिए कम-विश्वास वाले मैचों को फ़्लैग करते समय उच्च-आत्मविश्वास वाले उद्धरण प्रमुखता से प्रदर्शित कर सकते हैं।

एक आम चुनौती तब उत्पन्न होती है जब एक ही दस्तावेज़ के कई हिस्से एक क्वेरी से मेल खाते हैं। यदि "रोजगार अनुबंध टेम्पलेट" के 12, 15 और 18 भाग आपके शीर्ष परिणामों में दिखाई देते हैं, तो उन्हें तीन अलग-अलग उद्धरणों के रूप में सूचीबद्ध करना प्रतिक्रिया को अव्यवस्थित करता है। इसके बजाय, स्रोत दस्तावेज़ द्वारा समूहों को समूहित करें और उन्हें कई प्रासंगिक अंशों के साथ एकल उद्धरण के रूप में प्रस्तुत करें। यह दृष्टिकोण स्वच्छ आउटपुट उत्पन्न करता है और उपयोगकर्ताओं को प्रत्येक स्रोत से पूर्ण संदर्भ देखने में मदद करता है।

निम्न क्वेरी दस्तावेज़-समूहीकृत पुनर्प्राप्ति प्रदर्शित करता है। यह प्रत्येक दस्तावेज़ के भीतर टुकड़ों को रैंक करता है, संदर्भ को भारी करने से बचने के लिए प्रति दस्तावेज़ तीन हिस्सों तक सीमित करता है, और क्लीनर उद्धरण स्वरूपण के लिए सामग्री को एकत्रित करता है:

WITH ranked_chunks AS (
    SELECT
        dc.*,
        sd.title AS document_title,
        sd.source_url,
        dc.embedding <=> $1 AS distance,
        ROW_NUMBER() OVER (PARTITION BY dc.document_id ORDER BY dc.embedding <=> $1) AS rank_in_doc
    FROM document_chunks dc
    JOIN source_documents sd ON dc.document_id = sd.id
    WHERE dc.embedding <=> $1 < 0.5
)
SELECT
    document_id,
    document_title,
    source_url,
    array_agg(content ORDER BY chunk_index) AS chunks,
    MIN(distance) AS best_distance
FROM ranked_chunks
WHERE rank_in_doc <= 3
GROUP BY document_id, document_title, source_url
ORDER BY best_distance
LIMIT 5;

आपका एप्लिकेशन तब इसे उपयोगकर्ता के अनुकूल उद्धरणों में प्रारूपित कर सकता है:

"नियोक्ता 30 दिनों के नोटिस के साथ इस समझौते को समाप्त कर सकता है। - रोजगार समझौता टेम्पलेट, धारा 4.2, पृष्ठ 3

पुनर्प्राप्ति गुणवत्ता का मूल्यांकन और सुधार करें

पुनर्प्राप्ति गुणवत्ता RAG प्रभावशीलता निर्धारित करती है। खराब पुनर्प्राप्ति गरीब पीढ़ी की ओर ले जाती है, भले ही आपका एलएलएम कितना भी सक्षम क्यों न हो। यदि रिट्रीवर अप्रासंगिक विखंडू लौटाता है, तो एलएलएम बेकार पाठ पर संदर्भ विंडो क्षमता बर्बाद कर देता है। यदि रिट्रीवर प्रासंगिक हिस्सों को याद करता है, तो एलएलएम के पास सही उत्तर देने के लिए आवश्यक जानकारी का अभाव है। पीढ़ी की गुणवत्ता से अलग पुनर्प्राप्ति गुणवत्ता को मापने से आपको यह निदान करने में मदद मिलती है कि आपकी आरएजी पाइपलाइन में सुधार की आवश्यकता कहां है।

तीन मेट्रिक्स पुनर्प्राप्ति प्रदर्शन के विभिन्न पहलुओं को पकड़ते हैं:

• शुद्धता: पुनर्प्राप्त विखंडू का अंश जो वास्तव में प्रासंगिक हैं। कम परिशुद्धता का मतलब है कि एलएलएम को अप्रासंगिक संदर्भ प्राप्त होता है जो इसे भ्रमित कर सकता है या गलत जानकारी उत्पन्न करने का कारण बन सकता है। दूरी की सीमा को कसकर या पुनर्प्राप्त विखंडू की संख्या को कम करके सटीकता में सुधार करें।

• याद करना: प्रासंगिक विखंडों का अंश जो पुनर्प्राप्त किए जाते हैं। कम रिकॉल का मतलब है कि एलएलएम महत्वपूर्ण जानकारी को याद करता है, जिससे अपूर्ण या गलत उत्तर मिलते हैं। दूरी थ्रेसहोल्ड को ढीला करके, पुनर्प्राप्त चंक काउंट को बढ़ाकर, या इंडेक्स पैरामीटर को ef_searchसमायोजित करके रिकॉल में सुधार करें।

• मीन रेसिप्रोकल रैंक (MRR): रैंक सूची में पहला प्रासंगिक परिणाम कितना ऊंचा दिखाई देता है। एमआरआर मायने रखता है क्योंकि एलएलएम पहले के संदर्भ को अधिक भारी वजन देता है, और उद्धरणों को स्कैन करने वाले उपयोगकर्ता पहले शीर्ष परिणामों को नोटिस करते हैं। अपने एम्बेडिंग मॉडल या क्वेरी प्रीप्रोसेसिंग को परिष्कृत करके MRR में सुधार करें।

इन मेट्रिक्स को मापने के लिए, आपको एक मूल्यांकन डेटासेट की आवश्यकता होती है: प्रतिनिधि प्रश्नों का एक सेट जिसे मानवीय निर्णयों के साथ जोड़ा जाता है कि कौन से हिस्से प्रासंगिक हैं। इस डेटासेट को बनाने के लिए पहले से प्रयास की आवश्यकता होती है—किसी को नमूना क्वेरीज़ चलानी चाहिए और परिणामों को लेबल करना चाहिए—लेकिन यह आपको अनुमान लगाने के बजाय डेटा-संचालित सुधार करने देता है। 20-50 प्रश्नों से प्रारंभ करें जो आपके उपयोगकर्ताओं द्वारा वास्तव में पूछे जाने वाले प्रश्नों के प्रकार का प्रतिनिधित्व करते हैं। प्रत्येक क्वेरी के लिए, शीर्ष 10-20 हिस्सों को पुनः प्राप्त करें और एक डोमेन विशेषज्ञ को सरल पैमाने पर उनकी प्रासंगिकता का मूल्यांकन करने के लिए कहें (अप्रासंगिक, कुछ हद तक प्रासंगिक, अत्यधिक प्रासंगिक)।

इस मूल्यांकन के साथ, आप अलग-अलग कटऑफ़ (precision@5, recall@10) पर सटीकता और रिकॉल को माप सकते हैं और ट्रैक कर सकते हैं कि आपकी पाइपलाइन में परिवर्तन इन मेट्रिक्स को कैसे प्रभावित करते हैं। मूल्यांकन सेट के विरुद्ध अपने पुनर्प्राप्ति प्रश्नों को चलाएँ, परिणामों की तुलना मानवीय निर्णयों से करें और मेट्रिक्स की गणना करें। अधिकांश टीमें इसे एक स्कोरिंग स्क्रिप्ट में स्वचालित करती हैं जो तब चलती है जब भी वे चंकिंग रणनीतियों, एम्बेडिंग मॉडल या इंडेक्स मापदंडों को बदलती हैं।

जब मेट्रिक्स लक्ष्य से नीचे आते हैं, तो सटीक-रिकॉल ट्रेड-ऑफ को प्रभावित करने वाले मापदंडों के साथ व्यवस्थित रूप से प्रयोग करें:

• चंक आकार: छोटे हिस्से अधिक केंद्रित सामग्री को वापस करके सटीकता में सुधार करते हैं, लेकिन कई हिस्सों में प्रासंगिक जानकारी को खंडित करके याद को नुकसान पहुंचा सकते हैं। बड़े हिस्से याद रखने में सुधार करते हैं लेकिन प्रासंगिकता को कम करते हैं।

• चंक ओवरलैप: अधिक ओवरलैप सीमाओं के पार संदर्भ को संरक्षित करता है, जिससे खंडित किनारों के पास सामग्री से मेल खाने वाले प्रश्नों की मदद मिलती है। हालाँकि, ओवरलैप से भंडारण आवश्यकताएँ बढ़ जाती हैं और अनावश्यक सामग्री वापस आ सकती है।

• एम्बेडिंग मॉडल: विभिन्न मॉडल अलग-अलग शब्दार्थ संबंधों को पकड़ते हैं। कानूनी पाठ पर प्रशिक्षित एक मॉडल कानूनी अनुसंधान के लिए एक सामान्य प्रयोजन मॉडल से बेहतर प्रदर्शन कर सकता है। डोमेन-विशिष्ट या फाइन-ट्यून किए गए मॉडल पर विचार करें यदि सामान्य मॉडल खराब प्रदर्शन करते हैं।

• सूचकांक पैरामीटर: उच्च ef_search (HNSW) या probes (IVFFlat) क्वेरी विलंबता की कीमत पर अधिक उम्मीदवारों को खोजकर याद करने में सुधार करता है। डिफ़ॉल्ट मापदंडों से प्रारंभ करें और केवल तभी बढ़ाएँ जब रिकॉल अपर्याप्त हो।

• दूरी की सीमा: सख्त थ्रेसहोल्ड सीमांत मैचों को छोड़कर सटीकता में सुधार करते हैं। ढीली थ्रेसहोल्ड अधिक उम्मीदवारों को शामिल करके याद करने में सुधार करती है। अपने मूल्यांकन डेटासेट का उपयोग करके वह सीमा ढूंढें जो आपके उपयोग के मामले के लिए दोनों मीट्रिक को संतुलित करती है.