Blog

Retrieval-augmented generation for source-backed article writing

Naly ইঞ্জিনিয়ারিং নোট: স্থায়ী ও নিরীক্ষাযোগ্য প্রকাশনার জন্য সূত্র-প্রথম RAG নিবন্ধ খসড়া পদ্ধতি

এই নোটে একটি প্রোডাকশন স্থাপত্য ব্যাখ্যা করা হয়েছে যেখানে রিট্রিভাল একটি প্রথম-শ্রেণির কন্ট্রোল প্লেন, প্রম্পট-টাইমের একটি ইঙ্গিত নয়। Naly-এর নিবন্ধ জবগুলো ওয়েব ও arXiv প্রমাণ সংগ্রহ করে, স্বাভাবিকীকৃত উৎস তথ্য স্থায়ীভাবে সংরক্ষণ করে এবং HTML রেন্ডার করার আগে কাঠামোবদ্ধ ও নিরীক্ষাযোগ্য চুক্তির মাধ্যমে মডেল আউটপুটকে বাধ্যতামূলকভাবে চালায়, যাতে নিবন্ধগুলো প্রমাণভিত্তিক থাকে re

June 27, 202610 sources

TL;DRরিট্রিভাল-সহায়ক জেনারেশন (RAG) Naly-এর নিবন্ধ পাইপলাইনকে মডেল-মেমরি কম্পোজিশনের বদলে সূত্র-ভিত্তিক প্রকাশনা সিস্টেমে রূপান্তর করে। প্রতিটি খসড়া অনুরোধ প্রথমে ওয়েব ও arXiv প্রমাণ সংগ্রহ করে, URL স্বাভাবিকীকরণ ও স্থায়ীভাবে সংরক্ষণ করে এবং তারপর মডেলকে উত্তর-প্রথম খসড়া ও চূড়ান্ত HTML নিবন্ধ তৈরির অনুরোধ জানায়। এতে ঝুঁকি সরে যায় “মডেল কি হ্যালুসিনেট করবে?” থেকে “রিট্রিভাল স্তরটি কি সম্পূর্ণ ও ট্রেসযোগ্য?”—যেখানে সম্পাদকরা পান স্থিতিশীল আর্টিফ্যাক্ট, পুনরায় চালানো যায় এমন জব এবং প্রতিরক্ষাযোগ্য জনসম্মুখ দাবির কাঠামো।

সারসংক্ষেপ

Naly-তে RAG নকশা করা উচিত সূত্র স্থায়িত্ব ও নির্ধারিত কনট্র্যাক্ট. জুন ২৭, ২০২৬, ব্যবহারিক নির্ভরযোগ্যতা বড় মডেল থেকে কম এবং প্রকাশের আগে রিট্রিভাল আর্টিফ্যাক্টগুলো প্রশ্নযোগ্য, ভার্সন করা এবং যাচাই করা হয়েছে কি না—তা থেকে বেশি নির্ভর করে। এই নোটে দ্বৈত-প্লেন নকশা প্রস্তাব করা হয়েছে: রিট্রিভাল/সংরক্ষণ-এর জন্য একটি প্রমাণ প্লেন এবং ড্রাফটিং-এর জন্য একটি জেনারেশন প্লেন, তারপর দেখানো হয়েছে এই স্থাপনা কীভাবে সরাসরি সম্পাদনা আস্থা ও ঘটনার প্রতিক্রিয়া ব্যবস্থাপনাকে উন্নত করে।

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

Naly এটি একটি প্রোডাকশন কনটেন্ট সাবসিস্টেম হিসেবে Next.js 16.0.7 App Router স্ট্যাকের মধ্যে চালায় (next + react), যেখানে নিবন্ধ প্রকাশ আলাদা অফলাইন লিখন ধাপ নয়, বরং রানটাইম কোড পাথের অংশ। নিবন্ধ-জবের পথেই সব সীমাবদ্ধতা প্রয়োগ করতে হবে: উৎস রেকর্ড না থাকলে জব “লিখিত” হয় না, সারাংশের কাঠামো ভ্যালিডেট হওয়া দরকার, এবং HTML বাস্তবায়িত হতে হবে।

