Naly इंजीनियरिंग नोट्स: स्थायी स्रोतों के साथ पुनर्प्राप्ति-संवर्धित लेख लेखन

सार

पुनर्प्राप्ति-संवर्धित जनरेशन Naly की article pipeline को ऐसी research memory देता है जो केवल model weights की तुलना में अधिक ताज़ा और अधिक ऑडिट-योग्य होती है। प्रत्येक engineering note या market-intelligence article job के लिए, सिस्टम web और arXiv खोज सकता है, generated artifact के साथ source URLs रख सकता है, model से पहले उत्तर देने को कह सकता है, और परिणाम को HTML के रूप में render कर सकता है। मुद्दा automation अपने-आप में नहीं है; मुद्दा ऐसे दावे प्रकाशित करना है जिन्हें पाठक trace कर सकें।

थीसिस सरल है: article writing के लिए RAG को chatbot pattern नहीं, बल्कि production evidence system की तरह माना जाना चाहिए। chatbot को कमजोर उत्तर के लिए माफ किया जा सकता है; published article एक टिकाऊ trust surface बन जाता है। इसलिए Naly के implementation को तीन invariants चाहिए: drafting से पहले retrieval, publication के बाद भी बने रहने वाले source records, और ऐसा renderer जो readable Markdown को सुरक्षित रखते हुए unsafe HTML से बचता हो।

यह Naly में कहाँ बैठता है

Naly article jobs research acquisition और public publishing के बीच बैठते हैं। job एक selected topic से शुरू होता है, search intents बनाता है, web और arXiv material fetch करता है, results को source records में normalize करता है, और फिर model से उस bounded evidence set से answer-first article लिखने को कहता है। output केवल prose नहीं है। यह एक bundle है: Markdown content, rendered HTML, source URLs, source titles, source kinds, और इतना metadata कि समझाया जा सके कि हर source क्यों इस्तेमाल हुआ।

यह Naly के trust loop के लिए मायने रखता है। Naly का व्यापक editorial posture वह प्रकाशित करना है जिसे दूसरे छिपाते हैं: decision memos, calibration limits, failures, और claims के पीछे का evidence। Source-backed generation इस posture को operational बनाता है। पाठकों को यह अनुमान नहीं लगाना चाहिए कि कोई statement model के training data, official document, paper, या operator assertion से आया है।

RAG layer drafting के बाद नहीं, उससे पहले होनी चाहिए। Post-hoc citation attachment कमजोर है क्योंकि model पहले ही claims बना चुका होता है। मजबूत design में retrieval generation context को constrain करता है, और generation ऐसे claims बनाता है जिन्हें retrieved set के विरुद्ध check किया जा सकता है। visible article concise रह सकता है, लेकिन stored artifact को research trail बनाए रखना चाहिए।

तकनीकी तंत्र

Article writing के लिए, Naly का RAG flow एक batch pipeline है:

Topic selection एक bounded research question बनाता है, जैसे retrieval-augmented generation source-backed article writing को कैसे ground करता है।
Query planning उस question को web queries, official-document queries, और arXiv queries में expand करता है।
Retrieval official documentation, primary papers, और high-signal explanatory sources इकट्ठा करता है।
Normalization title, canonical URL, source kind, उपलब्ध होने पर publication या update context, और relevant snippets या abstracts extract करता है।
Source persistence generation से पहले URL ledger store करता है ताकि article को बाद में audit किया जा सके।
Prompt assembly model को topic, Naly-specific implementation facts, writing constraints, और retrieved evidence देता है।
Generation answer-first abstract, explicit failure modes, और references section के साथ Markdown बनाता है।
Validation check करता है कि rendered article में हर reference stored source object से map होता है।
Rendering Markdown को site के लिए HTML में convert करता है, साथ ही sanitization और production checks लागू करता है।

यह Vercel के RAG guide में बताए गए retrieval और augmented-generation pattern के करीब है: पहले relevant context retrieve करें, फिर generation से पहले उसे user या job question के साथ combine करें। फर्क यह है कि Naly conversational support के लिए optimize नहीं कर रहा। वह durable publication के लिए optimize कर रहा है, जहाँ source URL article के data model का हिस्सा है।

