मैंने रीडर में «शून्य मतिभ्रम» Q&A कैसे बनाया

यह लेख हमारे AI रीडर में शून्य-मतिभ्रम Q&A की इंजीनियरिंग साझा करता है: उत्तर सख्ती से आपके खुले पुस्तक के पाठ पर आधारित हैं, और मुख्य दावों को एक क्लिक में सटीक अंश तक ट्रेस किया जा सकता है। यदि आप AI पढ़ना, दस्तावेज़ Q&A या RAG-शैली ऐप बना रहे हैं, तो तीन पुनरावृत्तियों के सबक और अंतिम आर्किटेक्चर उपयोगी हों।

I. तीन चरणों में विकास

शून्य-मतिभ्रम Q&A पहले दिन से पूर्ण नहीं था। यह लागत, विलंबता और सटीकता के तनाव में विकसित हुआ। नीचे तीन चरणों का कालानुक्रमिक दृश्य—वर्तमान आर्किटेक्चर क्यों ऐसा दिखता है, इसके लिए संदर्भ।

flowchart LR
    P1[चरण 1: पूर्ण पाठ context में] --> P2[चरण 2: LLM मुख्य वाक्य निकालना]
    P2 --> P3[चरण 3: Segment index + Tool retrieval]
    P1 -.->|धीमा, महँगा, लंबी पुस्तकों पर गलत| X1[त्याग]
    P2 -.->|विवरण खोना, अभी भी धीमा| X2[त्याग]
    P3 -->|वर्तमान| OK[शून्य मतिभ्रम + ट्रेस योग्य]

चरण 1: पूरी किताब context में डालना (सबसे सरल—और सबसे पहले टूटा)

दृष्टिकोण: उपयोगकर्ता किताब खोलकर प्रश्न पूछे तो सारा निकाला गया मुख्य पाठ System Prompt या उपयोगकर्ता संदेश में रखें और चैट मॉडल से उत्तर लें। पुस्तक लगभग 4 लाख वर्ण से अधिक हो तो कठोर काट—केवल शुरुआत रहती है; बाद के अध्याय मॉडल के लिए अदृश्य।

फायदे:

• बहुत कम कार्यान्वयन लागत; लगभग कोई पूर्व-प्रसंस्करण नहीं;
• छोटी पुस्तकों और सरल दस्तावेज़ों पर ठीक—मॉडल ने वास्तव में «पूरी किताब देखी»;
• सरल UX: पूछें और उत्तर, «विश्लेषण की प्रतीक्षा» स्थिति नहीं।

नुकसान (जल्दी अस्वीकार्य):

• धीमे उत्तर: हर प्रश्न पर विशाल payload फिर भेजा जाता है; पहले token तक का समय और कुल विलंबता पुस्तक लंबाई के साथ बढ़ती है;
• उच्च token लागत: हर प्रश्न पर पूरी किताब का input भुगतान;
• लंबी पुस्तकें बुरी तरह विकृत: 4 लाख वर्ण के बाद दूसरा आधा, परिशिष्ट, निष्कर्ष मानो नहीं—और UI अक्सर स्पष्ट नहीं बताता कि काट हुआ;
• शून्य retrieval granularity: मॉडल को लाखों वर्णों में «सूई ढूँढनी»—विवरण छूटना आसान, आधारहीन लेकिन विश्वसनीय लगने वाले सार आसान—पढ़ने वाले ऐप को बचना चाहिए।

चरण 1 MVP के लिए ठीक, उत्पाद-स्तर के लिए नहीं।

चरण 2: हल्का LLM मुख्य वाक्य निकाले (context संकुचित—पर बहुत अधिक)

दृष्टिकोण: Q&A से पहले (या पहली बार खोलने पर) सस्ता मॉडल मुख्य पाठ पर: Spine अध्याय से विभाजित (या पूरी पुस्तक chunk), मुख्य वाक्य निकालें, [fफ़ाइल-शुरू-अंत] जैसे स्थिति टैग रखें, फिर संक्षिप्त context में जोड़कर बाद के Q&A के लिए।

सामान्य pipeline: Extract → Cache → Chat. एक बार निकालें (offline या माँग पर), «मुख्य वाक्य बंडल» संग्रहित, हर प्रश्न पर पुन: उपयोग—कई दस्तावेज़ Q&A प्रोटोटाइप जैसा।

फायदे:

• हर प्रश्न बहुत कम पाठ भेजता है; प्रति अनुरोध token चरण 1 से कम;
• पूर्व-प्रसंस्करण cache हो सकता है; उसी पुस्तक पर हर प्रश्न पर पुन: निकालना नहीं;
• स्थिति टैग उद्धरण की नींव।

नुकसान (लंबी पुस्तकों पर अभी भी विफल):

• भारी विवरण हानि: «मुख्य वाक्य» मॉडल चुनता है; सीमक, प्रतिवाद, तर्क श्रृंखला अक्सर गिरती है—उत्तर «सही पर एकतरफा»;
• लंबी पुस्तकों पर context अभी भी बड़ा: बड़े ग्रंथों के मुख्य वाक्य बंडल भी भारी—विलंबता और लागत कम हुई, हल नहीं;
• दोहरा LLM त्रुटि: निष्कर्षण छूट सकता है; Q&A अंश गलत पढ़ सकता है—त्रुटियाँ जुड़ती हैं;
• स्थिर context: उपयोगकर्ता एक अध्याय या पूरी संरचना पूछे, मॉडल को हमेशा वही पूर्व-निकाला blob—प्रश्न से गतिशील संकुचन नहीं।

सबक: मुद्दा «संकुचित करें या नहीं» नहीं, «संकुचन माँग पर है और क्या स्रोत पाठ पर लौट सकते हैं»।

चरण 3: Segment index + Tool retrieval माँग पर + स्रोत पाठ वापस (वर्तमान)

दृष्टिकोण: PageIndex से प्रेरित। चरण 2 की तुलना में तीन मुख्य बदलाव:

1. पूर्व-प्रसंस्करण संरचित index (TOC-स्तर सार + सटीक वर्ण span), सीधे Q&A context के रूप में अंश नहीं;
2. हर प्रश्न Tool Calling से माँग पर retrieval, फिर स्थिति टैग के साथ स्रोत पाठ खींचकर उत्तर;
3. System Prompt + frontend उद्धरण प्रारूप लागू, क्लिक से कूद और रीडर में हाइलाइट।

तीन चरण तुलना:

चरण 3 पर क्यों रुके: पढ़ने में शून्य मतिभ्रम «मॉडल को ज़्यादा से ज़्यादा पाठ दिखाना» नहीं, «उत्तर से पहले प्रश्न के लिए स्रोत साक्ष्य लाना»। चरण 1–2 ने context आकार पर लड़ाई की; चरण 3 pipeline विभाजित: index (पूर्व-प्रसंस्करण) → retrieve (Tool) → साक्ष्य (स्रोत) → उत्तर (बंधित जनरेशन)—सटीकता, लागत, ट्रेस योग्यता संतुलन।

नीचे चरण 3 विवरण।

II. समस्या परिभाषा: पुस्तक Q&A में मतिभ्रम सामान्य चैट से अधिक हानिकारक

सामान्य चैटबॉट में उपयोगकर्ता कभी-कभार त्रुटि क्षमा करते हैं। पुस्तक Q&A में लागत अधिक:

• वे पूछते हैं यह पुस्तक क्या कहती है—मॉडल की parametric memory नहीं;
• विश्वसनीय लगने वाला «पुस्तक का विचार» नोट, उद्धरण, पुन: साझा करने में भ्रमित कर सकता है;
• स्रोत के बिना सत्यापन नहीं—विश्वास बनाना कठिन।

अतः «शून्य मतिभ्रम» तीन कार्यान्वयन योग्य नियम:

1. पुस्तक प्रश्न पहले पुस्तक से पूछें: खुली पुस्तक से संबंधित कुछ भी retrieval (Tool) से गुजरना चाहिए;
2. उत्तर ट्रेस योग्य: मुख्य दावों में स्थिति टैग जिन्हें UI पार्स और कूद सके;
3. न मिले तो कहें: पुस्तक में न हो तो कहें—सामान्य ज्ञान को «पुस्तक कहती है» न बनाएँ।

शेष चरण 3 डेटा प्रवाह और नियम कार्यान्वयन।

III. आर्किटेक्चर: पूर्व-प्रसंस्करण → Tool retrieval → बंधित जनरेशन → क्लिक योग्य उद्धरण