স্ট্যাকের এই সামঞ্জস্যটি উদ্দেশ্যপূর্ণ:

  • next@16.0.7 + React Server Components সার্ভার স্পেসে জব-ট্রিগারড রেন্ডারিং হোস্ট করে, যা নিবন্ধের জন্য সার্ভার-সাইড আউটপুট কনট্র্যাক্টের সাথে সামঞ্জস্যপূর্ণ।
  • drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 টাইপ করা, স্থায়ী জব ও উৎস টেবিল নির্ধারণ করে যাতে প্রতিটি দাবির উৎস ট্রেস করা যায়।
  • ai@6.0.0-beta.105 স্কিমা-সচেতন আউটপুট নিয়ন্ত্রণের মাধ্যমে জেনারেশনকে চালিত করে।
  • marked@17.0.1 প্রজন্মিত Markdown সারাংশকে প্রকাশনার জন্য রেন্ডারকৃত HTML-এ রূপান্তর করে।
  • @vercel/blob@2.0.0 পুনঃব্যবহারের জন্য উৎপন্ন অ্যাসেটগুলোকে স্থায়ী URL হিসেবে সংরক্ষণ করে।
  • Anthropic টুলিং একই কনট্র্যাক্ট এনভেলোপের মধ্যে বিকল্প মডেল প্রোভাইডার হিসেবে যোগ করা যায়, কিন্তু কাঠামোগত সীমাবদ্ধতার বাইপাস হিসেবে নয়।

এটি একটি “generate then proofread” মডেলকে বদলে দেয় একটি ভিত্তিভিত্তিক লিখন লুপএর সাথে: রিট্রিভাল, যাচাই, জেনারেশন, রেন্ডারিং ও প্রকাশ—নিবন্ধ দৃশ্যমান হওয়ার আগে সবগুলোই পাস হতে হবে।

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

একটি মজবুত Naly নকশায় পাঁচটি সীমাবদ্ধ ধাপ থাকে:

  1. প্রমাণ পরিকল্পনা এবং কোয়েরি অর্কেস্ট্রেশন
  • বিষয়, তারিখের উইন্ডো ও প্রমাণ নীতি দিয়ে জব স্পেসিফিকেশন নির্ধারণ করুন।
  • প্রাথমিক উৎসের জন্য ওয়েব সার্চ ও arXiv সার্চ দুটিই চালান।
  • ক্যাননিক্যাল URL দ্বারা ডুপ্লিকেট সরান এবং প্রোটোকল, হোস্ট ও কোয়েরি স্ট্রিং স্বাভাবিকীকরণ করুন।
  1. সূত্র স্থায়িত্ব স্তর
  • প্রতি-URL মেটাডেটা সংরক্ষণ করুন (urlক্যাননিক্যালাইজড URL, ফেচ স্ট্যাটাস, ফেচ টাইমস্ট্যাম্প, শিরোনাম, উদ্ধৃতাংশ, উৎসের ধরন)।
  • কাঁচা পে-লোড থেকে মডেলের সামনে ব্যবহৃত স্নিপেট আলাদা করে সংরক্ষণ করুন যাতে আপস্ট্রিম পৃষ্ঠা পরিবর্তিত হলেও রি-রান নির্ধারিত থাকে।
  • ড্রিফট শনাক্ত করতে প্রতি-উৎস চেকসাম যোগ করুন।
  1. প্রসঙ্গ গঠন ও সীমা নির্ধারণ
  • প্রাসঙ্গিকতা ও সাম্প্রতিকতার ভিত্তিতে রিট্রিভাল প্রসঙ্গ সাজান।
  • প্রম্পট কনট্র্যাক্টে স্পষ্ট উৎস ID বাধ্যতামূলক করুন।
  • উত্তর-প্রথম আউটপুট আকার বাধ্যতামূলক করুন (intro claim, evidence bullets, risk caveats, uncertainty), সাথে क्रमবদ্ধ সূত্র রেফারেন্স।
  1. কঠোর স্কিমা-সহ গঠনমূলক জেনারেশন
  • কাঠামোবদ্ধ আউটপুট ব্যবহার করুন যাতে ভুল ফরম্যাট বা স্কিমা-লঙ্ঘনকারী সাড়া দ্রুত ব্যর্থ হয়ে সংকুচিত প্রসঙ্গে আবার চেষ্টা করে।
  • জেনারেশনকে সার্ভার কনটেক্সটে রাখুন এবং যে খসড়া উৎস ID-র সাথে ম্যাপ করা দাবি ছাড়া তথ্য দেয় তা বাতিল করুন।
  1. রেন্ডার, প্রকাশ ও যাচাই
  • যাচাইকৃত Markdown-কে HTML-এ রূপান্তর করুন এবং Markdown + HTML উভয়ই স্থায়ীভাবে সংরক্ষণ করুন।
  • শুধু সফল যাচাইয়ের পর চূড়ান্ত আউটপুট ক্যাশ করুন।
  • অ্যানালিটিক্স ও নিরীক্ষার ফিল্ড প্রকাশ করুন: উৎসের সংখ্যা, বাতিল দাবির সংখ্যা, পুনরায় চেষ্টা সংখ্যা এবং জেনারেশন লেটেন্সি।

