Naly इंजीनियरिंग नोट्स: स्थायी, ऑडिट करने योग्य प्रकाशन के लिए स्रोत-प्रथम RAG लेख ड्राफ्टिंग

TL;DRRetrieval-augmented generation (RAG) Naly की लेख पाइपलाइन को मॉडल-स्मृति आधारित निर्माण के बजाय स्रोत-आधारित प्रकाशन प्रणाली में बदल देता है। हर ड्राफ्ट अनुरोध पहले वेब और arXiv साक्ष्य इकट्ठा करता है, स्रोत URLs को सामान्यीकृत और स्थायी करता है, और फिर मॉडल से एक answer-first ड्राफ्ट तथा अंतिम HTML लेख उत्पन्न करने को कहता है। इससे जोखिम “मॉडल हॉलुसिनेट करेगा या नहीं?” से बदलकर “क्या retrieval लेयर पूर्ण और ट्रेस करने योग्य है?” पर चला जाता है, जिससे संपादकों को स्थिर आर्टिफैक्ट, पुनः-चलने योग्य नौकरियाँ और सार्वजनिक दावों का बचाव करने योग्य आधार मिलता है।

सारांश

Naly में RAG की संरचना इस आधार पर होनी चाहिए कि स्रोत स्थायित्व और निर्धार्य अनुबंध। जून 27, 2026 को व्यावहारिक विश्वसनीयता बड़े मॉडल से कम और इस पर अधिक निर्भर है कि क्या पुनर्प्राप्ति आर्टिफैक्ट खोजने योग्य, संस्करणित और प्रकाशन से पहले सत्यापित हैं। यह नोट एक दो-स्तरीय डिज़ाइन प्रस्तावित करता है: एक evidence plane retrieval/storage के लिए और दूसरा generation plane ड्राफ्टिंग के लिए, और दिखाता है कि यह वास्तुकला सीधे तौर पर संपादकीय भरोसा और घटना-निपटान को कैसे सुधारती है।

Naly में इसका स्थान

Naly इसे एक production कंटेंट सबसिस्टम के रूप में Next.js 16.0.7 App Router स्टैक (“next + react) में चलाता है, जहाँ लेख प्रकाशन रनटाइम कोड पथ का हिस्सा होता है, न कि अलग ऑफ़लाइन वर्डिंग चरण का। लेख-कार्य पथ पर ही सभी प्रतिबंध लागू किए जाने चाहिए: कोई लेख तब तक “लिखा” नहीं होता जब तक स्रोत रिकॉर्ड मौजूद न हों, सारांश संरचना सत्यापित न हो, और HTML को materialize न किया गया हो।

स्टैक का यह संरेखण उद्देश्यपूर्ण है:

next@16.0.7 + React Server Components जॉब-ट्रिगर रेंडरिंग को server space में होस्ट करते हैं, जो लेखों के लिए server-side आउटपुट अनुबंधों से मेल खाते हैं।
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 टाइप किए गए, स्थायी जॉब और स्रोत तालिकाएँ परिभाषित करते हैं ताकि हर दावा ट्रेस किया जा सके।
ai@6.0.0-beta.105 जेनरेशन को schema-aware आउटपुट नियंत्रण प्रदान करता है।
marked@17.0.1 उत्पन्न Markdown सारांशों को प्रकाशन के लिए render की गई HTML में बदलता है।
@vercel/blob@2.0.0 उत्पन्न assets को पुनः उपयोग के लिए टिकाऊ URLs के रूप में सहेजता है।
Anthropic उपकरणों को इसी अनुबंध envelope के भीतर वैकल्पिक मॉडल प्रदाता के रूप में जोड़ा जा सकता है, लेकिन structured प्रतिबंधों से बचने के लिए escape hatch के रूप में नहीं।

यह “पहले बनाओ फिर प्रूफरीड करो” मॉडल को बदल देता है, जिससे बनता है grounded लेखन लूप: retrieval, validation, generation, rendering और publish—ये सभी पास होने के बाद ही लेख दिखाई देता है।

तकनीकी तंत्र

एक मजबूत Naly डिज़ाइन में पाँच सीमित चरण हैं:

साक्ष्य योजना और query orchestration