flowchart TB
    subgraph prep [Offline / पहली बार पूर्व-प्रसंस्करण]
        A[TOC या लंबाई से पुस्तक विभाजित] --> B[LLM Segment सार]
        B --> C[स्थानीय Segment cache persist]
    end

    subgraph ask [उपयोगकर्ता प्रश्न]
        D[उपयोगकर्ता input] --> E{Segment cache है?}
        E -->|नहीं| F[पूर्ण पाठ निकालें / पूर्व-प्रसंस्करण पूछें]
        F --> prep
        E -->|हाँ| G[Tool Calling पंजीकृत]
    end

    subgraph retrieve [Tool retrieval]
        G --> H{प्रश्न प्रकार}
        H -->|अवलोकन / समीक्षा| I[get_full_book_segment_summaries]
        H -->|तथ्य / व्यक्ति / अध्याय| J[get_related_segment_summaries]
        J --> K[LLM सार कैटलॉग से Segment ID चुनता]
        K --> L[span से स्रोत + स्थिति टैग]
        I --> M[सभी Segment सार जोड़ें]
    end

    subgraph answer [जनरेट और प्रदर्शन]
        L --> N[Tool परिणाम मॉडल को]
        M --> N
        N --> O[System Prompt उद्धरण नियम]
        O --> P[स्ट्रीम उत्तर + स्थिति फ़ुटनोट]
        P --> Q[क्लिक योग्य फ़ुटनोट render]
        Q --> R[क्लिक → पूर्वावलोकन → कूद और हाइलाइट]
    end

मुख्य विचार: मॉडल को «स्मृति से उत्तर» न दें—«साक्ष्य इकट्ठा करें, उत्तर दें, स्रोत चिह्नित करें»।

IV. पूर्व-प्रसंस्करण: पूरी पुस्तक को खोज योग्य Segment index बनाना

यदि हर प्रश्न चरण 1 पूर्ण-पुस्तक context उपयोग करे, लंबी पुस्तकें token बजट फोड़ दें। चरण 3: किसी पुस्तक पर पहला AI चैट पर पृष्ठभूमि में Segment सार कार्य—TOC या पाठ लंबाई से Segment में विभाजित, प्रत्येक का सार, स्थानीय IndexedDB में persist।

प्रत्येक Segment में सार और मुख्य पाठ में भौतिक स्थिति:

विभाजन सटीकता और लागत संतुलित: TOC नोड का मुख्य पाठ ~20KB से कम हो तो केवल वह नोड; sibling 15–20KB बैच में मिल सकते हैं LLM से पहले; असंरचित लंबे ब्लॉक ~30–40k वर्ण अंतराल में।

सार System Prompt inline स्थिति टैग ([fसंख्या-संख्या-संख्या]) माँगता है ताकि Tool-स्रोत Spine offset से मेल खाए। मुख्य बाधा:

यदि सार किसी अंश से संबंधित हो, अंत में स्थिति टैग [fसंख्या-संख्या-संख्या] रखें (जैसे [f1-90-109])।
टैग परमाणु हैं—कोई वर्ण या अंक न बदलें, मिलाएँ या छोड़ें।

पूर्व-प्रसंस्करण के बाद Q&A संरचित Segment index पर निर्भर, पूर्ण-पुस्तक context नहीं—लंबी पुस्तकों पर शून्य मतिभ्रम की इंजीनियरिंग पूर्वापेक्षा।

V. स्थिति टैग प्रणाली: पाठ में «कहाँ» एन्कोड

शून्य मतिभ्रम को स्रोत से सामग्री और मशीन-पार्स, UI-कूद योग्य उत्पत्ति चाहिए। हम inline टैग:

[f{fileIndex}-{startChar}-{endChar}]

उदाहरण: [f5-123-165] = Spine फ़ाइल 5 (0-आधारित), वर्ण 123–165।

5.1 टैग मुख्य पाठ में कैसे लिखे जाते हैं

निष्कर्षण परत Segment अंत में [f{fileIndex}-{start}-{end}] जोड़ती है:

const position = `[f${fileIndex}-${absOffset}-${absOffset + segment.length}]`;
fileLines.push(segment.text.trim() + position);

पूर्व-प्रसंस्करण सार या Tool अंश, स्थिति Spine वर्ण offset से मेल—मॉडल अनुमानित पृष्ठ संख्या नहीं।

5.2 मॉडल आउटपुट पर बाधाएँ

System Prompt में Position Citation Rules—पाँच मुख्य बिंदु:

1. मानक प्रारूप: [f_fileIndex-startChar-endChar] अनिवार्य; तीन संख्यात्मक भाग;
2. केवल वर्तमान स्रोत से कॉपी: फ़ुटनोट इस turn के system/user या Tool से शब्दशः;
3. निर्माण नहीं: स्थिति गणना, संपादन, आविष्कार नहीं;
4. छोड़ना प्राथमिक: context में वैध टैग नहीं तो सामान्य उत्तर—कोई स्थिति टैग नहीं;
5. दावे के साथ inline: टैग प्रासंगिक वाक्य के बाद; अंत में उद्धरण सूची नहीं।