AI SDK इस तरह के job के लिए natural orchestration layer है क्योंकि इसका text-generation interface non-interactive automation, tool calls, multi-step results, और providers द्वारा URL sources लौटाने पर source metadata को support करता है। जब provider native source objects नहीं लौटाता, तब भी Naly article artifact से अपनी retrieved-source list attach कर सकता है और model-native sources को authoritative के बजाय supplemental मान सकता है।

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

Lewis et al. द्वारा मूल RAG formulation ने core problem को ठीक तरह frame किया: parametric language models facts को weights में store करते हैं, लेकिन उस knowledge को update करना और provenance देना कठिन रहता है। उनके retrieval-augmented model ने sequence model को dense vector index के साथ combine किया और knowledge-intensive tasks पर parametric-only baseline की तुलना में अधिक specific, diverse, और factual generation पाया।

Gao et al. का बाद का RAG survey इस idea को taxonomy में generalize करता है: naive RAG, advanced RAG, और modular RAG। Naly की article pipeline modular होनी चाहिए। Retrieval, ranking, source persistence, prompt construction, generation, reference validation, और rendering अलग-अलग units हैं जिनके failure modes अलग हैं। इन्हें अलग units की तरह treat करने से system को debug करना आसान होता है, जब कोई article कमजोर source cite करता है या बेहतर source miss कर देता है।

Self-RAG एक महत्वपूर्ण सावधानी जोड़ता है। Asai et al. तर्क देते हैं कि retrieval की जरूरत हो या न हो, fixed number of passages retrieve करना output quality को degrade कर सकता है। Naly के लिए इसका मतलब है कि top-k retrieval कोई ritual नहीं होना चाहिए। stable framework feature पर छोटा article official docs और एक paper से काम चला सकता है; literature-heavy article को कई arXiv sources और survey की जरूरत हो सकती है। Retrieval depth claim risk के अनुसार चलनी चाहिए।

RAGChecker evaluation lesson देता है। Ru et al. तर्क देते हैं कि RAG systems को retrieval और generation दोनों में fine-grained diagnostics चाहिए, खासकर long-form responses के लिए। Naly के लिए evaluation की unit केवल article quality नहीं होनी चाहिए। इसमें retrieval recall, source relevance, claim support, reference coverage, और यह शामिल होना चाहिए कि unsupported claims final Markdown में घुस तो नहीं गए।

Design trade-offs

High recall बनाम low noise केंद्रीय trade-off है। अधिक retrieval सही source खोजने की संभावना बढ़ाता है, लेकिन यह भी संभावना बढ़ाता है कि कमजोर snippets prompt में प्रवेश करें और model को steer करें। Naly को staged approach पसंद करनी चाहिए: broad collection, strict filtering, फिर compact prompt context।

Source persistence auditability सुधारता है, लेकिन storage और maintenance work भी बनाता है। URLs drift करते हैं, papers revise होते हैं, और documentation pages move होती हैं। durable record में canonical URL, fetched timestamp, title, source type, और ideally content digest या excerpt boundary शामिल होनी चाहिए। इससे Naly model error और changed source में फर्क कर सकता है।

Answer-first writing reader value सुधारता है, लेकिन uncertainty को बहुत aggressively compress कर सकता है। article को conclusion से lead करना चाहिए, साथ ही failure modes और caveats के लिए बाद का section बचाकर रखना चाहिए। answer-first summary entry point है; यह evidence को flatten करने का license नहीं है।

Rendered HTML distribution और reading experience सुधारता है, लेकिन security boundary बनाता है। Marked Markdown parsing के लिए fast और useful है, लेकिन उसका documentation साफ चेतावनी देता है कि वह output HTML sanitize नहीं करता। Naly article renderer को generated HTML sanitize करना चाहिए और replay के लिए trusted Markdown source उपलब्ध रखना चाहिए।