সবচেয়ে গুরুত্বপূর্ণ নকশাগত পরিবর্তন হলো দায়বদ্ধতার পৃথকীকরণ: রিট্রিভাল গুণমান ও জেনারেশন গুণমান দুটি ভিন্ন ব্যর্থতা-ক্ষেত্র, প্রতিটির মেট্রিক আলাদা। Next.js Server Components এই বিভাজনের সাথে সামঞ্জস্যপূর্ণ কারণ রেন্ডারিং নির্ধারিত থাকতে পারে, আর রিট্রিভাল ও জেনারেশন থাকে নিয়ন্ত্রিত অ্যাসিঙ্ক টাস্কে।

সাহিত্য কী বলে

সাম্প্রতিক RAG গবেষণা এই স্থাপত্য প্যাটার্নকে সমর্থন করে। ২০২৪ সালের একটি RAG স্থাপত্য সমীক্ষা দেখায় যে রিট্রিভাল-অগমেন্টেড সিস্টেম বাহ্যিক প্রমাণের ওপর জেনারেশন নির্ভর করে ফ্যাক্ট ড্রিফট কমায়, তবে পাইপলাইনের জটিলতা ও মডিউলার সমন্বয়ে বাণিজ্যিক খরচ বাড়ার কথাও উল্লেখ করে [Gupta et al., 2024]। ২০২৫ সালের একটি ফলো-আপ সমীক্ষায় বলা হয়েছে যে এখন দৃঢ়তা নির্ভর করে অভিযোজিত রিট্রিভাল, ডিকোডিং কন্ট্রোল এবং এন্ড-টু-এন্ড মূল্যায়নের ওপর, শুধু জেনারেশন গুণমানের ওপর নয় [Sharma, 2025]।

উৎপাদনগত গুণনিয়ন্ত্রণের জন্য ২০২৫ সালের মূল্যায়ন-কেন্দ্রিক সমীক্ষা স্পষ্টভাবে মূল্যায়নকে অভ্যন্তরীণ রিট্রিভার/জেনারেটর মেট্রিক ও বাহ্যিক সিস্টেম মেট্রিকে ভাগ করেছে; এই বিভাজন নিবন্ধ পাইপলাইনের জন্য বিশেষভাবে কার্যকর, কারণ ভাষার গুণগত মান ভালো হলেও “খারাপ নিবন্ধ” মানে ভুল উৎস নির্বাচন হতে পারে [Gan et al., 2025]। উৎসভিত্তিক কাজও এখন রিট্রিভ করা প্রসঙ্গ ও NLI-ধাঁচের পরীক্ষার মাধ্যমে দাবির সমর্থন শ্রেণিবিন্যাস করা ডিটেকশন স্তরের দিকে যাচ্ছে, যা পোস্ট-জেনারেশন ভ্যালিডেশনের বাস্তবিক গুরুত্বকে শক্তিশালী করে [Gerner et al., 2025]।