UI कभी-कभार दो-भाग अवैध टैग (जैसे [f1-293]) render से पहले फ़िल्टर करता है।

VI. Tool Calling: पहले retrieve, फिर उत्तर

जब चैट पुस्तक से बँधा (resourceId मौजूद, chatType === 'chat'), हर जनरेशन से पहले दो Tools executors के साथ—मानक OpenAI function calling लूप।

6.1 get_related_segment_summaries — लक्षित Segment खोज

के लिए: अवधारणा, पात्र, कथानक, अध्याय विवरण—स्पष्ट retrieval इरादा।

प्रवाह:

1. मॉडल उपयोगकर्ता शब्दों को पुस्तक में संभावित शब्दों में बदलता है (System Prompt में «Optimize Search Queries»);
2. question के साथ Tool;
3. सभी Segment सार token बजट से बैच (~30k tokens प्रति बैच, अधिकतम 5);
4. प्रत्येक बैच: अलग LLM अनुरोध { id, title, summary } से प्रासंगिक Segment ID (अधिकतम 5), JSON जैसे {"Thinking":"...","answer":["1","3"]};
5. चुने Segment के लिए Spine से टैग युक्त स्रोत पाठ—सार नहीं—Tool परिणाम।

मुख्य डिज़ाइन: Tool स्रोत लौटाता है, सार नहीं। मॉडल वास्तविक अनुच्छेदों से inline [f…] के साथ उत्तर, «सार → पुन: सार» विचलन से बचाव।

6.2 get_full_book_segment_summaries — पूर्ण-पुस्तक अवलोकन

के लिए: «पुस्तक सारांश», «समीक्षा», «समग्र संरचना/विषय»—वैश्विक दृश्य।

सभी Segment summary पढ़ने क्रम में जोड़ें—केवल chunk प्रासंगिकता से मुख्य अध्याय न छूटें।

6.3 System Prompt: पुस्तक पहले, tools पहले

बँधी पुस्तक पर Core Principles for Reading Assistant:

1. Book First, Tool First
   - पुस्तक से संबंधित कोई भी प्रश्न पहले tools;
   - उत्तर मुख्यतः retrieval पर—बिना retrieval «पुस्तक सामग्री» न बनाएँ।

2. General Knowledge as Fallback Only
   - केवल: आम बातचीत / उपयोगकर्ता स्पष्ट रूप से पुस्तक छोड़े / tools खाली;
   - पुस्तक में न हो तो «इस पुस्तक में उल्लेख नहीं» सामान्य ज्ञान से पहले।

3. Direct Style
   - सीधे मुद्दे पर—«प्रदत्त सामग्री के आधार पर…» जैसी भराव नहीं।

जनरेशन tool लूप: tool_calls → execute → role: tool → अंतिम पाठ तक। tools सक्षम पर thinking चैनल बंद, protocol संघर्ष से बचाव।

VII. Frontend ट्रेस: फ़ुटनोट से हाइलाइट

मॉडल [f5-123-165] कच्चा नहीं दिखता; render परत क्लिक योग्य उद्धरण।

7.1 फ़ुटनोट render

टैग Markdown लिंक [1]([f5-123-165]) में, क्रमांकित फ़ुटनोट; समान स्थिति dedupe।

7.2 क्लिक इंटरैक्शन

1. पहला क्लिक: [f…] पार्स → fileIndex + offsets → Spine पाठ → पूर्वावलोकन (वैकल्पिक TOC शीर्षक);
2. वही फ़ुटनोट फिर: पूर्वावलोकन बंद;
3. कूद पुष्टि: रीडर दृश्य, वर्ण अंतराल हाइलाइट।

मॉडल टैग से उपयोगकर्ता-दृश्य स्रोत तक श्रृंखला कभी दूसरे LLM से नहीं—नियतात्मक, पुनरुत्पादनीय।

VIII. सीमा मामले और ईमानदार अवनति

शून्य मतिभ्रम ≠ «हमेशा उत्तर»—साक्ष्य नहीं तो निर्माण नहीं:

IX. डिज़ाइन समझौता: «vector RAG» क्यों नहीं?

दस्तावेज़ Q&A सहकर्मी पूछते: retrieval-augmented generation हो तो Embedding + vector DB Top-K क्यों नहीं?