Failure modes

Retrieval miss: search step plausible लेकिन incomplete sources खोजता है। यह आमतौर पर तब होता है जब query planner बहुत narrow होता है या ऐसे product terms इस्तेमाल करता है जो literature से अलग होते हैं। Mitigation: multiple query styles इस्तेमाल करें, official docs शामिल करें, और जब article research claims करता है तो कम से कम दो primary या arXiv sources की मांग करें।

Citation laundering: कोई source references में दिखाई देता है, लेकिन वह उसके पास वाले sentence को वास्तव में support नहीं करता। यह no citation से भी खराब है क्योंकि यह false confidence बनाता है। Mitigation: claims को source snippets के विरुद्ध validate करें और उन articles को reject करें जहाँ references केवल topical हों।

Stale source drift: publication के बाद official documentation page बदल जाता है। Mitigation: generation time पर source metadata persist करें और date label record करें। major claims चलाने वाले sources के लिए, licensing अनुमति दे तो snapshot या digest store करें।

Over-retrieval: बहुत सारे chunks model को article thesis का answer देने के बजाय context summarize करने पर मजबूर कर देते हैं। Mitigation: source ranking इस्तेमाल करें, near-identical documents deduplicate करें, और prompt evidence को raw count के बजाय claim relevance से cap करें।

Context poisoning: spam pages, generated SEO pages, या low-quality summaries primary material से ऊपर rank कर जाते हैं। Mitigation: official documentation, arXiv, standards, और source repositories को secondary commentary से ऊपर rank करें, जब तक article स्पष्ट रूप से industry reception के बारे में न हो।

Renderer risk: generated Markdown में raw HTML, unsafe links, या malformed tables शामिल हो सकते हैं। Mitigation: rendered HTML sanitize करें, links normalize करें, scriptable content reject करें, और performance, security, metadata, और accessibility पर Next.js guidance के अनुरूप production checks चलाएँ।

Implementation notes

Naly के current runtime facts को देखते हुए, clean architecture एक TypeScript job है जो इस्तेमाल करता है ai@6.0.0-beta.105 model orchestration के लिए, evidence collection के लिए web और arXiv retrieval tools, article और source records के लिए Neon के साथ Drizzle ORM, marked@17.0.1 Markdown-to-HTML rendering के लिए, और publishing surface के लिए Next.js 16।

Database को sources को first-class rows की तरह treat करना चाहिए, Markdown text के blob की तरह नहीं। practical schema में article table, article-source join table, और URL, title, source kind, retrieved timestamp, उपलब्ध होने पर arXiv ID जैसा canonical identifier, और extraction status के लिए source fields होते हैं। article record फिर Markdown, rendered HTML, summary, key points, और publication metadata की ओर point कर सकता है।

Vercel Blob larger artifacts या immutable render outputs के लिए उपयोगी है, जबकि Postgres sources और article metadata के queryable ledger के रूप में बेहतर रहता है। यह separation audit queries को cheap रखता है: हर article list करें जिसने source इस्तेमाल किया, हर source list करें जो article ने इस्तेमाल किया, और हर article list करें जिसका source extraction failed हुआ।

Generator prompt को output के shape में source discipline मांगना चाहिए: no unsupported claims, no invented URLs, और references section जिसके links persisted source list से match होने चाहिए। model fluid prose लिख सकता है, लेकिन job को source truth own करना चाहिए। अगर model ऐसा reference emit करता है जो retrieve नहीं हुआ था, तो validator को article fail करना चाहिए, न कि चुपचाप publish।

अंत में, production behavior मायने रखता है। Next.js पहले से server components, code splitting, prerendering, और caching defaults देता है, लेकिन generated content pipelines को फिर भी explicit error handling, security checks, metadata, और Core Web Vitals awareness चाहिए। RAG Naly को evidence के साथ लिखने में मदद करता है। Production engineering सुनिश्चित करती है कि evidence पाठकों तक तेज़ी से, सुरक्षित रूप से, और बार-बार पहुँचे।