সংক্ষেপে, গবেষণাগুলো একটিমাত্র ধারণায় মিলিত হয়: RAG শুধুই প্রসঙ্গ ঢোকানোর উপায় নয়, এটি একটি প্রকৌশলগত চুক্তি রিট্রিভাল ও জেনারেশনের মধ্যে। তাই Naly-কে শুধু প্রম্পট নয়, এই চুক্তি অপ্টিমাইজ করতে হবে।

নকশা বাণিজ্য

  • নতুনত্ব বনাম নির্ধারিত আচরণ: কঠোর TTL পুরনো ডাটা কমায় কিন্তু পুনরায় ফেচিংয়ের খরচ বাড়ায়। স্ন্যাপশট স্থায়ীভাবে রেখে আপনি নির্ধারিত রেন্ডারিং বজায় রেখে ফ্রেশনেস উইন্ডো আবার যাচাই করতে পারেন।
  • রিট্রিভালে রিকল বনাম প্রিসিশন: বিস্তৃত রিট্রিভাল কভারেজ বাড়াতে পারে কিন্তু শব্দ ও বেশি ডাটা ঢোকে; দ্বিতীয় স্তরের প্রাসঙ্গিকতা ফিল্টার দাবির গুণগত মান রক্ষা করে।
  • স্কিমা কঠোরতা বনাম পাঠ্য প্রবাহের স্বাভাবিকতা: কঠোর আউটপুট স্কিমা যান্ত্রিক নির্ভরযোগ্যতা বাড়ায় কিন্তু শৈলীর স্বাধীনতা কমাতে পারে। উত্তর-প্রথম স্কিমা প্যাটার্ন পাঠযোগ্যতা ধরে রেখে গার্ডরেল রাখে।
  • স্থির রেন্ডারিং গতি বনাম নিরীক্ষাযোগ্যতা: পূর্ব-রেন্ডারকৃত HTML ডেলিভারি পারফরম্যান্স বাড়ায় এবং পুনরাবৃত্ত গণনা কমায়, কিন্তু শুধু তখনই যখন ব্যবহৃত উৎস আর্টিফ্যাক্টগুলো অপরিবর্তনীয় রেফারেন্স হয়।
  • জটিলতা বনাম অপারেশনাল খরচ: প্রতিটি অতিরিক্ত যাচাই ধাপ (উৎস পরীক্ষা, স্কিমা পরীক্ষা, আর্টিফ্যাক্ট স্থায়িত্ব) লেটেন্সি বাড়ায়। এটি চালু রাখতে ক্যাশিং, রাউট বাউন্ডারি এবং বিল্ড-টাইম যাচাই সংক্রান্ত পরবর্তী প্রোডাকশন নির্দেশনা গুরুত্বপূর্ণ।