हम RAG कर रहे हैं—जनरेट से पहले retrieve। अंतर: समुदाय में «RAG» अक्सर vector समानता; हमारा चरण 3 Segment index + Tool माँग पर स्रोत pull—जानबूझकर vector परत नहीं। नीचे आर्किटेक्चर कारण, vector RAG का मूल्य नकार नहीं।

दायरा: «कोई retrieval नहीं» नहीं, «vector retrieval नहीं»

• व्यापक RAG: retrieve → generate → हम करते हैं;
• Vector RAG: embedding समानता से recall → इस संस्करण में नहीं।

पूर्व-प्रसंस्करण Segment सार index; मॉडल Tools से Segment चुनता, स्रोत पाठ पाता है। Retrieval बिना अलग embedding मॉडल और vector index रख-रखाव।

कारण 1: कस्टम LLM providers—एकीकरण सतह छोटी

उपयोगकर्ता अपनी API keys, कस्टम base URL, या स्थानीय Ollama—चैट मॉडल उनकी पसंद।

सामान्य vector RAG एकीकरण विस्तार:

• चैट मॉडल के अलावा अक्सर embedding मॉडल (दूसरा नाम, कभी दूसरा endpoint);
• स्थानीय Ollama को अलग embedding और आयाम/API अनुकूलता;
• अधिक विफलता: चैट ठीक पर खाली retrieval—embedding, index, आयाम असंगति; एक provider end-to-end से कठिन debug।

यहाँ Segment चयन और उत्तर एक provider config साझा—«चैट A, index B» नहीं। प्लग योग्य LLM ऐप के लिए अक्सर कुछ recall अंक से महत्वपूर्ण।

कारण 2: Embeddings index से बँधे—provider बदलना महँगा

Vector RAG में वेक्टर सार्वभौमिक मध्य प्रारूप नहीं—एक embedding मॉडल के निर्देशांक। A से index, B से query: समानता तुलनीय नहीं—अक्सर पूर्ण re-embedding, आयाम (768 / 1024 / 1536 …) storage schema लॉक।

चरण 3 संरचित सार + वर्ण span persist, वेक्टर नहीं; चैट मॉडल बदलने पर index पुनर्निर्माण नहीं; साक्ष्य श्रृंखला (स्रोत स्थिति) वही—«कभी भी अलग LLM आज़माएँ» से मेल।

कारण 3: TOC-भारी लंबे दस्तावेज़ों पर संरचित रूटिंग अक्सर पर्याप्त

ई-पुस्तक, PDF में अध्याय संरचना; पूर्व-प्रसंस्करण Segment शीर्षक + सार। «अध्याय X क्या कहता है» या «पुस्तक Y कैसे परिभाषित» के लिए कैटलॉग से चुनकर स्रोत खींचना व्यवहार में स्थिर; Tool [f…] स्रोत लौटाता, शून्य मतिभ्रम वर्ण span पर।

वेक्टर धुंधली अर्थ, बहुभाषा, लंबे अंतराल literal mismatch में मदद; TOC + पूर्व-प्रसंस्करण + मजबूत ट्रेस रीडर में Tool + स्रोत वापसी + उद्धरण नियम में ROI अक्सर अधिक।

भविष्य: संकर recall, पुनर्लेखन नहीं

vector मोटा recall (embedding केवल Top-N अध्याय उम्मीदवार) जोड़ सकते हैं, अंत Segment चुनें → स्रोत → क्लिक ट्रेस—शून्य-मतिभ्रम नियम वही। यदि जोड़ें: embedding वैकल्पिक, मॉडल बदलने पर स्पष्ट re-index संकेत—मूक गलत retrieval नहीं।

तब तक: कोई भी OpenAI-संगत चैट API; चैट मॉडल बदलने पर स्थानीय index पुनर्निर्माण नहीं।

X. सारांश

«शून्य मतिभ्रम» मॉडल कभी नहीं गलती नहीं—आउटपुट साक्ष्य श्रृंखला से बँधा: retrieval नहीं → पुस्तक सामग्री का दिखावा नहीं; retrieval है → सत्यापन योग्य स्रोत स्थिति।

यदि आप AI पढ़ना या दस्तावेज़ Q&A बनाते हैं, पूर्ण dump → मुख्य वाक्य → Tool-first माँग पर पथ और inline स्थिति टैग + स्रोत वापसी संदर्भ कार्यान्वयन हो सकता है।

ये Foxycape AI रीडर निर्माण के सबक हैं—केवल संदर्भ। रीडर डाउनलोड पृष्ठ पर आज़माएँ।