नौकरी विनिर्देशन को विषय, तिथि सीमा और evidence नीति के साथ परिभाषित करें।
प्राथमिक स्रोतों के लिए वेब खोज और arXiv खोज दोनों चलाएँ।
canonical URL के आधार पर deduplicate करें और प्रोटोकॉल, होस्ट तथा query string का normalization करें।

स्रोत स्थिरता परत

प्रति-URL मेटाडेटा सहेजें (url, canonicalized URL, fetch status, fetch timestamp, शीर्षक, अंश, स्रोत प्रकार)।
मॉडल-facing स्निपेट को raw payload से अलग रखें ताकि अपस्ट्रीम पृष्ठ बदलने पर भी re-runs deterministic रहें।
प्रति स्रोत चेकसम जोड़कर drift का पता लगाएँ।

संदर्भ निर्माण और प्रतिबंध

relevance और recency के क्रम में retrieval संदर्भ बनाएं।
prompt contract में स्पष्ट स्रोत IDs आवश्यक करें।
answer-first आउटपुट आकार को बाध्य करें (intro claim, evidence bullets, risk caveats, uncertainty), साथ में क्रमबद्ध स्रोत संदर्भ।

कठोर स्कीमा के साथ structured generation

structured output का उपयोग करें ताकि गलत या schema-violating प्रतिक्रियाएँ तुरंत fail हों और कड़े संदर्भ के साथ retry किया जाए।
generation को server संदर्भ में रखें और ऐसे ड्राफ्ट को अस्वीकार करें जो बिना मैप किए स्रोत IDs के समर्थनहीन तथ्य दावा करते हैं।

रेंडर, प्रकाशन और सत्यापन

मान्य markdown को HTML में बदलें और markdown + HTML दोनों को स्थायी रखें।
सफल सत्यापन के बाद ही अंतिम आउटपुट को cache करें।
स्रोत गणना, अस्वीकृत दावे, retry count और generation latency जैसी analytics और audit फ़ील्ड emit करें।

सबसे महत्वपूर्ण डिज़ाइन परिवर्तन है जिम्मेदारियों का पृथक्करण: retrieval गुणवत्ता और generation गुणवत्ता अलग विफलता डोमेन हैं और उनके अलग-अलग मेट्रिक्स होते हैं। Next.js Server Components इस विभाजन के अनुकूल हैं क्योंकि rendering निर्धार्य रह सकता है, जबकि retrieval और generation नियंत्रित async tasks में होते हैं।

साहित्य क्या कहता है

हालिया RAG साहित्य इस वास्तुकला पैटर्न का समर्थन करता है। 2024 के एक RAG architecture सर्वेक्षण में बताया गया कि retrieval-augmented systems बाहरी साक्ष्यों पर generation को condition करके तथ्यात्मक drift कम करते हैं, लेकिन pipeline complexity और modular coordination में trade-offs भी दर्शाते हैं [Gupta et al., 2024]। 2025 के एक follow-up survey में कहा गया है कि robustness अब adaptive retrieval, decoding control और end-to-end evaluation पर निर्भर करती है, केवल generation quality पर नहीं [Sharma, 2025]।

Production quality control के लिए 2025 के evaluation-focused survey में मूल्यांकन को internal retriever/generator metrics और external system metrics में स्पष्ट विभाजित किया गया है; यह विभाजन विशेष रूप से लेख pipelines के लिए उपयोगी है क्योंकि “खराब लेख” का अर्थ यह भी हो सकता है कि भाषा गुणवत्ता अच्छी होने पर भी स्रोत चयन गलत हो [Gan et al., 2025]। साक्ष्य-आधारित कार्य भी ऐसे detection layers की ओर बढ़ा है जो retrieved संदर्भ और NLI-style checks से claim support का वर्गीकरण करते हैं, जिससे पोस्ट-जेनरेशन validation का व्यावहारिक मूल्य मजबूत होता है [Gerner et al., 2025]।

संक्षेप में, ये papers एक ही thesis पर मिलते हैं: RAG केवल context डालने का तरीका नहीं है, यह है इंजीनियरिंग अनुबंध retrieval और generation के बीच। इसलिए Naly को केवल prompt नहीं, बल्कि अनुबंध को ऑप्टिमाइज़ करना चाहिए।

डिज़ाइन trade-offs