ব্যর্থতার ধরন

  • উৎস ড্রিফট: জব তৈরির পরে URL 404/নরম পরিবর্তন দেখাতে পারে। প্রতিকার: ক্যাননিক্যাল কী + স্ন্যাপশট হ্যাশ + ফallback উৎস চেইন।
  • রিট্রিভাল অতিরিক্ত-প্রসার: কম প্রিসিশনের উচ্চ রিকল থেকে বিশ্বাসযোগ্য কিন্তু সমর্থনহীন সংশ্লেষ তৈরি হতে পারে। প্রতিকার: evidence-first সীমা বাধ্যতামূলক করুন এবং উৎস-ম্যাপ ছাড়া দাবিগুলো ব্লক করুন।
  • মডেল ফরম্যাটিং ব্যর্থতাস্কিমা মিসম্যাচ বা জেনারেশন থেকে JSON কাটা গেলে সমস্যা। প্রতিকার: কঠোর স্কিমা যাচাই এবং কমানো প্রসঙ্গে পুনরায় চেষ্টা।
  • ডাবল-পাবলিশ রেসএকাধিক ওয়ার্কার একইসাথে আংশিক আর্টিফ্যাক্ট প্রকাশ করতে পারে। প্রতিকার: জব আইডেম্পটেন্ট কীগুলো, রো-লেভেল স্টেট ট্রানজিশন (pending -> drafting -> validated -> published).
  • রেন্ডারিং রিগ্রেশন: ভুল Markdown বা অনিরাপদ HTML রূপান্তর। প্রতিকার: নির্ধারিত marked রূপান্তর পথ এবং নমুনা ম্যানিফেস্টের সাথে যুক্ত HTML আউটপুট টেস্ট।
  • ক্যাশ বিভ্রমসার্ভার আউটপুটে পুরনো ডাইনামিক ডাটা থাকলে প্রকাশিত টেক্সট ও উৎস সূচি মেলে না। প্রতিকার: রাউট রেন্ডারিং কৌশলকে স্পষ্ট রানটাইম ফ্রেশনেস নীতির সাথে সমন্বয় করুন এবং যেখানে প্রমাণ ফ্রেশ থাকা জরুরি সেখানে ইম্প্লিসিট ক্যাশ এড়িয়ে চলুন।

বাস্তবায়ন নোট

একটি বাস্তবধর্মী রোলআউটের জন্য এটিকে প্রকাশনা চুক্তি কাঠামো হিসেবে ধরুন:

  • Drizzle-এ টাইপ-নির্দিষ্ট, স্থায়ী জব ও উৎস টেবিল তৈরি করুন: ক্যাননিক্যাল হোস্ট/পাথ অনুযায়ী URL অনন্যতা, ফেচ স্ট্যাটাস এনাম, এবং চেকসাম কলাম।
  • Neon-সঙ্গত ড্রাইভার পাথ সার্ভারলেস এক্সিকিউশন আচরণের সাথে স্থিরভাবে ব্যবহার করুন; Drizzle নথিতে রানটাইম-নির্দিষ্ট ও neon-* ড্রাইভার অপশন দুটোই বর্ণনা করা আছে।
  • জেনারেশনে কাঠামোবদ্ধ আউটপুট চুক্তি কঠোরভাবে প্রয়োগ করুন এবং রেন্ডারের আগে অবৈধ অবজেক্টে ব্যর্থ করুন।
  • Next.js প্রোডাকশন গাইডলাইন ব্যবহার করে সার্ভার সীমা, এরর পেজ, ক্যাশিং এবং নিবন্ধ রুটের SEO মেটাডেটা নিশ্চিত করুন যেন প্রকাশনা পর্যবেক্ষণযোগ্য ও দ্রুত থাকে।
  • কভার ইমেজ, অ্যাটাচমেন্ট, এক্সপোর্টের মতো উৎপন্ন ব্লব Vercel Blob দিয়ে স্পষ্ট এক্সেস নীতি ও নির্ধারিত নামকরণ দিয়ে সংরক্ষণ করুন, যাতে সংঘর্ষ না হয়।
  • প্রকাশের আগে অপারেশনাল চেক চালান: ন্যূনতম উৎস সংখ্যা, ন্যূনতম উৎস বৈচিত্র্য, প্রমাণের ফ্রেশনেস, এবং ম্যাপড দাবির ন্যূনতম সম্পাদন হার।

এটাই মূল পরিবর্তন: নিবন্ধ আর মডেলের কৌশলগত বুদ্ধিমত্তা দিয়ে বিচার করা হয় না; বরং দেখা হয় রি-ট্রাই ও রিডেপ্লয়েও প্রমাণ ও জেনারেশন কতটা সমন্বিত থাকে।

উৎস তালিকা

Sources