Naly ইঞ্জিনিয়ারিং নোটস: স্থায়ীভাবে সংরক্ষিত উৎসসহ রিট্রিভাল-অগমেন্টেড নিবন্ধ রচনা

সারসংক্ষেপ

রিট্রিভাল-অগমেন্টেড জেনারেশন Naly-র নিবন্ধ পাইপলাইনকে এমন একটি গবেষণা স্মৃতি দেয়, যা শুধু মডেল weights-এর তুলনায় বেশি সতেজ এবং বেশি নিরীক্ষাযোগ্য। প্রতিটি engineering note বা market-intelligence article job-এর জন্য, সিস্টেমটি web এবং arXiv অনুসন্ধান করতে পারে, তৈরি artifact-এর সঙ্গে source URL রাখতে পারে, মডেলকে আগে উত্তর দিতে বলতে পারে, এবং ফলাফল HTML হিসেবে render করতে পারে। উদ্দেশ্য automation নিজেই নয়; উদ্দেশ্য এমন দাবি প্রকাশ করা, যা পাঠক অনুসরণ করে যাচাই করতে পারেন।

থিসিসটি সরল: নিবন্ধ লেখার জন্য RAG-কে chatbot pattern হিসেবে নয়, production evidence system হিসেবে দেখা উচিত। একটি chatbot দুর্বল উত্তরের জন্য ক্ষমাযোগ্য হতে পারে; প্রকাশিত নিবন্ধ হয়ে ওঠে স্থায়ী trust surface. তাই Naly-র implementation-এ তিনটি invariant দরকার: drafting-এর আগে retrieval, publication-এর পরেও টিকে থাকা source records, এবং এমন renderer যা readable Markdown সংরক্ষণ করে কিন্তু unsafe HTML এড়ায়।

Naly-তে এর অবস্থান

Naly article jobs গবেষণা সংগ্রহ এবং public publishing-এর মাঝখানে থাকে। job শুরু হয় নির্বাচিত topic দিয়ে, search intents তৈরি করে, web এবং arXiv material আনে, results-কে source records-এ normalize করে, তারপর সেই bounded evidence set থেকে answer-first article লেখার জন্য model-কে বলে। output শুধু prose নয়। এটি একটি bundle: Markdown content, rendered HTML, source URLs, source titles, source kinds, এবং প্রতিটি source কেন ব্যবহৃত হয়েছে তা ব্যাখ্যা করার মতো যথেষ্ট metadata.

এটি Naly-র trust loop-এর জন্য গুরুত্বপূর্ণ। Naly-র বিস্তৃত editorial posture হলো অন্যরা যা লুকায় তা প্রকাশ করা: decision memos, calibration limits, failures, এবং claims-এর পেছনের evidence. Source-backed generation সেই অবস্থানকে operational করে। কোনো statement model-এর training data, official document, paper, না operator assertion থেকে এসেছে, তা পাঠকদের অনুমান করতে হওয়া উচিত নয়।

RAG layer drafting-এর আগে থাকা উচিত, পরে নয়। post-hoc citation attachment দুর্বল, কারণ model ইতিমধ্যে claims গঠন করে ফেলেছে। শক্তিশালী design-এ retrieval generation context সীমিত করে, এবং generation এমন claims তৈরি করে যা retrieved set-এর বিরুদ্ধে check করা যায়। দৃশ্যমান article সংক্ষিপ্ত থাকতে পারে, কিন্তু stored artifact-এ research trail থাকা উচিত।

প্রযুক্তিগত প্রক্রিয়া

article writing-এর জন্য, Naly-র RAG flow একটি batch pipeline:

Topic selection একটি bounded research question তৈরি করে, যেমন retrieval-augmented generation কীভাবে source-backed article writing-কে grounded করে।
Query planning সেই question-কে web queries, official-document queries, এবং arXiv queries-এ প্রসারিত করে।
Retrieval official documentation, primary papers, এবং high-signal explanatory sources সংগ্রহ করে।
Normalization title, canonical URL, source kind, publication বা update context যখন available, এবং relevant snippets বা abstracts বের করে।
Source persistence generation-এর আগে URL ledger সংরক্ষণ করে, যাতে 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 দেখে যে rendered article-এর প্রতিটি reference একটি stored source object-এর সঙ্গে map করে কি না।
Rendering site-এর জন্য Markdown-কে 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-এর জন্য স্বাভাবিক 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.-এর original RAG formulation core problem-টি ভালোভাবে ধরেছিল: 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 ধারণাটিকে একটি taxonomy-তে generalize করে: naive RAG, advanced RAG, এবং modular RAG. Naly-র article pipeline modular হওয়া উচিত। Retrieval, ranking, source persistence, prompt construction, generation, reference validation, এবং rendering আলাদা failure modes সহ আলাদা units. এগুলোকে আলাদা units হিসেবে দেখলে কোনো article দুর্বল source cite করলে বা ভালো source মিস করলে system debug করা সহজ হয়।