ताज़गी बनाम निर्धारणीयता: कठोर TTLs से staleness कम होती है लेकिन re-fetch लागत बढ़ती है। snapshots को persist करने से आप deterministic rendering बनाए रखते हुए भी ताज़गी विंडो का revalidation कर सकते हैं।
retrieval में recall बनाम precision: व्यापक retrieval coverage बढ़ा सकता है लेकिन noise डालता है; दूसरा-stage relevance filter दावों की गुणवत्ता की सुरक्षा करता है।
स्कीमा कठोरता बनाम prose fluency: कठोर output schemas मशीन विश्वसनीयता सुधारते हैं लेकिन शैलीगत स्वतंत्रता घटा सकते हैं। answer-first schema pattern पठनीयता बनाए रखते हुए guardrails देता है।
स्थिर rendering गति बनाम auditability: pre-rendered HTML वितरण प्रदर्शन बेहतर करती है और बार-बार compute खर्च घटाती है, लेकिन तभी जब उपयोग किए गए स्रोत आर्टिफैक्ट स्थायी संदर्भ हों।
जटिलता बनाम operations लागत: प्रत्येक अतिरिक्त validation चरण (स्रोत जांच, स्कीमा जांच, artifact persistence) विलंब जोड़ता है। Next production guidance में caching, route boundaries और build-time verification पर ध्यान रखना इसे ऑपरेशनल रूप से संभालने के लिए आवश्यक है।

विफलता मोड

स्रोत drift: जॉब निर्माण के बाद URLs पर 404/soft changes लौट आते हैं। शमन: canonical key + snapshot hash + fallback source chain।
retrieval overreach: कम precision के साथ उच्च recall, विश्वसनीय पर असमर्थित संश्लेषण पैदा कर सकता है। शमन: evidence-first प्रतिबंध लागू करें और बिना स्रोत मैच के दावों को ब्लॉक करें।
मॉडल formatting failure: जेनरेशन से schema mismatch या truncated JSON। शमन: कठोर schema validation और छोटे संदर्भ के साथ retry।
डबल-पब्लिश racesसमानांतर workers आंशिक आर्टिफैक्ट publish कर सकते हैं। शमन: job idempotency keys, row-level state transitions (pending -> drafting -> validated -> published).
रेंडरिंग regressions: गलत markdown या असुरक्षित HTML transforms। शमन: deterministic marked conversion path और sample manifests से जुड़े HTML output परीक्षण।
Cache illusions: server आउटपुट में stale dynamic data स्रोत और अनुक्रमांक में असंगति पैदा कर सकता है। शमन: रूट रेंडरिंग रणनीति को स्पष्ट runtime freshness policy के साथ संरेखित करें और जहाँ evidence freshness जरूरी हो वहाँ implicit cache से बचें।

कार्यान्वयन नोट्स

व्यावहारिक रोलआउट के लिए इसे एक publication contract contract की तरह लें:

Drizzle में स्रोत तालिकाएँ स्पष्ट constraints के साथ परिभाषित करें: canonical host/path के हिसाब से URL अनन्यता, fetch status enums, और checksum कॉलम।
Neon-compatible driver path का उपयोग serverless execution व्यवहार के साथ सुसंगत रूप से करें; Drizzle docs दोनों runtime-specific और neon-* driver विकल्पों का वर्णन करती हैं।
जेनरेशन में structured output contract लागू करें और render करने से पहले अमान्य ऑब्जेक्ट पर fail करें।
Next.js उत्पादन मार्गदर्शन का उपयोग server boundaries, error pages, caching और लेख routes के लिए SEO metadata में करें ताकि प्रकाशन दृश्य और तेज बना रहे।
Vercel Blob के माध्यम से उत्पन्न blobs (जैसे cover images, attachments, exports) को स्पष्ट access policy और deterministic naming के साथ संग्रहित करें ताकि collisions न हों।
प्रकाशन से पहले ऑपरेशनल checks emit करें: न्यूनतम स्रोत गणना, न्यूनतम स्रोत विविधता, evidence freshness और मैप किए गए दावों की न्यूनतम completion दर।

यह मुख्य बदलाव है: लेख अब मॉडल की चालाकी से नहीं आँका जाता; इसे इसलिए आँका जाता है कि retries और redeploys के बीच साक्ष्य और जेनरेशन कितने समकालिक बने रहते हैं।