Self-RAG একটি গুরুত্বপূর্ণ সতর্কতা যোগ করে। Asai et al. যুক্তি দেন যে retrieval দরকার হোক বা না হোক fixed number of passages retrieve করলে output quality কমতে পারে। 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-এ ঢুকে পড়েছে কি না, তা অন্তর্ভুক্ত হওয়া উচিত।

নকশাগত trade-offs

High recall versus low noise হলো central trade-off. বেশি retrieval সঠিক source খুঁজে পাওয়ার সম্ভাবনা বাড়ায়, কিন্তু weak snippets prompt-এ ঢুকে model-কে steer করার সম্ভাবনাও বাড়ায়। Naly-র staged approach পছন্দ করা উচিত: broad collection, strict filtering, তারপর compact prompt context.

Source persistence auditability বাড়ায়, কিন্তু storage এবং maintenance work-ও তৈরি করে। URLs drift করে, papers revised হয়, এবং documentation pages সরে যায়। durable record-এ canonical URL, fetched timestamp, title, source type, এবং ideal হলে content digest বা excerpt boundary থাকা উচিত। এতে Naly model error আর changed source আলাদা করতে পারে।

Answer-first writing reader value বাড়ায়, কিন্তু uncertainty অতিরিক্তভাবে compress করতে পারে। article conclusion দিয়ে শুরু করা উচিত, তবে পরে failure modes এবং caveats-এর জন্য section রাখতে হবে। answer-first summary entry point; এটি evidence flatten করার license নয়।

Rendered HTML distribution এবং reading experience উন্নত করে, কিন্তু এটি security boundary তৈরি করে। Marked Markdown parsing-এর জন্য দ্রুত এবং useful, কিন্তু এর documentation স্পষ্টভাবে সতর্ক করে যে এটি output HTML sanitize করে না। Naly article renderer-এর generated HTML sanitize করা উচিত এবং replay-এর জন্য trusted Markdown source available রাখা উচিত।

Failure modes

Retrieval miss: search step plausible কিন্তু incomplete sources খুঁজে পায়। এটি সাধারণত ঘটে যখন query planner খুব narrow হয় বা literature-এর থেকে ভিন্ন product terms ব্যবহার করে। Mitigation: multiple query styles ব্যবহার করুন, official docs অন্তর্ভুক্ত করুন, এবং article research claims করলে অন্তত দুইটি primary বা arXiv sources require করুন।

Citation laundering: references-এ একটি source দেখা যায়, কিন্তু সেটি কাছাকাছি sentence-কে আসলে support করে না। এটি no citation-এর চেয়েও খারাপ, কারণ এটি false confidence তৈরি করে। Mitigation: source snippets-এর বিরুদ্ধে claims validate করুন এবং references merely topical হলে articles reject করুন।

Stale source drift: publication-এর পর একটি official documentation page বদলে যায়। Mitigation: generation time-এ source metadata persist করুন এবং date label record করুন। major claims drive করে এমন sources-এর জন্য licensing অনুমতি দিলে snapshot বা digest store করুন।

Over-retrieval: খুব বেশি chunks model-কে article thesis-এর উত্তর দেওয়ার বদলে context summarize করতে বাধ্য করে। Mitigation: source ranking ব্যবহার করুন, near-identical documents deduplicate করুন, এবং raw count নয়, claim relevance অনুযায়ী prompt evidence cap করুন।

Context poisoning: spam pages, generated SEO pages, বা low-quality summaries primary material-এর ওপর rank করে। Mitigation: article industry reception নিয়ে না হলে secondary commentary-এর ওপরে official documentation, arXiv, standards, এবং source repositories rank করুন।

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-এর সঙ্গে consistent 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-কে Markdown text-এর blob নয়, first-class rows হিসেবে দেখা উচিত। practical schema-তে থাকে article table, article-source join table, এবং URL, title, source kind, retrieved timestamp, arXiv ID-এর মতো canonical identifier যখন available, এবং extraction status-এর source fields. article record তখন Markdown, rendered HTML, summary, key points, এবং publication metadata-র দিকে point করতে পারে।

Vercel Blob বড় artifacts বা immutable render outputs-এর জন্য useful, আর Postgres sources এবং article metadata-র queryable ledger হিসেবে বেশি ভালো। এই separation audit queries সস্তা রাখে: একটি source ব্যবহার করা every article, একটি article-এ ব্যবহৃত every source, এবং source extraction failed হওয়া every article list করা যায়।

generator prompt-এ output-এর shape-এ source discipline require করা উচিত: unsupported claims নয়, invented URLs নয়, এবং এমন references section যার links persisted source list-এর সঙ্গে match করতেই হবে। model fluid prose লিখতে পারে, কিন্তু source truth job-এর মালিকানায় থাকা উচিত। model যদি retrieve না করা reference emit করে, validator-এর article quietly publish করার বদলে fail করা উচিত।

শেষে, 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 দ্রুত, নিরাপদে, এবং বারবার পাঠকদের কাছে পৌঁছায়।